Add universal unhooking call to meterpreter server

[mrjefftang]

This is a second attempt at #174. The initial request choked on a powershell.exe host process for 2 reasons:

1. Error handling the relocation of sechost.dll caused an invalid memory read
2. clr.dll performs runtime byte patching of itself to automatically determine the offset of TLS via some magic so we will avoid restoring the clr.dll image.

On the suggestion of @sempervictus, this is implemented as an extension/stage.

[bwatters-r7]

Hello again, @mrjefftang! Could you provide an example run? I am curious about when this extension gets loaded and how. I know some extensions are loaded at the start automatically while others are loaded on-demand. I don't see any corresponding change/PR to the framework side or any change to existing code to help me understand the loading chronology here. Is this an autoload based on the location in a filesystem?

[timwr]

@bwatters-r7, framework pr is here rapid7/metasploit-framework#10676

[bwatters-r7]

@timwr, I scrolled right past it..... Thanks!

[mrjefftang]

Extension is a plug-in. Set to auto load before stdapi if enabled or on demand by user

[sempervictus]

In terms of the order of operations, this doesnt make much sense (to me anyway) as an evasion strategy as a meterpreter extension, because extension loading requires metsrv to be loaded and active, and therefore already detected by the hooks we're trying to remove in the 1st place.
I think that this would make much more sense as a payload stage which would preempt the acquisition and loading of metsrv into memory. Something along the lines of:

1. Exploit->
2. stager->
3. unhookstage (maps memory for metsrv, unhooks the PE space, downloads the last stage, metsrv, loads it into the now clean memory, executes metsrv passing the original stage's transport)->
4. metsrvstage

Thoughts?
ping @OJ since we chatted about this recently and, well, just because its meterpreter-related... :)

[mrjefftang]

There's definitely a trade off of when we deliver this stage.

From my understanding, metsrv only establishes a connect back so there's minimal API calls. So by setting autounhook, we can unhook prior to stdapi getting loaded and user input/scripts runnign which could cause more noise.

In theory, we could just merge this all into the reflective DLL loader for metsrv but I think the trade off of letting metsrv run and callback will confirm exploit worked vs risking a large payload going down and failing somewhere in the loading process.

[sempervictus]

Stages such as reverse TCP are establishing the initial transport, which is already under observation if they hook all the things. However, that can be obfuscated and with some cleanup, made to look like normal memory ops (rwx isn't great). The callback subsequently pulls in metsrv, and the existing transport is handed back to it for reuse as an address on a register. My suggestion is to place the unhook piece between stage0 and the acquisition of metsrv to prep the memory space into which the metsrv stage will be loaded.

[bwatters-r7]

Waiting on feedback to some issues documented on the framework side.