Skip to content

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.

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.

On ws-042, the Security log is cleared, another log is cleared, and a channel is switched off, so the records of the USB session are gone or never written.Step through it

ws-042 Foothold

  1. Step 1 of 3, Security Log Cleared, on ws-042
  2. Step 2 of 3, Another Log Cleared, on ws-042
  3. Step 3 of 3, Channel Switched Off, on ws-042
  1. 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.

  2. 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.

  3. 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.

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 LogWritten OnLook ForSwitch It On
1102 The audit log was cleared (opens in a new tab) Security logThe computer whose Security log was clearedA 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 logThe computer whose log was clearedEvent 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 Name alice

  • The domain of that account. On a workstation a local account would show the computer name here instead.

    As Windows writes it: Account Domain CORP

  • Match 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 ID 0x1A2C3D

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.

KQLDefender XDR, Advanced hunting
// 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 desc

How 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.

Sources