An anti-forensics finding would name a long-serving administrator, but two of your three indicators have ordinary explanations. What do you assert?

## Why this decision is different from the technical one Most findings in an incident report describe a machine. An anti-forensics finding describes a *person's intent* — it says someone deliberately destroyed evidence. That is the claim most likely to trigger consequences outside the incident (an HR process, legal involvement, suspension, referral), and it is the claim most likely to be attacked by anyone reviewing your work. When the person is a long-serving administrator whose ordinary job involves exactly the actions in question, the base rate for the innocent explanation is high and the cost of being wrong is severe and personal. So the question is not "can I build an argument" but "what am I willing to assert, at what confidence, to whom, and what does the assertion set in motion". ## Structure the report so inference is visible The discipline that makes this survivable is separating three layers and never letting them merge: 1. **Observation.** What the artefact is. "The $STANDARD_INFORMATION times on this binary precede its $FILE_NAME times, and the entry-modified time falls inside the activity window." No adjectives. 2. **Alternative explanations tested.** Every ordinary process that produces the observation, and what you did to test each one. This is the part weak reports omit, and its absence is what a hostile reviewer finds first. 3. **What survives.** The inference, with a confidence label and the evidence that would change it. Write the two withdrawn findings into the report rather than deleting them. A reader who sees you disprove your own indicators trusts the one you kept; a reader who sees only the surviving indicator has no way to know how hard you tried to break it. Withdrawal is not retreat — it is the thing that makes the remaining claim worth reading. ## The bar for asserting deliberate destruction A defensible bar has three parts: - **No ordinary process produces it.** Not "unusual", not "I have not seen it before" — actually inconsistent with how the host is administered, tested against peer hosts and against the procedures that govern them. - **Independent corroboration.** Two artefacts from different sources agreeing beats one artefact of any strength, because the innocent explanations for each are usually different and rarely both hold. - **Someone argued the other side.** Have a colleague — ideally one who knows how that estate is actually run, which often means the administrator's own team — try to explain the finding innocently before it is published. If they succeed, you learned it cheaply. If the surviving indicator clears that bar, state it. If it clears it only partly, state it at the confidence it deserves: "consistent with deliberate backdating; I could not identify an ordinary process on this host that produces it; I cannot establish who performed it" is a strong, honest sentence, and it is very different from naming someone. ## Keep the evidentiary claim separate from the personnel decision You own whether the artefact supports the inference. You do not own whether someone is suspended. Two practical consequences: - **Do not recommend a personnel action inside the technical findings.** Report the finding and its confidence; let the people who own employment decisions weigh it against everything else they know, including things you were never told. - **Do not let the report name intent it cannot support.** "The audit policy change was undocumented" is a fact. "The administrator concealed the change" is an accusation, and unless you can evidence concealment specifically, it does not belong in your section. ## Do not lose the incident inside the argument The most common failure here is that the anti-forensics dispute consumes the investigation. Two things remain true no matter how the argument resolves: - **The window is unlit.** Whatever caused the gap, this host's own account of the period does not exist, and it has to be reconstructed from surfaces the change never governed — the identity provider, network telemetry, peer hosts, forwarded copies. Do that work in parallel; it is often what settles the argument. - **The intrusion hypothesis does not depend on the tampering claim.** You can keep investigating an intruder without asserting that a named employee helped them. Collapsing the two is how investigations go badly wrong in both directions: an innocent administrator is accused, or a real intruder is dropped because the tampering claim fell apart. ## The relationship you still need The administrator you would be naming is also the person who knows this estate best, holds the access you need, and can tell you which oddities are six years of accumulated history. An accusation made early and withdrawn later costs you that cooperation for the rest of the incident and beyond. Interview before you assert, share the artefact and ask for the innocent explanation, and treat a good answer as a result rather than an obstruction. ## And fix the systemic part The reason this was hard is that an administrative change to auditing on a critical host left no record. That is the finding with the longest life: undocumented changes to security-relevant configuration turn ordinary administration into something indistinguishable from evasion, and they cost an investigation weeks. Recommending a change record for security-configuration edits is worth more than winning the argument about this one.