An intruder held domain admin for forty days — how do you decide which backups you can trust?

## The backup platform is inside the blast radius A common and comfortable assumption is that backups sit outside the incident: whatever happened to the estate, the copies are safe. Estate-wide privilege breaks that assumption. In a typical enterprise the backup server is domain-joined, its service account is highly privileged by necessity, its console authenticates against the same directory, and its agents run on every host. Someone who reached domain-level privilege had a path to all of it. Mature intruders take that path deliberately, because destroying or shortening recovery is what makes the rest of their leverage work. So "can I trust this copy?" decomposes into two independent questions, and both must be answered yes. ## Question one: when was it written? This is the timeline question. A copy written after the earliest confirmed adversary activity is a faithful snapshot of a system they were operating in. Its data may be fine; its executables, system state, scheduled jobs and configuration are not trustworthy. Copies written before that date are candidates. The hard version of this question is structural: if the retention window is shorter than the dwell time, there is no candidate at all. Forty days of dwell against a fourteen-day retention leaves nothing to restore to, and no amount of investigation changes that. ## Question two: was it out of reach afterwards? A copy written before initial access is still not trustworthy if the intruder could reach it afterwards — they could delete it, expire it, or in principle alter it. What makes a copy defensible here is a property of where it lived: - **Offline or removable media** physically disconnected after the write. - **Immutable or WORM-locked** object storage with a retention lock that the platform's own administrators cannot lift for the lock period. - **A separate trust domain** — a backup tenant or account whose credentials are not the estate's directory credentials, ideally with different administrators. The general principle is the same one that governs the rest of the recovery: a thing you are trying to trust must not depend on a thing you already believe was compromised. ## Reading the backup platform's own records This is the evidence that decides question two, and it is an under-used surface. Backup products keep their own job history and administrative audit trail: jobs created, run, modified and deleted; retention policies changed; copies expired; immutability or lock settings toggled; console logons. Read it as a timeline and lay it against the intrusion timeline: - Was retention shortened, and by whom, and when relative to the intrusion? - Were copies expired or deleted outside the normal schedule? - Was an immutability lock disabled shortly before the copies you now want disappeared? - Do console logons correlate with the accounts the investigation has already attributed to the intruder? Cross-check against records the same account could not so easily curate: directory change and replication metadata for the backup service account's group memberships and rights, storage-side or cloud-provider audit records for the object store, and the storage platform's own logs. Where the backup platform's records and an independent surface disagree, believe the one further from the compromised privilege — and treat the disagreement itself as a finding. Be careful about the direction of each claim. An audit record showing a retention change proves a change was made by an account, not that a human intruder made it; a *missing* record proves nothing on its own, because someone with that privilege could suppress it. Absence of tampering evidence is not evidence of absence, which is exactly why an out-of-reach copy is worth more than a clean-looking audit trail. ## Validating the candidate before it matters Having picked a candidate, restore it somewhere isolated and look at it before production depends on it. You are validating the restore point, not hunting the estate: are the indicators the investigation has already established — the account they created, the task they registered, the file they dropped — absent from this image? Is the configuration what you expect for that date? If an indicator turns up, the timeline was wrong and the whole choice moves earlier. ## What good looks like in the answer The strong answer separates the two axes (written before / out of reach afterwards), names the evidence used for each, treats the backup platform as a compromised-until-proven-otherwise system rather than an oracle, and is honest about the case where there is no trustworthy copy: then recovery becomes rebuild-and-migrate rather than restore, and that is a legitimate, frequently correct outcome rather than a failure of the responder.