Event ID 1102 shows that the Windows Security audit log was cleared. That is often an attempt to hide activity, so it should be treated as a high-priority alert. Investigate the SubjectUserName, SubjectDomainName, SubjectUserSid and SubjectLogonId, and correlate with nearby logon, privilege and process events. It is generated under the Other Events subcategory.
Why Event ID 1102 is a security signal, not just an audit event
When the Windows Security log is cleared, the defender loses part of the record that explains what happened before, during, and after an incident. That is why Event ID 1102 is usually treated as a deliberate concealment attempt until proven otherwise. The event is most useful when read alongside account activity, privilege use, and process creation around the same time window.
A cleared log does not prove compromise by itself, but it does change the investigative posture. Security teams should assume the timeline may be incomplete, then reconstruct the missing window from adjacent sources such as endpoint telemetry, authentication records, and central log ingestion if they are available.
For teams building consistent detections, the Windows Event Log Guide is the most direct reference for understanding where Event ID 1102 sits in the wider Windows audit model, and it helps anchor the event to the surrounding logon and audit events that make it actionable.
What usually matters most when 1102 appears
The critical question is not simply who cleared the log, but what else was happening immediately before that action. Investigators should care about whether the same subject account also performed privileged operations, interactive logons, remote administration, service changes, scheduled task creation, or suspicious process launches. Those nearby events often explain whether 1102 was routine maintenance, troubleshooting, or an attempt to erase evidence.
The field values in the event are important because they identify the subject account and session context associated with the clear action. SubjectUserName, SubjectDomainName, SubjectUserSid, and SubjectLogonId give you the most direct pivot points for correlating the event to other logs and to the identity that performed the action.
That correlation becomes much stronger when the endpoint is also producing richer telemetry. A Sysmon Guide is useful here because Sysmon event data can help reconstruct process ancestry, network activity, and tamper attempts that may surround a cleared Windows log.
If the activity window includes PowerShell, the log clear may be part of a broader tradecraft chain rather than an isolated action. The PowerShell Security Guide is relevant because script logging, transcription, and related telemetry often provide the missing context after native audit records are disrupted.
How to investigate and retain evidence after a log clear
Start by identifying the exact time of the clear event and then building a narrow timeline around it. Pull nearby logon events, special privilege use, process creation, service installation, task creation, remote access indicators, and any forwarder or SIEM copies of the Windows events that were already exported before the log was cleared. If the endpoint is still available, preserve volatile and near-volatile evidence before making changes that could overwrite the remaining trail.
Then verify whether the event is isolated or repeated. A single 1102 on a managed admin workstation may have a different operational meaning than repeated clearing across multiple hosts, especially if the same subject account appears in each case. Repetition is often a sign of a deliberate attempt to reduce visibility, not merely noise.
Centralized detection matters because local log clearing should not erase everything. A SIEM Guide supports the operational side of this problem by showing how to onboard Windows logs, retain them long enough for investigation, and build correlation that still works when the endpoint view is damaged.
Risk and Threat Considerations
Event ID 1102 matters because clearing the Security log can hide evidence of privilege escalation, lateral movement, or persistence activity. The practical risk is not the event itself, but the loss of visibility that follows, especially if the attacker times the clear after credential theft or just before exfiltration.
Failure mechanism: An adversary or insider with sufficient rights clears the Windows Security log to remove local audit evidence, then continues activity from a now-weaker evidence trail. If defenders rely only on endpoint-local logs, the investigation loses the sequence needed to confirm scope and intent.
Impact: Missing audit history can delay containment, obscure the initial access path, and reduce confidence in scoping decisions. It can also force a heavier dependence on external telemetry, which means teams that did not retain off-host copies may be unable to reconstruct what actually happened.
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 NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1070.001 — Indicator Removal on Host: Clear Windows Event Logs | 1102 is the Windows log-clearing event and maps directly to indicator removal. |
| Recommendation — Correlate 1102 with adjacent host and account activity, then hunt for follow-on concealment and persistence. | ||
| NIST CSF 2.0 | DE.AE-03 — Anomalies and events are analyzed to understand the root cause | A cleared security log is an anomalous event that needs root-cause analysis. |
| Recommendation — Investigate the clear event as an anomaly and reconstruct the lost timeline from other telemetry. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Security teams must analyze audit events and correlate them with related records. |
| AU-9 — Protection of Audit Information | Log clearing is an integrity and availability threat to audit information. | |
| Recommendation — Review 1102 with surrounding audit records and preserve off-host evidence for analysis. Protect audit logs with centralized collection and controls that reduce local tampering. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | The event is fundamentally about audit log integrity and retention. |
| Recommendation — Centralize Windows logs and alert on log-clearing activity across the estate. | ||
Practitioner Guidance
What to verify: Confirm whether the clearing account is expected to have that privilege, whether the host is managed, and whether the same SubjectLogonId appears in adjacent suspicious activity. If the answer is no, treat the event as potentially malicious until surrounding evidence explains it.
What to prioritise: Preserve the surrounding timeline first, then review authentication, privilege, process, and remote administration events in the same window. The highest-value work is usually correlation, not staring at 1102 in isolation.
Practitioner takeaway: Treat 1102 as an evidence-loss marker, not a standalone verdict. The event becomes meaningful when you use it to find the actor, the access path, and the activity that was likely being hidden.