← Blog

Most of our Windows alert noise was our own test harness, and silencing it cut the baseline by about 80%

Discovery · 2026-11-02

In 10,000 alerts an hour, and 87% of them came from one audit setting we showed that Wazuh rule 60107 (Security event 4673) was most of the Windows lab victim's noise, and that we had caused it by turning on "Sensitive Privilege Use" failure auditing. This is the follow-up. We pulled the raw events, found out what was actually failing, and tuned it. Everything here is about our lab victim and our test harness. A production Windows fleet has no vmtoolsd.exe guest-operation logons to silence, so none of this says how noisy your hosts are.

What was failing

The earlier post said we did not know which process was failing the privilege checks. The committed run bundles hold rule ids, not event fields, so the answer came from raw alerts on the lab host. Those raw files are not committed, which means the counts in this section come from the report analysis/reports/noise-tuning-60107-100230-2026-10-30.md and not from anything you can re-derive from the repo's bundles. Across 163 local bundles with Windows alerts:

• Rule 60107 produced 158,534 alerts. One combination made up 99.7% of them (158,126): svchost.exe from System32, the single privilege SeTcbPrivilege, the built-in Administrator account, result AUDIT_FAILURE.
• The failures came in bursts of about 195, each sitting inside one batch (type 4) logon of Administrator by vmtoolsd.exe, closed by a logoff about 3 seconds later.
• Those logons are our own harness. Every time it runs a program in the guest through vmrun runProgramInGuest, VMware Tools logs in as Administrator. Short operations (file-exists and process polls, about 15 ms) produced none. The roughly 3-second program runs produced about 195 each.

So most of the "baseline noise" was the measurement instrument. The audit setting from the first post is what made the instrument visible.

Round one: the failing event

Rule 100450 is a level-0 child of 60107. It matches only a Security 4673 failure from exactly C:\Windows\System32\svchost.exe for exactly SeTcbPrivilege as a RID-500 account. Anything else still alerts, including a SeDebugPrivilege failure (the shape of an unprivileged lsass dump attempt), any other process, a masquerading svchost.exe outside System32, or any other account.

The same report also tightened our own level-10 rule 100230, which was firing about 43 times per baseline with no attack running, by requiring the parent not be a service account.

Measured after deploy, on the seven runs of the next wave (run-2026-10-30-001 to -007, all detected):

The "before" figures are the report's. The "after" figures we re-read from the bundles: the first run, run-2026-10-30-001, had a baseline of 474 hits, and run-2026-10-30-007 had 1,629.

Round two: the logons themselves

With 60107 gone, the 474 to 1,629 baseline was growing run by run. In run-2026-10-30-007 three rules, 67022 (logon, 4624), 67023 (logoff, 4634) and 67028 (special privileges, 4672), accounted for 295, 294 and 296 of the 1,629 hits. They are the same harness logons, now visible because 60107 no longer buried them. They climb through a batch because each baseline window overlaps the guest operations of the entries before it.

Three more level-0 rules cover them:

• 100451 silences a 4624 only if every one of these holds: logon type 4, logon process Advapi, caller exactly C:\Program Files\VMware\VMware Tools\vmtoolsd.exe, and a RID-500 target. Other logon types (interactive, network, RDP), other callers and other accounts still alert.
• 100452 silences a type-4 4634 logoff of a RID-500 account.
• 100453 silences a 4672 for RID-500 only. The rule file calls this the deliberate trade-off, because a 4672 event carries no logon type or caller. Every RID-500 logon loses its "special privileges assigned" alert, though the 4624 for the logon itself still alerts if it is not one of ours.

The 4688 process-creation rule 67027 was deliberately left alone: our detections chain from it, and atomics are launched by vmtoolsd.exe, so silencing it risked hiding a real detection.

What we measured

After the install on the lab manager, the first four runs were run-2026-11-02-013 to -016, all detected.

The previous wave's median baseline was 1,138 (from the report); the median of these four is 172.5, about 85% lower. The ranges overlap nowhere: 474 to 1,629 before, 116 to 264 after. For a like-for-like pair, the first run of each wave went from 474 to 116 (about 76% lower).

Where the floor is now, honestly

The reduction is real but it is not a flat floor. The baseline still climbs through a batch: 116, 131, 214, 264 in the first four runs, and then 354, 427, 375, 343, 333 in the five Wave 3 runs (run-2026-11-02-017 to -021). Rule 67027 (the harness's own process launches) is the largest single piece, 49 to 186 per baseline, and 60107 is still present at 1 to 17 per baseline, down from thousands. So the honest summary is "from about 500 to 1,600 down to about 100 to 430", not "solved". The report's own next step for the floor is the 4688 launches, which is the harder question for the reason above.

Caveats

• The replay cannot test the safe side. Every 670xx event in the replayed windows was harness-generated, so the host replay shows the rules match the harness but cannot show they spare a real logon. A unit test pins that behaviour; no live run does. Treat it as designed, not measured.
• Level 0 hides alerts, it does not delete them. The silenced events are still available if full archiving is on. They just stop counting as alerts.
• No detection regressed in these runs. All nine runs from run-2026-11-02-013 to -021 graded detected. That is nine runs, not proof that no future rule depends on these logon events.
• The cause of the original bursts is inferred from the bundles and raw events, not from a controlled A/B of the harness. We have not re-run the harness with failure auditing switched off.

The practical lesson: when a lab baseline looks absurd, check whether the thing generating the events is you.