The 8th release of the Cobalt Strike 3.0 series is now available. The release extends Malleable C2 to influence how Beacon lives in memory, adds code-signing for executables, and gives operators control over which proxy server Beacon uses. There’s a lot of good stuff here. Let’s dig into it.
Malleable PE
A key goal of Cobalt Strike is to challenge analysts and keep the toolset interesting as they and their capabilities evolve. Many forward leaning security programs rely on memory forensics to detect and respond to actors with capabilities similar to and beyond Cobalt Strike. This release adds some flexibility in this area.
Cobalt Strike 3.7’s Malleable C2 stage block specifies how Beacon lives in memory through changes to Beacon’s Reflective DLL stage. Here’s what this looks like:
stage {
set userwx "false";
set compile_time "14 Jul 2009 8:14:00";
set image_size_x86 "512000";
set image_size_x64 "512000";
transform-x86 {
prepend "\x90\x90"; # NOP, NOP!
strrep "ReflectiveLoader" "DoLegitStuff";
}
transform-x64 {
# transform the x64 rDLL stage
}
}
Let’s start with permissions: Something magical happens when an analyst sweeps processes for RWX pages. Payloads fall out of the memory. Stagers fall out too. This is because many offensive tools use these liberal permissions, even when they’re not needed. The userwx option gives you control over this. Set userwx to false and Beacon’s Reflective DLL Loader will avoid these permissions.
Veteran analysts with multiple rounds of Cobalt Strike experience may know the size of Beacon’s reflective DLL in memory. I’ve heard 0x42000 thrown around many times. This is the SizeOfImage value in Beacon’s PE header. The image_size_x86 and image_size_x64 options control this value. If you emulate a specific threat actor, consider a SizeOfImage value that matches their malware.
Finally, in the cyber, attribution matters. Nothing feeds fantastical pet attribution theories quite like when the actor compiled their malware. The compile_time option changes this value in Beacon’s Reflective DLL header.
The transform-x86 and transform-x64 blocks pad and transform Beacon’s stage. If you choose to prepend data, make sure it’s valid code for the stage’s architecture. There’s no check for this.
The Malleable C2 documentation has more information on these new options.
Code Signing
This release adds a code signing capability to Cobalt Strike. This feature requires a valid code-signing certificate stored in a Java Keystore file. Those of you who’ve signed Cobalt Strike’s Java Applet already have one of these keystores available. Use Malleable C2’s code-signer block to tell Cobalt Strike about your code-signing certificate.
# setup code-signing certificate for our EXEs and DLLs
code-signer {
set keystore "keystore.jks";
set password "password";
set alias "server";
}
After you specify a certificate, the Sign executable file box in Attacks -> Packages -> Windows EXE and Attacks -> Packages -> Windows EXE (S) becomes available. Check this box and Cobalt Strike will sign your artifact. It’s as easy as that!
Proxy Override
I’ve had many requests for a way to specify alternate proxy settings for Beacon. This release adds user-specified proxy settings to Beacon’s stageless artifacts. Go to Attacks -> Packages -> Windows EXE (S) and press … next to the proxy field to configure this option.
You may leave these proxy settings as-is (default), instruct Beacon to connect directly, or make Beacon use the proxy configuration and credentials that you specify. These options should help in a few situations.
Check out the release notes to see a full list of what’s new in Cobalt Strike 3.7. Licensed users may use the update program to get the latest. A Cobalt Strike trial is also available.