What is JA3/JA4 and how does it help detect C2?

JA3 hashes the TLS ClientHello (and JA3S the ServerHello) into a fingerprint of the TLS library a client or server uses; JA4+ is a more robust successor. They help detect C2 by flagging clients or servers that reuse a known malware TLS stack, computed in Zeek or Suricata. But fingerprints collide (many benign clients share a JA3), can be spoofed (utls, some C2s mimic browsers) and drift with updates, so they are a prioritisation signal only — confirm with beacon timing, destination reputation and host evidence.

JA3, JA4 and TLS Fingerprinting for C2 Detection

JA3 hashes the TLS ClientHello (versions, cipher suites, extensions) into a fingerprint of the client library; JA3S does the same for the server response. JA4+ is the newer, more robust successor. These fingerprints can flag C2 clients that reuse a known TLS stack — but because they are collisions by design and can be spoofed, they are a correlation signal, not a verdict.

Signals at a Glance

Fingerprint	Captures	Use
JA3	Client ClientHello	Flag known malware/C2 client stacks
JA3S	Server ServerHello	Flag known C2 server stacks
JA4	Client, robust to ordering	Successor to JA3; harder to evade
JA4S / JA4H / JA4X	Server / HTTP / X.509	Pivot across server, HTTP and cert

Collecting and Matching

Zeek and Suricata both compute these fingerprints. Log them for all TLS, then match against curated malware fingerprint lists and — more powerfully — against your own rarity baseline:

// KQL: rare JA3 seen talking to few destinations (hunt, not block)
TlsEvents
| summarize clients=dcount(SrcIp), dests=dcount(DstIp), conns=count() by Ja3Hash
| where clients <= 3 and conns > 10
| join kind=inner (TlsEvents) on Ja3Hash
| project TimeGenerated, SrcIp, DstIp, Ja3Hash, Sni
// Rare client fingerprints that beacon to new infrastructure are worth a hunt.

Pair known-bad lists with rarity: a JA3 that matches a public Cobalt Strike/Sliver value AND is rare in your environment AND beacons is a strong lead.

Why Fingerprints Alone Fail

Collisions: common libraries (and many browsers) share JA3 values, so a match is not proof of malware.
Spoofing: tools like utls and some C2s let operators mimic a browser's ClientHello, defeating static JA3 matching — JA4+ is more resistant but not immune.
Drift: TLS stacks change with updates, so fingerprint lists need maintenance.
Conclusion: use fingerprints to prioritise, then confirm with beacon timing, destination reputation and host-side evidence.

Vetted sources

Compute JA3/JA3S in Zeek or Suricata and adopt JA4+ where your tooling supports it. Use curated fingerprint lists (e.g. abuse.ch / community sets) plus your own rarity baseline. Never alert on a fingerprint match alone — correlate with timing and reputation.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

Collecting and Matching

Why Fingerprints Alone Fail

Build Detections That Fire

C2 Beaconing Detection

Detection Hub

JARM and C2 Infra Hunting