What is a JA3 Fingerprint? How TLS Client Fingerprinting Works

May 2026

A JA3 fingerprint is a 32-character hash that identifies the software a client used to open an encrypted connection, derived from the shape of its TLS handshake (Salesforce, 2017). It is a quietly powerful technique: it lets you recognise the software behind a connection from the handshake alone, even when the IP, the domain, and the certificate all change.

What makes it interesting is how much, and how little, a single fingerprint reveals. It identifies the toolkit rather than the operator, which is why one JA3 hash in recent CyberDesserts research ran across four unrelated campaigns at once, from AndroxGh0st credential harvesting to Interlock ransomware. Read it for what it is and it becomes a sharp instrument for clustering, triage, and threat hunting.

By the end you will know what a JA3 fingerprint is, how it is built, how to pull one from your own traffic, and how to read what it tells you, worked through a real fingerprint from research telemetry.

Get threat intelligence like this delivered to your inbox. Subscribe to CyberDesserts for practical security insights, no fluff.

What a JA3 fingerprint is and how it is built

JA3 is a method of fingerprinting a TLS client from the Client Hello packet it sends to begin a handshake. It was created at Salesforce in 2017 by John Althouse, Jeff Atkinson, and Josh Atkins, and is now widely supported across network security tools (Salesforce, 2017).

The method reads the decimal values of five fields from the Client Hello, in a fixed order: the TLS version, the accepted cipher suites, the list of extensions, the elliptic curves, and the elliptic curve point formats. Those values are concatenated into a single string, using commas between fields and hyphens between values within a field. The string is then hashed with MD5 to produce the 32-character fingerprint.

A real example from the original specification makes it concrete:

769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0
  -> ada70206e40642a3e4461f35503241d5

The number 769 is the TLS version, the long middle list is the cipher suites the client offered, and the trailing groups are extensions, curves, and point formats. Change any of those and the hash changes. There is a server-side equivalent, JA3S, which applies the same idea to the Server Hello using three fields, and the two are often paired to fingerprint both ends of a negotiation.

The reason this works is that the contents and ordering of a Client Hello are decided by the library and configuration the client was built with, not by the user. A given build of a scanning tool, a browser, or a malware family produces the same Client Hello every time, so it produces the same JA3 hash. Same build, same fingerprint.

What JA3 is used for, and where you'll encounter it

Because the fingerprint is stable across destination IPs, ports, and certificates, JA3 lets a defender recognise a client by its TLS behaviour even when everything else about the connection changes. That makes it useful for clustering activity that shares tooling, spotting automation hiding behind rotating infrastructure, fingerprinting malware that beacons over TLS, and enriching an indicator with the question of what software produced it.

You will meet JA3 in more places than most introductions mention:

• Network sensors. Suricata and Zeek both compute JA3 and log it next to their TLS records, which is where most defenders first encounter one.
• SIEM and detection pipelines. The hash is indexed as a searchable field, so an analyst can pivot from a single connection to every other client carrying the same fingerprint.
• Threat-intelligence feeds and IOC libraries. Hashes for known malware and scanner toolkits are published and traded the same way IPs and domains are.
• Bot management and fraud tooling. WAFs and anti-fraud systems use TLS fingerprinting to separate genuine browsers from automated clients impersonating them.

The common thread is recognition without identity. JA3 tells these systems that two connections came from the same kind of client. It does not tell them who the client belongs to, which is the distinction the rest of this piece turns on.

How to read a JA3 from your own traffic

Generating a JA3 takes a network sensor and one configuration switch. Enable JA3 fingerprinting in suricata.yaml under the TLS app-layer settings, then point Suricata at a packet capture and filter the TLS events it writes to eve.json:

# suricata.yaml -> app-layer.protocols.tls.ja3-fingerprints: yes
suricata -r capture.pcap -l ./output
cat output/eve.json | jq 'select(.event_type=="tls") | {src_ip, ja3: .tls.ja3.hash, ja4: .tls.ja4}'

Each TLS event carries the hash at .tls.ja3.hash, and on Suricata 7.0.3 and later the JA4 fingerprint appears in the same record. Zeek computes JA3 through a community script and writes it to its ssl.log. The research telemetry in the next section came from Suricata running as a host-mode sidecar on a live interface, with JA3 and JA4 fingerprinting both enabled, rather than from a saved capture, but the field you read is identical either way.

Generating the fingerprint is the easy part. The skill is knowing what a match does and does not prove.

One fingerprint, four operators: JA3 in real traffic

In a 120-hour AI infrastructure research deployment, a single JA3 hash, b885946e72ad51dca6c70abc2f773506, surfaced across four unrelated operations. AndroxGh0st credential harvesting, reconnaissance against vLLM endpoints, a multi-CVE exploit burst, and the Interlock ransomware campaign that AWS documented separately against Cisco firewalls in March 2026 (AWS Security Blog, 2026).

Nothing else lined up. The source addresses, the user agents, and the post-exploitation behaviour varied across all four. The JA3 was the sole link between them, and it linked them because they ran the same scanning toolkit, not because they were the same crew. The full cross-campaign analysis, including how often the hash appeared and why that frequency points to operator tooling rather than a commodity default, is in the AndroxGh0st and TLS fingerprinting research, and the deployment behind the credential harvesting is documented in the exposed credentials pipeline research. Earlier windows of the same programme, before TLS fingerprinting was in place, characterised scanners by user agent and behaviour rather than JA3; that work is in the AI infrastructure scanning research.

The teaching point sits one level up from the finding. If you had matched only on that JA3 and trusted the public source, you would have labelled AndroxGh0st credential theft as Interlock ransomware with total confidence. The hash was right. The conclusion would have been wrong.

What a JA3 fingerprint can and cannot prove

Here is the rule the worked example earns. A JA3 fingerprint is strong evidence of the tool and weak evidence of the operator. Treat it as the former and it clusters activity, triages alerts, and surfaces automation. Treat it as the latter and it manufactures false attribution: two unrelated crews can run the same off-the-shelf scanner and emit the same hash while sharing nothing else at all.

This is also why a fingerprint, or any single indicator, should never carry an attribution on its own. The same research deployment caught the AndroxGh0st harvester on an IP that read 2 of 91 on VirusTotal in May 2026, a near-clean score on a host that was actively stealing credentials. One signal said benign, the JA3 pointed at the wrong operator, and only the convergence of independent artifacts, the documented POST body, the user-agent pattern, and a triggered canary token, supported a confident call. A fingerprint is a lead, not a name.

Used that way, JA3 is one of the more useful enrichment signals a defender has. Used as a verdict, it is a fast route to a confident mistake.

It helps to keep the layers separate: the tool is one build, the toolkit is a scanner several groups may share, the malware family is what it serves, and the operator or threat actor is whoever runs it. A JA3 identifies the first two, never the last.

← Scroll to see full table

Want to know what runs behind the fingerprints? The Threat Actor Tools Guide breaks down the tooling that sits behind the fingerprints.

The JA3 family: JA3, JA3S, and JA4

JA3 is the client-side fingerprint, but it belongs to a small family worth knowing as a set.

← Scroll to see full table

Source: Salesforce (JA3 and JA3S, 2017); FoxIO (JA4)

JA3 has known weaknesses, and the biggest is no longer an evasion trick. Since early 2023, Chrome has randomised the order of its handshake extensions (from version 110), with Firefox following, so the same mainstream browser now produces a different JA3 on almost every connection; an attacker can trigger the same effect deliberately by reordering fields. Google's GREASE values can also perturb fingerprints unless they are normalised out, which the original method accounts for. Modern TLS 1.3 clients negotiate in ways that can make distinct tools look alike.

JA4, part of a broader JA4+ family from FoxIO, is the successor built to close those gaps. It sorts the handshake fields before hashing, so reordering no longer defeats it, and its structured format makes a fingerprint readable rather than an opaque string. JA3 is still worth understanding because most tooling and most existing intelligence still speak it. Knowing both, and the limits of each, is the working position.

Summary

A JA3 fingerprint tells you which tool knocked on the door. It does not tell you whose hand was on it.

Read it that way and it is a sharp instrument for clustering, triage, and enrichment. The fingerprint is where the investigation starts, not where it ends.

CyberDesserts publishes hands-on security research grounded in primary data. Subscribers get new analysis the moment it lands, no sales pitches, no fluff.

References

1. Althouse, J., Atkinson, J., Atkins, J. TLS Fingerprinting with JA3 and JA3S. Salesforce Engineering, 2017.
2. AWS Security Blog. Interlock ransomware campaign targeting enterprise firewalls. 18 March 2026.
3. CISA, FBI. Known Indicators of Compromise Associated with AndroxGh0st Malware. Joint Cybersecurity Advisory AA24-016a, 2024.
4. Suricata. Official documentation, JA3 fingerprinting. Open Information Security Foundation.
5. FoxIO. JA4+ network fingerprinting.
6. VirusTotal. IP reputation lookup (detection ratio observed May 2026).