JA3 has been gaining some popularity within the security community to easily flag known tools or malware using a signature which can be generated easily from the Transport Layer Security (TLS) values used during communication which employs such encryption. Though JA3 signatures are easy to use and seem like an easy way in which defenders can detect malicious communications, they can just as easily be tampered with to evade detection and blend in with normal TLS/SSL traffic.
In this post, we will begin to uncover some of the methods that are implemented in the wild by command and control (C2) servers and agents to evade detection. Our focus will be on evasion techniques utilized by well-known C2 Frameworks that utilize several techniques to evade detection. With respect to JA3 signatures specifically, some efforts have been made by the developers of these tools to avoid detection. Additionally, there is clear evidence that these same techniques for evasion are actively being used by malware to bypass detection.
Unraveling JA3/S: A Primer
First, let’s briefly summarize on what JA3 is and why it can be used to detect malicious traffic. JA3 is a method of fingerprinting the TLS handshake that was first published by John Althouse, Jeff Atkinson, and Josh Atkins from Salesforce back in 2017. Internet traffic which implements TLS will transmit values to each other in an effort to establish a secure connection. The following values are used to form a JA3 hash (SSLVersion, Cipher, SSLExtension, EllipticCurve, EllipticCurvePointFormat) and for the JA3S hash (SSLVersion,Cipher,SSLExtension). These values are transmitted in the clear prior to encryption so that the client and server know which type of encryption ciphers are available to use. These are the basis of what is used to form a JA3/S hash. These values can be used to ID certain types of malicious traffic when reliable. For a more thorough explanation you can see the original post from SalesForce.
Understanding JA3/S Randomization and Cipher-Stunting
As previously mentioned, part of the JA3/S signature is derived from the cipher. The cipher list is transmitted during the client/server hello negotiation. An example of this can be seen in the image of a packet capture below.
During this process, the server will choose the highest available cipher that is supported by both ends of the connection. This means that for every connection made between one endpoint and one server, the JA3/S signature would be expected to be the same and result in the same JA3/S signature. However, by using JA3/S randomization, the server will choose a random cipher from the list of supported ciphers. By using a different cipher, the JA3/S hash which is derived from these values will end up being different.
To evade detection, malware authors will have to tamper with the TLS values used which are the basis of the JA3 signature. By doing so they can successfully bypass detection. An easy way to do this is by randomly choosing a cipher suite. This is technique is known as JA3/S randomization.
A Growing Trend: JA3/S in C2 Frameworks
The Akamai research team has shared insights on this matter. In summary, the findings of their research show that TLS fingerprints jumped from 18,652 distinct fingerprints globally in August 2018 to more than 1.3 billion the end of February 2019. This suggests that following research and interest in JA3/S fingerprinting by the security community, malware authors and bot controllers implemented techniques to circumvent TLS signatures.
JA3/S randomization/Cipher-Stunting has also started to creep into C2 Frameworks like Empire as of the version 3.0 master release according to the Github changelog. The image below shows the source code from Empire GitHub, which highlights a sample way in which JA3 randomization can be achieved.
Evading Detection: More Than One Approach
As with all novel techniques used in the security community to identify threats, attackers have always been quick to change tactics to circumvent detection strategies. While we have seen red-team tools utilize JA3 randomization to thwart detection other methods exist to do the same. As the adage says, “there is more than one way to skin a cat." For example, JA3 impersonation can be done by mimicking the TLS values of common browsers or even using the underlying operating system HTTPS client to bypass detection.
Conclusion: The Challenge of Detection
It becomes clear that with any techniques that can be utilized to catch “badness” by security practitioners, attackers will adapt swiftly to continue to operate without being detected. Identifying C2 Frameworks with JA3 signatures becomes difficult when the Framework is implementing JA3/S randomization or another technique. Security tools and techniques defenders use need to be very flexible and be able to adapt quickly to changes. If they do not, then C2 will continue to evade detection and operate under the radar of cyber security professionals. JA3 signatures, even without tampering, are a low fidelity indicator of malicious activity and the techniques described in the post make them even less reliable due to the ease in which they can be manipulated.
With this in mind, JA3 signatures can be used as supplemental indicator of compromise but should not be heavily relied upon due to the low fidelity and the ease in which they can be tampered with. Signature-based detections are only as good as the data underlying them can be trusted and how well they are maintained. Ideally detection of C2 needs to utilize a multi-faceted network detection strategy that is nimble and able to generalize. Of course, this approach requires a much greater investment but will pay off significantly in the long run.
Check out my second blog where I examine a method known as malleable C2 profiles.