A Brave New World: Malleable C2

Last week, Raphael Mudge released an awesome update to Cobalt Strike’s asynchronous agent, Beacon, in the form of new fully customizable/malleable command and control communications.

Beacon’s initial communications channel with its C2 server was with HTTP, with a DNS control channel added soon after. This allowed Beacon to behave similarly to most documented crimeware strains. The ability to communicate using SMB pipes was added at the end of last year, enabling the emulation of like some of the more advanced APT agents like Red October and Duqu. However, there still wasn’t a way to make the network traffic really look like the specific C2 for any of these samples. With this update, communication profiles for Beacon can be built, customized, and deployed that modify network indicators for both in-memory agent and the control server itself. In English: you can customize how your command and control looks over the wire!

When I’ve excitedly talked about Beacon’s malleable C2, most people react with an “Oh, that’s kind of cool” that doesn’t quite match my enthusiasm. Before I get into why I think this is a big deal, what can you do with it, and why it matters, I want to go into a bit more detail on how the profiles work and exactly what you can customize.

A Beacon communication channel has two main components: a GET request from the agent to the server, to which the server responds with an encrypted command if one is queued, and a POST from the agent with the encrypted results of the command. Beacon’s default behavior is to use a pool of randomized URIs for GET tasking and POST results, as well as a standard 60 second initial callback interval with a 0% jitter. More detailed information on Beacon and its communication structure is available here.

Now, with the malleable C2 update, Beacon can accept a pre-specified profile that can modify the URIs, initial interval/jitter, user agent, metadata/ID format, and headers of both the client AND the server interactions, for both the GET and POST requests. Raphael has some excellent documentation on malleable C2, as well as a blog post you should read to give you more technical background on the topic. Below is an example profile built to simulate the C2 from a Magnitude Exploit Kit infection:

And here’s how that communication will now look over the wire:

Hopefully the above information has gotten some gears spinning in those of you with a red team mindset, and you have started to see the potential implications. There are three big reasons why I’m excited about this capability:

1. Standard protocol on our engagements is to set up a backup C2 infrastructure with very long callback intervals (possibly 24 hours or more depending on the assessment window). We set this up in case our primary server gets burned and traffic blocked, so we have a functional backup that preserves all of our access. However, the traditional Achilles heel is that in the end our backup server uses the same communications as the primary. Catch one, and it’s much easier to catch the other. With this update, we can now use a completely different communications profile for our backup server, so even if an IR team is able to write network signatures for our primary C2 infrastructure, our backup traffic will look completely different. We can also set the callback interval for this server to be whatever we want immediately on staging, where we previous had to modify the 60 second default manually.

2. We can shape our traffic to blend in with standard network traffic as much as possible to sneak by some more robust system defenses. Since we can include binary data in our C2, we can do things like make our traffic look like a Google Webbug, complete with .GIF header. Proxy stripping out all headers? We can stuff IDs/metadata chunks in the URI itself. We can make our command and control look like Pandora streaming, Amazon browsing, and more. Use your imagination ;)

3. Finally in what I feel is most exciting reason, we can use this capability to simulate specific threat actors or campaigns. Like the Magnitude example above, we can simulate specific crimeware strains as long as we have a .pcap or a detailed description of its C2. We can also simulate specific APT C2, such as the Putter Panda campaign described by Crowdstrike. Raphael calls this “Adversary Replication” or “false flag operations” and had a great talk on the subject at ShowMeCon 2014, a video of which you can find here. And we can simulate these campaigns without having to have the specific malware itself, just details about its C2! Think about it, you can test malware detection capabilities live on the network, but without the actual malware.

While there are a few current limitations with the profiles (like having to stick with the inherent GET/POST structure of Beacon’s communications), overall they’re phenomenally flexible. A few caveats if you are interesting in building your own profiles- your GET and POST URIs need to be different, and you may run into size constraints of the total exchange if you try to stuff too many headers into your profile. Definitely use the c2lint tool now included with Cobalt Strike to compile/test your profiles, and then execute a local test run before you decide to deploy a profile in the field. Also, once a Beacon agent is staged from a C2 server with a specific profile, that agent will only communicate with a server that has the same encryption key AND communications profile. If you switch profiles on the server, your agent will no longer be able to communication properly, so keep all of your profiles in a safe place!

I spent a bit of time building out a few profiles for crimeware strains, APT variants, and ‘normal’ traffic and it was surprisingly easy- the learning curve is pretty short and testing goes fairly quickly. We’re maintaining a Github repository of various profiles which includes the examples I was able to build out. The hardest part, surprisingly, isn’t building the profiles but finding a good source of malware C2 .pcaps and/or detailed descriptions of their communications. The resource sites https://malwr.com/ and http://malware-traffic-analysis.net/ are a great start, but if anyone has some good sources for detailed malware network indicators, especially descriptions of both client AND server indicators, please let me know. And if you’re interested in this stuff, please hit me up on twitter, by email (will [at] harmj0y.net), or at harmj0y in the #armitage channel in FreeNode.