← Blog

Nine Windows techniques went from "ran, nobody noticed" to detected, and one rule arm still missed

Detection win · 2026-11-02

Everything below is what happened in our own lab: one Windows victim, Wazuh 4.14.7, one Atomic Red Team test per technique. "Detected" means a Wazuh rule we expected fired inside the 90-second detonation window. It says nothing about how these rules would behave on a production fleet.

Where we started

Earlier waves had already run these techniques. Each executed cleanly (exit 0) and each graded partially-detected, meaning the test ran and the SIEM was busy but no technique-specific rule matched. Two examples: run-2026-10-20-013 (T1569.002) had 2,784 alerts and none of them were about a service-control-manager change, and run-2026-10-20-014 (T1685) was recorded as failed with zero alerts at all. run-2026-10-18-011 (T1649) was another partial.

Then we wrote rules, but only from what the endpoint actually logged. Two things shaped them.

1. Write against the captured command line, not the public Atomic text. The lab-services wave (run-2026-11-02-008, -010, -011, -012) executed four tests whose only alerts were generic process-creation rules. The rule file records the facts that mattered: AutoIt3.exe and the reg.exe launched under PsExec produced no Sysmon process-create event, and hashcat.exe itself logged nothing. In those cases the only place the payload shows up is the command line of a Security 4688 event, or of the cmd.exe wrapper. So the hive-save and hashcat patterns match the command line of any process rather than pinning an image name.

2. Ship every rule as a pair. Each new detection has a Sysmon event-1 arm and a Security 4688 arm. That is not decoration; it is the lesson of earlier runs in this lab, where reg.exe emitted no Sysmon event 1 on our victim and only the 4688 version of the rule could fire (first seen in run-2026-10-25-001, fixed and detected in run-2026-10-26-001).

What fired

All nine bundles show the harness marker round-tripping and the live-rule check passing (69 of 69 shipped rules live for the first four, 80 of 80 for the rest). The first four runs were each graded with exactly the two expected rules matched. Detection latency in the bundles ran from 35 seconds (T1649, run-2026-11-02-020) to 94 seconds (T1059, run-2026-11-02-014). The detonation window held 31 to 74 alerts in total, so each detection was one or two matching alerts among a few dozen, not among thousands.

Two of the nine were not new rules at all:

• T1110.003 was already covered by 100440/100441. The earlier partial (run-2026-10-20-007, 3,147 alerts) was a run on a very noisy baseline. On the quieter baseline the same rules fired.
• T1555.004 is the awkward one. In run-2026-10-20-012 rule 100402 did fire on the exact vaultcmd test, but the rule only declared T1555, so the grader scored the run partial. The detection existed; the label was the gap. Adding T1555.004 to the rule is what moved it to detected in run-2026-11-02-018. We are noting this because it means one of the "nine new detections" is a bookkeeping fix, not new coverage.

The arm that missed

T1685 is the honest entry. We shipped 100448 (a child of bundled rule 92027) and 100449 (the 4688 arm). In run-2026-11-02-021 only 100449 fired. The rule comments in gated_rules.txt record why 100448 stayed quiet: the run contains no 92027 alert at all. The Sysmon event for the Invoke-AtomicTest child never produced an alert, and the agent's event queue had hit 90% and full about a minute earlier (rules 202/203). The 4688 event carried the exact command line, so the run still graded detected.

So the pair design earned its keep on the only run where it was tested by failure. We would not over-read that: it is one run, and we have not reproduced the dropped Sysmon alert or confirmed the queue is the cause rather than a coincidence. The wrapper also returned exit 1 for this test, which is the AMSI bypass interacting with Defender, as in the earlier failed run.

What this does and does not show

• It shows that, for these nine tests on this victim, a rule written from the real command line fires, and that giving each rule a second arm on a different log source survived a lost alert.
• It does not show coverage of the techniques in general. Each rule is tuned to one Atomic test's command line. A different tool doing the same thing (another way to save the SAM hive, another cracking tool, a script that exports a certificate without Export-Certificate) would not be caught by these rules.
• False positives are untested here. The runs measure that the rules fire, plus the noise already in the window. They do not measure how often these patterns appear in benign administration, and a few are plainly admin-adjacent (AutoIt, sc sdset, cscript with a .js). That is why the levels run from 6 to 12 rather than all being high.
• Deployment status. All fourteen new rule ids (100446 to 100449, 100460 to 100469) are live on the lab manager and no longer listed in gated_rules.txt. Merging this post changes nothing about that; the rules are in the repo's local_rules.xml and the lab manager.

Related

The T1649 test is tracked under certificate-theft, the T1569.002 test under psexec-service-execution, and the T1685 test under bring-your-own-vulnerable-driver-byovd. The other six map to lsa-secrets-cached-credential-dumping, living-off-the-land-lotl-lolbins, web-skimmer-magecart-formjacking, password-cracking-rainbow-tables, password-spraying and credentials-from-password-stores-vaults.

Note on run ids: the first four runs were issued by the harness under ids that collided with parked prerequisite-only bundles, so they were renumbered to 013 to 016 on commit (see gated_rules.txt). The execution.command inside those four bundles still shows the original harness ids.