Renato Malta
One of Tempest’s Cyber Threat Intelligence team’s missions is to identify and document the TTPs (Tactics, Techniques, and Procedures) used by adversaries and cybercriminals.
An essential part of this process is identifying and monitoring the infrastructure used by these agents. We have recorded an increasing usage of Cobalt Strike as Command and Control for malicious activities.
1.Summary
- Released in 2012, Cobalt Strike (S0154) is a commercial adversary simulation platform that has a wide range of post-exploitation features that assist the work of Red Teams and defense teams.
- However, these benefits have also been used by APT operators, ransomware cartels, and cybercriminals, which several entities in the cybersecurity industry have widely reported.
- Based on the analyzed material, we could notice the frequent use of default Cobalt Strike configurations which may offer detection opportunities for defense teams.
- This report is intended to provide an overview of over 6800 Cobalt Strike servers exposed to the Internet and their configurations. The particularities described in the document can assist defense teams in detecting, hunting, and emulating threats that use this framework and provide insights for detection of tools using similar techniques such as Metasploit, Empire, Covenant, and others.
2.Methodology
For this analysis, we combined public methodologies, which take advantage of particularities noticed in standard installations of Cobalt Strike Team Server and can be used as fingerprint to identify these servers on the Internet.
Recorded Future described one of the techniques and identified these servers using information contained in the “Cobalt Strike Team Server Population Study” done by Strategic Cyber LLC (developer of Cobalt Strike). Unless changed by its operator, the Cobalt Strike Team Server uses a standard self-signed certificate, whose hash SHA25687f2085c32b6a2cc709b365f55873e207a9caa
10bffecf2fd16d3cf9d94d390c can be used for identification in search engines such as Shodan and Censys.
Another technique, described by Salesforce, identifies malicious servers on the Internet with the help of the JARM software, which uses attributes from the response of TLS servers to generate some sort of fingerprint. The default installation of Cobalt Strike has the JARM 29d21b20d29d29d21c41d21b21b41d494e0df9532e75299f15ba73156cee38 which can also be identified in search engines like Censys.
Additionally, we use lists of servers made available in the RiskIQ service in open sources, such as the profile on Pastebin CobaltStrikeMonitor and social networks, on which several security researchers post identified servers daily.
With the IP addresses, we use the script developed by SentinelOne to extract the configuration that defines how the communication and execution of the beacon will be done for each server; thus, besides identifying patterns and specificities, we can confirm that these addresses are active and hosting Cobalt Strike servers.
The data collected in this study are related to 3949 servers spread across the Internet. In many moments, the graphs below show numbers that are higher than the volume of servers. This occurs in situations where the same servers have two or more characteristics presented in the chart.
3.Server Analysis
Between 11/05/2021 and 20/10/2021, we identified 6,819 active Cobalt Strike servers with an average of 100 new ones per day, which may be in use by both criminals and security teams, for example, the servers identified in IP addresses related to the United States Department of Homeland Security, in the image below.
4.Geolocation
The servers we identified are located in more than 30 countries; the United States, China, and Hong Kong appear at the top of the list, which doesn’t necessarily determine the location or nationality of the adversaries operating these servers.
Brazil appears among the countries hosting the fewest servers, with only 13 occurrences. In fact, these numbers can be explained due to the location of the most significant global hosting and cloud computing providers, such as Alibaba, Amazon, and Google.
5.Hosting
Out of more than 250 hosting services used, we noticed a preference for large cloud services such as Tencent, Amazon, and Alibaba. Cloud services allow more flexibility in the activation and deactivation of servers and are also generally less expensive than traditional hosting providers.
We also noticed a significant presence of providers with greater resistance to takedown requests, such as Vultr/Choopa and Leaseweb.
Many servers were identified through the domains, and some of them were using the Cloudflare service, which made it impossible to locate their hosting providers.
6.Configuration analysis
As described in the methodology section (above), we sought to extract the configuration of the beacons contained in the servers identified in our monitoring process. These configurations, also known as “Profile,” refer to one of Cobalt Strike’s most powerful features: the Malleable C2.
The feature allows the tool operator to use profiles that will enable customization of network traffic, payload injection into processes, and in-memory obfuscation methods, making them harder to detect by security tools. Below is an image that represents this set of configurations.
7.Listener
The basic operation of Cobalt Strike is tied to Listeners, which allows the user to configure the command and control method (C2) that will be used in the attack. For each attack or payload generated, there’s a Listener embedded in the target. This determines how the communication process will take place between the infected host and the server. A user can configure several information about the Listener and choose the type of operation that will be performed through C2, such as DNS, HTTP, HTTPS, SMB, SMTP, and others.
Our study directed our sensors exclusively to servers whose traffic is based on HTTP and HTTPS protocols.
Only 5 of them used the hybrid HTTP + DNS Listener on the identified servers, and the vast majority used HTTPS by default.
8.User Agent
This configuration allows you to customize the user agent that the beacon will use to communicate with the server. With this, the operator can try to simulate the behavior of common browsers and thus not attract the attention of defense mechanisms or analysts scanning the network traffic for anomalies.
The most famous user agent is Internet Explorer due to its extensive adoption in corporate environments. Still, it was also possible to identify configurations related to other browsers such as Firefox and Chrome and browsers for mobile devices such as iPhone and Android.
9.URI
Several configurations can be implemented to customize the communication between the beacon and the Cobalt Strike server. One of them is to manipulate the URI that will be accessed.
It’s common for threat operators to use URIs that forge commonly used accesses, such as JQuery traffic (/jquery-3.3.1.min.js) and communication with the Amazon site (/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books).
10.Jitter Factor
By definition, beaconing is the practice of sending short, regular communications from one host to another using beacons. Not all beacons are malicious. There are many benign use cases, such as system time services, software update services, and many others.
Cobalt Strike is used to communicate to the server that the compromised machine is active, ready to receive instructions and commands.
But this regular, continuous communication makes it easy for defense mechanisms to identify and detect it, so to stay hidden from these tools, many post-exploitation frameworks use a feature known as the Jitter factor.
Jitter is a statistical variation in the delay of data delivery over a network, i.e., it can be defined as a measure of the variation in delay between successive packets of data.
By default, the Cobalt Strike beacon communicates with the server every sixty seconds. Still, the operator can change the frequency and, in addition, configure a value for the Jitter factor from 0 to 99 that will be used to randomize the time of this communication.
Most of the identified servers have the Jitter factor at 0, meaning that the verification time is not randomized, which may facilitate the detection of their communication within the network.
11.Data Transform Instructions
Data Transform is a sequence of instructions that tell the beacon how to transform data before it is sent to the server, which also uses these instructions to translate the received data. In this way, if network traffic is intercepted, it’s challenging to identify what is being transmitted.
For example, if configured in this way, the beacon will encode the data in Base64. The server, programmed with this instruction, would automatically decode the received material using the same method.
Although these instructions can be used together, we have separated the ones most commonly used by the servers we have identified:
12.Process Injection
Process payload injection is a defense evasion technique widely used by malware and post-exploitation tools like Cobalt Strike. Through this, it’s possible to execute malicious code in the memory space of another process.
There are several ways to conduct the injection, and, in the case of Cobalt Strike, the method by which the beacon will be injected is also contained in the configuration of the server and the beacon itself.
See below the methods most commonly used by the servers in our samples:
- RtlCreateUserThread – Injects code across session boundaries.
- CreateRemoteThread – Remote injection into a process.
- CreateThread – Injects malicious code into its own process.
- SetThreadContext – Assumes threat from a temporary process generated for a post-exploitation job.
- NtQueueApcThread-s – Uses NtQueueApcThread to queue a single function that runs when the target process thread is activated.
More details about process injection mode in the Cobalt Strike documentation.
13.Spawn_to
The Spawn_to settings control the process that will be abused by a beacon in order to generate the post-exploit work, so the operator can simulate processes that are commonly used in the operating system to try to confuse defense systems and security analysts.
One detection opportunity will be to observe if these processes execute commands that are not part of their traditional behavior.
In the example table below, extracted from a log, it’s possible to see the execution of commands such as whoami /all, route print or cmd /c set by the process rundll32.exe, whose primary function is to load DLLs into memory and not to execute network commands, for example.
In the configurations we had access to, the most used process is rundll32.exe, which is part of the default configuration used by Cobalt Strike. Below are the ten most used processes:
14.Watermark
One information that is often relevant in the analysis and investigation of intrusions involving CobaltStrike is the watermark parameter contained in the beacon configuration. This identifier is a number generated from the Cobalt Strike license file, which can help identify and link multiple campaigns to the same actor.
A large portion of the identified servers (1148) use the “0” watermark, which is linked to pirated versions of the product that have been leaked on underground forums.
Three other watermarks frequently appear in our monitoring: the 305419896 attributed to an affiliate of the Maze ransomware group, the 1359593325 attributed to Trickbot-related operations, and the 1580103814 attributed to the LuckyMouse group.
Having been made visible through reports from security firms, these watermarks may be customized in an attempt to throw off analysts, causing misattribution. Therefore, it’s impossible to determine that the number of servers identified with these watermarks actually belongs to the mentioned groups/actors.
15.Final Considerations
The Cobalt Strike detection process can be complex because of its ability to customize processes and connections, making it almost impossible to disassociate its traffic from legitimate traffic on a regular network using only one of its configuration parameters.
However, during our analysis, we identified that several servers use identical “profiles”, often based on the operator’s adoption of the default Cobalt Strike configuration. This behavior could be seen in the Jitter factor settings, the data transform instructions, and the choice of the process to be used on the target machine. This kind of sloppiness in customizing the attack can be an important part of its detection. More details on ways to detect this threat in the whitepaper about the tool were published in the middle of this year.
Despite the growing numbers of Cobalt Strike used by ransomware cartels, it’s important to remember that initial access to corporations is often through known malware families such as Trickbot, BazarLoader, QakBot, and others. We recommend that you pay extra attention to these families
We have made the IOCs of the servers analyzed in this study available on Tempest’s GitHub. Customers of the Threat Intelligence service can have real-time access to updates on this list via our MISP.
END OF REPORT
