Event log clearing and the gaps that survive

Event log clearing is the anti-forensic technique every operator learns first and the one that leaves the most usable trail. That second part is counter-intuitive. The whole point of clearing logs is to remove evidence, and an attacker who manages to clear Security.evtx has removed thousands of events you wanted to read. But the act of clearing is itself loud, the techniques that try to be quieter leave a different and equally diagnostic signature, and the channels most operators forget about preserve enough to reconstruct what was cleared.

Knowing what survives matters because it changes the question you ask the host. "What is in the Security log" becomes "what is missing from the Security log, and where else did those events go".

1102, 104, 1100: the noisy way

The default reflex of an operator who wants the Security log gone is wevtutil cl Security. This produces:

• A single EventID=1102 in Security.evtx, generated immediately after the clear, recording the account that did the clearing and the time. This event survives in the cleared log because it is the first event written to the freshly cleared file. Treat it as the smoking gun. The account name, the source workstation, and the time of clearing are all in the event data.
• A matching EventID=104 in System.evtx from the Microsoft-Windows-Eventlog provider, with the channel name that was cleared. This is the System-log mirror of 1102. Sometimes only one of the two survives because the operator cleared multiple channels and the order matters.
• A 1100 from the Event Log service indicating service shutdown, if the operator stopped the service before clearing. The combination of 1100 followed by an unexplained gap followed by 1102 is the classic "shutdown, tamper, restart" pattern.

These three events are the loud signature. An attacker who knows what they are doing will not generate them, or will generate them and then clear again to remove them, which produces a second 1102 and an even smaller surviving log. Every clearing pass leaves a 1102. The fact that a host has multiple 1102s in its history is itself anomalous.

The events that get cleared are not the only victims. Clearing a channel resets the underlying EVTX file, which means the on-disk file is rewritten. The old file's chunks are unallocated. They are recoverable from disk if you image the host within a reasonable window, which is the other branch of this story (covered in the carving post).

wevtutil cl versus thread suspension

A more sophisticated operator does not clear logs at all. They suspend the threads of the Windows Event Log service (eventlog), do the noisy thing they want to do, and resume the threads. While the threads are suspended, events generated by the OS and applications are queued in the ETW infrastructure but not written to the EVTX file. When threads resume, the queue is mostly flushed, but events that overflowed the buffer during the suspension window are lost forever.

This is what Invoke-Phant0m does (PowerShell, by Halil Dalabasmaz). The Mimikatz module event::drop does something similar but operates by hooking the ETW callback inside the service process. Both leave:

• No 1102. Nothing was cleared.
• No 104. Same reason.
• A gap. Events from before and after the suspension window are present; events from inside are missing. This is the detection.

The gap is detectable in two ways. The first is a contiguous-RecordID sanity check: the EVTX chunk header records FirstEventRecordIdentifier and LastEventRecordIdentifier, and you can verify that record IDs are monotonic across chunks. Suspension does not break the RecordID counter (the service is suspended, not the kernel ETW provider), but the timestamps inside the chunk will show a window with no events from busy providers, which on a domain controller is glaringly obvious.

The second is correlation against channels you cannot suspend without elevating again. The Microsoft-Windows-EventLog%4Operational.evtx channel logs the lifecycle of the event log service itself. Thread suspension does not generate explicit "thread suspended" events here, but the service's internal heartbeat (events 105, 106, and provider-specific debug events when the operational channel is at higher verbosity) sometimes record the inconsistency.

The third, harder, is the Sysmon trail. Sysmon writes to its own channel via its own driver and is not affected by event log service suspension. A host with Sysmon will have a continuous record of process creates and image loads across the suspension window. Cross-reference the time of the suspected gap in Security.evtx against Sysmon's Operational channel; if Sysmon shows a powershell.exe process with command-line content matching the Phant0m source code (or any of the dozen public variants) running at the start of the gap, you have your answer.

The forwarded events channel

Windows Event Collector (WEC) is the standard mechanism for forwarding events to a central collector. Forwarded events arrive at the collector in Microsoft-Windows-EventLog%4ForwardedEvents (on Windows Event Collector subscribers) and retain the originating host's Computer field, the original RecordID, and the original timestamps.

If your environment has WEC and the collector itself was not compromised, the forwarded events channel is sometimes the only intact record of what happened on a host whose local log was cleared. The events are byte-identical to what was generated on the originating host (modulo collector-added metadata), and the originating host's RecordID lets you stitch the forwarded copy back into the local log's RecordID timeline.

The catch: WEC subscriptions are pull-based by default, with a 15-minute heartbeat. A fast-moving attacker can clear the local log between forwarding heartbeats and the collector will only have the events from before the last successful pull. Configure subscriptions in MinLatency mode (push, with 30-second batch latency) on the channels you care about. This costs network and collector throughput; it pays back the first time you need it.

The other catch: WEC does not forward by default. If nobody configured the subscription, the collector channel is empty. Check the subscription state on candidate collectors before you bet an investigation on this evidence path.

Selective deletion and the EVTX-level question

Selective record deletion (removing specific events from a live EVTX file while leaving the rest) is theoretically possible by editing the file with knowledge of the format and recomputing the chunk CRCs. In practice nobody does this in live operations because the event log service has the file open and locked; you cannot edit it from userland without taking the service down, and taking the service down generates 1100/105 events.

What does happen in the wild is offline tampering after the fact. An operator who exfiltrates the EVTX file, edits it on their own machine, and re-uploads it to replace the live file (after stopping the service) will leave:

• Inconsistent CRCs on chunks they edited, unless they correctly recomputed both the chunk header CRC and the records-region CRC.
• Inconsistent LastEventRecordNumber in chunk headers if they did not also update those.
• Discontinuities in RecordIDs across chunk boundaries.

Any decent parser flags these. evtx_dump will warn on CRC mismatch by default. EvtxECmd logs the discrepancy in its output. Treat any CRC warning during parsing of an EVTX file from a suspected-compromised host as a potential tampering indicator and image the underlying disk before doing anything else.

What surfaces only in Microsoft-Windows-EventLog%4Operational.evtx

This channel is separate from Security.evtx and most attackers ignore it. It records:

• Event log service start and stop (105, 106).
• Channel state changes (subscription started, channel enabled/disabled).
• Manifest registration events.

When the Event Log service is restarted (because the operator used Stop-Service eventlog, or because they patched something and rebooted), you get events here that pair with the 1100/105/106 family. If Security.evtx shows 1100 at time T and EventLog%4Operational.evtx shows a corresponding service-state change at the same T, the shutdown was orderly. If Security.evtx shows a gap with no 1100 but EventLog%4Operational.evtx shows the service was restarted, the service crashed or was killed without an orderly shutdown, which is suspicious in itself.

This channel is small and reads fast. Add it to your default triage checklist.

Cross-validating against host artifacts

When the Security log is gone or doctored, the artifacts that survive are the usual suspects:

• The Master File Table for the EVTX file itself. $STANDARD_INFORMATION and $FILE_NAME timestamps will show when the file was rewritten by clearing.
• The USN journal for DATA_OVERWRITE and DATA_TRUNCATION events on Security.evtx. These show the clearing in journal terms with high-resolution timestamps.
• Prefetch for wevtutil.exe execution, or for powershell.exe runs that lined up with the suspected clearing.
• Shimcache and AmCache for tooling that the operator brought in to perform the clearing, particularly if they used a non-default binary.
• RAM dump artifacts if you captured one. The event log service's in-memory cache will have records that were never flushed to disk.

The Security log is one source. Treat it as one source. The investigation that depends on it alone is one tampered file away from useless. The parser on this site flags chunk CRC mismatches and RecordID gaps in its output, which is the cheap first-pass check for whether you are looking at a tampered log before you have invested an hour reading it.

Further reading

• Halil Dalabasmaz's Invoke-Phant0m source. Read what it does. The detection follows directly.
• Roberto Rodriguez's ThreatHunter-Playbook entry on 1102 and the surrounding clearing-detection material.
• Microsoft's documentation on Windows Event Collector subscriptions for the WEC configuration that gives you the forwarded-events safety net.