Overview

Clear Windows Event Logs (T1070.001) is a defense evasion technique where attackers delete or wipe Windows event log channels — such as Security, System, Application, or custom logs — to destroy forensic evidence of their prior activity. By clearing logs, an attacker erases indicators of credential theft, lateral movement, persistence installation, and execution, making post-incident reconstruction significantly harder or impossible.

Every security team needs reliable detection for this technique because log clearing is almost never a legitimate automated operation in a production environment. When an attacker clears logs, it is a strong signal that something serious has already happened on that host — the clearing event itself is often the last breadcrumb left behind. Missing it means potentially closing an incident that is still active.

Attacker Perspective

Attackers clear Windows event logs as a deliberate anti-forensics step, typically performed after achieving their primary objective but before exfiltration or as part of cleanup during lateral movement.

• Native wevtutil abuse: Attackers run wevtutil cl Security or loop across all channels with for /F "tokens=*" %1 in ('wevtutil el') DO wevtutil cl "%1" to bulk-wipe every log channel in seconds — no third-party tooling required.
• PowerShell Clear-EventLog: Scripts invoke Clear-EventLog -LogName Security,System,Application or use [System.Diagnostics.Eventing.Reader.EventLogSession]::GlobalSession.ClearLog("Security") to clear logs while living off the land.
• Metasploit post-exploitation module: The post/multi/manage/clear_event_log Metasploit module automates clearing Security, System, and Application logs immediately after a session is established, leaving only the clearing event itself.
• Cobalt Strike built-in command: Cobalt Strike’s Beacon includes the clearev command, which clears Security, System, and Application logs on a compromised host without dropping a separate binary.

This technique is attractive because it requires only standard Windows privileges (Event Log Management rights or local Administrator), leaves almost no trace of prior activity, and is trivially simple to execute using built-in tools already present on every Windows system.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Event ID 1102: Generated whenever the Security log is cleared. Enable via Group Policy: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Audit Policy Change → Audit Audit Policy Change: Success. This event fires even if the attacker subsequently clears the Security log — the clearing event itself is written before the wipe takes effect.
• Windows System Event Log — Event ID 104: Generated when any log channel other than Security (e.g., System, Application, PowerShell Operational) is cleared. This is written by the Windows Event Log service (wevtsvc) and requires no additional audit policy — it is on by default, but confirm the System log is being forwarded to your SIEM.
• Windows Security Event Log — Event ID 4688 (Process Creation): Captures the full command line of processes launched, including wevtutil.exe invocations. Enable via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Detailed Tracking → Audit Process Creation: Success, AND enable command-line capture via GPO or registry: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1.
• Sysmon Event ID 1 (Process Creation): Provides richer process telemetry than Event ID 4688, including parent process GUID, hashes, and full command line. Deploy Sysmon with a configuration that includes rules for wevtutil.exe, powershell.exe, and cmd.exe. Sysmon logs are written to Microsoft-Windows-Sysmon/Operational.
• Sysmon Event ID 11 (File Creation) and Event ID 23 (File Delete): Can capture direct manipulation of .evtx log files under C:\Windows\System32\winevt\Logs\, which some tools perform directly via the filesystem rather than the API.
• PowerShell Script Block Logging — Event ID 4104: Captures the full content of PowerShell scripts and commands, including Clear-EventLog and direct .NET API calls. Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1, generates events in Microsoft-Windows-PowerShell/Operational.
• Windows Event Forwarding (WEF) or SIEM agent: Ensure all of the above channels are being forwarded in near real-time. If log clearing succeeds on a host, events that hadn’t been forwarded yet will be lost — minimize this window by tuning your collection interval and confirming subscription health.

Key Indicators

• Event ID 1102 in Security log: Source: Windows Security log. Field: EventID = 1102. The event body includes SubjectUserName (who cleared it), SubjectDomainName, and SubjectLogonId. Any occurrence outside a known, documented maintenance window should be treated as high-priority.
• Event ID 104 in System log: Source: Windows System log. Field: EventID = 104. The event body includes Channel (which log was cleared) and the user context. Pay special attention when the channel is Microsoft-Windows-PowerShell/Operational or Microsoft-Windows-Sysmon/Operational — clearing these specifically targets detection tooling.
• wevtutil with clear (cl) argument: Source: Sysmon Event ID 1 or Security Event ID 4688. Fields: Image (or NewProcessName) contains wevtutil.exe AND CommandLine contains cl or clear-log. Example patterns: wevtutil cl Security, wevtutil.exe cl System, wevtutil cl ""Windows PowerShell"".
• PowerShell Clear-EventLog command: Source: PowerShell Script Block Logging Event ID 4104. Field: ScriptBlockText contains Clear-EventLog or ClearLog or Eventing.Reader.EventLogSession. Any of these in a script block from a non-administrative scheduled task is high confidence malicious.
• Bulk log clearing loop pattern: Source: Sysmon Event ID 1 or 4688. Field: CommandLine matches pattern wevtutil el paired within the same session with repeated wevtutil cl calls — indicates automated bulk clearing of all channels, a strong attacker behavioral signature.
• Suspicious parent process for wevtutil: Source: Sysmon Event ID 1. Fields: ParentImage is cmd.exe, powershell.exe, mshta.exe, wscript.exe, cscript.exe, or any remotely executed shell (e.g., parent is a web server process or wsmprovhost.exe for WinRM). Legitimate administrative clearing is almost always done interactively by a named admin, not spawned from a script host.
• Direct .evtx file deletion: Source: Sysmon Event ID 23 (File Delete). Field: TargetFilename matches C:\Windows\System32\winevt\Logs\*.evtx. This catches attackers who bypass the API and delete log files directly on disk.
• Clearev from Cobalt Strike Beacon: Source: Sysmon Event ID 1. The Beacon process (often an injected or renamed binary) spawns cmd.exe /c wevtutil cl Security and subsequent clears in rapid succession within a few seconds — look for high-frequency wevtutil cl calls with the same ParentProcessGuid.

Detection Logic

Rule 1 — Broad: Any Security or System log cleared
IF EventID IN (1102, 104) THEN alert(severity=HIGH, host=ComputerName, user=SubjectUserName)

This rule fires directly on the canonical clearing events. False positive volume is very low in most environments — legitimate log clearing outside scheduled maintenance is rare. Expect near-zero daily alerts in a well-maintained environment; any alert warrants immediate triage.

Rule 2 — Process-based: wevtutil invoked with clear arguments
IF EventID IN (1, 4688) AND (Image ENDSWITH "wevtutil.exe" OR NewProcessName ENDSWITH "wevtutil.exe") AND CommandLine MATCHES_REGEX "(cl|clear-log)\s+" AND NOT (ParentImage IN ["mmc.exe", "eventvwr.exe"] AND User IN [known_admin_accounts]) THEN alert(severity=HIGH)

This catches the clear action at the process level, even if the resulting Event ID 1102/104 was somehow suppressed or not yet forwarded. The exclusion for mmc.exe and eventvwr.exe covers admins using the Event Viewer GUI to manually clear a log — validate these exclusions are tight to named accounts.

Rule 3 — PowerShell: Clear-EventLog or .NET API usage
IF EventID = 4104 AND ScriptBlockText MATCHES_REGEX "(Clear-EventLog|\.ClearLog\(|clear-log)" AND NOT (Path IN [approved_admin_scripts] AND User IN [known_admin_accounts]) THEN alert(severity=HIGH)

This rule catches PowerShell-native log clearing, including less obvious .NET API calls that bypass the Clear-EventLog cmdlet name. Lower volume than Rule 2 but catches a different execution path. Script path exclusions should be limited to a small, audited whitelist.

Rule 4 — High-Precision: Rapid bulk clearing (attacker automation signature)
IF EventID IN (1, 4688) AND Image ENDSWITH "wevtutil.exe" AND CommandLine CONTAINS "cl" GROUP BY ParentProcessGuid, ComputerName HAVING COUNT(*) >= 3 WITHIN 60 SECONDS THEN alert(severity=CRITICAL)

This rule specifically targets the attacker pattern of clearing all log channels in a loop. Three or more wevtutil cl executions from the same parent process within 60 seconds is nearly impossible to explain with legitimate behavior. Expect very low false positive rates — this should be treated as a critical incident trigger.

Tuning Guidance

• Legitimate administrative maintenance: Some organizations schedule log clearing as part of system maintenance (this is bad practice but exists). Identify these hosts and schedules, then exclude by ComputerName IN [maintenance_hosts] combined with a time-window condition — never exclude by user alone, as attacker activity could occur under the same account.
• Event Viewer GUI use by admins: An administrator manually clearing a log via the Event Viewer MMC snap-in will generate Event ID 1102/104 with parent process mmc.exe or eventvwr.exe. Exclude with ParentImage = "mmc.exe" AND User IN [named_admin_accounts] but keep the alert for any admin account that is not explicitly named — do not use a wildcard exclusion for all admins.
• Security tooling and EDR agents: Some EDR or backup agents may enumerate log channels using wevtutil el during inventory. Verify the specific agent binary and add an exclusion like ParentImage = "CrowdStrike_sensor.exe" only after confirming the behavior with your vendor — the cl (clear) argument should never appear in legitimate agent activity.
• CI/CD or test environment lab systems: Build pipelines and test environments sometimes wipe logs between test runs. Tag these systems in your asset inventory and apply a ComputerName IN [lab_hosts] exclusion scoped only to those environments — never apply this to production.

When the Alert Fires: Investigation Steps

1. Verify the alert is real: Navigate to the raw event in your SIEM and confirm Event ID 1102 or 104 exists in the original log source with a valid SubjectUserName and timestamp. Cross-reference with your WEF/SIEM agent heartbeat to rule out a collection gap or agent restart that might mimic a clearing event.
2. Identify the affected host and user: Extract ComputerName, SubjectUserName, SubjectDomainName, and SubjectLogonId from the clearing event. Check Active Directory to determine if the account is a standard user, local admin, domain admin, or service account — privileged accounts should immediately escalate your severity rating.
3. Pull the full command line and process chain: Query Sysmon Event ID 1 or Security Event ID 4688 on the same host within a ±5-minute window of the clearing event, filtering for wevtutil.exe or powershell.exe. Walk the ParentProcessGuid chain upward to identify the root process — look for unexpected ancestors such as wsmprovhost.exe (WinRM), mshta.exe, or office application processes.
4. Identify which logs were cleared and what is missing: Review Event ID 104 entries to see exactly which channels were cleared (field: Channel). Then query your SIEM for log volume from that host for the 24 hours prior to the clearing event — a sharp drop in event count from Security or Sysmon channels indicates successful evidence destruction and should widen your investigation scope.
5. Check for network connections and files written to disk: Query Sysmon Event ID 3 (Network Connection) on the affected host for the 2 hours before and after the clearing event, looking for outbound connections to rare or external IPs. Also query Sysmon Event ID 11 (File Create) for dropped payloads in %TEMP%, C:\ProgramData, C:\Users\Public, or any path containing .exe, .dll, .ps1, or .bat files.
6. Look for lateral movement from this host: Query Security Event ID 4648 (explicit credential use) and 4624 (logon type 3 = network) originating from the affected host in the surrounding window. In your SIEM, pivot on the SubjectLogonId from the clearing event to find other authentication events tied to the same session and trace where that session accessed other systems.
7. Search for persistence mechanisms added: Query Sysmon Event ID 13 (Registry Value Set) for modifications to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU\...\Run, and service-related registry keys. Also query Security Event ID 4698 (scheduled task created) and Sysmon Event ID 11 for new files in startup folders — if any persistence is found, this is a confirmed active compromise requiring immediate escalation.

Response Playbook

Containment

• Isolate the host — leave it powered on: Use your EDR console (CrowdStrike Network Containment, Defender for Endpoint Isolate Device, or equivalent) to isolate the host from the network immediately while keeping it running. Do not shut it down — volatile memory may contain attacker tooling, injected code, or active session keys that are critical for forensics.
• Disable the affected user account: In Active Directory Users and Computers or via Disable-ADAccount -Identity [username] in PowerShell, disable the account that performed the clearing. If it is a service account, coordinate with the application owner before disabling — but the risk of leaving it active outweighs the inconvenience.
• Block identified C2 IPs and domains: Take any external IPs or domains identified in Sysmon network events and block them at your perimeter firewall, web proxy, and internal DNS. Submit them to your threat intel platform for enrichment and check if other hosts in your environment have communicated with them.
• Terminate the malicious process: Using your EDR console, kill the process identified as the root of the clearing activity (e.g., the Beacon process or suspicious script host). Document the PID, hash, and command line before termination for your forensic record.
• Revoke active sessions and tokens: Use your identity provider to revoke all active sessions for the affected user — in Azure AD/Entra ID, run Revoke-AzureADUserAllRefreshToken. If the account had access to cloud resources, rotate associated API keys or OAuth tokens immediately.

Eradication

• Remove identified persistence mechanisms: Based on investigation findings, delete any malicious scheduled tasks (schtasks /delete /tn [taskname] /f), remove registry Run keys, and disable or delete any rogue services identified via sc delete [servicename]. Document each one removed.
• Search for and delete dropped payloads: Using your EDR console or by mounting the disk image offline, scan %TEMP%, C:\ProgramData, C:\Users\Public, and all user profile directories for files matching hashes or names identified during investigation. Cross-reference with VirusTotal for any unsigned or recently created executables.
• Reset credentials for all affected accounts: Force a password reset for the user account that cleared the logs and for any other accounts that authenticated from that host during the suspected compromise window. If a domain admin account touched the host, treat all domain admin credentials as compromised and initiate a broader credential reset per your IR playbook.
• Check for backdoors on lateral movement targets: For every host that received an authentication from the compromised system during the investigation window, run the same persistence checks (registry Run keys, scheduled tasks, new services). A clearing event often signals the attacker is covering tracks after moving — the real foothold may be elsewhere.
• Rotate any exposed secrets or API keys: If the compromised host had access to secrets management systems, cloud credentials, or application API keys, rotate all of them immediately. Check cloud provider audit logs (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) for any API activity using those credentials after the estimated time of initial compromise.

Recovery

• Verify the host is clean before reconnecting: Run a full EDR scan and review all persistence locations manually before removing network isolation. If your confidence in the cleanup is anything less than high — particularly if logs were cleared before your investigation began — re-image the host from a known-good baseline rather than attempting in-place remediation.
• Re-enable the user account only after confirming no persistence remains: Before re-enabling the disabled account, verify through HR or the user’s manager that the activity was not authorized, reset the password, enforce MFA enrollment or re-verification, and confirm no shadow accounts or backdoor access paths remain for that identity.
• Monitor the host and user for 72 hours post-remediation: Create a temporary high-sensitivity watchlist or alert rule in your SIEM scoped to the recovered host and user account. Flag any new process executions, network connections to rare destinations, or authentication anomalies and treat them as potential re-compromise indicators requiring immediate escalation.
• Document the full timeline and close the incident formally: Reconstruct the attacker timeline as completely as possible given the cleared logs — use authentication events, network flow data, and any endpoint telemetry that was forwarded before the clearing occurred. Submit a formal incident report with root cause, affected scope, and a gap analysis of what evidence was lost.
• Update detection rules based on new IOCs: Any new command-line patterns, process hashes, C2 destinations, or attacker behaviors observed during this incident should be codified into your detection rules before closing. Share IOCs with your threat intel sharing communities (ISACs, MISP, etc.) and review whether this playbook itself needs refinement based on what worked and what didn’t.