Clearing and Silencing Logs
Also calledlog clearing, anti-forensics
Clears a log or switches a channel off, so the record of what happened is gone.
- Technique
- MITRE ATT&CK T1685.005: Disable or Modify Tools: Clear Windows Event Logs (opens in a new tab)MITRE ATT&CK T1685.001: Disable or Modify Tools: Disable or Modify Windows Event Log (opens in a new tab)
- Needs
- Local Admin
- Gives
- A quieter machine, where the records of what was done are gone or were never written, so the timeline must be rebuilt from other hosts.
How the Attack Works
After acting on a machine, the quiet move is to remove the record. That means clearing a log, which deletes what came before it, or shrinking, redirecting or switching off the channel that would hold the next records. Clearing leaves its own event, so it is noisy, while silencing a channel leaves no event at all, and only a gap in the log and the Event Log Settings key show that it happened.
Read first Where Sign-In Evidence Lands, Reading Logon Events
How It Plays Out
The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.
ws-042 Foothold
Step 1 of 3: Security Log Cleared
On ws-042 Foothold
The Security log on ws-042 is cleared. Every record before it is gone, but Windows writes one event to say it happened.
Logged
1102 The audit log was cleared
On ws-042, in the Security log
The Security log was cleared, with the account that cleared it.
What Defenders See
The Security log holds a single event 1102 where a busy day's events should be, naming the account that cleared it.
Step 2 of 3: Another Log Cleared
On ws-042 Foothold
The PowerShell Operational log is cleared too, so the script records it held are gone.
Logged
104 The %3 log file was cleared
On ws-042, in the System log
A named log was cleared, with the account that cleared it.
What Defenders See
The System log on ws-042 shows event 104 naming the log that was cleared and the account that cleared it.
Step 3 of 3: Channel Switched Off
On ws-042 Foothold
A logging channel is disabled or its size cut to near zero, so the next records are never written at all.
What Defenders See
No event is written for this. The Event Log Settings key shows the channel's Enabled at 0, or its maximum size cut to near zero, dated by the key's last write.
Needs First
What the attacker must already hold for this attack to be possible.
- Local Admin RightsAdmin rights or SYSTEM on the machine, enough to clear a log or change its settings.
Comes From
Gives the Attacker
What running it hands the attacker to use next.
A quieter machine, where the records of what was done are gone or were never written, so the timeline must be rebuilt from other hosts.
What Defenders See
What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.
| Event and Log | Written On | Look For | Switch It On |
|---|---|---|---|
| 1102 The audit log was cleared (opens in a new tab) Security log | The computer whose Security log was cleared | A single event 1102 in the Security log with little before it, read against whether anyone was meant to clear it, and when. | Always written |
| 104 The %3 log file was cleared (opens in a new tab) System log | The computer whose log was cleared | Event 104 in the System log naming a log that was cleared, read with 1102 to tell a cleared log from one shrunk or switched off. | Always written |
What It Looks Like
One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.
1102 The audit log was cleared
In the Security log on ws-042,
The one event a cleared Security log leaves, on ws-042 during the USB session.
The account the clear ran under, the session the USB activity ran under. It is the account to account for, not proof she did it herself.
As Windows writes it:
Account NamealiceThe domain of that account. On a workstation a local account would show the computer name here instead.
As Windows writes it:
Account DomainCORPMatch this Logon ID to event 4624 to see how and when the session signed in. The clear removed the rest, so an earlier sign-in may be all that is left.
As Windows writes it:
Logon ID0x1A2C3D
Defender for Identity Alerts
Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.
- Group Policy Tampering (opens in a new tab)Only reaches the case where a Group Policy change switched logging off through policy. A log cleared, or a channel disabled, on one machine is outside Defender for Identity's reach, so lean on the endpoint and the collector.
Blind Spots
Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.
- Clearing a log destroys what came before it, so the records you most want are the ones already gone. Events 1102 and 104 date the clear, but do not bring the records back.
- A channel that is disabled or shrunk writes no event at all, so a gap in a log is the only sign, and only the Event Log Settings key dates when it started.
Look for It on a Machine
The Registry keys on an endpoint that hold a trace of this, each opening its own page.
Hunt It
The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.
Needs the device onboarded to Defender for Endpoint. The SecurityLogCleared action matches event 1102. A disabled or shrunk channel writes no action, so read the Event Log Settings key for that.
// The Security log cleared, recorded by Defender for EndpointDeviceEvents| where Timestamp > ago( 30d)| where DeviceName startswith "ws-042"| where ActionType == "SecurityLogCleared"| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, InitiatingProcessCommandLine| order by Timestamp descHow to Prevent It
The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.
Windows Event Forwarding (opens in a new tab)
Forward the events you choose to a collector as they are written, so a cleared or shrunk local log still leaves a copy to read.
Tiered administration (opens in a new tab)
Keep admin rights, which a log clear needs, off everyday machines, so fewer accounts can silence a log at all.
Sources
- MITRE ATT&CK T1685.005: Disable or Modify Tools: Clear Windows Event Logs (opens in a new tab)
- MITRE ATT&CK T1685.001: Disable or Modify Tools: Disable or Modify Windows Event Log (opens in a new tab)
- Microsoft Learn: Security event 1102, the audit log was cleared (opens in a new tab)
- Microsoft Learn: event 104, the log file was cleared (opens in a new tab)
- Velociraptor: Windows.EventLogs.Modifications (opens in a new tab)
- Microsoft Learn: use Windows Event Forwarding to assist in intrusion detection (opens in a new tab)