Malleable C2 Profiles and You
Like most defenders out there today we keep hearing and seeing CobaltStrike used by actors. I wanted to share some notes on some back of the napkin research I’ve been doing related to it in hopes that it sparks interest in others to begin investigating more.
It wasn’t until about 2 years ago I realized how powerful CobaltStrike is. If I am this late, I can’t imagine how far heavily funded adversaries are in generating their toolsets. I know some more advanced Red Teams have been using these capabilities to their fullest, but many are still using the defaults. Some of this may come as old news, but for me, this was quite profound. I’m talking about Malleable C2 Profiles. A very generic set of these profiles may be found here:
The pieces didn’t connect as to what these were until I found
Simple things, like User Agent -
all the fields for SMB beacons, DNS beacons — setting the pipes or DNS settings.. 🤔 This is pretty fantastic stuff! We talk about how actors blend in, here is your chance.
and I started to get really curious as to how these are being used. I wont break down each section, but here are the resources to understand what is going on:
In short of what I am getting at, if an actor or red team wants to blend in, using these malleable C2 profiles is how the job will get done. CobaltStrike itself has a lot of options, but I feel the money is on these profiles. Now, I do not have a CobaltStrike teamserver, or own a license. I am only basing my analysis on what I’ve analyzed and seen in the wild. However, there are cracked versions on the internet easily obtainable (probably backdoored 🤷♂, but obtainable), and @BC-Security1 made the ability to import malleable profiles to Empire (more here).
ThreatExpress has been keeping their profiles up to date with each CS release.
I want to scope this blog on post exploitation.
post-ex {
set spawnto_x86 "%windir%\\syswow64\\<mfpmp>.exe";
set spawnto_x64 "%windir%\\sysnative\\<mfpmp>.exe";
set obfuscate "[true|false]";
# Obfuscate the permissions and content of our post-ex
DLLs set smartinject "[true|false]";
# Directs Beacon to embed key function pointers (ex)
GetProcAddress, LoadLibrary) into its same-arch post-ex
DLLs.
set amsi_disable "[true|false]";
# Disable AMSI (Antimalware Scan Interface) in powerpick,
execute-assembly and psinject before loading .NET or PS
code
}Everything else is obviously very interesting, but for some reason post-ex interests me the most.
What’s the point of spawn_to?
The idea is, which is great, allows the operator to select what process to spawn beacon into. Upon its use, a process will spawn. In practice, the process will sometimes look out of place by having a non-standard parent process, no command line arguments or maybe a network connection.
From Beacon help:
There is a lot of ways to remove OpSec with CobaltStrike — maybe it’s not widely known or understood, but Beacon has a lot of options for configuration.
I’ve seen others on Twitter begin to publicly share scans of CobaltStrike Team Servers. I don’t believe it’s entirely public how some are gathering these data points 🤷♂, but I am glad it’s happening.
Some great references:
- Awesome-CobaltStrike-Defence — https://github.com/MichaelKoczwara/Awesome-CobaltStrike-Defence
- RiskIQ — https://www.riskiq.com/blog/labs/cobalt-strike/ and https://www.riskiq.com/blog/external-threat-management/jarm-incident-response/
- RecordedFuture — https://www.recordedfuture.com/cobalt-strike-servers/
- SANS — https://isc.sans.edu/diary/Threat+Hunting+with+JARM/26832
- Salesforce — https://engineering.salesforce.com/easily-identify-malicious-servers-on-the-internet-with-jarm-e095edac525a
- 🔥 NMAP NSE — https://github.com/whickey-r7/grab_beacon_config
There you go, lots of options and details there.
Lists released:
All the scanning and public lists lead to this small set of binaries being used to spawn into:
Note: rundll32.exe is the default.
How can defenders use this information? Why is this important?
We can use the spawn_to values as a jump off point for detection coverage by looking for and asking the following:
- Is it normal for <spawn_to value> to have no command line arguments?
- What is the default/normal process lineage for <spawn_to value>?
- Does the <spawn_to value> make network connections?
- Is it normal for <spawn_to value> to load jscript, vbscript, Amsi.dll, and clr.dll?
Does our EDR/AV product provider visibility to answer these questions? This should be looked into.
Should we go and generate new coverage for the list above? It’s a good start, however, I recommend baselining all of system32.
If threat actors of all sorts can get their hands on CobaltStrike, it is in your threat model. Spawn_to is only one of the many things Beacon can do (more here). We have only scratched the surface. I only hope that as organizations buy and use CobaltStrike, they are taking the time to understand it and build out detection capabilities. I also wish more teams publicly released or talked about how they are using CobaltStrike so that more defenders can learn from its use.
I hope you have found this interesting and use this as a way to begin (or continue) your journey in understanding more about CobaltStrike and its many uses.
