HuntCONSTRUCTED
Hunt: the Security audit log was cleared
Event 1102 is the first record of the new log, so it survives the clearing and names the account that did it. One of the cheapest hunts there is, and worth thirty days rather than seven.
Defense ImpairmentT1685.005checked 2026-09-21
Needs
- The Windows Security log, forwarded off the host. A cleared log that was never forwarded has taken its own 1102 with it on the next clear.
- Thirty days of retention on that source
Will also return
- Image preparation before a machine is handed over. It should never appear on a machine already in service.
- An administrator clearing a log on a test machine. Rare enough to ask about every time.
Why thirty days
Almost nobody clears the Security log for an operational reason, so the expected result is nothing, and a query that returns nothing is cheap to run over a long window. Seven days would miss the operator who cleared it three weeks ago and has been quiet since.
A note on the identifier
ATT&CK version 19 moved this technique to T1685.005, under the new Defense Impairment tactic. Older material, and the tags Sigma tooling still validates, call it T1070.001 under Defense Evasion. They are the same technique.
What else to run beside it
Event 104 in the System log records any other log being cleared, and 4719 records the audit policy being changed, which is the quieter way to achieve the same thing. The event log cheat sheet has the full tampering table, and the endpoint pack carries this as a Sigma rule.
KQL
Microsoft SentinelUntestedSecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 1102
| project TimeGenerated, Computer, Account, Activity
| order by TimeGenerated descSPL
Splunk with the Add-on for Microsoft WindowsUntestedindex=wineventlog sourcetype="WinEventLog:Security" EventCode=1102 earliest=-30d@d
| table _time host Account_Name Account_Domain
| sort - _timeElastic
EQL, Winlogbeat or Elastic AgentUntestedany where winlog.channel == "Security" and event.code == "1102"