T1685.005
Clear Windows Event Logs
What it is
Windows keeps a record of security-relevant activity in its event logs, and clearing that record is a direct attempt to destroy the evidence of what happened on a system. This is an attack on the defender's own visibility rather than on the host, which is why it sits alongside the techniques that disable or modify defensive tooling.
It's a simple, well-documented action: a single built-in command or a couple of clicks in a standard tool, available to anyone with sufficient privilege.
How adversaries use it
Near the end of an operation, or sometimes partway through it, an attacker with adequate privilege clears one or more Windows event logs, most often the Security log specifically, to remove the record of what they did on that host.
This is typically a late-stage move: cleanup after the attacker has already accomplished what they came to do, intended to slow down or defeat whoever investigates afterward. It's a tell in its own right, since legitimate administrators essentially never clear the Security log as part of routine operations.
Detect it in Elastic
Data source: Windows Security event log's own audit record of the clear action, plus endpoint process-creation telemetry for the tool that performed it
Key fields
There are two complementary signals, and they're worth treating as two separate detections rather than one. First, the clear action itself generates its own audit record the moment it happens, regardless of what other auditing is enabled. Second, the process that performed the clearing (a built-in command-line utility or a specific PowerShell cmdlet) shows up in ordinary process-creation telemetry, which Elastic covers with a separate rule named Clearing Windows Event Logs.
One important, general point worth making explicit: clearing a log does not retroactively delete events that were already shipped somewhere else. If events were already forwarded to a central collector before the clear happened, that copy survives entirely intact, and the clear action itself is recorded as its own event, in the very log being cleared.
Example event
{
"host": {
"name": "example-host"
},
"event": {
"action": "audit-log-cleared"
},
"winlog": {
"channel": "Security",
"event_data": {
"SubjectUserName": "j.doe"
}
}
}Prebuilt Elastic rule: Windows Event Logs Cleared
Hunt guidance
Two things to check, and they often disagree with a learner's first instinct. First, the clear action generates a specific, well-known event of its own, and that event is logged regardless of the audit policy in effect at the time, so it's a reliable signal in its own right rather than something that depends on prior configuration. Second, check what survived the clear. Windows logs multiple channels independently, and clearing one does not touch the others: a security-relevant event recorded on a different channel from the one that got cleared can remain completely intact, sitting right alongside the record of the log being wiped. It's worth specifically checking adjacent log sources rather than assuming a clear means the trail has gone cold.
A cleared log is itself a strong finding regardless of what else is recoverable: legitimate administrators have very little routine reason to clear the Security log specifically.
Ruling out legitimate activity
Genuine administrative log maintenance does happen, though it's uncommon for the Security log specifically compared to other, lower-sensitivity logs.
The distinguishing signal is largely who did it and why. A known administrator performing scheduled log rotation as part of documented maintenance is different from an unfamiliar account clearing the Security log with no accompanying change ticket or maintenance window. Given how rarely this happens for legitimate reasons, treat any occurrence as worth a direct conversation with whoever's account performed it before assuming it's routine.
References
Practice it
1 scenario in this catalog covers T1685.005. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →