Windows Authentication Detection & Triage Lab
“What does a failed logon look like to the analyst, and how do they decide what it means?”
- Two cases: local triage, then a real remote attack
- Correlated 9 failures to a success from one source
- Caught Wazuh mislabelling a brute force as pass-the-hash
Case summary
A Wazuh lab that follows Windows authentication events from collection to an analyst disposition: a local failed-logon triage, then a real remote brute-force attack from Kali investigated end to end.
Overview
The sections below are a concise case-file overview. The detailed assessment report is kept separate so the case page remains readable while the complete evidence and findings remain available to readers who want them.
Full write-up: Following a failed logon through a SIEM →
Context
Most of my practice has been offensive. I know how a password attack looks from the attacker’s side, and I wanted to see the same activity from the analyst’s chair. Instead of clicking through SIEM dashboards, I follow one kind of event, Windows authentication, from the moment it is recorded to the decision an analyst makes about it.
Objective
Practice the full defensive path (collect, detect, triage, investigate, document a disposition) and verify each step instead of assuming it works.
Lab
Two VMs on an isolated VirtualBox host-only network (192.168.56.0/24): a Windows 10 endpoint with a Wazuh agent, and a Wazuh 4.14.8 server (manager, indexer, dashboard) sized to 2 vCPU and 4 GB to fit a 15 GB laptop. Kali is the attack host.
Approach
- Verify the pipeline first. Confirmed the agent was enrolled, connected and reporting before trusting any detection.
- Follow the event. Windows Security log, agent, manager (decode, then rules), indexer, dashboard.
- Read Event 4625 properly. Logon type, status and sub-status, and source address separate a typo from a guessed username from a remote attack.
- AUTH-001: triage failed logons generated on the endpoint itself.
- AUTH-002: run a real attack from Kali with NetExec over SMB (RDP was firewalled), using a 10-password list where I deliberately did not track which one was correct, then investigate without knowing the answer.
Results
- AUTH-001: 14 failed-logon alerts triaged. Interactive logon type with a loopback source showed the activity came from the endpoint itself, so the disposition was benign, with an escalation note and the indicators that would change that call.
- AUTH-002: 9 failed network logons (4625, logon type 3) from
192.168.56.1, then a successful one (4624) 47 ms after the last failure. Same sub-status as AUTH-001, but the logon type and external source changed the whole read. Disposition: escalate, confirmed account compromise through credential guessing (lab-controlled). - Timing evidence: the last seven failures and the success landed within about 150 ms of each other, which reads as tool behaviour rather than a person typing.
- A wrong label: Wazuh rule 92652 called the success “possible pass-the-hash” (T1550.002). The evidence showed plaintext guessing, so I recorded it as brute force (T1110) leading to valid accounts (T1078), a correction to the SIEM rather than agreement with it.
Limits
One endpoint, a lab attack I ran myself, and a custom rule (100101) that mostly relabels a detection Wazuh already had. Not yet demonstrated: frequency-based detection, automated failed-then-success correlation, Sysmon or PowerShell detection, privilege-related detection, or a full incident-response lifecycle.
Next
A rule that counts repeated failures from one source in a time window and flags a success that follows, compared against Wazuh’s existing rules. Then ATT&CK mapping based on what Wazuh actually tags, then Sysmon and PowerShell telemetry.
A short project-level account is shown above. Full reports are opened separately and are not duplicated into the case summary.