Shulou(Shulou.com)05/31 Report--

How to identify malicious Cobalt Strike servers, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Abstract

Cobalt Strike is a penetration platform for security professionals to simulate targeted attacks and post-penetration actions by advanced hackers. The tool was developed and licensed by Washington-based Strategic Cyber LLC, whose illegal use of the tool is regulated and subject to export controls. Nevertheless, the Cobalt Strike framework has become the most popular choice for this type of software, including other paid suites such as Metasploit Pro and Core Impact. Although Cobalt Strike is not the only platform used by pirated users and cybercriminals, it has been used by various threat groups, including APT32, who use the tool for initial penetration, and the Cobalt group of the same name relies heavily on the framework.

Considering that security testers, and more importantly, malicious attackers, make extensive use of the Cobalt Strike platform, it is obvious that it is necessary to identify Cobalt Strike servers connecting to corporate network assets.

Although the detection method has been disclosed, it is still unpatched by a large number of Cobalt Strike servers to allow fingerprint identification and other subsequent detection. By sampling the Cobalt Strike servers in the opposition and comparing the fingerprint identification methods to help the defenders better track and monitor the framework. Tracking the Cobalt Strike server can help the red team detect the activity of the blue team without modifying the Cobalt Strike default configuration.

Although patches make specific fingerprint identification methods more difficult, the Cobalt Strike server is still quite exposed and relatively easy to find. Many Cobalt Strike servers did not update their systems before the patch was released, while the newly deployed ones used the upgraded software.

Recently deployed Cobalt Strike servers are more likely to deploy a newer Cobalt Stike version (beyond 3.12) while continuing to use the default TLS certificate, so this is still a reliable detection mechanism.

Compared with historical threat activity, most malicious and neutral users of the current Cobalt Strike server seem to use the default, unpatched Cobalt Stike configuration, perhaps to be compatible with other Cobalt Stike servers, or simply because the default settings work well, so users don't bother to change anything.

Detection of Cobalt Strike servers can help defenders establish early warning mechanisms in their corporate networks, pre-empting the blue team.

Disclosed Cobalt Strike server identification method

On February 19th, 2019, Strategic Cyber LLC released Cobalt Strike Team Server Population Study. Part of the purpose of this study is to investigate the license status of Cobalt Strike software and to identify and analyze significant changes to the version of the software currently in use.

This study confirms a number of ways to identify Cobalt Stike servers in the field:

The Cobalt Strike server comes with a default security certificate, which can be used for fingerprint identification unless the administrator modifies the default certificate:

SHA256: 87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c

Serial Number: 146473198

When enabled, the Cobalt Strike DNS server responds to any DNS requests with bogon (fake) IP:0.0.0.0 (this is not a unique feature of CS servers)

The default control port for Cobalt Strike servers is 50050/TCP, which is not open on most other servers.

The "404 Not Found" HTTP response of the Cobalt Strike server is different from the NanoHTTPDweb server and can be detected.

Overall, the most reliable method in the above list is to fingerprint the Cobalt Strike server using the default security certificate. The rest of the detection methods are uncertain, and all methods have high confidence after mutual verification with other methods. For example, any server that uses port 50050 and provides NanoHTTP web server-specific HTTP responses is more like a Cobalt Strike server than a server that displays only HTTP response signatures.

Method based on NanoHTTPD response

The Cobalt Strike server is based on NanoHTTPD and was first released in 2012. NanoHTTPD is an open source web server framework based on java. The NanoHTTPD server response contains an extra null byte: "HTTP/1.1" is followed by a null byte (0x20), which does not exist in other web server responses.

On January 2, 2019, Cobalt Strike version 3.13 was released. According to a statement issued by Cobalt Strike, one of the changes compared to previous versions is the "removal of extraneous null bytes from the HTTP status response."

Any HTTP response from a Cobalt Strike server prior to 3.13 contains this empty byte, and you can use the scanner to retrieve the HTTP response to search for them. You can also manually grab the connection to the Cobalt Strike server, and you can easily see this extra space. Because the Cobalt Strike instance running the cracked version is not updated or patched, this approach increases the possibility of discovering a malicious Cobalt Strike server.

Security company Fox-IT released a study of Cobalt Strike servers on February 26, 2019, which not only provides details and how to identify servers prior to version 3.13 (corresponding to extra null characters in HTTP responses), but also includes a list of more than 7000 Cobalt Strike host IP found using this test method in Rapid7 public data from 2015 to 2019.

Similarly, on February 27, 2019, the Zhi Chuangyu security research team published a blog detailing their use of NanoHTTPD 404 Not Found response exceptions and null byte exceptions reported by Strategic Cyber LLC to identify Cobalt Strike servers. They found fewer servers in ZoomEye's data, but still more than 3000. According to the Chuangyu report, the open source NanoHTTPD code that builds Cobalt Strike responds as follows:

HTTP/1.1 404 Not FoundContent-Type: text/plainDate: Day, DD Mmm YYYY HH:MM:SS GMTContent-Length: 0

Knowing that Chuangyu's detection logic is based on this discovery. However, they then observed that the order in the HTTP response may actually be different, and in some Cobalt Strike system responses "Content-Type" is displayed after "Date".

Detection method based on JA3 fingerprint

For users with detailed network traffic data, JA3 is a more reliable way to discover Cobalt Strike servers. The open source JA3 project, developed by three Salesforce researchers, can detect suspicious TLS browsing by fingerprinting the HTTPS negotiations between the server and the client. TLS/SSL versions, acceptable cipher suites, and elliptic curve details (such as elliptic curve point format) can be fingerprinted just as browsers can be fingerprinted by other versions, add-ons, and other features specific to the browser.

JA3 signing is for the client, while JA3S signing is for the server. In the case of Cobalt Strike, the TLS negotiation between Client beacon (using Windows sockets to initiate communication) and the Cobalt Strike server running on Kali Linux has been fingerprinted. These fingerprints need to be used together to reliably find the Cobalt Strike server. Although Cobalt Strike consumers can partially avoid this detection through redirection, many Cobalt Strike servers do not use such proxies.

JA3 and JA3S signatures can be used with tools such as Zeek/Bro and Suricata. Data from these network detection tools can then be entered into a SIEM such as Splunk. Signatures for JA3 and JA3S can be obtained from Salesforce's Github account and other sources.

JA3

The default SSL/TLS certificate of Cobalt Strike is fixed, so this certificate is generally used as an eigenvalue to discover the Cobalt Strike server. The SSL default certificate passed by the server to the client has obvious characteristics:

Carly EarthGrad staged CyberspaceWith where and where OhmCobaltStrike reignedOUTUBANCEPenTestingmcnagogical Major CobaltStrike

The JA3 method is used to collect decimal byte values for the following fields in a Client Hello packet: version, acceptable password, extended list, elliptic curve cryptography, and elliptic curve cryptographic format. Then concatenate these values together, split the fields with "," and separate the values in each field with "-".

The order of these fields is as follows: TLS version information, acceptable passwords, extended list, elliptic curve cryptography, and elliptic curve cryptographic formats.

Take the connection traffic of CobaltStrike4.1 as an example.

771 mast 49188-49192-61-49190-49194-107106-49162-49172-53-49157-4916757-56-49187604918949193103-64-4916149171747491564916651-50-49196157-4919849202-16316919915919749201158162 (if there are no above fields, the values of these fields are empty)

The MD5 hash values of these strings are then calculated to generate 32-character fingerprints that are easy to use and share, which are the fingerprints of the JA3 TLS client. For example, the above CobaltStrike4.1 client fingerprint: fa704723a210632b2ff9ad03be418651

JA3S

After creating the JA3, the server of the TLS can be identified in the same way, that is, the TLS Server Hello information can be identified by fingerprint. JA3S collects decimal byte values for the following fields in the Server Hello packet: version, acceptable encryption algorithm, and extension list, and then concatenates these values, using "," to separate the fields, and "-" to separate the values in each field.

The order of these fields is as follows: TLS version information, acceptable passwords, extended list

CobaltStrike4.1 server: 771, 49192, 9-> 5513ab2983a0db88fadd353de0341e7c

The same server creates Server Hello messages in different ways based on the contents of the Client Hello information machine, so it is not possible to fingerprint the server based solely on its Hello messages, as JA3 does. Although servers respond differently to different clients, their responses to the same client are always the same.

For example, the client is sending TLS Client Hello packets, where the data is all A. Therefore, the content of the server's response is also made up of A, and will always use A to provide the same response. At the same time, another client is also sending packets, and the content is B. Similarly, the server now responds with B, and always responds with a B string of B. As you can see, the server responds differently to different clients, but for each client, it always responds in the same way.

In this log output, JA3 is on the left and JA3S is on the right, using the same client to interact with the same server four times. Then, more than 4 interactions were conducted using different clients again. It is not difficult to find that the response mode of the server is always the same for the same client, but different for different clients.

For example, both Meterpreter of MetaSploit and Beacon of CobaltStrike (not version 4.1) use Windows sockets to initiate TLS communication. On Windows 10, JA3=72a589da586844d7f0818ce684948eea (specify IP address), JA3=a0e9f5d64349fb13191bc781f81f42e1 (specify domain name). Because other ordinary applications on Windows use the same sockets, it is difficult to identify malicious traffic. However, the C2 server on Kali Linux responds to the client application in a way that is unique to the way a normal server on Internet responds to the socket. Although servers respond differently to different clients, their responses to the same client are always the same. Therefore, if combined with ja3+ja3s, you can identify this malicious communication without considering details such as the destination IP, domain name, or certificate.

Introduction of Detection method based on JARM

Recently, Salesforce researchers published an article called Easily Identify Malicious Servers on the Internet with JARM and a JARM scanning tool on Github. the related content has been discussed by some foreign researchers.

JARM is an active TLS server-side fingerprint tool with the following main uses:

Quickly verify that a group of TLS servers use the same TLS configuration

Partition TLS servers through TLS configuration and identify companies that may belong

Identify the default application or infrastructure of the site

Identify malware ClearC control nodes, as well as other malicious servers.

The core of JARM is that TLS Server returns different Server Hello packets according to different parameters in TLS Client Hello. The parameters of Client Hello can be modified artificially, so the corresponding special Server Hello is obtained by sending several carefully constructed Client Hello, and finally the fingerprint of TLS Server is formed. Specific parameters that can have an impact include, but are not limited to:

Operating system and its version

Third-party libraries such as OpenSSL and their versions

The calling order of the third-party library

User-defined configuration

……

As mentioned earlier, TLS servers respond differently to different clients, but their responses to the same client are always the same. Therefore, it is not possible to fingerprint the server just according to JA3S, as JA3 does.

On the other hand, JARM adopts a way similar to fuzz, actively sends 10 TLS Hello packets to the TLS server, analyzes the specific fields in the Server Hello, hashes the responses of 10 TLS servers in a specific way, and finally generates JARM fingerprints.

The 10 TLS client Hello packets in JARM are specially designed to extract the only response from the TLS server. For example:

JARM sends different TLS versions, passwords, and extensions in different order

TLS Clint sorts passwords from the weakest to the strongest. Which password will TLS Server choose?

……

In short, JARM is different from JA3 and JA3/S, which are commonly used in traffic analysis threats:

JA3 and JA3/S are mainly based on traffic, and the server produces different JA3S fingerprints for different clients.

JARM is completely active to scan and generate fingerprints, and the server can produce unique JARM fingerprints.

Using JARM to identify C2

In the original Easily Identify Malicious Servers on the Internet with JARM text, the author gives a list of C2 and JARM:

Malicious Server C2JARM FingerprintOverlap with Alexa Top 1MTrickbot22b22b09b22b22b22b22b22b22b22b352842cd5d6b0278445702035e06875c0AsyncRAT1dd40d40d00040d1dc1dd40d1dd40d3df2d6a0c2caaa0dc59908f0d36029430Metasploit07d14d16d21d21d00042d43d000000aa99ce74e2c6d013c745aa52b5cc042d0Cobalt Strike07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb10Merlin C229d21b20d29d29d21c41d21b21b41d494e0df9532e75299f15ba73156cee38303

Ideally, if JARM corresponds to C2 only, then we have one more feature to actively discover C2 nodes.

However, when verifying, the 360Quake team searched the JARM corresponding to Cobalt Strike and found 2338 separate IP, but the application of TOP5 is:

Number of applications CobaltStrike team server 1137CobaltStrike-Beacon server server 373Tomcat-Web server 40Weblogic application server 21WordPressCMS blog system 14

You can see that there are other Web applications with the same JARM as the above CobaltStrike, such as Tomcat, Weblogic and WordPress, which open TLS, which means that CobaltStrike is only a subset of the JARM corresponding to the TLS server.

In the later verification, it is found that the JARM fingerprint has no strong correlation with the upper application, and the Tomcat and Cobalt Strike using the same JDK have the same JARM fingerprint, which explains why so many Weblogic and Tomcat applications have been identified.

Therefore, CobaltStrike; can not be judged directly through JARM. Similarly, JARM is not unique to CobaltStrike, and its JARM is related to TLS services in different JDK environments. JARM is only a way to identify the characteristics of the TLS server, can only be used as an auxiliary means, and can not be completely used as the unique fingerprint of the upper application of Web.

After reading the above, do you know how to identify malicious Cobalt Strike servers? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.