The fact that more and more network traffic is encrypted is a good thing as it helps to protect our data. And as the use of TLS encryption increases, so does the number of network device vendors who deploy in-line and are adding MITM decryption capability that can mirror decrypted network traffic to QRadar Network Insights (QNI). But if I choose to leave my network data encrypted, how do I gain visibility into what is happening on my network?
Being able to see which devices are communicating over our networks using flows and QNI isn’t impacted by encryption. And for those protocols that either don’t or infrequently use encryption there is tremendous visibility into those communications. To extend insight into encrypted traffic, QNI has added the generation of JA3/JA3S hashes as part of the QRadar 7.3.3 release.
Overview of JA3/JA3S Hashes:
When an application initiates an encrypted session it starts by establishing a TCP connection with the host and then sends a Client Hello packet. This packet contains a wealth of information including the protocol version along with the cipher suite, compression methods and extensions. The server then provides a response specific to the information contained in the Client Hello packet through a Server Hello packet that is sent back to the application. This handshake occurs at the beginning of every TLS session and allows both devices to negotiate the protocol version, cryptographic algorithms, etc. that will used in their encrypted communications. For the Client Hello packets there are a number of key elements that tend to be very consistent for a given application. Similarly the Server Hello packets consistently respond based on the Client Hello packet received for a given host and application.
What if we could capture the information that is sent in the Client Hello packet and the Server Hello packet and compare these across sessions to gain insight into the application and any changes in behavior? And do so in a consistent and easy to manage way? Thanks to JA3 and JA3S fingerprints, we can do exactly that.
Like traditional fingerprints the JA3 / JA3S hashes provide a standardized way of representing the key elements of the Client / Server Hello packets. They do so by concatenating the TLS Version, Ciphers, List of Extensions, Elliptic Curves and Elliptic Curve Formats as comma separated values and then applying an MD5 hash to create the JA3 or JA3S (where the JA3 is based on the Client Hello and the JA3S is based on the Server Hello).
Some real world examples:
To give you an example of how this works I replayed PCAPs of encrypted network sessions containing malware activity of unknown origin through QRadar Network Insights (QNI). On the Network Activity tab in QRadar I see a fair amount of Suspect Content activity associated with a particular source IP address. I add filters to select this particular source IP and then flows with JA3 hashes:
With these filters applied we see a well-defined set of JA3 hashes across these network sessions. A quick online lookup reveals that these JA3 Hashes are associated with a Tofsee botnet. We can then search Network Activity to identify all network sessions that have this same JA3 Hash. Similarly we can search for other occurrences of the JA3S independent of IP Address or Domain.
The malware above utilized TLS 1.0 for encryption but the creation of JA3 and JA3S hashes works the same for other protocol versions including TLS 1.3.
In this second example I’ve run some additional PCAPs (again containing live malware) through QNI where we can see JA3 and JA3S hashes across both TLS 1.0 and TLS 1.2.
In this case, an on-line search of the JA3 hash shows that it is associated with both Metasploit and CobaltStrike.
It’s interesting to note that the TLS versions used for these sessions are different even though the JA3 hashes are exactly the same. However, we see that the 2 hosts responded with different Server Hellos based on the different JA3S hashes.
Pivoting into QRadar Incident Forensics we can see the JA3 and JA3S text before being hashed. The Client Hello specifies TLS 1.2 in both cases (as shown by the 771 version number at the beginning of the TLSJA3Text field).
Where the Server Hello above responds with version 771 (TLS 1.2) the server below responds with version 769 and downgrades the session to use TLS 1.0.
QNI software available to QRadar customers:
Starting with the QRadar 7.4.0 release which came out early this year, QRadar Network Insights can now be deployed as software on your own hardware. All QRadar customers are entitled to software QNI. It just requires a node license for each instance deployed and sufficient Flows Per Minute (FPM) licensing to accommodate the flows coming into QRadar. If you’re interested in analyzing JA3 / JA3S fingerprints for encrypted traffic on your networks, I would encourage you to download QNI from IBM Fix Central and explore for yourself.
#Highlights#Highlights-home#QRadar