Event ID 1102: The audit log was cleared

Event 1102 lives in the Other Events audit subcategory. Clearing the Security log is treated as a first-class action Windows will always record, because the whole point of the event is to survive the very act someone is trying to hide.

The provider is Microsoft-Windows-Eventlog, the service that manages the event log subsystem itself, not the Security-Auditing provider that generates the bulk of 4624/4625/4688-style events. That distinction matters operationally: 1102 is the log service reporting on itself, so it lands in the Security channel but is generated independently of whatever audit policy is configured for logon or object access.

The payload is deliberately narrow. Instead of the usual EventData block, 1102 carries a LogFileCleared structure with four fields: SubjectUserSid, SubjectUserName, SubjectDomainName, and SubjectLogonId.

SubjectUserSid and SubjectUserName identify the account that issued the clear, SubjectDomainName tells you whether that account is a domain account (NETBIOS or FQDN form) or a local account (in which case the field holds the local computer name), and SubjectLogonId is the hexadecimal logon session identifier tying this action back to the session that authenticated the user.

That last field is the single most useful piece of the event for an analyst, because it lets you pivot to the 4624 logon event that opened the session and see exactly how and when that account got onto the box in the first place.

On a single workstation, this event is rare enough that seeing it at all is notable. On a domain controller or a server holding anything of value, it should be treated as a break-glass alert every time, full stop, because there is essentially no routine administrative task that requires clearing the Security log rather than archiving and rotating it. Windows already handles log rotation through size limits and archival settings; an administrator who wants to manage log size configures retention, they do not manually invoke a clear.

The instruments that produce 1102 are narrow and well known: wevtutil cl Security from an elevated command prompt or script, the PowerShell Clear-EventLog -LogName Security cmdlet (deprecated in newer PowerShell but still functional on many hosts), or clicking Clear Log inside the Event Viewer GUI. All three route through the same underlying eventlog service call, which is why all three produce the identical 1102 record with the same field set regardless of which tool the operator used.

A SOC sees this event in a few recurring shapes. The most common malicious pattern is post-compromise cleanup: an attacker who has already escalated privileges, moved laterally, or exfiltrated data runs wevtutil cl Security as one of the last steps before disengaging, hoping to erase the logon and process-creation trail that would otherwise show how they got in and what they touched.

The second pattern is log-clearing as an anti-forensic habit baked into commodity malware and ransomware deployment scripts, where a batch file loops through all major logs (Security, System, Application) and clears each one in sequence right before or after the payload detonates.

The third, rarer pattern is a misconfigured monitoring or compliance script that someone wrote years ago to keep log files small on a legacy server, which is exactly the kind of stale automation this event is designed to surface so it can be decommissioned.

1102's closest neighbor is the System log's Event ID 104, generated by the same Eventlog provider when any log other than Security is cleared (System, Application, or a custom channel). The two events share the identical LogFileCleared schema and the same triggering mechanisms, but they land in different channels and carry different forensic weight.

1102 in the Security log is the higher-priority signal because the Security log is the one attackers have the strongest incentive to erase; 104 against the System or Application log is worth watching but is more often tied to benign disk-space housekeeping on log-heavy application servers.

A batch script that clears every log on a host will produce one 1102 and one or more 104 events in the same few seconds, and seeing that combination together is a stronger indicator of deliberate anti-forensic activity than either alone.

The reason attackers who clear the Security log still get caught by this exact mechanism is structural: the clear action is not exempt from being logged, it is the log service logging its own state change, and that entry is written to the newly-emptied log immediately after the clear completes.

An adversary who wants zero trace left behind cannot avoid generating 1102 through the standard clearing tools; the only way around it is to delete the underlying .evtx file directly from disk (which requires touching a locked file and usually needs the eventlog service stopped first, a much noisier and more detectable action) or to have never let the event reach a durable store in the first place.

That last point is the real defensive lesson: forwarding Security logs off-host in near-real-time, whether via Windows Event Forwarding, a SIEM agent, or Sysmon-adjacent shipping, defeats the entire tactic, because by the time an attacker clears the local log the 1102 event and everything preceding it has already left the machine.

The honest baseline here is that legitimate log clears are close to nonexistent in a well-run environment, which makes 1102 one of the highest-signal, lowest-volume events available to a SOC.

The rare benign case is a planned maintenance window where an administrator is decommissioning a machine, resetting a golden image, or intentionally scrubbing a test VM before re-imaging, and in every one of those cases there should be a corresponding change ticket, and the SubjectUserName should map to a known administrator whose SubjectLogonId correlates to an interactive or RDP session that started shortly before the clear, not a service account or an unfamiliar identity.

The true-positive pattern an analyst looks for starts with the account itself: does SubjectUserName correspond to an account that has no documented reason to be touching that host's audit configuration, or does the SubjectDomainName format look like a local account on a server where only domain admins should be logging on locally? From there, pull the SubjectLogonId and walk it backward to the 4624 that created it.

If that logon was itself unusual, an off-hours interactive logon, a new source IP, a logon type inconsistent with how that account normally connects, or if the same logon session shows privilege-escalation events like 4672 (special privileges assigned) immediately before the clear, the case for malicious intent gets strong fast.

A clear that follows within minutes of suspicious process creation, PsExec or WMI lateral movement, or a spike in failed logons that suddenly stops is a textbook cover-tracks sequence and should be treated as a near-certain compromise indicator rather than something to triage slowly.

The false-positive side is narrow but real, and analysts need to rule it out quickly rather than dismiss every 1102 as noise. Confirm there is an actual change ticket or scheduled maintenance record for that host and timestamp; confirm the acting account is a real, known administrator rather than a shared or service account; and confirm no other suspicious activity, lateral movement indicators, new scheduled tasks, or unexpected outbound connections appear in the window immediately before the clear on that host or its neighbors.

If any of those checks fail, or if the host is a domain controller, a jump box, or anything holding privileged credentials, escalate regardless of who the account claims to be, because the entire value of this event is that it should almost never fire, and an analyst who waves it through on the assumption that it's routine maintenance is the exact gap this event exists to close.