https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/
It’s not fun to get caught on an assessment because your target has your toolset signatured. It’s even less fun if that signature is easily bypassed. Cobalt Strike’s Malleable C2 is a method of avoiding that problem when it comes to command and control (C2) traffic. Malleable C2 provides operators with a method to mold Cobalt Strike command and control traffic to their will. For instance, if you determine your target organization allows employees to use Pandora, you could create a profile to make Cobalt Strike’s C2 traffic look like Pandora on the wire. Alternatively, if a client wants to test detection capabilities, you could make your traffic look like a well-known malware toolkit like Zeus.
Raphael Mudge (@armitagehacker) previously covered Malleable C2 in the official Cobalt Strike documentation as well as on his blog:
Will Schroeder (@harmj0y) also covered Malleable C2 in his post A Brave New World: Malleable C2. A big thanks to both Raphael and Will for their previous work!
This post covers how to create new Malleable C2 profiles for Cobalt Strike, using Bing web search as an example. The aim of the post is not to cover every option Malleable C2 provides (that’s what documentation is for!); rather, the goal is to provide a workflow for traffic selection and profile creation. A GitHub repo with the Bing web search and my other profiles can be found here.
Consider your target environment when deciding on the website or application we want to emulate. Ideally, our Cobalt Strike C2 traffic will blend in with normal traffic on the target network. If a network defender does end up reviewing our traffic, we want to maximize the chances of being dismissed as legitimate.
In a highly-targeted test, this may mean creating individual profiles per targeted department. For instance, if our target is the loan processing department at a financial institution, a digital document signing service (like Docusign) would likely blend in. Enumerate specific applications using open source intelligence gathering techniques where possible.
Each profile contains the following elements:
This may seem like a lot to fill out per profile, but it is manageable and provides extensive customization options.
Before we go further, it’s useful to understand the basics about how Beacon communicates. After Beacon stages, it sends a GET request to the server with host metadata. This is controlled by the http-get client portion of the profile. Beacon will thereafter check-in at the designated sleep interval. If the teamserver has taskings for the Beacon, it will provide them in the response to the next check-in request. The teamserver response is controlled by the http-get server portion of the profile.
When Beacon has output from a tasking, it will send the data back to the teamserver via a POST request (as configured by the http-server client portion of the profile.)
Beginning in Cobalt Strike version 3.6, it is possible to change the HTTP verb from POST to GET. The response to this POST request, http-post server in the profile, is disregarded by Beacon. By default, Beacon uses an HTTP POST request for steps #3 and #4 above. Depending on your target environment or the traffic you’re emulating, alternating GET and POST requests may get noticed. In those cases, set the http-post section’s verb to GET.