A hunt hit lands in a self-hosted CI runner's job logs. What do you preserve before you start pivoting?

## Why this step exists at all A hunter's instinct on a hit is to pivot immediately — same user, same host, wider window, upstream and downstream. Pivoting is right, but it costs you the state you were in, and on build infrastructure the underlying records are on a clock. The discipline is to spend two or three minutes freezing what you have before the pivot, because some of it will not be there when you come back. ## What is actually ephemeral here This is not a generic "logs expire" point. Build systems are unusually hostile to slow investigators: - **The runner workspace is reused.** A self-hosted runner's job directory is cleaned or overwritten by the next job on that runner. Files an intruder staged there — an archive, a dumped environment — can be gone within minutes of the next queued build, with nobody acting maliciously. - **Run history has a retention window**, often measured in weeks, after which the job log and its step output are deleted by the platform on schedule. - **Run history is deletable by non-admins of yours.** Anyone with administrative rights on the repository or organisation can delete a workflow run. They do not need to be the intruder; a tidy engineer will do. - **Shell history is a file on a host you do not own.** In this environment the security team has read access to build infrastructure but no authority to stop or freeze a pipeline, so you cannot assume you will get a second look at the host on your own timetable. - **Secret values are masked in log output**, which matters for interpretation: masking hides the value in the text, it does not mean the process was denied the value. ## What to preserve, concretely **The evidence.** Export the matched records themselves — not a screenshot — into whatever case store your team uses. Each exported record should keep its source identifier (which platform, which repository, which run and job id), its **event time** and, separately, the **collection time** the platform recorded it, because the gap between the two is how you later explain a record that looks out of order. Hash the export so you can show later that the copy you are arguing from is the copy you took. Screenshots are a fine supplement for a report; they are not the record. **The provenance of the hunt.** A finding nobody can re-derive is a finding somebody will eventually doubt. Write down, at the moment of the hit: - the exact query text, verbatim, not a description of it; - the platform, index or source it ran against; - the time range searched **and its timezone** — build systems typically log UTC while people talk in local time, and this is where investigations acquire off-by-hours errors; - the number of results, and whether the result set was truncated by a display or row limit; - the hypothesis you were testing when you ran it. Re-running the same query a week later against a rolling window is not reproduction: the window has moved and the oldest data has aged out. **Your own footprints.** Record every query you ran, every console page you opened, and above all any interactive access you made to the runner itself. Anything you do on that host lands in the same shell history and the same job environment you are going to present as evidence. An investigator who cannot subtract themselves from the timeline hands the other side an easy argument. ## What is deliberately not in scope here Two neighbouring decisions are not yours to make at this moment, and conflating them is a common answer-level mistake: - **Host acquisition.** Whether and how the runner host itself is imaged, and in what order its volatile state is captured, belongs to the forensic process and its own capture ordering. Your job is the platform-side records that will disappear on a business schedule while that decision is being made. - **Stopping the activity.** Freezing the runner takes the release train down, and in this environment you do not have the authority to do it anyway. That is an escalation to the people who own the pipeline, not a step you take between two queries. ## The failure this prevents The realistic bad outcome is not evidence tampering. It is a hunter who pivots for forty minutes, builds a compelling picture, goes to write it up, and finds the originating job run has been deleted by an engineer clearing failed builds, the workspace overwritten by the nightly job, and their own query lost in a browser tab that has since been reloaded. The finding survives only as an assertion — which, for a hit with no rule and no vendor verdict behind it, is exactly the thing it could not afford to be.