Feature mem w or x

[sempervictus]

64bit processes under Win2016 appear to despise RWX allocations. This branch contains work addressing the PSH side of unmanaged memory allocations for current injection methods (probably will not touch the psh_old template as its really designed for XP on PSHv1). Initial PR contains the rig changes adding new variables for old protection flags and a rework of the PSH reflection template allocating memory as RW (0x04) then marking it executable (0x01) after copying shellcode into the RW buffer. Creation of the execution thread is predicated on success of the executable protection setting. .NET to follow.

[sempervictus]

ping @busterb @dmaloney-r7 @acammack-r7: could you guys take a look at this? Passes internal testing, seems to be written correctly. More eyes-on would be preferred though... We can also simplify the templates and use the Powershell::Script.sub_vars method to reduce text size, but those efforts can be implemented in a separate PR. I'll get the MSIL stuff converted to template format from Util::EXE hackery near-term as well and get that pushed in a separate PR. This work alone doesn't solve all our problems - we still need proper W^X memory management in our x64 stagers, or they blow up once executed, even if the PSH allocation/protection is permissible.

[OJ]

@sempervictus I'm happy to take on some of this work.

[sempervictus]

All done actually - the old style template is for psh1.0 compatibility which doesn't run into this problem - can't think of how you'd install it on 2016, or why :-). I'm 50% done with msil jit cleanup, which doesn't even perform unsafe memory allocations directly. The stagers are really the big thing now, and internal meterp c code. Iirc we do some RWX there too.

[OJ]

This all looks good @sempervictus, one question I have is this: what happens when payloads use inline encoding (shikata_ga_nai is the perfect example) as the encoders assume memory is RWX ? Am I right in thinking that we're going to have to do something to the encoders that cause decoded code to be written elsewhere? There be dragons in there.

This is obviously a general question, not just one specific to this PR :) Thanks!

[sempervictus]

That sir, is a good question. Iirc we use alphanum in PSH, but still should require in place modification of the stack. It seems to work though, which is suddenly a bit baffling. Curious to know why...

[sempervictus]

Thinking on the encoding bit, PSH payloads use alphanum but we can layer. I use rc4 which decrypts in-place and still executes... So this works, possibly due to the shellcode performing a alloc RWX. I want to know why it works for sure, but I do know it works.

[thelightcosine]

@sempervictus looks like some merge conflicts caused by your other PRs landing, can you take a quick look, thanks

[sempervictus]

Will do, thx, a bit tight of a schedule today (actually working some of your folks in other areas), but I'll resolve it by tonight.

[thelightcosine]

rogeo, i can cut a new gem release after we get this last one in

[sempervictus]

@dmaloney-r7: sorry for lag, you're all probably out the office building an ark by now, but rebased and re-pushed. Given @OJs concern: could i ask you to manually psexec a couple of hosts on your end just so i know i'm not crazy thinking this works?

[thelightcosine]

@sempervictus this doesn't seem to be working. powershell target for psexec runs but i never get a session established, i think OJ may be correct. I'm going to go ahead and cut a new rex-powershell gem with what we have so far, can you make a PR for framework, to remove the version restriction on rex-powershell and fix the various spec failures on framework related to powershell with the new version. thanks

[sempervictus]

Aye aye, will tackle later tonight.

So far as it not working, I'll diff my branch from master to find deltas, as mine works... Then again, part of the reason I keep a fork is to avoid sig based detection off master. I did enable wrap double quotes as default in MSF, so I'll push that change too - we may have a circular dep in all of this (still my fault for asking you to go through the hell of splitting out Rex).

Longer term: what're we gonna do about RWX? On Linux, mprotect is part of many lsms now, with more to come. I imagine windows will follow suit, though the heavy reliance on .net buys us time. Encoders and rc4 decryption shell code need in-place changes made to executable regions. Do we go for mark-x-after-decode or some other technique? How's multi encoding handled then?

Thanks again for all the time and effort on these PRs - the folks at MSFT are hopefully doing the cost calc on amsi devel vs our amsi defeat (they'll never beat unicorn and such, but we need to stay a bit more intelligible). Maybe next time they'll just ask us what we think about the problem :-)

[sempervictus]

@bwatters-r7: I belive this is related to our PSH discussions, i've rebased on master and pushed again - the is the only serious deviation between my stable branch and upstream/master prior to the reorg PR a couple days ago.

[bwatters-r7]

@sempervictus I got here through an odd series of issues that no longer appear to be issues..... Is this still something we need to move forward with? I can get a sessions on my 2016x64 machine via a psh staged payload using the current master.

[sempervictus]

Not necessary, but probably a good idea to keep for later when rwx outside a jit owned page pool is no longer allowed.

[bwatters-r7]

OK; if there's no plan to work on this in the hear-term, let's close it for now. We might want to port the 'Attic' label to our different deps.