Fingerprinting

In the investigation panel you'll see codes labeled JA3, JA4, JA4H, and JA4X. These are “fingerprints”: they identify what kind of software is making the connection, even when the software is trying to hide. This page explains each one in plain English.

Why fingerprints matter

Anyone can set their User-Agent (the text field that says “I'm Chrome version 118”). Malware does this all the time to blend in. But the underlying behavior of the software (the order it does things, which features it supports) can't easily be changed without rebuilding the software. That's what a fingerprint captures.

When an attacker uses a popular hacker toolkit, every copy of that toolkit produces the same fingerprint, even across different victims, different IP addresses, and different fake domain names. That's gold for detection.

JA3: TLS fingerprint (older)

TLS is the encryption used by every site that starts with https://. Before the encryption starts, the client (your computer) sends a “ClientHello” message listing all the options it supports. JA3 is a short hash of those options.

Two catches: JA3 only works on older TLS (versions 1.0 through 1.2), and recent TLS (1.3) introduced deliberate randomization that breaks JA3 in many cases. For modern traffic, JA4 is the better fingerprint, but Beacon computes both, because plenty of older C2 malware still uses TLS 1.2.

JA4: TLS fingerprint (newer)

JA4 is the updated version. It works across TLS 1.2 and 1.3 and is more stable against minor changes. It's also structured: the first few characters actually mean something (TLS version, whether a server name was provided, etc.) so you can read part of it directly without a lookup table.

Both JA3 and JA4 are computed automatically. You see them in the fingerprint section of the investigation panel regardless of whether you uploaded a raw PCAP or Zeek logs.

JA4H: HTTP fingerprint

Same idea, but for unencrypted HTTP (and for HTTPS when Beacon can reconstruct the HTTP layer from Zeek or Suricata logs). It hashes the HTTP method, version, which cookies and headers are present, whether Accept-Language is set, and the order of the headers.

Real browsers have very consistent JA4H fingerprints. Malware and scripts tend to produce wildly different ones, often missing headers that no real browser ever omits. JA4H catches a lot of crude automated clients that would otherwise fly under the radar.

JA4X: certificate fingerprint

When a server presents an HTTPS certificate, JA4X hashes the structure of that certificate: who it claims to be issued by, what fields it contains, and in what order. Certificate- generation tools (including the ones baked into C2 frameworks) leave consistent signatures.

Beacon also flags self-signed certificates (certificates a server issued to itself rather than getting one from a real authority) and certificates where the fields look obviously fake. Both are common with stood-up C2 servers.

Known-bad matching

Beacon maintains a library of fingerprints from public research on well-known hacker toolkits:

• Cobalt Strike: the most common commercial red-team tool, also the most common tool found in real breaches.
• Sliver, Havoc, Mythic: open-source alternatives to Cobalt Strike.
• Metasploit: the older standby, still widely used.
• Many others, updated continuously from public research.

When a fingerprint in your upload matches one in the library, you see a Known bad badge in the investigation panel with the name of the toolkit. That's usually (not always, but usually) a real finding worth acting on.