Wazuh rule 92900 is meant to catch LSASS credential dumping. It matches on an enumerated list of GrantedAccess masks: 0x1010 and 0x40.
Run the classic living-off-the-land dump:
rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <lsass pid> <path> full
Enter fullscreen mode Exit fullscreen mode
Sysmon Event ID 10 fires with GrantedAccess 0x1fffff. That value is not on the list, so 92900 produces nothing. The dump succeeds. The rule is still present, still enabled, and still counts as covered in any report that counts rules.
That is the part worth sitting with. An enumerated-list rule does not fail loudly. It fails silent, and the silence is indistinguishable from “nothing happened.”
The discriminator, and why the obvious one is the wrong one
Widening the mask list does not fix it: the Wazuh agent itself opens LSASS, so 0x1fffff on its own is benign traffic. The thing that separates the malicious open from the benign one is CallTrace.
The obvious key is comsvcs.dll, since that is what the command loads. It is the wrong key. comsvcs’ MiniDumpW hands off to MiniDumpWriteDump, which lives in dbgcore.dll. Key on dbgcore instead and you catch the same comsvcs dump plus every dumper that reaches MiniDumpWriteDump by another path.
This is not a guess. In the public thread the reporter tested both against a live endpoint: dbgcore.dll appears in the CallTrace for the comsvcs dump, and also for ProcDump. comsvcs does not appear in ProcDump’s CallTrace at all. A comsvcs-only rule would have missed ProcDump entirely.
The cost is real and should be stated: dbgcore and dbghelp also turn up in benign crash-handling traces, so this trades a silent miss for noise you have to tune.
The general shape
Two things travel together here, and only one of them is about Wazuh.
A rule written as a list of known-bad values answers “is this value on my list?”, not “did this technique happen?”. Any value off the list is silence. The rule is intact, the report is green, and the technique lands.
So the check that matters is not “is the rule there?” but “does it fire when I run the thing?” — and then run a second tool down the same code path before calling the gap closed. Here, one tool would have produced a rule that looked fixed and still missed the more common dumper.
The full test output is in the upstream tracker, in the wazuh/wazuh issue numbered 38716. I am not linking it directly here, but the number is exact and the thread is public, so you can check every claim above against what the reporter actually ran.