Next-Gen AV Evasion - custom http(s) stager and metsrv.dll that unhook's windows API before running

[pussinboots1992]

Not really an issue/bug, more a feature request. Alot of the Next-Gen AV technologies are catching meterpreter payloads and are becoming very hard to evade because they hook the windows API functions used by the meterpreter payloads (both the stagers and the metsrv.dll). So even if you are using custom encoding/obfuscation, you get caught.

Cylance released a custom metsrv.dll which supposedly un-hooks any user-mode hooks on the Windows API functions prior to actually initialising the meterpreter to ensure any AV hooks cannot catch the call's to these API's and anayze them.

https://github.com/CylanceVulnResearch/ReflectiveDLLRefresher

@wchen-r7, It would be nice to have this functionality built-in to the framework or in the new evasion modules.

Here are some interessting articles on how these evasion techniques work:

https://www.mdsec.co.uk/2019/03/silencing-cylance-a-case-study-in-modern-edrs/

Of course, one can use other tools to bypass these next-gen AV solutions (dnscat2 PowerShell client for example will fly right past an agressively configured Cylance anti-virus) but their fonctionality is limited and I am way too lazy to build a custom meterpreter alternative.

I guess writing payloads that use un-documented functions would be an alternative but hard to maintain.

[OJ]

Isn't this the same functionality that's baked into the universal unhooking extension?

[pussinboots1992]

I guess so...however my stagers are being caught before they even reach the handler to grab the metsrv.dll. So I wonder if the un-hooking shouldn't be happening before the very first GET request / tcp connect leaves the stager (if using reverse_http/tcp payloads).

@OJ, you are right, sorry. I had not read this comment:

https://github.com/rapid7/metasploit-payloads/pull/302#issuecomment-431636591

I agree with @sempervictus FYI @mrjefftang that the un-hooking is hapening too late and Cylance will catch the reverse_https stager communication before the metsrv.dll is even sent back to be loaded by the stager. I though it was maybe related to the exe file having weird characteristics (high entropy, rwx permissions on memory sections, exe at a weird location on the file system, low number of imports, blacklisted IP or domain name on the handler side etc... that was causing it to get killed). But even if I sign the executable and place it in program files and prevent communication with Cylance's cloud it get's killed as soon as it communicates with the handler.

I know for a fact that is is the API hooking which is catching my shell's because if I rename the CyMemDef64.dll file (which is loaded into the process by Cylance and which implements the hooking), it flies right by the Anti-Virus and I can do anything I want without triggering any alerts.

[sempervictus]

Have you by chance tried writing up a manual stager in c using either metasm or another compiler? They may be hooking on sparse bytes in the instruction set at possible/known offsets before you even trigger, or most likely, hooking our api resolution tricks. Edit: pardon, didn't see the follow up posts. Yeah, we need some entropy in the api resolver code. Depending on WHERE it hooks, you may have luck with rc4 stagers (I use em almost exclusively).

[pussinboots1992]

@sempervictus, I was thinking of trying something like this :

https://github.com/rsmudge/metasploit-loader

To see if it would react differently...I will give the rc4 tcp stager a try, I like using the http(s) payloads because they obviously work well in tighly firewalled networks with egress traffic being proxied/inspected outbound. I know that a simple reverse_tcp Powershell nishang one-liner also gets past an agressively configured Cylance AV.

[sempervictus]

Maybe we can shoehorn rc4 http into this weekend too. I never finished that metasm block and it'd be mighty useful

[pussinboots1992]

I confirm that using the custom loader above, adapted for x64 flies past an agressively configured Cylance AV (I also encoded second stages using a custom XOR encoder but I dont think it was necessary). I did not have much luck with the auto un-hook though, the AV did catch my process migrations and my kiwi module usage. I had to take ownership over the dll file that they inject into new processes which implements the API hooking and rename it :-), then re-establish a new (un-hooked) meterpreter session...

[pussinboots1992]

@sempervictus, I have rarely been blocked by IDS or proxies when using the regular reverse_https payload. When I am it is usualy because it needs some cookie, user-agent or has issues with the handler's reputation :-). I rarely see IDS systems configured for SSL interception and most nextgen firewall's and proxies do not catch stageless or encoded second stages. Are you having issues with equipements which decrypt your https payloads and blocks them based on signature because the encryption is SSL and not application level like with RC4 ?

[sempervictus]

Some vendors take the unfortunate step of trying to make themselves look effective by signing parts of open source tools like ours and claiming defensive capacity over classes of threat by catching one unmodified, unobfuscated, data frame. IDS TLS MITM is getting harder, as is http proxy TLS intercept due to pinning, but its still quite common (at least for the latter). Even encoded payloads can be decoded by emulation of the execution context, which is why I tend to lean on rc4 stages (thank you mihi), no key, no decrypt, ids/ips can spin wheels till cows come home and not see the real content.