When a C2 platform is hardcoded to beacon in a particular fashion, its detection from a defender’s perspective is trivial. Namely, we merely need to create a single signature based on the hardcoded characteristics, which would then be capable of detecting that C2 across multiple deployments. In order to help prevent this, malware authors introduced malleable profiles (quite some time ago now), which give the C2 operator the ability to quickly and easily alter the communication characteristics of the beacons. These profiles allow the C2 traffic to blend in by mimicking everyday traffic from common applications, making it difficult for defenders to distinguish between legitimate and malicious communication. One of the first well known C2 platforms to introduce malleable profiles was Cobalt Strike, but other platforms such as Empire also offer this capability.
In this blog post, we will go through a concept of how to help identify these malleable profiles by parsing them and turning them into content for NetWitness Packets.
Looking into the malleable profiles, a number of which can be found here: https://github.com/rsmudge/Malleable-C2-Profiles, we can see how they will alter the traffic based on the parameters supplied. A small snippet of the http-get section from the jquery-c2.4.2.profile can be seen below:
The section shown above defines the HTTP GET for the beacon, which is typically used for checking in. We can see the URI that will be requested, the headers and associated values that will be sent by the client and server, as well as some other options that will specify where and how data will be sent. All of the profiles follow this format, which means that we could create a utility to extract this content from them, and in turn generate NetWitness content for their detection in the form of application rules. The utility would simply identify each section and parse the relevant parameters in order to create the content.
The screenshot below shows the utility being executed against a directory of malleable profiles that were freely available online, 82 in total:
The parser generated a total of 210 application rules from the 82 profiles. This is because the tool creates content for the HTTP GET, HTTP POST, HTTP stager sections, and any variants there are of each. The tool outputs the content as an .nwr file, which can be directly imported into the Packet Decoders, the following link has instructions on how to import the rules under the heading, Import Rules from a File and Export Rules:
The logic for all of the rules can then be seen and edited if need be:
Some of the application rules may generate false positives in your environment. However, these rules are intended to be used as an initial pivot point to help hone in on sessions that could potentially be a C2 using malleable profiles. Therefore, some level of whitelisting would most likely be required to reduce any noisy hits. Application rules are also named according to the section the content was created from, so if you have more than one match for single profile, such as the GET and POST, then the fidelity of the matches rises:
Some of the profiles will not contain a user agent string, such as the default.profile. In the instance of Cobalt Strike, if this is the case, it will randomly pick a user agent string from a default list; we therefore need to make sure we also create content for that list so it can be used as a pivot point to help with hunting through the hits. Attached to this blog post is a CSV file for all of the default user agent strings that Cobalt Strike may use. This CSV file will need to be turned into a Feed so you can use it as an additonal pivot point: https://community.rsa.com/t5/rsa-netwitness-platform-online/create-a-custom-feed/ta-p/586192:
- MalleableProfilesForAdvancedNetWitnessOptions.nwr - This set of rules requires that all headers are extracted from the HTTP traffic, this is done by enabling an option on the Decoder as previously described in one of our blog posts (https://community.rsa.com/t5/rsa-netwitness-platform-blog/detecting-command-and-control-in-rsa-netwitness-cobalt-strike/ba-p/521072). This option can cause performance issues with the Decoder, so do monitor closely if enabling
The detection concept presented here is not about how to detect Cobalt Strike with 100% accuracy from the network perspective. It is however, another technique that can help with identifying the C2 operators that opt for configuring their Cobalt Strike C2 with default and freely available malleable profiles. While an attacker may choose to use non-standard profiles in their C2 configuration, the technique and the app rules outlined in this blog will help you to identify all the Cobalt Strike variants with default malleable profiles that that may find their way into your network.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.