A retro DNS sweep hits a C2 domain from a CI runner five months ago. What does that prove?

## Separate the record from the story The single most valuable habit in this domain is to state what an artefact *is*, then state the inference separately and at the strength the artefact supports. A retro hit is where that habit is tested hardest, because the sweep began with an artefact somebody already labelled malicious — so everything found by it arrives pre-loaded with a conclusion. ## What a DNS query log actually contains A resolver query log records, per request: a timestamp, the querying client's address, the queried name, the query type, and usually the response code. That is the whole of it. From it you may assert: - **a name was asked for**, at a time, by something behind an address. You may not assert, from this record alone: - **which process asked.** The resolver sees a UDP or TCP query from an address. There is no PID, no image path, no command line. On a build host the plausible candidates include a package manager, a container image pull, a browser, a security agent detonating a sample, a scanner, and an implant — and the log distinguishes none of them. - **that a connection followed.** Resolution and connection are separate steps. A process may resolve and never connect; it may resolve and be blocked at egress; another component may have resolved on its behalf. Proving a session needs a flow record, a proxy entry or host network telemetry. - **what moved.** No query log carries payload. Even a flow record, which does prove a session existed and how many bytes and packets crossed, carries no payload at all — it can show that bytes moved, never what they were. - **that the host was compromised.** That is a verdict assembled from several artefacts, not read off one. A response code of NOERROR tells you the name resolved. It does not tell you what the querying process did with the answer. ## The identity problem five months out On an engineering estate, the client address is a weak handle on a host. Self-hosted runners are ephemeral: a container or VM is created for a job and destroyed after it, and its address returns to the pool. Five months later that address may have belonged to a dozen different workloads. So resolving "which machine was this" is its own step — reconcile the address and timestamp against DHCP or IPAM leases, the runner scheduler's job records, or the orchestrator's assignment history. Until that is done, "ci-runner-07" is a label on a log line, not an identified host. ## The host is gone; the log is not This is the defining constraint of a retro finding, and it changes what investigation is even available. There is no memory image to take, no disk to acquire, no running process to inspect — the machine that produced the record was destroyed months ago as part of normal operation. You are reconstructing from surfaces that outlived it: - **flow records** for the window, which can show whether a session to the resolved address existed and roughly how much crossed it; - **the build system's own records** — the job log for that pipeline run, the base image it started from, dependency resolution output, artefact provenance; - **the package registry**, which knows exactly which version of the vendor's update that pipeline pulled and when; - **any peer host** that took the same update and still exists, which is where live forensics is actually possible. That last pivot is often the most productive move: the destroyed runner is a dead end, but the same trojanised update almost certainly landed somewhere still running. ## Building a defensible claim A well-formed conclusion from this hit reads roughly: *"Resolver logs show queries for a domain that the vendor attributes to the second stage of this campaign, originating from an address assigned to a CI runner between these dates. We have not yet corroborated an outbound session, and host artefacts for that runner no longer exist. Our current hypothesis is that the trojanised update version identified by the vendor was installed on this pipeline; the registry record showing which version was pulled would confirm or refute it."* Compare that with "the CI runner was beaconing to C2 five months ago" — which asserts a session, an implant, and continuity of behaviour that a single query record simply does not carry. The second sentence is what gets challenged, and correctly. ## Why the overstatement matters operationally Overstating a retro hit propagates. It drives a compromise declaration, which drives credential rotation across the build system, notifications, possibly a customer disclosure — all potentially correct, but you want them driven by evidence you can still defend a month later when someone asks how you knew. Understating is not the fix either: a resolved C2 domain from a build host in the campaign window is a serious lead and should be escalated immediately. The discipline is escalate hard, claim precisely.