Privileged principals possess the capability to purge Windows event logs. This includes the local SYSTEM account (S-1-5-18) and local Administrators, both of which are granted Clear access by default on most event log channels. Domain Administrators typically inherit this capability as well, not through an explicit grant in the log's security descriptor, but via their default nested membership in the local Administrators group on domain-joined machines. On certain logs—the System log, for example—Server Operators are also granted Clear access by default, though the specific set of default grantees varies by channel; the Security log, notably, ships with a tighter default SDDL. Beyond these built-in defaults, any identity explicitly granted the Manage auditing and security log user right (SeSecurityPrivilege) or explicitly assigned Clear access in a given channel's security descriptor can purge that log—these are two independent paths to purge capability, and for the Security log specifically, both the SeSecurityPrivilege grant and the channel's Clear ACE come into play. It is common in forensic examinations to encounter users operating with administrative privileges—whether legitimately assigned or obtained through privilege escalation. Such elevated access affords the capability to manipulate or eradicate forensic artifacts in an effort to impede post-incident analysis.
Standard channel-clear operations, however, are rarely executed without residual indicators. When the Security (audit) log is cleared—whether via Event Viewer, wevtutil cl Security, Clear-EventLog -LogName Security, the EvtClearLog API, or equivalent interfaces—the Event Log service writes Event ID 1102 ("The audit log was cleared") as the sole new entry in the now-empty Security channel, preserving attribution despite the destruction of all preceding records.
Clearance of any non-Security channel (System, Application, Setup, or operational logs) generates Event ID 104 from the Microsoft-Windows-Eventlog provider. The 104 record is written into the channel that was cleared and identifies both the target channel name and the clearing principal. In practice, these events are commonly collected and monitored from the System channel, although the precise destination follows the cleared channel’s identity.
Consequently, even when historical content is no longer recoverable, the residual 1102 and 104 events furnish reliable markers of the clear action, its timestamp, and the responsible account. These artifacts carry independent evidentiary weight—particularly in intrusion, ransomware, or data-spoliation investigations—and should be correlated against known legitimate administrative workflows, data-retention policies, and concurrent authentication (4624) and process-creation (4688 / Sysmon) telemetry. Mass or sequential log clears remain a high-fidelity indicator frequently observed in ransomware and advanced persistent threat tradecraft (MITRE ATT&CK T1070.001) and warrant continuous, prioritized alerting.
When the Security event log is purged through any standard interface (Event Viewer GUI, wevtutil cl Security, PowerShell's Clear-EventLog -LogName Security, the EvtClearLog API, or functional equivalents), the sole surviving record in that channel is Event ID 1102 ("The audit log was cleared"), generated by the Microsoft-Windows-Eventlog provider. Critically, Event ID 1102 is generated regardless of the Audit System Events policy setting; this residual marker is produced by the Event Log service itself as an intrinsic byproduct of the clear operation, independent of whether success auditing for system events is enabled. The 1102 record furnishes:
- definitive confirmation that the Security channel was purged,
- a precise timestamp of the clearance,
- the Subject's Security Identifier, Account Name, Domain Name, and Logon ID.
(The equivalent residual-artifact principle governs non-Security channels via Event ID 104, logged within the cleared channel itself).
Because the 1102 (or 104) record is written into the channel as part of the same clear operation that destroys the preceding content — materializing as the sole new entry once the purge completes— the record reliably survives the clearance and constitutes a high-integrity anti-forensic indicator. Its evidentiary value derives precisely from this: the destruction of prior content is what necessitates and produces the marker, not an event that predates it. Administrator-equivalent privileges—or the specific Manage auditing and security log (SeSecurityPrivilege) right for the Security channel—are required to execute a successful clear.
Event Log Attacks
Windows event logging has long been treated as a comparatively trustworthy evidentiary source, yet it has come under sustained and increasingly sophisticated attack. The underlying .evtx files are deliberately locked, access-controlled objects that are highly intolerant of structural corruption. The Security channel, in particular, is writable only by the Local Security Authority Subsystem Service (LSASS) and related privileged components; public Windows APIs expose only wholesale clearance operations and do not provide supported interfaces for selective record deletion. Design intent therefore remains "all-or-nothing".
That design has been repeatedly circumvented. Early proof-of-concept tooling such as WinZapper (targeting Windows NT/2000-era logs) demonstrated selective event removal but proved unreliable, frequently corrupting the log file and rendering the Event Log service unusable until reboot. More mature capabilities later appeared in the wild. The Shadow Brokers disclosure of the Equation Group's DanderSpritz framework included the eventlogedit module, which removes targeted records by extending the preceding record's declared length to absorb the excised entry, then recalculating chunk- and file-header metadata (record counts, offsets, checksums) to preserve structural consistency. Standard parsers stop reading at the first end-tag and treat the absorbed bytes as harmless trailing data within the enlarged prior record. The original record data typically remains resident within the file and is recoverable; Eric Zimmerman's EvtxECmd, among other forensic parsers, automatically flags the resulting structural anomalies (record-ID discontinuities, header inconsistencies, etc.).
Benjamin Delpy's Mimikatz implements complementary techniques: the event::clear command performs a conventional clearance (normally generating Event ID 1102), while the experimental event::drop patches the Event Log service to suppress further writes. When the two are combined, an entire channel can be emptied without producing the expected 1102 residual event—although the service is left in a non-logging state, creating detectable temporal gaps. PowerShell tooling such as Invoke-Phant0m enumerates and terminates the worker threads of the Event Log service inside its hosting svchost.exe process; the service continues to report a "Running" state to the Service Control Manager while emitting no further events. Additional research has demonstrated suspension of the service, direct modification of the on-disk or memory-mapped log structures, and subsequent restoration, as well as in-memory manipulation of the mapped log segments. All of these techniques require administrative-equivalent privileges.
Adversaries have also been observed flooding channels with noise rather than attempting deletion or suppression. Collectively, these methods compel caution in the interpretation of any local event-log corpus: absence of expected records, unexplained EventRecordID gaps, missing 1102/104 markers, or abrupt cessation of logging may themselves constitute high-value indicators. At the same time, many intrusions still leave logs untouched.
The practical defensive implication is clear. Enterprises should prioritize real-time log forwarding and centralized, append-only storage; such architectures neutralize many selective-edit and on-host clearance techniques. Residual risk remains for attacks that simply halt logging. Detection of those cases requires complementary analytics capable of identifying hosts that cease forwarding, exhibit anomalous temporal gaps, or display other statistical deviations from expected log volume and continuity.
Post a Comment