New post module to Load Powershell scripts into Powershell Session

[benpturner]

This new post module takes any powershell session type and allows a user to import-modules into the powershell session and use them locally. To implement this I have had to create a stager approach that has been added to the powershell mixin module. Anything over 20000 bytes gets staged and uploaded. This module only works for powershell sessions as stated in the module.

Additionally, @sempervictus made some changes to the powershell coding and wanted to merge into this PR.

[jvazquez-r7]

It's always useful to fill the Pull request description. Even when you can feel which the purpose of the pull request is obvious :).

It doesn't need to be a book or anything like that. Just a brief description of the pull request purpose, the changes done, verification steps and what to expect.

Normally it's easy for the author because it's just to share how you're testing your own new code :-)

And I really think it helps reviewers to handle pull request much faster (I'd say by others of magnitude! :) )

Thanks for your contribution!

[benpturner]

@jvazquez-r7 Sorry, i've been putting too many little changes up and should have waited, but I was quite impatient sharing with @davehardy20 to make sure we both tested this out. I will ensure I put full details on each request from now on. Thanks for you feedback

[sempervictus]

@benpturner: the boilerplate code in a lot of these PRs is already handled by libs internal Rex and Msf namespaces. Operations such as substitution, compression, etc, should be performed on a
Rex::Powershell::Script object (chunks of this module look to be adapted from our older work on PSH - we moved away from this because it creates a lot of redundant code).

I do see your stager has a different high-value limit than our default for CMD - i'll address this in a PR tonight which will allow us to pass a value to the script generator to create arbitrary size stages (and will allow you to call that with a value instead of the staging code here).

Basically @Meatballs1 and i have tried to make it so that Metasploit-level modules using Powershell are entirely focused on the "business logic" and all the PSH stuff happens neatly in the background. Although the business logic here is in itself working with powershell, i think the meat of this is the command execution calls you have at the bottom.

Great work by the way, rather handy to have these sessions and not rely on meterp as a shim. Thanks

[benpturner]

@sempervictus I'm not sure the stager you have would work in this example as we are not using a streamreader value we are just splitting a base64 encoded script into chunks for easier distribution to the powershell session not a meterpreter or shell session. I may be wrong, if you could point me in the right direction I'm happy to change.

[sempervictus]

I saw that when starting the PR last night and got to thinking that we might want to rework the staging process into two parts altogether:
1 - chunk the input into appropriate segments
2 - iterate over a list of encoder/decoder sets to encode and wrap the chunk in a decoder
3 - run through a selected stager (CMD/PSH/.NET/whatever) to push into the session.

Namespace-wise, i figure we can do the gruntwork in Rex to create the encoder/decoder chunks as well as stager giblets, then tie it together in Msf for Exploit and Post to consume with convenience methods.

[benpturner]

@sempervictus Have you implemented a stager that would work for this example? This is quite a cool bit of functionality to upload scripts to the remote powershell session. I agree, it would be better to centralize the code though in the mixin module.

[davehardy20]

I think Ben under sells this somewhat, this module allows us to import
directly into memory tools such as powersploit, power view and powerup, all
from within metasploit-framework, no pulling down from github. This allows
post exploitation and further recon a whole lot simpler than was previously
possible. Also to be fair it makes the download modules option of our
powershell payloads a little redundant.
Any help from the devs of metasploit-framework will be greatly accepted.

Dave
On 21 May 2015 21:34, "Ben Turner" notifications@github.com wrote:

@sempervictus https://github.com/sempervictus Have you implemented a
stager that would work for this example? This is quite a cool bit of
functionality to upload scripts to the remote powershell session

—
Reply to this email directly or view it on GitHub
#5379 (comment)
.

[benpturner]

@sempervictus I've merged the function into the mixin file

[sempervictus]

@benpturner: i'm forking this PR now to get sorted, thanks for pushing that method to lib. I'm very sorry for the lag on this, shooting for a PR to your branch before morning.

@davehardy20: we've actually had that functionality for a few years now. The current powershell lib code allows for exactly that, and actually is how the PSH psexec does its AV avoiding magic - in mem execution. The beauty of this is in its elegance and the persistence of the PSH session across deterministic operations on the MSF side which can lead to fun things like tunneling session over PSH's remote connection to a host god knows where else in the domain as a valid transport.

[sempervictus]

Created your first PR merged with recent push from our end, and slightly modified for added entropy, some runtime cleanup, and a basic compression test as an alternative to staging if feasible.

My apologies again for the delay. Awesome work by the way - much cleaner than having to prep the PSH on our end or use iterative loaders to compose it in MSF for a one-shot exec (see the DotNet compiler bit, it wont benefit much from this as it usually needs to instantiate a separate PSH session with an elevated CLR, but its a hell of a lot more clunky than your work).

[sempervictus]

@benpturner: i think that i made a mistake when submitting a PR to your repository in that it targeted master. The merged commits dont show up here, and a quick look over the PR in your framework repo shows the commit going to the master branch. We can merge your master branch into this branch, rebase off the current master, and far as i'm concerned this should be merged in - i've been using the merged modified codebase for a few weeks now "with great success" as Borat would say.
@devs: sorry for the confusion here, thats on me. Can someone give this a once-over from the R7 side once we merge up and pull the results into master?

[sempervictus]

@devs: could someone give this a once over and merge in?

[bcook-r7]

While the concept is great and we want more powershell and something like this landed, this PR does not follow the contributing guide or have a test plan, so we cannot land it as-is. It's similar to the the enum_services update for powershell PR.

[benpturner]

Hi @bcook-r7 , I have had a few PR's submitted and have been working with @sempervictus sempervictus on this and I think he has worked with @Meatballs1 . I put the original request in May and we had some tweaking to fit with the current Powershell classes, but this completely relies on the new Powershell session type we implemented back in April. Can you let me know whats not right with this as i'm keen to get this introduced to help weaponise the powershell session types.

Thanks

[Meatballs1]

Please edit original post with some more details as described in https://github.com/rapid7/metasploit-framework/blob/master/CONTRIBUTING.md

[benpturner]

@bcook-r7 @Meatballs1 I've added a description of the changes implemented for this post module.

[benpturner]

@bcook-r7 I'm trying to chase this up. Its been a month since the last message, thanks

[benpturner]

@hmoore-r7 Are you able to help with this at all, i've been trying to get this submitted with @sempervictus for a while now but not updates since July. I have done all they asked. Thanks in advance

[hdm]

Since this changes the calling syntax, are you sure that all other callers to this method have been updated?

[benpturner]

@sempervictus are you able to advise on some of this?

But actually looking at his change here, if the 'eof' parameter was provided it would default to nil, therefore any other call to this function wouldn't need updating necessarily I dont think in this case would it?

[hdm]

@benpturner No problem!

[benpturner]

Any update on this? @sempervictus

[benpturner]

@hmoore-r7 Hopefully all other issues have been addressed.

[hdm]

Minor typo, will get during merge