Hunting Cobalt Strike Servers
A comprehensive view on the techniques used to fingerprint Cobalt Strike’s C2s
Introduction
If you are looking for a method to hunt Cobalt Strike servers this is the article for you. I have grouped different techniques for this purpose and I created Shodan queries to have an overview of all active Cobalt Strike command and control (C2) servers.
Why do this?
To date, having an updated Cobalt Strike IP list to proactively monitor or block is a goldmine for Threat Intelligence analysts because it can prevent post-exploitation attacks from different cybercriminals groups like ransomware operators and espionage-focused Advanced Persistent Threats (APTs).
Moreover, identifying malicious infrastructure and how it is used can give defenders a clear advantage when it comes to neutralizing threats.
Seeing how many C2s are created can help one quantify the breadth of a threat actor’s campaigns and other data gathered — such as the tempo of server creation — brings further insight into pending surges and lulls in activity, or evidence of novel techniques and new intelligence.
It can also provide new indicators and intelligence that is otherwise not available in the public domain.
Who use Cobalt Strike?
APT29, UNC2452, APT32, APT41, APT19, TA505 and Mustang Panda are just some of the threat actors who have used Cobalt Strike for their operations. Proofpoint and Recorded Future reported that adversarial use of Cobalt Strike increased in the last years and remained a high-volume threat in 2021.
Several ransomware strains like Ryuk, Conti, Egregor and DoppelPaymer have started to use Cobalt Strike to speed up their ransomware deployment. Cisco Talos reported that 66% of ransomware attacks involved Cobalt Strike.
The THE DFIR REPORT also noticed that Cobalt Strike is used as a post-exploitation tool with various malware droppers responsible for the initial infection stage like IcedID, Ursnif, BazarLoader and TrickBot.
Let’s hunt…
Let’s start with the analysis of the various methods that can be used to hunt Cobalt Strike C2 servers via the Shodan platform. Following the 15 methods used to reach this goal:
- Shodan Product:”Cobalt Strike Beacon”
- SSL certificates and serial numbers
- Default 404 Not Found Response
- Default port 50050 + Banner hash
- Default DNS server response
- Default SSH client hash
- Extra space in HTTP response header
- JA3 fingerprint
- JA3S fingerprint
- JARM TLS fingerprint
- Region and hosting provider
- ASN/ISP scanning with Nmap script
- Pivoting the HTML hash
- Pivoting the HTTP Header hash
- Watermark (License ID)
These techniques can miss more advanced threat actors with a greater opsec that use advanced C2 configurations to evade detections, domain fronting techniques or block the crawlers of various services such as Shodan or Censys to limit the visibility of intelligence analysts. Nonetheless, they can still be useful for creating a general baseline of findings and create actionable intelligence for your company.
1. Shodan Product:”Cobalt Strike Beacon”
Since November 2021 Shodan has registered “Cobal Strike Beacon” as a product in its dashboard. Thanks to this feature it is possible to hunt for new Cobalt C2s that match this search. This search provides a precise and comprehensive overview of the currently active Cobalt Strike servers with a low false positive ratio. Let’s see:
At the time of writing over 1800 Cobalt Strike servers have been detected. China, the US and Hong Kong are the main involved countries:
The 443, 80 and 8443 are the most commonly used ports:
Thanks to this search it is also possible to notice who the main ISPs that are hosting Cobalt Strike servers around the world are, with Tencent, Alibaba, DigitalOcean and Amazon in the top spots:
Using the following ASN:
The historical trend data is only available for the last 6 months, during which the number of CS servers has remained constant. This search gives very reliable results and thanks to this new feature it is possible to have a comprehensive view of all the C2 found by Shodan during its scans:
This specific search, being very precise, will be used to pivot the Cobalt servers’ unique properties in some of the following techniques.
2. SSL certificates and serial numbers
The Cobalt Strike product ships with a default SSL certificate for HTTPS communication. This self-signed certificate has no place in a live/advanced operation, but it’s still used in many Cobalt Strike deployments.
One technique to find Cobalt Strike Beacon controllers is to search for the SHA-256 or SHA-1 hashes of Cobalt Strike’s default certificate or the default SSL serial number.
Default certificate:
md5:950098276A495286EB2A2556FBAB6D83
sha1:6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C
sha256:87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390CDefault Serial number:
ssl.cert.serial:146473198
As you can see in the screenshots above, the results of the hash and serial searches are the same because these two fields are linked together.
At the time of writing, over 470 Cobalt Strike servers are currently up & running with the default certificate. China, the US and Hong Kong are the main countries involved. In Shodan’s historical trends it is possible to see how in 2021 there was a wide use of Cobalt with the default certificate.
Is it possible to assess with a good degree of confidence that the results are reliable, as the SSL fingerprint is unique and specifically related to Cobalt Strike. The default certificate can be replaced with a valid SSL certificate, or its parameters can be changed using a Malleable C2 profile.
In the following diagram, you can see the different SSL certificates and serials currently used by Cobalt Strike servers identified with the aforementioned search:
3. Default 404 Not Found Response
The default 404 Not Found HTTP response header for Cobalt Strike servers has a Content-Length value of 0 and a Content-Type value of text/plain, as follows:
HTTP/1.1 404 Not Found
Content-Type: text/plain
Date: Day, DD Mmm YYYY HH:MM:SS GMT
Content-Length: 0You can use Shodan section for HTTP headers without the extra space to find the Cobalt Strike servers:
In this case the total servers are over 2100 with again China, the US and Hong Kong as the top hosting countries. The 80, 443, 8080 and 8443 ports are the most used with Tencent, Alibaba and Amazon as the main ISPs:
Threat actors can evade this detection method in different ways, for example by change the default response using a Malleable C2 Profile, including adjusting the server parameters and header data to align it with a legitimate server.
4. Default port 50050 + Banner Hash
The Cobalt Strike C2 server can accept by default client connections on TCP port 50050. Filtering only for that leads to too many results:
This method requires more filters to be considered acceptable. For example, every banner contains a hash property which is the numeric hash of the data property. Cobalt’s hash (described here) can be used as an additional filter.
Thanks to this filter, it is possible to notice how the results decrease drastically, producing a number consistent with the other searches analyzed so far:
This method could be very effective. However, false positive filtering should be required and you will miss servers using a different port, making this search incomplete.
5. Default DNS server response
When enabled, the Cobalt Strike DNS server responds to any DNS request received with a bogus (fake) IP: 0.0.0.0.
Unfortunately, this is something that you cannot search for directly in Shodan and therefore makes it a less actionable technique for the scope of this article. Furthermore, this is not unique to Cobalt Strike servers and can be modified in the Cobalt Strike settings.
6. Default SSH client hash
Thanks to the HASSH Profiling Method (described here) is possible to calculate the default hash for the CobaltStrike SSH client which is:
hassh(CobaltStrike_SSH-client) = a7a87fbe86774c2e40cc4a7ea2ab1b3crelated to: SSH-2.0-libssh2_1.8.0 || SSH-2.0-libssh2_1.7.0
Thanks to this Greynoise search is possible to notice that over 700 IPs have this hash with a total of 1100 IPs tagged by Greynoise as Cobalt Strike.
However, the results appear to be incomplete. For example, China is missing as the main country unlike what we have seen in the search trends described above.
7. Extra space in HTTP response header
On January 2, 2019, Cobalt Strike version 3.13 was released with a fix for an “extraneous space” in the HTTP response header of a Cobalt Strike server that FOX-IT later reported was one of the characteristics it had been leveraging to identify Cobalt Strike servers with high confidence during the prior 18 months.
This space is no longer present and can thus no longer be used to identify, servers from Cobalt Strike versions 3.13 and up. Moreover, in older versions, the space can be removed from the HTTP response header using a Malleable C2 profile.
8. JA3 fingerprint
JA3 is an open-source project that can create SSL fingerprints for communication between clients and servers. The unique signatures can represent several values collected from fields in the Client Hello packet.
The known JA3 signatures related to Cobalt Strike include the following. For example, Cobalt Strike’s Beacon uses a Windows socket to initiate TLS communication. This method is not specific to Cobalt Strike. Moreover, since Shodan does not foresee the search for JA3 it is not possible to use it as a search method.
9. JA3S fingerprint
After creating JA3, a new method was created for the TLS handshake server-side fingerprint, the TLS Server Hello message. The JA3S method is to gather the decimal values of the bytes for the following fields in the Server Hello packet: Version, Accepted Cipher, and List of Extensions.
It is possible to extract all JA3s from a known C2 list to cluster them and expand the search based on other similarities. This is out of scope for this article and in any case, there would still be the risk of too many false positives.
Following the most used JA3s based on the previously showed Shodan results:
10. JARM TLS fingerprint
Similar to JA3/JA3S, JARM has the ability to fingerprint the TLS values of the remote server. It does this by interacting with the target server sending 10 TLS Client Hello packets and recording the specific attributes from the replies. It will then hash the result values and create the final JARM fingerprint.
When you scan a Cobalt Strike server using JARM, the results you get back are dependent on the Java version that is used. According to Cobalt Strike’s documentation, OpenJDK 11 is the preferred version that needs to be installed by the operators. This makes it easier to identify a potential Cobalt Strike server, however, you should be aware that this approach is also prone to false positives. This is because many other legitimate servers on the internet use this version of Java to operate their web applications.
The JARM fingerprint that corresponds to a default configuration of the Cobalt Strike is:
Default JARM:
07d14d16d21d21d00042d41d00041de5fb3038104f457d92ba02e9311512c2
Other JARMs related to Cobalt Strike servers can be found here. This method is prone to many false positives and can only help a defender or a CERT team understand if an IP could be related to a Cobalt C2, but it cannot be used as a main method to hunt servers in the wild.
The following image shows the most used JARMs, based on Shodan’s results:
11. Region and hosting provider
If any of the searches described above return too many results you can apply a filter based on the specific hosting provider/org, ISP, and/or region.
Check this article to see an example of which hosting providers are prone to host Cobalt servers.
Here you can find an example of an optimized Shodan search taken by the mentioned article that filters only IPs related to the ReliableSite organization.
Once a specific provider has been identified as suspicious, it is possible to use it as a filter in Shodan and run all the searches described above to pivot for further findings.
12. ASN/ISP scanning with Nmap script
Threat actors — when deploying Cobalt Strike C2s — not only use the same configurations on each server, but also deploy C2s on the same subnets/range.
If you identify a subnet of interest you can scan it with Nmap to download the beacon configurations and thus identify other active Cobalt Strike IPs. This way you can expand your list of malicious IPs to block. To grab beacon configuration you can use different scripts like this one.
So, let’s take a Conti example where Threat Actors deployed a C2 on 162.244.80.235. Scanning the subnet, it is possible to find more Cobalt Strike C2s (possibly attributed to Conti) with the same configurations. Check this article for additional details.
13. Pivoting the HTML hash
For web servers, the Shodan crawlers calculate a numeric hash of the website. To find identical websites there’s the http.html_hash property, search filter and facet. http.html_hash is a numeric hash of the HTML for the website. You can also generate the hash with this tool.
Based on how the Cobalt server is configured the hash value could be null based on the default settings (though this in itself can potentially be an identifier). If instead the Threat Actor has in any way modified the default configurations, a hash value will be generated. It is possible to pivot on the html_hash to find out which other Cobalt servers have been seen with that same hash in order to cluster them.
Here is an example starting from the previously described search:
As you can see, the following http.html_hash:-171462651 has 4 results but if you remove the filter related to the “Cobalt Strike” product, the results become 11, extending the list of potentially malicious IPs:
14. Pivoting the HTTP Header hash
Shodan also extracts the http.headers_hash that can be used to identify a possible Cobalt Strike server. The list of the main hashes related to this field is:
As in the previous example, if you check the http.headers_hash:-1885449825 you will see a total of 9 results. If you remove the filter related to the “Cobalt Strike” product, the results become 16, extending the list of potentially malicious IPs:
15. Watermark (License ID)
One type of information that is often relevant in the analysis and investigation of intrusions involving Cobalt Strike 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.
Many servers use the “0” watermark, which is linked to pirated versions of the product that have been leaked on underground forums.
Other watermarks have been attributed in the past to different threat actors like:
- 305419896 attributed to an affiliate of the Maze ransomware group
- 1359593325 attributed to Trickbot-related operations
- 1580103814 attributed to the BazarLoader.
- and more.
You can check how many watermarks have been spotted by Shodan using this search:
Next steps…
Which of these techniques is the most effective?
Now that we have listed all the techniques it would be very interesting to understand which is the best and most reliable.
To check which method is the most effective, once you have downloaded the list of IPs deriving from a specific Shodan search, you can try to download the Cobalt Strike beacon configurations from the servers. By observing how many servers return a result, you can calculate the percentage and consequently draw up a ranking.
Furthermore, you can understand how many overlaps are present in the various searches to get an idea of which searches can be combined together to have the largest and most reliable list with the least number of searches.
Conclusion
The article explains 15 techniques for identifying active Cobalt Strike servers. Each of these techniques can be combined with others to get the most reliable Cobalt Strike IP list. Furthermore, some of these techniques can also be used as a basis for fingerprinting various malicious infrastructures managed by different threat actors.
Happy Hunting & follow me on Twitter!
References
I highly recommend this presentation which deals with this topic:
https://github.com/aaronst/talks/blob/master/scanttouchthis.pdf
Moreover below you can find how Mandiant approach the malware infrastructure monitoring and how is important this activity for the Threat intelligence agencies:
Other references:
https://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects
