How would you find command-and-control beaconing in network telemetry when you have no indicators to search for?

With no indicators, I have to detect on the property that makes it beaconing: something on the inside contacts something on the outside on a schedule.

Timing first. Group outbound connections by source host and destination, and look at the distribution of intervals. A tight distribution is the classic signal. Actors add jitter to break this, so I would look at the shape rather than expecting exact periodicity — a randomised interval within a bounded range still looks very different from human-driven traffic, which is bursty and irregular.

Volume and shape next. An idle implant checking in produces many short sessions with small, similar request and response sizes and a characteristic asymmetry. Long-lived sessions with sustained transfer are a different pattern and may indicate staging or exfiltration rather than the beacon itself.

Rarity is the other axis. Destinations contacted by only one or two hosts in the whole estate, newly observed domains, rare user agent strings, rare TLS or JA3/JA4 fingerprints, and unusual destination ports all narrow the field fast. A long-tail analysis usually surfaces more than a timing analysis on its own.

DNS deserves its own pass, because DNS-based C2 will not show as a connection to a suspicious host at all. High query volume to a single domain or its subdomains, unusually long or high-entropy labels, and unusual record types are the signals there.

The dominant false positive source is benign periodic traffic — software update checks, product telemetry, monitoring agents, certificate revocation checks, cloud sync clients. All of these beacon by design. So the workflow is really to baseline the periodic traffic in the environment first, then look at what is periodic and rare rather than periodic alone.

The limits matter and I would state them. Encrypted payloads mean I am reasoning about metadata only. Domain fronting and C2 hosted on legitimate cloud or SaaS platforms defeat destination-reputation approaches entirely, because the destination is genuinely legitimate. A beacon with a very long interval — hours or daily — may simply not produce enough events inside my retention window to look periodic.

So I would treat a network finding as a lead, not a conclusion, and confirm on the host: what process owns the connection, what its parent is, and whether there is a corresponding persistence mechanism. Network telemetry tells me where to look; host telemetry tells me what it is.