A Sigma rule for cleared event logs catches one of the noisiest things an attacker can do on the way out: wiping the Windows event log to cover their tracks. Windows records the act of clearing the Security log as Event ID 1102, and because legitimate administrators almost never clear it, this is one of the rare detections where the event's mere existence is the signal. This post writes that logic as Sigma so it converts to KQL or SPL, and pairs it with the process-level paths attackers actually use to clear logs.

Key Takeaways

• Clearing the Security log writes Event ID 1102 (MITRE ATT&CK T1070.001); clearing any other log writes Event ID 104 in the System log.
• A Sigma rule for cleared event logs can fire on existence alone, because routine administration rarely involves wiping the Security log.
• A companion process-creation rule covers the tools that do the clearing — wevtutil, Clear-EventLog, wmic, and the .NET EventLog.Clear() method.
• The durable countermeasure is forwarding logs off the host, because an attacker cannot delete events that already left the machine.
• The rule converts cleanly to KQL; 1102 arrives via SecurityEvent, while the process paths arrive via DeviceProcessEvents.

Environment

• sigma-cli 1.0+ with a backend installed (kusto for Microsoft Sentinel here).
• Windows endpoints forwarding the Security and System logs — 1102 lands in Security, 104 in System.
• Process command-line logging via Sysmon or Security 4688 for the companion rule.
• Ideally Windows Event Forwarding or a SIEM agent already shipping events, so a local clear cannot erase what you have collected.
• A SIEM workspace to validate the converted query before promoting it to an analytics rule.

The Problem

Clearing the event log is anti-forensics in its crudest form. An attacker who has finished their work and wants to slow down the investigation runs wevtutil cl Security or the PowerShell equivalent, and the local record of what they did is gone. It is destructive, it is obvious in hindsight, and it is still common precisely because it works against defenders who only look at logs on the host after the fact.

The detection irony is that the clear operation logs itself. Event ID 1102 is written to the Security log as the first entry after the wipe, recording the account that performed it. So the question is not whether you can see it — you can — but whether you see it in time and off the box. That is why this detection is really two halves: a near-trivial rule on 1102, and a discipline of getting events off the host before they can be deleted. The technique reference is MITRE ATT&CK T1070.001.

The Solution — Writing a Sigma Rule for Cleared Event Logs

Step 1 — Detect the Security-log clear with Event ID 1102

This rule is as simple as a useful rule gets. The event only exists when the Security log was cleared, so the condition is just the event itself, with the subject account carried through for triage:

title: Security Event Log Cleared
id: 3f9c1a72-8d40-4e6b-b2c5-7a1e9f4d0c38
status: stable
description: Detects clearing of the Windows Security event log, a common anti-forensics step
references:
  - https://attack.mitre.org/techniques/T1070/001/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.defense_evasion
  - attack.t1070.001
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 1102
    Provider_Name: 'Microsoft-Windows-Eventlog'
  condition: selection
falsepositives:
  - Rare: an administrator deliberately clearing logs during decommissioning
level: high

There is no suspicious_* block here because there is no benign-versus-malicious shape to separate — the act itself is the indicator. The handful of legitimate clears (a machine being decommissioned, a deliberate log rotation by hand) are worth the one alert each they generate.

Step 2 — Catch clears of every other log with Event ID 104

Event ID 1102 only covers the Security log. When an attacker clears the System, Application, or PowerShell logs, Windows writes Event ID 104 to the System log instead. A second rule covers those, keyed on the channel that was cleared:

title: Windows Event Log Cleared (Non-Security Channel)
id: 6b2e8d10-4f73-4a59-9c0e-2d5a8f1b7e64
status: stable
description: Detects clearing of a non-Security event log channel via Event ID 104
references:
  - https://attack.mitre.org/techniques/T1070/001/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.defense_evasion
  - attack.t1070.001
logsource:
  product: windows
  service: system
detection:
  selection:
    Provider_Name: 'Microsoft-Windows-Eventlog'
    EventID: 104
  condition: selection
falsepositives:
  - Occasional administrative log maintenance
level: medium

Clearing the PowerShell/Operational or Microsoft-Windows-Sysmon/Operational channels through this path is a strong signal, because those are exactly the logs an attacker wants gone after running tooling. The essential Windows Event IDs reference lists the channels worth watching for this.

Step 3 — Cover the clearing tools with a process-creation rule

The event-based rules tell you a log was cleared; a process-creation rule tells you how, and catches the attempt even in the brief window before the clear completes. It covers the common command-line methods and depends only on Sysmon or Security 4688 command-line logging:

title: Event Log Cleared via Command-Line Tooling
id: 8d4a1f60-2c97-4b85-a0e3-6f9b2d7c1e50
status: experimental
description: Detects wevtutil, PowerShell, or wmic being used to clear event logs
references:
  - https://attack.mitre.org/techniques/T1070/001/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.defense_evasion
  - attack.t1070.001
logsource:
  category: process_creation
  product: windows
detection:
  selection_wevtutil:
    Image|endswith: '\wevtutil.exe'
    CommandLine|contains:
      - ' cl '
      - ' clear-log '
  selection_powershell:
    CommandLine|contains:
      - 'Clear-EventLog'
      - 'Remove-EventLog'
      - '.Clear()'
      - 'wevtutil'
  selection_wmic:
    Image|endswith: '\wmic.exe'
    CommandLine|contains: 'ClearEventLog'
  condition: 1 of selection_*
falsepositives:
  - Backup or maintenance scripts that rotate logs with wevtutil
level: high

1 of selection_* means any one of the three methods fires the rule. The PowerShell block deliberately includes .Clear() to catch the .NET path — [System.Diagnostics.EventLog]::new('Security').Clear() — which never touches wevtutil and is a common way to evade rules that only watch the binary.

Step 4 — Convert and route to the right table

Conversion is the same single command. The 1102 event maps onto SecurityEvent, and the process rule onto DeviceProcessEvents:

sigma convert -t kusto -p sysmon security_log_cleared.yml

The converted query is short, which is the point — a log clear is unambiguous enough that the value is in alerting fast, not in clever filtering. This slots straight into the kind of correlation logic from my SIEM correlation rules walkthrough:

SecurityEvent
| where EventID == 1102
| project TimeGenerated, Computer, SubjectAccount = strcat(SubjectDomainName, "\\", SubjectUserName), SubjectLogonId

Because this fires rarely, it is a good candidate for a high-severity, near-real-time analytics rule rather than a scheduled hunt. A cleared Security log on a server at 03:00 is worth waking someone for.

Step 5 — Make the detection survive the clear with forwarding

The weakness of any host-based log rule is that the host can be wiped before you read it. The countermeasure is structural, not detective: ship events off the box as they are written, so the clear only destroys a local copy you no longer depend on. Windows Event Forwarding or a SIEM agent both achieve this — once 1102 has been forwarded, deleting the local Security log changes nothing about your alert.

This is also why the 1102 rule is reliable even though it fires on a single event: the forwarded copy exists independently of the host's log state. Treat forwarding as the prerequisite that makes the detection trustworthy, not an optional extra.

Frequently Asked Questions

Why does clearing the log still generate Event ID 1102?

Windows writes 1102 as the first record after the Security log is cleared, by design, so the clear cannot erase the evidence of itself. The attacker can clear again, but each clear leaves a fresh 1102, and a forwarded copy is already gone from their reach.

What is the difference between Event ID 1102 and 104?

1102 is written to the Security log specifically when the Security log is cleared. 104 is written to the System log when any other channel — System, Application, PowerShell, Sysmon — is cleared. Cover both to detect log clearing across all channels.

Will this catch a log cleared with PowerShell instead of wevtutil?

The event-based rules will, because 1102 and 104 fire regardless of the tool used. The process rule includes Clear-EventLog, Remove-EventLog, and the .NET .Clear() method so it also catches the PowerShell paths that never invoke wevtutil.

How do I keep an attacker from deleting the evidence?

Forward events off the host as they are written, using Windows Event Forwarding or a SIEM agent. Once an event has left the machine, clearing the local log does not remove it from your SIEM, which is what makes a single-event rule like this dependable.

Is a single 1102 event enough to alert on?

Yes, in most environments. Routine administration rarely clears the Security log, so the false-positive rate is low enough to justify a high-severity alert. Document the rare legitimate cases — decommissioning, deliberate manual rotation — in the rule rather than suppressing the alert.

Conclusion

Log clearing is a blunt anti-forensics move, and the detection is correspondingly blunt: the act records itself as Event ID 1102, and clearing any other channel records itself as 104. Writing these as Sigma gives you portable, near-zero-tuning rules that convert into whatever SIEM you run, plus a process-creation rule that catches the .NET and command-line methods an attacker reaches for.

The detection only matters if the evidence outlives the host, though. Pair these rules with log forwarding so a clear destroys nothing you actually depend on, and treat a cleared Security log as the high-severity event it is. Of all the rules in this series, this is the one with the best signal-to-effort ratio — and the one most undermined if you skip the forwarding.

Related Posts

• Windows Event Forwarding Setup for Centralised Security Logs — the forwarding that makes this detection survive a clear.
• Essential Windows Event IDs for Security Monitoring — the other channels and event IDs worth collecting for this technique.
• From Logs to Threats: SIEM Correlation Rules for Real Attacks — how to correlate a log clear with the activity it was trying to hide.

Authoritative reference: MITRE ATT&CK T1070.001 — Clear Windows Event Logs and the SigmaHQ rule repository.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.