Windows Security Event ID 1102 fired on a compromised workstation — does that mean the logs for that period are gone?
answer
- ask where else the record lives
- the clear writes its own entry
- local channel versus collector copy
- the forwarder's last send bounds the loss
basics
~20 sEvent ID 1102 records that the Windows Security log was cleared, and is written after the clear itself. Anything already forwarded to the collector survives there, so the cleared window is usually still readable centrally.
solid answer
~50 sNo. Event ID 1102 in the Windows Security channel means that channel was cleared; the Event Log service writes the record immediately after the clear, naming the account and the time, so the act of destroying the log leaves its own entry. Clearing only destroys the host's local copy. Every record the forwarder had already shipped sits on a collector the host cannot reach, under retention the SOC controls — so I read the cleared window centrally, filtered to that host. What is genuinely lost is bounded by the forwarder's progress: records written after its last successful send and before the clear exist in no copy anywhere. So my first move is to find the last event actually received from that host before the gap, and to check the account and time in the 1102 against change records, because imaging and administrators clear logs too.
go deeper
Be ready to say in one line what 1102 means, that it is written after the clear, and that anything already forwarded still lives on the collector. Naming the account and time as the first things you check is expected.
Explain the mechanics: the channel is a local file, the forwarder ships from a stored position, and the unrecoverable slice is whatever was written after its last successful send. Show how you size that slice from the collector.
Demonstrate the judgment: correlate the clearing account against change records before escalating, decide whether acquiring the host still adds anything, and state the unobserved minutes in the report instead of implying the window was clean.
Own the design consequence: telemetry that only lives where an administrator can delete it is not evidence. Argue for forwarding that the host cannot revoke, and for central retention chosen against expected dwell time rather than storage cost.
## What Event ID 1102 actually is Windows writes one event into the Security channel every time that channel is cleared: Event ID 1102, `the audit log was cleared`. The Event Log service writes it immediately after the clear, so it is normally the first record in the newly empty channel, and it carries the account name, domain and SID of the principal that performed the clear, that logon's identifier, and the time. This is deliberate design: the act of destroying the record leaves a record. ## What it proves, and what it does not It proves that an account holding the privilege to clear the Security log used it on that host at that time. It does not tell you what the log contained. It does not tell you the clear was hostile. And it does not tell you a person was at the keyboard — an action recorded under an account proves a credential was accepted and used, never that its owner was present. Clears happen for dull reasons: imaging and build automation, an administrator emptying a full channel, some management tooling. So 1102 is a strong lead rather than a verdict. The first triage moves are to compare the account, the host and the minute against change records, and to look at what else that account did that day. Forwarding 1102 and alerting on it is usually a high-precision detection because genuine clears are rare — but on estates where imaging produces them, exclude the build hosts by asset rather than muting the rule for everyone. ## The two-copy model — the point of this topic A host produces one stream of records that lives in two places with two different owners. | copy | lives where | controlled by | destroyed by | |---|---|---|---| | local | a fixed-size channel file on the host | anyone with administrative rights on that host | a clear, or rotation overwriting it | | forwarded | a collector or SIEM the host cannot write to | the SOC, under its own retention | central retention expiry | Clearing the channel destroys only the first copy. That is why a cleared Security log is very often still fully readable: you read it off the collector, for that host, over that window. Whoever cleared the log removed their own copy of a letter they had already posted. ## What is really lost The loss is bounded by the forwarder's progress, not by the clear. A forwarder reads the channel from a stored position and ships in batches, so at the instant of the clear it has drained everything up to some point and nothing after it. Records written after that point and before the clear exist nowhere: the local one was destroyed, the remote one was never made. Under healthy conditions that is seconds to a couple of minutes. If the forwarder was lagging, stopped, or the site link was saturated, it can be hours. So the investigative question a clear raises is not `what did the log say` but `how far behind was the forwarder when the channel was emptied`. You answer it from the collector: find the newest event received from that host before the clear, and the interval between it and the 1102 is the window that has no copy anywhere. That interval is what the incident report must name as unobserved, rather than implying it was clean. ## Deciding whether the host is still worth acquiring If the central copy of the channel is intact for the whole window, acquiring the host adds little to the log question — but the log question is only one question. The host still holds everything that was never logged in the first place: files on disk, persistence, artefacts no audit policy covers. And the clear itself raises the priority of the host, because someone taking the trouble to empty a Security log is a reason to treat that machine as compromised until shown otherwise. ## Get the direction of the claims right - 1102 present means the log was cleared. 1102 absent does **not** mean it was not: a channel file removed while the service is stopped, or a rebuilt host, leaves no such record. - A record present centrally means it was shipped. Central silence does **not** mean nothing happened — it can equally mean nothing was shipped. - A clear is an artefact you observed, not a behaviour you have characterised; do not write `evidence destruction` into a case note until you can say which account did it and whether it had a benign reason.
- Does the 1102 record tell you which events were destroyed?No. It records the clear, not the contents. You reconstruct what was in the channel from the collector's copy for that host and window. The only genuinely missing part is what was written after the forwarder's last successful send and before the clear, and you size that interval by finding the last event the collector received.
- If the collector's copy is intact, is the host still worth acquiring?Usually yes, but for different reasons. The central copy answers what was logged; the host answers what was never logged at all — files, persistence, running state, artefacts outside audit policy. The clear also raises the host's priority, since deliberately emptying a Security log is itself a reason to treat the machine as compromised.
- Is a 1102 always malicious?No. Imaging and build automation, an administrator clearing a full channel and some management tooling all produce it. That is why the account, the host and the minute get checked against change records before anyone escalates. A clear with a matching change ticket on a build host is a benign true positive, not a false positive.
Clearing your own Security log is like shredding your copy of a letter you already posted. The recipient still has theirs, and the shredder left a receipt.
saying these in an interview costs you the question
- Says a cleared log means the events are permanently destroyed
- Treats 1102 as proof of an intruder without checking the account
- Assumes the collector's retention matches the host's channel
- Thinks the clear also removes the 1102 record itself
- Forgets that events not yet forwarded are lost outright