Log Dejargonizer

Windows Security Log · Event 1102

Event 1102: The audit log was cleared

Someone wiped the Windows Security log. There is almost no legitimate reason to do this on a production machine, and it is one of the few events that is a finding entirely on its own. Whatever was in the log is gone.

Also written as 1102Event ID 1102The audit log was clearedSecurity log cleared

What it means for you

On a personal computer

The record of security activity on this PC was deleted. People occasionally do this to tidy up Event Viewer, but if you did not, it is a serious sign — erasing the log is one of the first things done to hide an intrusion.

For an analyst

This is why forwarding logs off the host matters: 1102 tells you evidence was destroyed but not what it said, unless you already shipped it elsewhere. The event survives the clear because it is written immediately afterwards. Treat it as act-now and pull the forwarded copy before anything else.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
The audit log was cleared.

Subject:
  Security ID:  CORP\jbrooks-adm
  Account Name: jbrooks-adm
  Domain Name:  CORP
  Logon ID:     0x3E9A11

The fields that decide it

Everything else in the log line is context.

SubjectUserName
The account that cleared the log. This is the entire event.
SubjectDomainName
The account's domain.
SubjectLogonId
The session that did it. Join to the 4624 to find where they signed in from — which may itself be the only remaining trace.
SubjectUserSid
The security identifier of the account, which survives a rename.

Ordinary reasons this happens

Most of the time it is one of these.

  • An administrator clearing logs while rebuilding or decommissioning a machine.
  • A deliberate cleanup before handing a test machine to someone else.
  • Troubleshooting where someone clears the log to watch a specific problem reproduce cleanly.
  • Some backup and archiving tools clear the log after exporting it, though this should be a configured and documented behaviour.

When it is not ordinary

Destroying evidence after an intrusion.

What gives it awayA clear with no matching change record, particularly on a server or domain controller, and particularly outside working hours.

ATT&CK T1070.001

Covering the tracks of privilege escalation.

What gives it awayA clear shortly after account creation, group membership changes, or unusual privileged sign-ins on the same host.

ATT&CK T1070.001

Preparing a machine before a wider attack.

What gives it awayClears across several machines in the same window, which no legitimate process does.

ATT&CK T1070.001

What to do next

  1. Retrieve the forwarded copy of the log from your collection platform immediately. That is the actual investigation; the local log is gone.
  2. Read SubjectUserName and establish whether that person cleared it deliberately.
  3. Take the Logon ID and find the corresponding 4624 to learn where the session came from.
  4. Check whether other machines were cleared in the same window.
  5. Look at what the same account did in the hours before, using whatever logs remain elsewhere — endpoint tooling, network records, other hosts.
  6. If it cannot be explained, isolate the machine and treat everything on it as untrusted.

Queries to run

kql There should be nothing here. Anything that appears is worth a phone call. 
SecurityEvent | where EventID == 1102 | project TimeGenerated, Computer, ClearedBy = SubjectUserName, SubjectLogonId | order by TimeGenerated desc
kql Pulls the source address of the session that cleared the log, which often survives when nothing else does. 
SecurityEvent | where EventID == 1102 | join kind=leftouter (SecurityEvent | where EventID == 4624 | project SubjectLogonId = TargetLogonId, IpAddress, LogonType) on SubjectLogonId | project TimeGenerated, Computer, SubjectUserName, IpAddress, LogonType
powershell Check a single machine directly. The event persists after the clear because Windows writes it as the first entry in the new log. 
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} | Select-Object TimeCreated, MachineName, Message
splunk 
index=wineventlog EventCode=1102 | table _time dest Account_Name

Common questions

Why does Event 1102 still exist if the log was cleared?

Because Windows writes it as the first entry in the newly emptied log, immediately after the clear completes. It is the one record that deliberately survives the operation, which is exactly what makes it useful.

Is clearing the Windows Security log ever legitimate?

Occasionally — during a machine rebuild, when handing over a test system, or while troubleshooting a problem that needs a clean log to observe. What separates those from an attack is that they are planned, documented, and performed by someone who will confirm it when asked. An unexplained clear on a production server should be treated as an incident.

Can I recover a cleared Windows event log?

Not from the machine itself — the clear is destructive and there is no undo. You can recover it only if the events were already forwarded somewhere else, which is the strongest practical argument for centralised log collection. Forensic recovery from disk is occasionally possible but unreliable and not something to plan around.

Someone cleared the Security log on my server. What do I do first?

Pull the forwarded copy of that host's logs from your collection platform before anything else, because that is now the only record of what happened. Then identify the account from the 1102 event, find where it signed in from, and treat the machine as untrusted until you can explain the clear.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026