The detection illusion

01The prediction

It is widely believed that many successful attacks are invisible to default logging — that a network can be compromised without leaving a usable trace. We thought this was likely true even for common techniques, so we wrote it down in advance: more than 30% of successful attacks would evade native Windows event logs. Stating the threshold beforehand is what lets a negative result mean something.

02How we measured it

We executed two real attacks — a Kerberoasting service-ticket request (ATT&CK T1558.003) and an SMB credential-use logon (T1078) — across eight held-out defensive postures on a live multi-domain forest. For every attack that succeeded, we recorded whether the corresponding Windows Security event fired: event 4769 for the Kerberoast, event 4624 for the credential-use logon. We scored the same attacks under four detection configurations.

config Ano monitoringthe baseline: nothing is collected, so nothing can be seen.

config B / Dnative event logsWindows events 4769 and 4624, read directly from the live domain controllers.

config CWazuh SIEMa security-monitoring layer with tuned rules over the same events.

03What we found

Of 30 successful attacks under native logging, all 30 were recorded. The native detection gap was zero. With no monitoring at all, by definition every successful attack was invisible. The contrast that matters is between those two configurations, not among the monitored ones.

Why does the gap close so completely? Both techniques are intrinsically loud in the Windows Security log. A Kerberoast requests a service ticket, and the domain controller records event 4769 every time. A credential-use logon records event 4624. There is no quiet variant in this attack set: when delegation is hardened to AES-only encryption, the Kerberoast does not become stealthy — it simply fails, producing no crackable ticket, so it never enters the "successful but undetected" category at all.

04Native logs versus a SIEM

To complete the comparison, we deployed a Wazuh SIEM — a manager and indexer on the forest, agents on the domain controllers, and rules keyed to the relevant accounts — and re-ran the attacks with both detection sources recording each execution at once. This gives a direct, same-execution comparison rather than two separate runs.

Wazuh detected every one of the 45 successful attacks, the same zero-percent gap as the native logs. The two sources agreed on 95.6% of executions. In every case where they disagreed, Wazuh was the one that caught the event: on two credential-use logons, its continuous collection recorded an event that the native point-in-time query happened to miss. The reverse never occurred.

The difference between the two sources is therefore not about what the logs contain — both see the same Windows events — but about how the events are collected. A SIEM that ingests continuously is a more forgiving collector than a single query run against a live log. The choice of detection source did not open a gap; it narrowly closed a collection-timing one. This is consistent with our broader reading of the result: the events exist, and the operational question is whether anything is collecting and watching them.

05What this means

We do not read this as "detection is solved." Two techniques is a small sample, and both are unusually loud. The useful conclusion is narrower and, we think, more accurate than the common framing: for these attacks, the native Windows logs are not the weak link. The weak link is operational. The events are written, but only an organization that is collecting and alerting on them benefits. The unmonitored configuration — the one that misses everything — is also the common one in practice. That is where the illusion lives: in believing one is covered because the logs could see the attack, when nothing is watching them.

06Limitations