Why run a newly published C2 domain back through five months of historic DNS logs?

## The two directions an indicator travels When a threat-intelligence report lands with a command-and-control (C2) domain in it, that single artefact is used in two completely different directions, and confusing them is the mistake this question exists to catch. **Forward**, into the controls: the domain goes into the DNS sinkhole, the proxy blocklist, the mail gateway, the detection rule. From the moment enforcement takes effect, anything in the estate that tries to reach that name is blocked or alerted on. This is *prevention and detection of future activity*. **Backward**, across the telemetry you already hold: the same string is searched against months of stored resolver logs, proxy records, flow records and host telemetry. This is the **retro search** (also called a retrospective sweep or retro-hunt), and it answers a question the forward path structurally cannot: *did this already happen to us?* ## Why intelligence always lags An indicator becomes publishable only after somebody, somewhere, has already been attacked with it, investigated it, and decided to disclose. In a supply-chain case the lag is often brutal: a signed update from a build-tool vendor ships in October and is trusted by everyone who takes it; the vendor discovers the compromise in February; the second-stage domain the implant calls is published in March. Every organisation that installed the update had five months of activity that was, at the time, invisible to every control they owned — because the artefact that would have identified it did not exist yet. That lag is not a defect to be engineered away. It is the normal shape of intelligence, and it is precisely why the backward direction exists. ## What the retro search is searching Start with the surfaces that carry the artefact and reach furthest back at the lowest cost. For a domain that is usually the resolver query logs and the egress proxy, both of which record a name and a client for every request. Flow records show sessions to addresses rather than names, which makes them useful once you know what the domain resolved to at the time. Host telemetry — process and network events from an endpoint agent — gives you the process that made the request, but typically covers a much shorter window than the network logs do. In an engineering estate the delivery vector matters too. If the vector was a poisoned dependency or a trojanised installer, the build system's own records — job logs, dependency resolution, artefact provenance, and the package registry's record of which version was pulled and when — are small, cheap and directly on point. ## What a hit does for you The **earliest** historic match is the highest-value output of the sweep. It gives you: - a **lower bound** on when the activity was already underway, which anchors the incident timeline; - a **scope**: the set of clients that produced matches is your initial host list; - a **pivot window**: whatever preceded that first match on those hosts is where the delivery event lives. Note the phrase *lower bound*. The earliest match is the earliest evidence in the telemetry you happen to still hold, not the moment of initial access. Access may well predate your first record, and a candidate who states the earliest match as "the time the attacker got in" has overstated the evidence. ## The asymmetry that makes this urgent Hosts are transient in a modern engineering estate. CI runners are rebuilt from images, containers are recycled, laptops are reimaged, cloud instances are replaced. Five months later the machine that made the request very often does not exist in any recoverable form. **The log may be the only surviving evidence of the intrusion**, which is why the sweep is run before anybody starts touching or rebuilding hosts, and why the record of what was found is treated as evidence rather than as a scratch query. ## How this differs from hunting A retro search starts from a **known artefact** handed to you by somebody else and asks whether it appears in your data. It is mechanical, bounded, and its scope is fully determined by the indicator and the window. That is a different activity from hypothesis-driven hunting, which starts with a behaviour you suspect and no artefact at all. Both look like "searching old logs"; only one of them begins with something a vendor published. ## The wrong answers "We blocked it, so we are covered" is the classic miss: blocking is a statement about the future. "We would have alerted at the time" is the same error wearing a detection badge — a rule that did not exist in October produced nothing in October. And "we searched from the day we ingested it" is a sweep that has been silently truncated to zero useful history.