10,000 alerts an hour, and 87% of them came from one audit setting
Most of our posts are about what fired when we attacked something. This one is about what fires when we don't. Before every detonation, the lab harness records 30 minutes of alerts from the victim. Across the 2026-10-27 wave we finally measured that baseline properly, and the result was bad enough to deserve a post of its own.
The numbers
| Windows victim (29 runs) | Linux victim (4 runs) | |
|---|---|---|
| Baseline alerts per hour (30 min before detonation) | median >= 10,000 | median 130 |
| Alerts in the 90 s detonation window | median 1,813 | 5 |
| Same window, minus one rule | median 147 | 3 |
Same SIEM, same harness, same 30-minute window. The Windows host is roughly 75 times louder than the Linux one, and the real gap is bigger than that. The harness queries the baseline with a 5,000-hit cap, and 27 of the 29 Windows runs hit it. So 10,000 an hour is a floor. Only two Windows runs came in under the cap, at 836 and 3,626 an hour.
One rule is most of it
Wazuh's built-in rule 60107, "Failed attempt to perform a privileged operation", fires on Windows Security event 4673. It is level 4, so it never pages anyone, but it is 87.2% of all Windows baseline hits (119,656 of them) and 91.7% of the alerts in the detonation windows. Take that one rule out and the median detonation window drops from 1,813 alerts to 147.
Everything else is small. The next biggest sources are the logon/logoff and process-creation family (4624, 4634, 4672, 4688 via rules 67022, 67023, 67028 and 67027), at 1 to 4% each.
The next wave, on 2026-10-28, showed the same thing: 17 of 21 Windows baselines hit the cap, and 60107 was 91.2% of the window alerts.
We caused it
This noise did not come with Windows. We turned it on.
Our earlier victim image, golden v1, used through 2026-10-16, had a median Windows baseline of about 300 alerts an hour. On 2026-10-17 we switched to golden v2, a "telemetry-complete" build. Its provisioning script (lab/provision/win-victim-telemetry/enable-telemetry.ps1) turns on a list of advanced audit subcategories, and one of them is:
'Sensitive Privilege Use' = 'success,failure' # 4673/4674 (SeDebugPrivilege use around lsass dumping)The reason was sound. We wanted the privilege-use events that show up around credential dumping from lsass. But "Sensitive Privilege Use" audits every check of a sensitive privilege on the box, and with failure auditing on, a normal Windows host fails those checks constantly. Every v2 Windows baseline we have measured since has been at least 836 an hour, and most hit the cap. Our 2026-10-25 scorecard counted 60107 at 80.6% of all baseline rule hits (118,620 of 147,095) in the bundles that record per-rule counts.
To be clear about what we don't know: the committed run summaries carry rule ids, levels and timestamps, not the raw events. We can't yet say which process is failing those privilege checks. That needs a raw-event pull.
Why this matters for detection, not just disk space
Signal-to-noise. In the 2026-10-27 wave, each Windows detection was one matching alert among about 1,800 others. The median noise-to-signal ratio was 1,808 to 1. The detections still worked: 13 runs were graded detected after noise adjustment, with a median latency of 43 seconds, because they match on our own rule ids rather than on volume. An analyst scrolling a queue would not have had it so easy.
ATT&CK tags lie at this volume. Rule 60107 carries the ATT&CK tag T1078 (Valid Accounts). If you grade detections by "did an alert with this technique tag fire," run 014 alone would "detect" T1078 with 1,683 false positives. Our harness grades by rule id, which avoids this. A dashboard that counts alerts by technique tag would not.
The cap hides things. When 27 of 29 baselines are cut off at 5,000 hits, "this rule never fired in the baseline" is weaker evidence, because the rule might be in the part that got cut off. The noise makes our own false-positive checks less trustworthy.
Our own rules are noisy too
Rule 60107 is Wazuh's. Rule 100230 is ours: "Access token manipulation: SYSTEM-integrity process created by a non-service parent", at level 10. It fired 1,249 times across the baselines, about 43 per run, with no attack running. Level 10 is meant to get attention. A rule that fires 43 times in a quiet half hour is a false-positive source, and it's on our tuning list.
What we'd tell a defender
- Measure your baseline before you write the rule. Count alerts per hour on a quiet host, by rule id. If one rule is most of the volume, fix that first.
- Every audit subcategory you enable has a cost. "Sensitive Privilege Use" with failure auditing is the expensive one here. Turn it on deliberately, and check the 4673 rate when you do.
- Tune the rule or the policy, and don't just hide it. The two options we're weighing are turning failure auditing off for that subcategory (if the lsass-dump signal we wanted comes from the success events) or setting rule 60107 to level 0 on that host. Neither is applied yet.
- Grade detections by rule id, not technique tag. A built-in rule tagged T1078 will "detect" valid-account abuse all day on a healthy machine.
Caveats
- This is one lab VM, measured in the 30 minutes after a snapshot revert, so it includes boot and restore noise. It is a floor for our lab, not a false-positive rate for a real fleet. A true idle-host baseline needs its own run.
- The Windows numbers are lower bounds because of the 5,000-hit cap.
- The Linux sample is small (4 runs in the wave).
Grounded in analysis/reports/noise-baseline-2026-10-27.md (reproduce with python -X utf8 analysis/noise_baseline.py --date 2026-10-27), section 5 of analysis/reports/scorecard-baseline-and-definitions-2026-10-25.md, and the committed lab/results/run-2026-10-27-* and run-2026-10-28-* bundles.