Skip to content
Reverse Engineering
Anti-Forensicbeginner

Event Log Clearing

Attackers wipe Windows event logs to destroy evidence, but the clearing itself is logged and leaves recoverable gaps and residue.

Clearing the Windows event logs is one of the bluntest anti-forensic moves: an attacker erases Security, System, and PowerShell logs to remove records of logons, service installs, and command execution. It is fast, scriptable, and built into the OS, which makes it popular with both ransomware crews (to slow incident response) and stealth actors (to remove a specific noisy event).

The technique is self-defeating in an important way: Windows logs the act of clearing a log. A defender who knows where to look can almost always prove that clearing happened, narrow it to a time window, and frequently recover much of the deleted content from secondary sources.

How it works

The standard built-in methods enumerate and clear logs through the Event Log service:

powershell
# Clear every log channel (loud and total)
wevtutil el | ForEach-Object { wevtutil cl "$_" }

# Or target a single channel
Clear-EventLog -LogName Security

More careful actors avoid wevtutil and instead suspend the EventLog service threads or use tools like DanderSpritz's eventlogedit to surgically remove individual records from a live .evtx, leaving the rest intact — a quieter approach that does not generate a "log cleared" event but corrupts the record-ID sequence.

Detection & analysis

Static analysis:

  • Parse the .evtx files and hunt for Event ID 1102 (Security log cleared) and Event ID 104 (System/Application log cleared). These records name the account that performed the clear. Tools: EvtxECmd, Chainsaw, Hayabusa.
  • Check for record-ID and timestamp gaps: legitimate logs have monotonically increasing EventRecordID values. A jump in record IDs with no corresponding clear event indicates surgical record deletion (DanderSpritz-style).
  • Inspect .evtx file metadata — a freshly cleared log has a recent creation time and a small size relative to its configured maximum.

Dynamic analysis:

  • Sysmon and command-line auditing (Event ID 4688 / Sysmon 1) capture wevtutil cl, Clear-EventLog, and Remove-EventLog invocations even after the target log is wiped, because those events land in different channels or forwarded copies.
  • Recover content from secondary sources that survive a local clear: Windows Event Forwarding (WEC) collectors, SIEM-ingested copies, Volume Shadow Copies of the winevt\Logs folder, and unallocated space carving for ElfChnk/ElfFile chunk signatures.

Detection rule hint: Alert on Event ID 1102 or 104 outside of approved maintenance windows, and separately alert on any Security-log EventRecordID discontinuity not explained by a clear event — the latter catches surgical deletion that produces no 1102. Always pull the same time range from your log-forwarding collector to reconstruct what was removed.

Votes

Comments(0)