Which attacks show up in Event ID 1102?

What Event ID 1102 usually tells you about attacker behaviour

Event ID 1102 is not a benign administrative note. It usually means someone cleared the Windows Security log, which is a classic sign of log tampering, post-compromise cleanup, or an attempt to break detection and investigation. The key question is not just whether the event exists, but whether it fits a broader sequence of suspicious activity across the same host and account.

Attackers clear logs when they want to reduce visibility after credential theft, privilege escalation, lateral movement, or execution of tools that would otherwise leave a trail. That is why Event ID 1102 is best treated as an investigation trigger, not as proof of compromise by itself.

On its own, the event only confirms that the security audit log was cleared. What makes it meaningful is the context around it: who did it, from where, what else happened on the host, and whether management or administrative activity could legitimately explain it.

How to interpret the event in the rest of the timeline

Start with the subject user and logon ID recorded with the event, then correlate that identity across nearby logon, process creation, service, and remote administration activity. If the log clear is legitimate, there should usually be a defensible administrative story, such as a documented reset, rebuild, or maintenance workflow.

Look for events that commonly precede or follow log clearing, including unusual privileged logons, remote shell use, script execution, service creation, scheduled task creation, PowerShell activity, and evidence of other logs being disabled or truncated. A useful investigation often depends on Windows Event Log Guide because the surrounding Windows audit trail is what turns Event ID 1102 into an actionable signal.

In practice, the event is more suspicious when it appears on a server or workstation that should not be administratively touched, when it is followed by a gap in telemetry, or when the same account also shows signs of remote execution or privilege use. If the event appears after a burst of other suspicious activity, treat it as an attempted cover-up rather than an isolated log event.

What to do when the log was cleared

Preserve whatever telemetry remains before investigating further. If the local security log is gone, your next evidence sources are typically forwarding targets, endpoint telemetry, remote management records, EDR/XDR data, and administrative access logs from surrounding systems. If the activity is tied to a system used for scripting or orchestration, review the host for companion traces that may survive log clearing, such as Sysmon data or script logging. The Sysmon Guide is useful here because it focuses on tamper detection and event-level visibility beyond the native security log.

If you confirm that the clear was not authorised, treat credentials and active sessions on that host as suspect. At minimum, review whether the account used to clear the log had broader access than necessary, whether other privileged sessions were active, and whether lateral movement may already have occurred. In many cases, the right response is to isolate the endpoint, rotate exposed credentials, and rebuild trust in the host before returning it to service.

When the clear was performed through management tooling, separate expected administrative activity from suspicious operator behaviour. A sanctioned log clear should be explainable, attributable, and rare. Unexplained clears, especially after suspicious process or remote access activity, are a strong indicator that the attacker was trying to hide prior actions.

Risk and Threat Considerations

Clearing the Windows Security log creates a visibility gap that can hide both the initial compromise and the later actions that matter most to incident response. That gap is especially dangerous when the attacker already has administrative rights, because the same access that enables execution can also remove the evidence needed to prove scope.

Failure mechanism: An attacker or malicious insider uses elevated access to clear the audit trail after credential theft, remote execution, privilege escalation, or lateral movement, then continues operating with reduced detection risk.

Impact: Investigators lose chronology, containment becomes slower, and any downstream compromise may remain undiscovered until the attacker has already expanded access or exfiltrated data.

Practitioner Guidance

What to verify: Confirm whether the clear maps to an authorised maintenance action, a rebuild, or a documented administrative workflow. If you cannot tie the event to a known change record, treat it as suspicious until proven otherwise.

Decision rule: If the same user or host also shows unusual privilege use, remote administration, or suspicious process activity, prioritise containment and forensic preservation before trying to determine motive.

What practitioners underestimate: The event is often only the cleanup step. The real question is what happened before the log was cleared, and whether other telemetry sources still contain the missing trail.

Practitioner takeaway: Event ID 1102 should shift the investigation from “what does this event mean” to “what evidence was the actor trying to erase, and what other hosts may already be affected?”

Related resources from NHI Mgmt Group

• Which attacks show up in Event ID 4624?
• Which attacks show up in Event ID 4648?
• Which attacks show up in Event ID 4625?
• Which attacks show up in Event ID 4719?