C2 Beaconing Detection

C2 beaconing detection is a statistics problem, not a signature problem. An implant has to periodically check in with its command-and-control server to receive instructions, and that periodicity is a fingerprint even when the traffic is fully encrypted. You detect it by measuring the regularity of connections to each destination: low jitter, many check-ins, consistent small payloads. No machine learning required — just the right analytic over your network logs. This guide ships it.

Beaconing maps to MITRE ATT&CK T1071.001 — Application Layer Protocol: Web Protocols and T1573 — Encrypted Channel. It is the network counterpart to DNS tunneling — both are covert channels you catch by behavior, not content.

What is C2 beaconing?

After an attacker plants an implant (a Cobalt Strike beacon, a custom RAT), the implant cannot just sit and wait — it has to reach out to the command server on a schedule to fetch new instructions and return results. That heartbeat is “beaconing.” The content is usually encrypted and the payloads small, but the pattern — the same host contacting the same destination at a roughly regular cadence, over and over — is what gives it away.

Attackers know this and add jitter (interval randomization) and randomize payload sizes to blur the pattern. The defensive answer is to look at the distribution over many samples: jittered beacons still cluster around a central interval far more tightly than genuine human or application traffic does.

What are the signals of beaconing?

No single signal is conclusive — a software updater also polls regularly. The detection is the combination, especially low interval variance plus a long observation window plus small uniform payloads to a destination with no business reason.

How to detect C2 beaconing

The analytic measures interval regularity per source-destination pair over Zeek connection logs. Low variance plus a high connection count is the beacon.

index=zeek sourcetype=zeek:conn
| sort 0 id.orig_h id.resp_h ts
| streamstats current=f last(ts) AS prev_ts by id.orig_h, id.resp_h
| eval interval = ts - prev_ts
| stats count AS conns, avg(interval) AS mean_int, stdev(interval) AS jitter,
        avg(orig_bytes) AS avg_bytes by id.orig_h, id.resp_h
| eval cov = jitter / mean_int
| where conns >= 50 AND cov < 0.15 AND mean_int > 5
| sort cov

The coefficient of variation (cov = jitter ÷ mean interval) is the key score — a low value means tightly regular connections. Combine it with a high connection count and small average bytes, and you have a beacon. Add JA3/JA3S fingerprint matching to flag known C2 TLS clients outright.

How to test your beaconing detection

In an isolated lab on infrastructure you own:

1. Run a benign beaconing simulator (a script polling a lab server on a fixed interval) and confirm the analytic scores it.
2. Add jitter to the simulator and confirm the distribution-based score still catches it.
3. Replay normal traffic and a software updater and confirm they rank below the threshold or are enriched out.
4. Validate JA3 matching against a known test fingerprint.

How to defend against C2

• Proxy and log all outbound so beaconing has a record to analyze.
• Threat-intel on destinations to flag known C2 infrastructure.
• Hunt periodically for low-and-slow beacons that sit below real-time thresholds.

Common beaconing detection mistakes

• Alerting on regularity alone. Updaters poll too — enrich the destination.
• Looking at single intervals. Jitter defeats that; measure the distribution.
• Too-short a window. Beacons reveal themselves over many samples, not minutes.
• No egress logging. Without proxy/Zeek logs, there is nothing to score.

C2 beaconing detection checklist

1. Capture connection logs (Zeek) and proxy logs for all egress.
2. Score interval regularity (coefficient of variation) per source-destination pair.
3. Require a high connection count over a long window plus small uniform payloads.
4. Add JA3/JA3S fingerprinting to flag known C2 TLS clients.
5. Enrich candidates with destination reputation (new/uncategorized domains).
6. Default-deny egress; route outbound through a logged proxy.
7. Block newly-registered and uncategorized domains.
8. Hunt for low-and-slow beacons below real-time thresholds.

The takeaway

C2 beaconing detection is statistics over network logs: score interval regularity (low jitter) and connection count per destination, enrich with JA3 and destination reputation, and constrain egress so beacons have nowhere to go. No ML required. Continue with DNS tunneling detection and Sysmon configuration, or browse the full Detection Engineering pillar.