Beaconing and C2: Behaviour Over Content

What is it?

A beacon is a compromised host checking in with its command-and-control server at intervals to ask for orders. Beaconing detection reads the behaviour — the regularity of the check-in, the small constant payload, the rare destination — and the TLS metadata (SNI, certificate, JA3 fingerprint) that remains visible even when the content is encrypted.

Why it matters

Command-and-control is the spine of most intrusions: it is how the attacker keeps control after the initial break-in. Finding the beacon finds the whole operation. And because the traffic is almost always encrypted, the only way to find it is by behaviour and metadata — the exact skills this lesson builds.

Where you see it

Beacons appear in flow records as an unusually regular series of small connections to one destination, and in TLS/proxy logs as the SNI, the certificate details and the JA3 client fingerprint of the connecting tool. Threat intelligence enriches the destination and the JA3 with known-bad reputation.

What normal looks like

Legitimate periodic traffic exists everywhere — an update client checks in on a schedule, telemetry reports home, a heartbeat keeps a session alive. But it goes to a named vendor endpoint, presents a valid CA-signed certificate with a real SNI, and its timing is loose rather than metronomic. Regularity alone is not guilt.

What suspicious looks like

A C2 beacon is metronomically regular (often with a little jitter to evade exactly this detection), sends a tiny constant payload, goes to a rare raw IP or a newly-seen domain, and shows TLS oddities — no SNI, a self-signed certificate, and a JA3 that matches known offensive tooling. Several of these together, not any one alone, make the case.

How analysts investigate

Pull a host's outbound flows and look for a destination it returns to at a suspiciously even interval with a constant small size. Then enrich that destination: read the TLS metadata and the JA3, and check reputation. Weigh it against the benign twin — a real update service — and raise confidence as each innocent explanation fails.

Common beginner mistakes

Calling any periodic traffic a beacon — legitimate update and telemetry traffic is periodic too.
Dismissing a beacon because the interval is not perfectly constant — jitter is a deliberate evasion.
Stopping at 'encrypted, cannot tell' instead of reading the SNI, certificate and JA3 that are still exposed.

What you will be able to do

Recognise a C2 beacon by its behavioural shape — interval, size, jitter, destination.
Read the TLS metadata (SNI, certificate, JA3) that survives encryption.
Separate a beacon from legitimate periodic traffic on a specific fact.

The hardest part of beaconing is that its benign twin — an update client, a telemetry agent — looks superficially the same: both check in on a schedule. The Tier-2 skill is telling them apart, and the difference is never in the (encrypted) content. It is in the regularity, the destination and the TLS metadata.

Signal	Benign periodic traffic	C2 beacon
Destination	Named vendor endpoint	Rare raw IP / new domain
Certificate	Valid CA-signed, real SNI	Self-signed, no SNI
JA3 fingerprint	Common client library	Matches known C2 tooling
Timing	Loose schedule	Metronomic (± jitter)

Worked example — beacon or update?

TLS metadata · two periodic destinations

dst=update.vendor.com   every ~1h  SNI=update.vendor.com  cert=valid CA  ja3=common
dst=45.9.148.200        every 60s  SNI=(none)             cert=self-signed  ja3=known-c2

Both are periodic and encrypted. Before reading on, decide: which is the beacon, and on which facts?

The answer: the second, and the deciding facts are all four independent signals. The first goes to a named vendor with a real SNI, a valid CA certificate and a common JA3, on a loose hourly schedule — a legitimate update client. The second goes to a raw IP with no SNI, a self-signed certificate, a JA3 that matches known C2 tooling, on a tight 60-second interval. Each signal alone might be explained away; the four converging, with no benign story left, is a high-confidence beacon.

Recap

C2 is read by behaviour and TLS metadata, never by (encrypted) content.
The benign twin is legitimate periodic traffic — separate them on destination, cert, JA3 and timing.
Jitter is deliberate evasion; a wobble around a centre is still a beacon.