Event ID 1102 is logged in the Security log each time the Windows Security audit log is cleared. It records the subject account details and logon ID of the actor who cleared the log. Treat it as a high-priority signal for evidence destruction or attempted concealment, and investigate immediately.
What Event ID 1102 tells you about the Windows Security log
Event ID 1102 is not a routine housekeeping event. It means the Security log was cleared, which removes part of the audit trail that defenders rely on for reconstruction, containment, and attribution. The event is most useful when treated as a preservation problem first and a hunting signal second, because the act of clearing logs often follows an attempt to hide prior activity.
The practical value of 1102 is that it marks a change in evidentiary continuity. If the Security log was cleared by an administrator, a script, or a compromised account, the event still tells you that the audit trail is now incomplete and that the actor had enough access to alter defensive visibility. That is why this event should be handled as a control failure and a potential precursor to deeper compromise, not just as an administrative action.
For context on Windows logging patterns, event IDs, and the surrounding telemetry that helps you reconstruct what happened before and after a log clear, use the Windows Event Log Guide. It is the most direct companion resource when you need to interpret 1102 alongside logon, process creation, and other audit records.
How to interpret log clearing as an incident signal
Clearing the Security log does not prove malicious intent by itself, but it is rarely a benign event in the middle of an investigation, an active intrusion, or a period of unexplained admin activity. The key question is whether the log clear aligns with a legitimate maintenance window, a documented troubleshooting action, or an unexpected gap in telemetry that reduces confidence in the rest of your evidence.
Look at 1102 in relation to recent authentication, privilege use, service creation, scheduled task activity, and remote management. If the same host shows a prior burst of failed logons, privilege elevation, or unusual administrative tooling, the log clear may be part of a concealment sequence rather than an isolated action. Where telemetry exists before the clear, preserve it immediately and correlate it with adjacent sources such as endpoint logs, forwarded events, and remote administration records.
Hunting for related Windows telemetry is easier when your endpoint instrumentation is stable and tamper resistant. The Sysmon Guide is useful here because Sysmon can provide process, network, and registry visibility that remains valuable even when the native Security log has been cleared.
What to do when a Security log clear has occurred
Once 1102 appears, treat the affected system as evidence-bearing. Capture volatile and near-volatile data first, preserve whatever logs remain, and identify the account that cleared the log before deciding whether normal operations can resume. If the account is unexpected, over-privileged, or recently compromised, rotate related credentials and review adjacent systems for the same pattern of log tampering.
Do not rely on the single event alone. Validate whether centralized forwarding, SIEM ingestion, or immutable storage retained the records that were removed locally. If they did not, you need a stronger retention and alerting posture for the next incident, because log clearing can erase the very records that would prove lateral movement, persistence, or privilege misuse.
Where PowerShell or remote administration may have been involved, the PowerShell Security Guide helps with the common tradecraft around script logging, transcription, and administrative abuse that can accompany a log-clearing event.
Risk and Threat Considerations
A cleared Security log creates a visibility gap that can break investigation timelines, delay containment, and reduce confidence in every event that should have been visible before the clear. Attackers value that gap because it can hide failed access attempts, privilege escalation, malware execution, service creation, and persistence steps that would otherwise support detection or attribution.
Failure mechanism: The actor with sufficient local or elevated access uses native logging controls or administrative tooling to remove evidence, then continues activity in a shorter or partially blinded telemetry window.
Impact: Defenders lose evidentiary continuity, incident response becomes less reliable, and the chance of missing earlier compromise or lateral movement rises materially.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0005 — Defense Evasion | Log clearing is a classic defense-evasion behavior that suppresses audit visibility. |
| Recommendation — Correlate log clearing with defense-evasion activity and hunt for precursor and follow-on actions. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The event is fundamentally about audit trail integrity and log retention. |
| Recommendation — Alert on audit log clearing and protect logs with centralized retention and tamper resistance. | ||
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Clearing the Security log directly threatens the protection and integrity of audit records. |
| AU-6 — Audit Review, Analysis, and Reporting | 1102 needs correlation with surrounding events to assess whether it indicates concealment. | |
| Recommendation — Protect audit records from unauthorized alteration or destruction and preserve them centrally. Review 1102 alongside adjacent events to determine scope, timing, and related activity. | ||
Practitioner Guidance
What to verify: Confirm whether the log clear was authorized, when it occurred, which account performed it, and whether forwarding or archival systems preserved the pre-clear records. If any of those answers are unclear, treat the host as potentially compromised until proven otherwise.
Decision rule: If 1102 appears outside a documented maintenance action, prioritise containment and evidence preservation before routine remediation. If the clearing account is privileged, shared, or unexpected, assume the blast radius may extend beyond the local host.
Practitioner takeaway: Event ID 1102 is less about the act of clearing a log and more about the loss of trust in the audit trail, so the correct response is to preserve what remains, reconstruct from independent sources, and investigate why visibility was deliberately or unexpectedly reduced.