Two hundred agentless printers beacon to one CDN-hosted name every 60 seconds — how do you reach a verdict?

## The situation, and why it is hard A segment of printers, appliances and building-management controllers cannot host an endpoint agent. Network metadata is the only telemetry you have. A hunt over check-in periodicity has surfaced a tight rhythm: hundreds of devices, one hostname, sixty-second gaps, tiny symmetric payloads. Every feature the beacon analytic looks for is present, and you have no process, no parent, no binary hash and no file system to corroborate with. You must reach a defensible verdict anyway. ## Prevalence is the first and strongest signal Count the population. If 214 of 217 devices of a single model do this and nothing else in the estate does, two hypotheses compete: 1. **Shipped behaviour** — the firmware phones home to a vendor telemetry or update endpoint. 2. **Mass compromise** — something reached every one of those devices and installed the same implant. They make different predictions, and that is what makes the case testable. Shipped behaviour should correlate with a firmware version or a rollout date, should be uniform across the population from the moment each device was updated, and should be absent on devices of other models. Mass compromise should show an onset spreading over time rather than appearing with a version, and should leave some other trace — an unusual management-protocol burst, an unexpected inbound connection, a device that also talks somewhere else. **The three devices that do not beacon are the most informative hosts in the set.** Find out what is different about them: an older firmware, a different subnet, an egress path that does not go through this proxy. Whichever it is, it tells you what the behaviour actually tracks. ## Discriminators available inside the metadata - **Onset.** Establish first-seen for the behaviour across the population and line it up against change records. A clean step at a firmware rollout is close to decisive. - **Payload determinism.** A telemetry updater's request usually varies a little with what it has to report — a page count, an error, a supply level — so `bytes_out` drifts within a narrow range and occasionally jumps. A check-in that is byte-identical every single time regardless of what the device is doing is a slightly different animal, and worth noting either way. - **Response constancy.** A fixed, small response repeated forever is consistent with "nothing to do", which is what both an idle beacon and an idle update check look like. It is not a discriminator on its own; treating it as one is a trap. - **Destination attribution.** Resolving into a large content-delivery network's address space tells you nothing about ownership — that is the shared infrastructure adversaries deliberately hide behind. What matters is the *name*: is `telemetry.vendor-cdn.example` a zone the vendor documents and controls, or a name that merely happens to sit on the same CDN as things you trust? - **Schedule fidelity across events.** Does the rhythm survive a device reboot and resume at the configured interval, and does it stop when the device is powered off? Behaviour that continues from an address after the device it belongs to is off is a very different finding. ## Leaving the data Metadata alone will not finish this. The verdict is completed with provenance: the vendor's own documentation of its telemetry endpoint and interval, the procurement and firmware history, and a conversation with the device owner — the facilities or print-services team who bought the kit and who will, understandably, not enjoy being told their printers are beaconing to a content network. Frame that conversation as "your fleet talks to this name every minute; can you confirm with the vendor that this is the telemetry service, and what it sends", not as an accusation. The vendor's answer — ideally naming the endpoint, the interval and the payload contents — is the evidence that closes the case, and their inability to answer is itself a finding worth escalating. ## Closing it properly: a benign true positive The likely outcome is not a false positive. The analytic fired on traffic that genuinely occurred and genuinely matched the pattern it was designed to find; the activity is simply authorised. That is a **benign true positive**, and the distinction matters operationally: a false positive means the analytic is wrong and should be changed, while a benign true positive means the analytic is right and the *estate* needs the exception recorded. What goes in the closure note: - The exact discriminator, in fields: source population (that model), destination name, median interval, byte ranges, onset date and its correlating change. - The evidence used, including who at the vendor or in the business confirmed it, and when. - The residual uncertainty, stated plainly: no endpoint visibility, so this is an argument from population, provenance and pattern, not a confirmed inspection of what the device sends. - **The reopen conditions** — what would make this interesting again: a device of this model reaching a different name, the interval changing, `bytes_out` rising materially, the behaviour appearing on a device of another model, or the rhythm continuing from an address while the device is known to be powered down. - An expiry, because vendor endpoints and firmware change; a discriminator with no review date silently becomes a permanent blind spot. Without that write-up the next hunter re-runs the same query, finds the same 214 devices, and spends the same two days. With it, they spend ten minutes checking that the observation still matches the recorded discriminator — and the day it does not, they have a precise, pre-argued reason to escalate.