Lion Cipher Lab

Detect Windows event log clearing and audit tampering (Event ID 1102)

• SOC Analyst / Blue Team
• Intermediate
• ~45 min
• Free · no account required

Why it matters

Almost every serious intrusion ends with the same move: the attacker tries to erase their tracks. On Windows the fastest way to do that is to clear the event logs -- the running record of logons, process starts, service changes, and security alerts. MITRE ATT&CK catalogues this as T1685.005, Clear Windows Event Logs (numbered T1070.001 before ATT&CK v19), and it is one of the most common defence-evasion steps there is. Here is the gift Windows gives defenders: clearing the Security log is not silent. The instant the log is emptied, Windows writes a single event into it -- Event ID 1102, 'The…

What you'll learn

• explaining why clearing the Windows Security log is a HIGH-fidelity signal: the act of clearing writes exactly one event -- Event ID 1102, 'The audit log was cleared' -- into the freshly-emptied log, and that single event names the account that did it
• generating the artifact SAFELY on a machine you own: backing a log up first, clearing it, and confirming that clearing the Security log yields 1102 while clearing a non-Security log yields Event ID 104 in the System log
• hunting 1102 (Security) and 104 (System) with PowerShell's Get-WinEvent using both a FilterHashtable and a FilterXPath query, and extracting the SubjectUserName -- the account that cleared the log -- from the event's XML
• adding Event ID 4719 (audit policy changed) as a companion tampering signal, so you catch an attacker quietly turning auditing off as well as one who wipes the record
• baselining the legitimate causes FIRST -- rare planned log maintenance, imaging, some backup tooling -- so a 1102 is treated as a strong LEAD to investigate, not an automatic verdict
• writing a portable Sigma rule for 1102 so the detection travels to any SIEM instead of living only in one PowerShell one-liner on one box
• reasoning honestly about missing logs: a determined attacker can stop the Event Log service or tamper before clearing, so absence of 1102 is NOT proof of innocence, and 1102 tells you a log was cleared but not what was in it
• stating the durable defence: FORWARD logs off-box (Windows Event Forwarding or a SIEM) so clearing the local copy no longer destroys the evidence -- detection plus off-box retention beats trying to prevent clearing
• placing the whole technique on MITRE ATT&CK as T1685.005 (Clear Windows Event Logs, formerly T1070.001) so you can name what you are hunting and recognise the old ID in existing rules

Steps in this lab

1. First, the shape of the idea — clearing a log is a signal, not a silence
2. Set up: back up a log first, so you lose nothing
3. Generate the signal — clear a log and watch the marker appear
4. Build the hunt — find 1102 and name who cleared the log
5. Hunt the companions — 104 (other logs cleared) and 4719 (auditing changed)
6. Baseline first — a signal is a lead, not a verdict
7. Make it portable — write a Sigma rule for 1102
8. Honest limits, and the fix that actually holds

Open the full interactive lab →