Not three percent. Three techniques.
The four chains you would most want to catch — discovery, collection, exfiltration, C2 — produced
zero alerts between them.
I want to be precise about what that number is and is not, because the number is easy to
misread in both directions.
What it is
A default install. Stock rules, no Sysmon, no ScriptBlock logging, no tuning. We replayed 24
techniques and counted how many produced an alert a human would see. Denominator: 24. Numerator: 3.
What it is not
It is not a claim that Wazuh is a bad SIEM. It is a claim that a default SIEM is close to
blind, and that most of the detection you think you bought is configuration you have not done yet.
The same technique, three SIEMs
T1110.001 (brute force) is the one technique we have run end-to-end on all three platforms.
| SIEM | Setup | Result | MTTD |
|---|---|---|---|
| Wazuh 4.14.2 | SSH brute force, 20+ failed logins, custom rule 100113
|
ALERTED ×2, coverage 100% | 25s / 45s |
| IBM QRadar CE 7.3.3 | hydra, 50 SSH login attempts against a live victim host | ALERTED | ~4s |
| Splunk Enterprise |
winsrv01, 12× EventCode 4625 — events replayed into Splunk, not generated by a live attack
|
ALERTED | 0s |
Read the third row differently from the first two. Wazuh and QRadar were measured against a real
attack on a real host: hydra and a live SSH brute force, with the alert coming back out of the
platform. The Splunk row is a real Splunk Enterprise, a real detection-as-code rule, and a real
query — but the 4625 events were replayed in rather than produced by an attack we ran. That makes
it a valid test of the connector and the rule. It is not a test of Splunk's ingest path, and we are
not going to let it read as one.
🔴 Do not read this table as a race either. The three numbers are not comparable and we are not
going to pretend they are. Splunk's 0s is not Splunk being six times faster than QRadar — it is
Windows 4625 events already sitting in the index before the clock started, while the Wazuh figure
includes agent-to-manager-to-indexer propagation on a technique we had to write a rule for.
Different telemetry, different clocks, different work. Published anyway, with the caveats attached,
because a table with an honest asterisk is worth more than three separate write-ups with none.
The MISSED row is the one we care about most. Alongside winsrv01, we ran cleanhost — a host
with no events at all — and the connector correctly returned MISSED. A benchmark where nothing
can fail is not a benchmark. That negative control is what makes the other rows mean anything. A
third host, dbsrv02, carried events timestamped 4s late and returned MTTD 4s, so the clock is
measuring something real rather than returning zero by construction.
Two more findings from the same lab — and two things withheld
- Real ransomware encrypting real files → caught by Wazuh file integrity monitoring in real-time mode. Two things are withheld here on purpose: the detection time, because the figure in our internal notes does not appear in any published report we can point you at, and the rule id, on the same ground.
- SSH brute force → alert and an actual firewall drop that reached the host and stayed there. The rule ids for that one are withheld on the same ground.
We had both sets of ids written down and we have taken them back out. An id you cannot trace to a
source file is a claim nobody can check, which is worse than no id at all.
Dates, because they matter
These are lab measurements taken in June 2026, not last week. The Wazuh lab run is 15 June, the
Splunk connector proof 26 June, the QRadar proof 29 June. Nothing here has been re-run since. If
any of these platforms has changed its default rule set in the meantime, our numbers are stale and
we would like to know.
Why we can publish this and a vendor cannot
Every SIEM vendor can measure their own product. None of them can publish a table where their
product is one row among three, because the row that looks worst is the one paying for the
marketing team. We sell neither Wazuh, QRadar, nor Splunk. That is the entire reason this table
exists.
We will also tell you what we have not measured. We have not run this against Sentinel or
Elastic on live systems. We have no third-party audit of any of it — every number above is our own
measurement of our own lab, and you should discount it accordingly until someone outside our
company reproduces one.
Run it yourself
The detection library behind this is 71 scenarios, 84 Sigma rules, 84 techniques, with zero gap
between scenarios and rules, plus 6 named threat-actor campaigns. Rules translate to Splunk SPL,
Sentinel KQL, Elastic and Wazuh from the same detection-as-code source.
If you run any of those SIEMs and want your own number instead of ours, say so — we would rather
argue with your data than with our own.
Corrections wanted. If you think the 3/24 is wrong, tell us which technique should have fired
and on what rule. We will re-run it and publish the correction with the same prominence as the
original claim.
Top comments (0)