How do you measure a beacon's check-in interval when the implant jitters its sleep?

## Why jitter is a weaker defence than it looks An implant's sleep timer is normally configured as a base interval plus a randomisation factor: sleep 60 seconds, jitter 30 percent, meaning each actual sleep is drawn from roughly 42 to 78 seconds. The intent is to break naive detection that asks "did this host connect at exactly 60-second gaps". It succeeds against equality tests and fails against distribution tests, because the randomisation is bounded and centred. Fifty draws from that band still look nothing like the gap distribution of a human browsing, which spans milliseconds to hours and is dominated by long idle stretches. ## The mechanics of the analytic **Aggregate first.** The unit of analysis is a pair — one source and one destination address or hostname — over a window. Anything smaller (an individual connection) has no rhythm; anything larger (a host across all destinations) mixes several rhythms and hides all of them. **Take deltas.** Sort the pair's connection start times and compute successive differences. You now have a sample of inter-arrival gaps. **Score the shape, not the value.** Useful, robust summaries: - **Median gap** as the estimate of the base sleep. Use the median rather than the mean, because a single overnight outage or a device reboot inserts one enormous gap that destroys a mean. - **Median absolute deviation, or the interquartile range, divided by the median.** This is a relative spread. A 30 percent jitter produces a characteristic, small relative spread; human traffic produces a relative spread far larger than one. - **Connection count.** Nothing below roughly a dozen gaps deserves a periodicity claim at all — you can fit a rhythm to noise if the sample is tiny, and this is where most amateur beacon hunts generate their false positives. - **A histogram of gaps, read by eye, for the survivors.** A jittered beacon gives a hump; a beacon with a two-tier schedule (fast when tasked, slow when idle) gives two humps; a scheduled task gives a spike plus multiples of it where check-ins were missed. **Frequency-domain alternatives.** Binning the pair's connections into fixed buckets and looking for a dominant periodic component — an autocorrelation peak or a spectral peak — finds the same thing from the other side and is more tolerant of missed check-ins, because a dropped connection removes a sample rather than merging two gaps into a double-length one. Whichever you use, this is descriptive statistics over the pair, not a trained detector; the point is to produce a ranked list a human reads, not a score you alert on. ## What actually defeats you **Not enough observations.** The hard case is a long sleep. A beacon that checks in twice a day with heavy jitter yields around a dozen gaps in a week — barely enough to distinguish from an updater that runs on a loose schedule. The answer is a longer window, which means your retention has to cover it, and a willingness to say the sample is insufficient rather than to guess. **No gaps at all.** If the channel is a single long-lived session — a websocket, a long-poll HTTP request held open, a control channel multiplexed inside an existing HTTP/2 connection — there is one connection record for hours of activity, and gap analysis has nothing to work on. That case is caught by *duration and byte-drip* instead: an unusually long session whose byte counters advance in small regular increments. Recognising which of the two shapes you are looking at is the actual skill. **Source ambiguity.** If the segment egresses through NAT or a shared proxy address, many hosts collapse into one apparent source and their independent rhythms interleave into something that looks random. You either need the pre-NAT source in the record or you accept that you are hunting per-destination rather than per-host. **Missing samples.** Sampled collection, a collector restart, or a device that sleeps overnight all punch holes in the series. Gaps then appear as multiples of the base interval, which is a useful tell in itself — clusters at roughly 1x, 2x and 3x a value is a strong periodicity signature, and a naive spread metric will mistake it for noise unless you look at the histogram. ## Reporting it honestly The output of this analytic is "this pair connects on a rhythm centred near N seconds with low relative spread across M observations". That is a statement about a machine running a loop. It is not a statement about malice, and the very next step is attribution of the destination and of the software, not escalation. Writing the claim in that form keeps the hunt defensible when — as usually happens — the top of the ranked list turns out to be an update service.