Maleable Profiles

To modify the profile we are using:

attacker@ubuntu ~/cobaltstrike> nano c2-profiles/normal/webbug.profile

post-ex Block

- amsi_disable

There are various post-exploitation commands which AMSI can instrument such as 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.

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 to disable AMSI in the spawned process prior to injecting the post-ex capability.

amsi_disable only applies to powerpick, execute-assembly and psinject. It does not apply to the powershell command.

Add the following above the http-get block:

post-ex {
        set amsi_disable "true";
}

- spawnto

To make spawnto changes work as defautl to defeat behavioural detections:

post-ex {
        set amsi_disable "true";

        set spawnto_x64 "%windir%\\sysnative\\dllhost.exe";
        set spawnto_x86 "%windir%\\syswow64\\dllhost.exe";
}

stage Block

- userwx

Setting userwx to false tells the reflective loader to allocate memory for the Beacon DLL as RW/RX rather than RWX. Although this does not remove any indications from the Beacon itself, having RX memory is certainly less suspicious than RWX.

stage {
        set userwx "false";
}

- cleanup

Setting cleanup to true tells Beacon to free the memory associated with the reflective loader after it has been loaded. Once the Beacon is loaded, the reflective loader is no longer required and leaving it in memory just results in indicators sitting there waiting to be spotted. This allows the reflective loader to be freed, thus removing those indicators for the remainder of Beacon's lifetime.

stage {
        set cleanup "true";
}

- obfuscate

Setting obfuscate to true instructs the reflective loader to load Beacon into memory without its DLL headers. The omission of these headers reduces the number of indicators in memory, then the "Use" column in the process explorer for Beacon's memory region is blank because the DLL is reflectively loaded from memory, rather than being loaded from disk. Every other legitimate RX region in the process is backed by a DLL on disk, so setting the module_x64 (and module_x86 for 32-bit payloads) tells the reflective loader to load the specified DLL from disk first and then overwrite the memory allocated for it with Beacon, this has the effect of making it appear as though Beacon's memory region is backed by a legitimate DLL.

When choosing a DLL, its size must be equal to or greater than Beacon and the DLL must not be needed by the application hosting Beacon (does not affect when executing the artifacts, but is relevant when injecting Beacon shellcode into existing processes).

stage {
        set obfuscate "true";
        set module_x64 "xpsservices.dll";
}