You disabled noisy audit subcategories on a domain controller last quarter without a ticket; IR now reads the six-week gap as evasion. What do you show them?

## The situation, honestly stated An absence of audit records is genuinely ambiguous. Turning auditing off is a textbook defence-evasion move, and it is also something busy administrators do to a noisy, ageing domain controller and forget to write down. Nothing about the *absence* distinguishes the two — the discriminators are all in the change itself: its provenance, its scope, its shape and its timing. A note on what the absence does and does not mean. Missing audit records prove nothing about what happened in that window. They do not prove an intrusion, and they do not prove innocence either. The window is unlit; that is the operational fact, and it is separate from the question of who turned off the light. ## Provenance: where the change lives and who made it Establish first what is actually disabled right now and since when. The effective per-subcategory policy on the host is what counts, not the intent expressed somewhere upstream — legacy and advanced audit settings can conflict, and a policy that reads "enabled" in a console can be inert on the machine. Then ask where the change lives: - **In Group Policy.** The policy object has a version number, an edit history, a last-modified timestamp on its files in the domain's policy share, and a replication trail to every domain controller. That is a change-managed, attributable act. - **Locally on one host.** A local audit-policy change on a domain controller is fragile: DCs refresh machine policy roughly every five minutes by default, far more often than member computers. A local override of a setting Group Policy manages would be put back almost immediately. This asymmetry is the strongest single argument available. A six-week absence cannot come from a furtive local flip; it has to come from policy. Conversely, a *short* absence — auditing off for forty minutes and back on again — is evasion-shaped, because that is what a local change looks like before policy restores it, and because restoring it afterwards is something only someone hiding an activity window bothers to do. If the audit of policy change itself was still on at the time, there will be a Windows Security record for the audit policy change (event ID 4719) naming the moment; if that subcategory was among those switched off, its absence is expected rather than sinister. Say which case you are in. ## Scope: how far the change reached Did the change land on every domain controller in the same organisational unit, or only this one? An administrator tuning log volume changes the policy that governs the class of machine; the picture is uniform across peers. Evasion is local to the host the intruder is standing on. Peer hosts showing exactly the same gap for exactly the same period is a powerful innocent explanation, and it is cheap to check. ## Shape: which subcategories, and which survived What someone disables tells you what they were solving for. - **Tuning for volume** switches off the loud ones — file-system object access, filtering-platform connections, detailed process creation — and deliberately leaves the cheap, high-value ones on, because logon and account-management auditing costs almost nothing and everybody wants it. - **Evasion** switches off precisely what would record the next step, often narrowly, and frequently only around one window. Process creation disabled while logon auditing survives is a tuning shape; logon and account-management auditing disabled on a domain controller while noisy object access still floods the log is not. ## Timing: what the change sits next to Six weeks before any other indicator, next to a disk-capacity alarm or a log-volume complaint, is a different story from twelve minutes before the first anomalous artefact. Even without a ticket, the surrounding evidence is usually recoverable: the capacity alert, the monitoring graph, the mail thread, the retention shortfall that provoked it. "Undocumented" is not the same as "unevidenced", and reconstructing the trigger is the most persuasive thing you can hand over. ## Then stop arguing and help The gap is a real operational problem regardless of who caused it. Two things follow. First, restore the auditing — with a documented rationale and a volume plan this time, since the original problem was real. Second, help IR relight the window from surfaces the audit policy never governed: the identity provider's own sign-in records, network flow and DNS at the boundary, other hosts' records of sessions to this DC, and any copy of the DC's logs that was forwarded off the box before the change. If an intruder used this window, their activity exists in places the local audit policy could not reach; if nothing turns up there, that is worth as much to you as to them. And say the uncomfortable part out loud: the change was undocumented, that is the actual defect, and it is what made six weeks of a domain controller's history unarguable rather than merely unrecorded.