Lion Cipher Lab

Fingerprint clients and servers with JA4+ and pivot on the fingerprints

• Threat Intel Analyst
• Advanced
• ~75 min
• Free · no account required

Why it matters

Infrastructure fingerprinting is how a threat-intel analyst turns one observation into a cluster: given a single suspicious flow, find every other host, tool, or session that shares its machine-level signature. This catalog already gives you two ways to do that on TLS -- JARM, which sends a server ten crafted handshakes and hashes the answers into one 62-character string, and reading JA3/JA4 client hashes out of a Suricata sensor. Both are single fingerprints on a single layer. JA4+ is the advanced generalisation, and the reason it deserves an advanced lab is a shift in kind, not degree: it…

What you'll learn

• the core reframing that makes this ADVANCED: JA4+ is not one fingerprint but a SUITE of components (JA4 client, JA4S server, JA4H HTTP, JA4X cert), so a pivot has several independent indicators instead of one -- the direct contrast with the single-hash JARM lab you may have done
• capturing your OWN TLS traffic to a pcap (dumpcap/tcpdump) from curl, a browser, and a self-hosted benign beacon -- and why capturing your own traffic keeps you on the right side of the authorization line JARM's active probing sits on
• running FoxIO's JA4+ tool against a pcap and reading JA4/JA4S/JA4H/JA4X out of its JSON output, one flow at a time
• reading the human-readable a_b_c JA4 format: what the 'a' prefix encodes (transport, TLS version, SNI present, cipher/extension counts, ALPN) and what the 'b' and 'c' hashes summarise (sorted ciphers; sorted extensions + signature algorithms)
• why JA4 IGNORES GREASE values everywhere and SORTS the cipher list before hashing -- the two design choices that make it survive the client-side cipher/extension-order randomization that breaks a naive JA3
• the durable judgment: WHICH component survives client evasion -- the client can shuffle or GREASE its ClientHello, but JA4S (server) and JA4X (cert) are not under the client's control, so they are the pivots that hold when the client mutates
• getting JA4H (HTTP) out of an encrypted capture legitimately, by decrypting YOUR OWN session with an SSLKEYLOGFILE you generated -- never someone else's traffic
• using a fingerprint as a PIVOT: clustering your own flows by shared component, then cross-referencing the public JA4 database (ja4db) to put an application/label on a hash
• the explicit JARM contrast: one active server hash vs a passive multi-component suite computed from a capture -- when each is the right reach, and why the suite gives you more places to pivot and more ways to be fooled
• the failure modes: CDN/shared-host false clusters, a client that mimics a common JA4, a server behind a proxy, database staleness -- and the never-single-signal rule that a fingerprint is a lead, never an attribution

Steps in this lab

1. Read this first: your own traffic, public data, no one else's packets
2. The shift that makes this advanced: a SUITE, not a single hash
3. Read a JA4 string before you make one: the a_b_c format
4. Why JA4 survives randomization: GREASE out, ciphers sorted
5. Install the JA4+ tool and tshark
6. Capture your OWN traffic to a pcap
7. Compute the suite: read JA4, JA4S, and JA4X from the JSON
8. Get JA4H (HTTP) by decrypting YOUR OWN session
9. Pivot: cluster your flows, then cross-reference the public JA4 database
10. JA4+ vs JARM, the failure modes, and doing it better

Open the full interactive lab →