This blog post is the first in a series that will cover basic threat investigation and threat hunting techniques using network metadata from Cognito Stream.
In a previous post, we described the importance of having access to the right data and its impact on the expedience of investigation outcomes. This first installment will focus on one of the enriched metadata attributes previously discussed – JA3 hashes.
As a brief recap for those less familiar with JA3 and JA3S, the original premise is that the client initiating the TLS connection, TLS Client Hello (JA3), and the server responding to the client, TLS Server Hello (JA3S), can be fingerprinted. Creating a hash of the client's TLS parameters in the Client Hello (JA3) provides a fingerprint of the OS/browser/application/SSL library being utilized by the client. Likewise, creating a hash of the server's TLS parameters in the Server Hello (JA3S) results in a fingerprint of the OS/application server/SSL library in how it responds to that specific client.
It's expected that hashes may not be unique due to the finite combinations of possible TLS parameters the client and server can choose from. Thus, specific OS, browser, application and SSL library combinations generally produce the same fingerprints. This, in theory, allows the identification of known applications based on a JA3/JA3S combination. More information is available in Salesforce Engineering's original post.
The original premise that specific client/server combinations would always produce the same set of hashes allowing one to fingerprint malicious activity from network metadata was quickly upset by the hacker community. Akamai posted a great blog article on Cipher Stunting which outlines criminal bots manipulating their TLS handshakes to produce different JA3 and JA3S hashes to avoid identification. Yet despite the shortcomings exposed by recent attacks, analysts can still use JA3 and JA3S for investigating suspicious communications between an internal host and an external server¬¬.
Using JA3 in Threat Investigations
Let's cover the more challenging use cases first where JA3, and possibly JA3S, hashes are changing frequently between the client and server, or there is an abnormal number of JA3 hashes observed from a single host.
Use Case 1: Frequently changing JA3/JA3S hashes
In this first use case, there is a possibility the attacker is trying to thwart identification based on JA3.
Normal apps, such as browsers, should always generate the same JA3 to a particular server. If you determine the hashes are changing unexpectedly, this could be a sign that the client's TLS parameters are being intentionally manipulated to evade detection.
Use Case 2: Numerous JA3 hashes from a single host
What about when a host seems to be generating large number of unique JA3 hashes for its TLS communications? In this case, knowing how your network and the services used by the organization behave can help you spot something looking seriously out of place.
For myself, to determine what may be normal, I performed “back-of-the-napkin” analysis of JA3 hashes being utilized by hosts (clients) in a handful of environments. In my situation, I found that the typical number of unique JA3 hashes observed over the span of a week from a single host range from 10 to 27. For the environment depicted in the graph below, the mean number of JA3 hashes is 12.5. Eyeballing this graph tells us that a host using between 11 and 20 unique JA3 hashes in any one week can be considered normal for an appreciable fraction of the machines in this environment.
Having this type of understanding helps you spot when something is out of place for the hosts in your network. You could further break this out by user machines and data center systems, but the methodology remains the same.
With these results, I then analyzed a few widely used SaaS products to get an idea of how JA3S hashes looked like when being accessed by a number of OS/browser combinations. This lets me understand what normal JA3S hashes may look like. For one SaaS, the JA3S being returned were almost always the same, even when the JA3 hashes from the clients varied based on source OS and browser. Another service revealed almost complete uniformity in both the JA3 hashes from the clients (Windows / Mac, Chrome / Edge) and uniformity in the JA3s hashes from the server.
For cases where the JA3 or JA3S hashes vary unexpectedly, or there is a large quantity of hashes, knowing how your typical host behaves and the services they normally access will help you investigate if there is a suspected threat.
Use Case 3: Unvarying and unknown JA3/JA3s hashes
Let's tackle the final use case where you have unvarying and unknown JA3 and JA3S hashes for suspicious client and server communications.
With the unknown JA3 and JA3S hashes in hand, there are some basic questions you should ask yourself to determine what you're most likely looking at. Here is a decision tree to help you think through the options.
With the answers to these types of questions, you can start to build a case whether the suspected communications are a threat. You may even uncover additional hosts in your environment that also have similar suspicious communications.
Having a general understanding of the client and server JA3/JA3S hashes for the services your organization consumes over TLS can help identify whether an attacker is trying to avoid detection by generating many unique JA3/JA3S hashes. Knowing how many unique JA3 hashes you can typically expect from a single host in your environment is key.
At the same time, observing a single unique pair of hashes (or small number of pairs) from a set of hosts to a set of servers can help identify a suspected attacker's footprint. This may be the only indication of potential malice when other detection-based methods have not triggered.
By knowing the general use and frequency of unique hashes in your environment, JA3 and JA3S fingerprinting can be valuable to threat investigations. Having access to the right metadata like JA3/JA3S is no longer a luxury and is a hard requirement. It can mean the difference between a rapid response and a missed detection.
Matthew Pieklik is a senior consulting analyst at Vectra. He studied computer science at the University at Buffalo. Prior to Vectra, he was a senior systems engineer at Juniper Networks and a senior security engineer at RigNet amongst other positions held in his 20+ year career in networking and security.