Disable or Modify Windows Event Log

Windows decides what it writes to the Security log from an audit policy, and that policy is a per-category, per-subcategory setting an administrator can change at will. Disabling Windows event logging is the act of turning part of that off, so that activity which would ordinarily have been recorded simply never becomes an event at all.

This is not log deletion and the distinction matters. Deleting logs leaves a mark: a cleared-log record, a file that shrank, a sequence number that jumps. Turning auditing off leaves nothing. The events are never generated, so there is no gap in a sequence, no tampering artifact, and nothing to recover. When auditing is switched back on, logging resumes from that moment; the period in between stays empty permanently.

An attacker who already has administrative rights on a host uses this to buy a quiet interval for the noisy part of the operation. The usual pattern is narrow and brief: disable one category, do the thing that would have been logged, then put the policy back, so that a later look at the configuration shows nothing wrong.

Selectivity is the point. Turning all auditing off makes a host go silent, and a silent host is conspicuous. Disabling one subcategory while everything else keeps flowing produces a host that looks entirely healthy to volume-based monitoring, and a gap that only shows up if somebody asks specifically what stopped.

It is also a technique with a short half-life by design, and that is what a defender exploits: the policy change itself is an audited event, and the host is rarely the only witness to whatever happened while the lights were out.

Data source: Windows Security event log audit-policy change records (Event 4719), the logging service's own start and stop records -- and the absence itself, in the category that stopped

{
  "host": {
    "name": "example-host"
  },
  "event": {
    "code": "4719",
    "action": "Audit Policy Change"
  },
  "winlog": {
    "event_data": {
      "Category": "Detailed Tracking",
      "SubCategory": "Process Creation",
      "AuditPolicyChanges": "%%8448"
    }
  }
}

Prebuilt Elastic rule: Disable Windows Event and Security Logs Using Built-in Tools

Hunt the change and the silence separately, then join them.

For the change: filter audit-policy change records and keep only the ones that REMOVE auditing. Additions are the overwhelming majority and they are almost all benign. Then ask whether the host, the subcategory and the time are explainable by a known configuration event.

For the silence: pick the event types the suspected subcategory produces and chart them per host over time. An absence is only meaningful against a baseline, so measure the host's own normal quiet first. Busy hosts go quiet for minutes at a time for ordinary reasons, and a gap shorter than the host's routine idle period is not findable and probably not the finding. A gap materially longer than anything that host has produced before is.

Two mechanical cautions. Audit subcategories are identified both by name and by GUID, and which of the two your pipeline populates depends on how the event was rendered and shipped, so normalize on whichever you actually have. And if you filter on a GUID, verify it maps to the subcategory you mean: the identifiers are allocated in blocks, adjacent values are adjacent subcategories, and a filter on the wrong one returns a confident zero that reads exactly like an absence of evidence.

Most importantly, do not try to reconstruct the window from the host. Whatever the host stopped recording, the authentication infrastructure, any network sensor watching the segment and the firewall the traffic crossed were all still writing, and none of them is the attacker's to switch off.

Audit policy changes are routine. Group Policy refresh, security baselines, hardening tools, monitoring agents and vendor installers all touch it, often on a schedule, and they generate the large majority of what you will see.

Three tests separate those from an attacker. Direction: legitimate configuration changes overwhelmingly ADD auditing; removals are rare and usually deliberate. Breadth: a change that lands across many hosts within a short window is a configuration deployment, and a gap that appears fleet-wide on the same dates is a collection or policy event, not an intrusion. A single host out of step with its peers is the one to chase. And reversibility: a change that is undone a short time later, returning the policy to exactly what it was, is a shape no configuration management tool produces and an attacker's cleanup step does.

Be careful with the negative evidence in particular. Silence in one category on one host is worth investigating, but confirm that the other categories on that host genuinely kept flowing before you call it an attack, because an agent outage, a shipper failure or a full disk produce a similar-looking hole for entirely dull reasons. The difference is that a collection failure takes everything with it; an audit-policy change is surgical.

• MITRE ATT&CK: T1685.001 Disable or Modify Windows Event Log
• Elastic Security: Disable Windows Event and Security Logs Using Built-in Tools

1 scenario in this catalog covers T1685.001. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →