skip to content

Your operator's log-clear was blocked and no Windows Security 1102 exists — what may you conclude?

level: middleimportance: should knowfreq 52%

answer

  1. one positive record, one absence
  2. 1102 records a completed clear
  3. absence looks like nobody tried
  4. prevention events live in the vendor console
  5. process creation happened before the block

basics

~10 s

Only that the clear never completed. Windows Security 1102 is written when the audit log is cleared, so its absence is indistinguishable from nobody trying. The prevention event is your only positive evidence.

solid answer

~50 s

The two records answer different questions and are routinely read as one. The endpoint prevention event proves the attempt occurred and that the agent convicted and stopped it - it is your only positive evidence, and it typically lives in the endpoint console, so whether the SOC has it at all depends on forwarding you must verify rather than assume. Windows Security event 1102 records that the Security audit log *was cleared*; it is a completion record, not an attempt record, so a blocked clear leaves no 1102 behind. Its absence therefore proves nothing on its own. What I would check next is whether the process-creation telemetry survived - a Sysmon Event ID 1 record, or Windows Security 4688 if command-line auditing is enabled - because that, not the block, is what a detection could be written on.

code

json · 13 lines
json
{
  "timestamp": "2026-03-11T14:22:07Z",
  "host": "WKSTN-4471",
  "user": "CORP\\j.mercer",
  "event_type": "prevention",
  "action": "blocked",
  "rule": "Clear Windows Event Logs",
  "technique": "T1070.001",
  "process_image": "C:\\Windows\\System32\\wevtutil.exe",
  "command_line": "wevtutil cl Security",
  "parent_image": "C:\\Windows\\System32\\cmd.exe",
  "...": "..."
}

go deeper

for a junior

Know that Windows Security 1102 means the audit log was cleared, and that a blocked clear therefore leaves none. Be able to say which of the two records is positive evidence that something was attempted.

for a middle

Explain where a prevention event physically lives and why forwarding to the SIEM is a separate fact to verify. Be ready to name the process-creation telemetry that survives a block and the 4688 command-line caveat.

for a senior

Demonstrate that you reason about direction: what each record proves, what it cannot, and which absences are ambiguous. Expect to be asked what you would build a detection on when the block truncated the behaviour.

for a principal

Own the consequence at estate scale: if prevention events are not forwarded, the organisation's memory of attempted evasion lives in a product console nobody queries. Decide whether that pipeline is worth funding against the noise it adds.

## Two records, two different claims On a Windows workstation estate running an endpoint agent in blocking mode, an emulation operator attempts a defence-evasion step: stop the sensor's service, then clear the Security event log with `wevtutil cl Security`. Tamper protection refuses the service stop and a prevention rule terminates the log-clear. Afterwards two records get discussed as though they were one thing. They are not. **The endpoint prevention event.** This is the agent saying: I matched this behaviour and I stopped this process. It carries the host, the user, the process image and command line, the parent image, and the rule or technique the vendor mapped it to. What it establishes is strong and narrow - the attempt happened, on this host, at this time, and the control acted. What it does *not* establish is that anyone in the SOC knows. Prevention events land in the vendor's own console by default; whether they are forwarded to the SIEM, whether a correlation rule keys on them, and whether they raise anything into a worked queue are three separate facts you have to check rather than assume. A great many estates have a rich prevention history that no analyst has ever looked at. **Windows Security event 1102.** This event means the Security audit log was cleared. It is written by the logging subsystem as a consequence of the clear happening - it is a completion record, not an attempt record. If the clear was blocked, the clear did not happen, so there is no 1102. That is the correct behaviour and the desirable outcome, and it is also why the absence of 1102 is evidentially worthless on its own: a machine nobody touched, a machine where the attempt was blocked, and a machine where nothing was ever tried all present the same empty result. Absence of a completion record is not evidence about attempts. ## The trap this sets for the results table The detection engineer reviewing the run sees "blocked" in the endpoint console and "clean" in the Security log and reads it as two independent confirmations. It is one confirmation and one non-observation. Worse, if the prevention event is not forwarded, the *entire* estate-side record of a defence-evasion attempt against a production workstation exists only inside a product console that nobody queries. The right conclusion is: prevented, with the positive evidence being the prevention event, and detection status unestablished pending a check of what else survived. ## What else survives a block, and why it matters A prevention terminates the process, but process creation generally happened first. If Sysmon is deployed, Event ID 1 records process creation with the full command line, the parent image and hashes. Natively, Windows Security 4688 also records process creation, but it carries the command line **only if** audit policy has been configured to include it - a default-configured estate has 4688 without the argument that makes it interesting. Those records are the material a detection could actually be built on, because they are written regardless of what the control decided afterwards. Checking for them is the difference between "we have no visibility of this behaviour" and "we have the telemetry and simply never wrote the rule". ## Direction of inference, stated carefully - A prevention event proves a control acted. It does not prove an analyst saw anything. - A 1102 proves a clear completed. Its absence proves neither an attempt nor a non-attempt. - A process-creation record proves a process was launched with those arguments. It does not prove the process succeeded at what it was launched to do. - None of the three proves malice; in an emulation run you already know the intent, which is exactly why the run is useful for testing what the records would have supported. ## What good looks like in the answer Say which record is positive evidence and which is an absence. Say where the prevention event physically lives and that forwarding is an open question. Say that 1102 is a completion record so a blocked clear cannot produce one. Then move to the constructive step - look for the process-creation telemetry for the blocked attempt, because if it exists a detection is cheap to write, and if it does not, the estate's only knowledge of this behaviour is a control that has to be right every time.

  • The agent also refused the attempt to stop its own service. What Windows record does that leave?
    Not a service state-change record, because the state never changed - the stop was refused. What can survive is the process-creation record for whatever tool was used to attempt it, if Sysmon Event ID 1 is collected or 4688 is configured with command-line auditing. Otherwise the attempt exists only as the agent's own tamper-protection event.
  • Why is absence of 1102 in the SIEM a weak way to show the block worked?
    Because it is an absence, and absences in this domain are ambiguous by construction. It has the same shape as a host nobody attacked. The positive evidence is the prevention record naming the host, the command line and the time; cite that, and use the missing 1102 only as a consistency check against it.
  • How do you check whether the SOC would ever have seen this prevention event?
    Query the SIEM for that host and time window and see whether the prevention event arrived at all. If it did, check whether any rule keys on prevention events of that class and whether the resulting alert goes to a worked queue rather than an informational index. Forwarded, matched and queued are three separate checks.

saying these in an interview costs you the question

  • Treats an endpoint console event as a SIEM detection
  • Says 1102 fires when a clear is attempted
  • Reads a missing 1102 as proof logging is healthy
  • Forgets process creation is recorded before the block
  • Assumes 4688 always carries the command line

context

resolving links…