AMSI vs Post-Exploitation
The Beacon payload is not the only place AMSI will snatch you, but also in various post-exploitation commands which AMSI can instrument. To name a few are powershell
, powerpick
and execute-assembly
. This occurs because Beacon will spawn new processes to execute these commands, and each process gets its own copy of AMSI.
\
In this case, the Beacon payload spawned powershell.exe and attempted to load PowerView.ps1 into it. This was detected by AMSI and killed. Defender also goes one step further and kills the process that spawned it (our Beacon), which is why we immediately lose the link to it.
The same will happen if we attempt to execute a .NET assembly that is known to Defender.
\
It would be a bit of a pain to modify and obfuscate every single post-ex tool, so Cobalt Strike introduced a configuration that we can apply in Malleable C2 called amsi_disable
. This uses a memory-patching technique which I have blogged about before to disable AMSI in the spawned process prior to injecting the post-ex capability.
SSH into the team server and open the profile you're using in a text editor (for me, that's webbug.profile).
\
Right above the http-get
block, add the following:
\
After modifying a profile, it's always a good idea to check it with c2lint to ensure you didn't break anything.
Warnings are ok, but errors are usually fatal.
\
You will need to restart your team server and re-acquire a Beacon on the file server. This time, Rubeus will execute.
amsi_disable
only applies to powerpick
, execute-assembly
and psinject
. It does not apply to the powershell command.
\
However, you'll notice that your Beacon probably still dies shortly thereafter. This brings us to behavioural detections.
Last updated