I set out to catch a credential-dumping attack in my homelab SIEM. What I actually caught was my SIEM missing it — and fixing that blind spot turned out to be the real work.

This is a detection-engineering write-up: one attack, an endpoint block, a visibility gap that hid the block from my SIEM, and the config change that closed it, with a verified before/after. It’s less “watch the alert fire” and more “the alert didn’t fire, and here’s how I found out why.”

The setup

I run a Wazuh SIEM on a headless box in my homelab, with agents on a few endpoints including a Windows 11 machine (win11-target). The plan was simple: run a real credential-access technique on the Windows host, then confirm Wazuh caught it and see exactly how it presented — the loop a SOC analyst runs every day.

The technique: OS Credential Dumping — LSASS Memory (T1003.001). When a process reads the memory of lsass.exe, it can lift credentials straight out of it. It’s one of the most common post-compromise moves there is, and detecting it is bread-and-butter for an MDR analyst.

I used ProcDump — a legitimate Sysinternals tool routinely abused for exactly this — to try to dump LSASS:

procdump.exe -accepteula -ma lsass.exe out.dmp

What actually happened: the attack didn’t complete

Windows Defender didn’t let it run. It recognised ProcDump against LSASS as a known technique and killed it on the spot, flagging it as HackTool:Win32/DumpLsass.E:

Two things worth noticing. First: endpoint defence worked — the dump never happened. I went looking for out.dmp afterwards and there was no such file, because ProcDump was terminated before it could write a single byte. The absence of the output file is the proof the block landed.

Second, the honest part: I’d originally set out to capture a specific behavioural signature — the Sysmon Event ID 10 GrantedAccess mask that fires when a process opens a handle to LSASS memory. I never got it. Defender blocked ProcDump before it opened that handle, so the behavioural telemetry I predicted never generated. That’s not a failed experiment — it’s a genuine finding about order of operations: a tool-signature block pre-empts the behavioural signal. To capture that EID 10 event I’d have to let the dump proceed via a Defender exclusion — a different experiment for another day.

The real problem: the block was invisible to my SIEM

Here’s where it got interesting. Defender blocked the attack on the host — but when I went to Wazuh to find the corresponding alert, there was nothing there. The most important security event on that machine that day — a blocked credential-dumping attempt — was completely invisible to my SIEM.

That’s the gap that actually matters. An endpoint control firing silently, with no signal reaching the place your analysts actually look, is arguably worse than no control at all: you’d never know it happened, and you’d never know if it stopped happening.

Diagnosing it

The cause was log collection. A Wazuh agent only forwards the Windows event channels it’s explicitly told to collect. Mine was pulling Security, System, Sysmon/Operational, and a couple of others — but not the Defender operational channel, which is where Defender writes its detection events. Defender was doing its job and logging locally; my agent just wasn’t listening on that channel.

The fix

One <localfile> block added to the agent’s ossec.conf, pointing at the Defender operational channel:

<localfile>
  <location>Microsoft-Windows-Windows Defender/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Save, restart the agent (Restart-Service WazuhSvc from an elevated prompt), confirm it reconnects.

Verifying the fix — the before/after

Then I re-ran the exact same attack. Defender blocked it again on the host, same as before — but this time the detection flowed into Wazuh, landing as rule 62123, level 12, on win11-target:

And here’s the discipline that mattered: I didn’t just trust the severity number. Earlier in the same session I’d been burned by a scary-looking level-12 alert that turned out to be a false positive (below), so I opened this one and read the eventdata to confirm it was genuinely my attack — not another coincidental fire:

• Channel: Microsoft-Windows-Windows Defender/Operational — confirming it came through the channel I’d just added. That single field is the before/after: invisible last run, ingested now.
• Event ID 1116 — the Defender detection event.
• Threat: HackTool:Win32/DumpLsass.E, with the ProcDump command line in the record — unambiguously my attack.

So there’s the whole chain working properly: Defender blocked it, Wazuh actually picked it up this time, and there was an alert sitting there for an analyst to triage. It even came with compliance mappings attached — PCI DSS, NIST 800-53, HIPAA — so it wasn’t just a detection, it was something a SOC could point to in a report.

The false positive I nearly believed

Worth including, because it’s half the job. Separately during this work, Wazuh threw a level-12 alert tagged with MITRE Application Shimming (T1546.011) — a persistence and privilege-escalation technique. Alarming at face value.

But reading it rather than reacting to it: the rule was matching on sdbinst.exe, a legitimate Windows tool, and the surrounding context was benign system activity, not an attack. A high severity and a frightening MITRE tag don’t equal a real incident. The rule fired correctly; the situation was benign. Triaging that difference — reading the parent process and surrounding events instead of trusting the label — is exactly the muscle the whole exercise was meant to build.

What this actually proved

Not “I can run an attack and watch an alert appear.” The findings were:

• A visibility gap, found and closed — an entire class of endpoint-defence events was invisible to my SIEM until I added the channel, verified with a clean before/after.
• A false positive, correctly triaged — a scary level-12 tag ruled out by reading context, not severity.
• The distinction between an attack being blocked and being seen — Defender stopped the dump; necessary, but not sufficient. If the block doesn’t reach your SIEM, your detection coverage has a hole exactly where you’d assume you were covered.

The attack failing was never the point. The SIEM going quiet when it shouldn’t have — that was the finding worth writing down.

---

References

• MITRE ATT&CK T1003.001 — OS Credential Dumping: LSASS Memory
• MITRE ATT&CK T1546.011 — Application Shimming (the false positive)
• Compliance mappings on the alert: PCI DSS 5.1/5.2, NIST 800-53 SI-3/SI-4, HIPAA

---