Spotting rogue TLS connections with JA3 fingerprinting

It’s impossible to imagine modern networks without the security and privacy provided by Transport Layer Security (TLS) encryption. If a server and client need to secure their traffic from prying eyes – HTTPS web servers, VoIP phone calls, Instant Messaging, numerous types of application traffic – then today it’s highly likely that TLS, preferably versions 1.2 or the more recent 1.3, will be employed to do the job.

Unfortunately, this applies to cybercriminals too, who have enthusiastically taken up the idea of hiding malware communication inside innocuous-looking TLS traffic. Once attackers have a foothold inside a network, they need a command & control (C2) channel to upload a payload, issue further instructions, or siphon data from a victim. Wrapping this C2 with TLS simply makes it harder to detect, particularly when the connection is hiding inside apparently mundane HTTPS on port 443.

THE TLS CHALLENGE

For defenders, this poses a challenge – how can good traffic be distinguished from bad when all TLS-encrypted traffic looks the same? One approach to analyse or blocklist the server certificates used to set up TLS, but like all blocklists this requires constant updating and risks being out of date. A more radical technique is TLS/HTTPS inspection, which decrypts, inspects, and re-encrypts traffic somewhere in the network. However, this comes with some off-putting downsides:

By design, TLS inspection breaks trust, which has upset agencies such as US-CERT while creating new security risks of its own
TLS inspection adds latency, complexity and expense, not helped by the rapidly growing volume of TLS traffic
Not all encrypted traffic uses TLS (e.g. SSH, most VPNs and Google’s QUIC)
In some situations, breaking trust might infringe compliance regimes such as the EU General Data Protection Regulation (GDPR)

ENTER JA3 FINGERPRINTING

As our JA3 Fingerprinting: Encrypted Threat Detection white paper explains, JA3 fingerprinting was proposed in 2017 by Salesforce researchers John Althouse, Jeff Atkinson, and Josh Atkins as an elegant way to sidestep these problems using a type of Encrypted Traffic Analysis (ETA). Rather than decrypting traffic to peer inside, the idea was to fingerprint the properties of the TLS handshake, which turns out to be unique for each combination of client application and server.

This is because there are a large number of variables each end must agree during the ClientHello exchange such as TLS version, accepted cipher suites, elliptic curve groups, elliptic curve point formats, and TLS extension lengths. Once the pattern of this exchange is turned into a 32-character hash using MD5, defenders have an identifying signature for each application initiating communication.

In their background on JA3, the researchers offered the example of the banking Trojan Trickbot malware trying to obscure itself by communicating using the Tor client from inside a network. This malware’s ClientHello routine results in the hash:

JA3 = 6734f37431670b3ab4292b8f60f29984

When applied to the resulting C2 ServerHello response this is called the JA3S, which for Trickbot using the same version of TLS and Tor looks like this:

JA3S = 623de93db17d313345d7ea481e7443cf

Arguably, this is just a more sophisticated version of filtering TLS certificates, because the detection system need only look for known bad signatures within a database. The advantage of JA3 is that it can detect rogue TLS regardless of evasion techniques such as IP address, constant changes in domain, or where legitimate websites are being abused for C2. Cleverer still, adding the JA3S fingerprint to the mix offers insurance against the theoretical possibility that malware and legitimate applications might generate the same hash.

A GOOD STARTING POINT

As with any signature-based system, JA3 is limited by what to do when encountering unknown applications or malware for which no hash yet exists. An extreme example of this is what Akamai dubbed ‘cipher stunting’, where botnets it was tracking tried to evade JA3 by randomising the cipher suites used in ClientHello. Rather like polymorphic malware a generation ago, this expanded the signature count into the millions and billions, where it risked becoming unmanageable.

Ironically, defenders should be encouraged by this – clearly JA3 detection was a big enough threat to bot C2, where the price for detection, a lost client, can be high. With TLS traffic growing, it’s a war of cat and mouse that will go on. It won’t do the whole job but what matters is that JA3 fingerprinting is still a simple, effective layer that no defender will want to be without.

To find out more about JA3 Fingerprinting, download our  White Paper