Event ID 1102: Security log cleared
- Event ID
- 1102
- Channel
- Security
- Provider
- Microsoft-Windows-Eventlog
- Log file
- Security.evtx
- Category
- Log integrity
- Default logging
- Logged by default
What event 1102 means
Event 1102 is written by the Windows Event Log service as the first record of a freshly cleared Security log. It survives the wipe because it is created after it, and it records the account that performed the clear in the UserData/LogFileCleared element: SubjectUserName, SubjectDomainName, SubjectUserSid and SubjectLogonId.
There are very few legitimate reasons to clear the Security log on a production system — archival is normally handled by log forwarding or by the retention settings. An analyst who finds a 1102 should treat everything before it as potentially lost and turn to other sources: forwarded copies in a SIEM, other channels on the host, and logs on the machines the account touched.
Clearing other logs (System, Application, PowerShell and so on) is recorded as System event 104, not 1102. Attackers who clear everything usually leave both.
When it is logged
Always logged by the Windows Event Log service when the Security log is cleared; no audit policy is required.
The fields live under UserData/LogFileCleared, not EventData. The clearing account needs the Manage auditing and security log right (administrators have it by default).
Key fields
| Field | What it tells you |
|---|---|
| SubjectUserName | Account that cleared the log. |
| SubjectDomainName | Domain or computer name of that account. |
| SubjectUserSid | SID of the account that cleared the log; stable even if the account is renamed. |
| SubjectLogonId | Logon session that performed the clear. Pivot to the 4624 with the same TargetLogonId on forwarded or other logs to find where the session came from. |
Common benign sources
- Lab machines, golden images and systems being prepared for deployment, where logs are wiped as part of a build.
- An administrator clearing a full log on a host configured to not overwrite events (after a 1104).
What attackers do that produces it
- Covering tracks after intrusion with
wevtutil cl Security, PowerShellClear-EventLogorRemove-EventLog, or Event Viewer's Clear Log action. - Ransomware and wipers clearing all event logs just before or after encryption.
- Clearing the log on a single server after lateral movement, while leaving other hosts intact.
Investigation tips
- Identify the session: SubjectLogonId and SubjectUserName, then look in forwarded logs or on domain controllers for the logon (4624, 4768/4769, 4776) that created it.
- Check System event 104 at the same time — several logs cleared together points to a script or tool.
- Search process creation (4688, Sysmon 1) and PowerShell 4104 around the timestamp for
wevtutil,Clear-EventLogorClearLogcalls to identify the executing process. - Compare the host's forwarded events with what remains locally to see exactly what was wiped.
MITRE ATT&CK techniques
| Technique | Tactics |
|---|---|
| T1685.005 Disable or Modify Tools: Clear Windows Event Logs | Defense Impairment |
MITRE ATT&CK v19.2. Technique and tactic names are MITRE's.
Sigma rules for this event
1 SigmaHQ detection rules (release r2026-07-01) target this event.
- High · 1
- HighSecurity Eventlog ClearedRule by Florian Roth (Nextron Systems), SigmaHQ, DRL 1.1
Rules by their named authors, published by SigmaHQ under the Detection Rule License (DRL) 1.1.
Run these rules on your logs
Drop a .evtx file into the viewer: all 2,395 bundled SigmaHQ rules run locally in your browser. Nothing is uploaded.