Once an implant lands, it needs to reach its operator - that regular "phone home" is a beacon, and its rhythm is what gives it away.
The tell is the timing
A beacon calls back on an interval (say every 60s) with small, near-identical requests. Real software is bursty (a page load, an update check); a beacon is metronomic. Even over HTTPS - where you can't read the payload - the cadence and size leak the pattern.
Attackers add jitter
To hide, implants randomize the sleep (e.g. 60s +/- 30%) - called jitter. So don't hunt for a perfect period; model the distribution of intervals and flag connections that are far more regular than normal browsing.
What to analyze
- Connection timestamps per (src, dst) - low variance in the gaps = suspicious.
- Consistent small byte counts in each direction.
- Long-lived, low-volume sessions to a single external host, around the clock.
- JA3/JA3S TLS fingerprints - some C2 frameworks have known TLS signatures.
Flow and proxy logs (or Zeek) give you the timestamps and byte counts you need. Tools like RITA automate the beacon-scoring over Zeek data.