SignalHunt
← All rules

WIN-1007

critical

Event Log Cleared

Detects the Security log being cleared (EventID 1102) or any other log being cleared (System EventID 104). Clearing logs is rarely anything but an attempt to destroy evidence, and both events are emitted by the act of clearing itself - so the one record an attacker most wants gone is the one they cannot remove by clearing.

T1070.001
Test this rule in the simulator

Detection logic

Fires as soon as one event matches: `EventID` is 1102 or 104.

{
  "detection_type": "selection",
  "selection": {
    "EventID": [
      1102,
      104
    ]
  }
}

Log source: product=windows, service=security · Event ID(s): 1102, 104

Required log fields

  • EventID
  • SubjectUserName
  • SubjectDomainName
  • Computer

Enabling this in your environment

Where: 1102 is written to the Security log unconditionally when it is cleared; 104 lands in the System log. Neither needs an audit subcategory enabled. 

auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable

This rule is only as good as your log forwarding: if events are shipped off the host in real time, clearing the local log is futile and 1102 becomes a high-signal alert. If they aren't, the alert arrives having already lost the context needed to investigate it.

Seen in incidents

False positives

  • Deliberate log rotation or clearing during decommissioning or forensic imaging
  • Some system-rebuild tooling clears logs as a final step

References