Password Spraying in a Noisy SIEM
Your SIEM ingests 8,000 EPS from 500 Windows endpoints, 12 servers, VPN, and Entra ID. Two analysts triage roughly 450 alerts per day. Three noisy rules dominate: more than five 4625 failures in five minutes per user (400 alerts/day), the string mimikatz in command lines (50/day, mostly from an AV scanner), and new service installation (30/day). On Monday, a low-priority rule fires: 60 distinct users had 4625 failures from 198.51.100.0/24 between 02:00 and 02:20. Three accounts succeeded: svc_helpdesk, finance, and jdoe. The successes show 4768 with AES, followed by 4624 type 3 for one account and 4648 for another. No 4624 type 10 appears. VPN logs show one session from the same /24 with a 14-minute duration.
1. Distinguish password spraying from brute force using the evidence. What would change your conclusion?
Read the worked answer
Password spraying: one source, many distinct users, low attempts per user (60 users in 20 minutes is roughly one attempt each), and three successes. Brute force would show many attempts against one or a few accounts, often with 4625 spikes per account and lockouts. The VPN session from the same /24 supports a single actor.
What would change the conclusion: if the failures were concentrated on one account with hundreds of attempts, or if the source were an internal NAT gateway or vulnerability scanner, spraying would be less likely. Check 4625 failure reason: bad password versus disabled/expired account; spraying often produces 0xC000006A for valid usernames and 0xC0000064 for invalid ones, which also enables username enumeration. Check the user-agent and VPN client strings, geo-IP, and whether the three successes came from the same session or different sessions. Also verify whether svc_helpdesk is a service account that should never log on via VPN; that success is the strongest signal. If the source IP is a known corporate egress or a penetration test, reclassify. The 14-minute VPN session suggests interactive use, not an automated spray only.
2. Write a tuned detection rule for this behavior. Include aggregation, threshold, time window, and exclusions, and explain why each choice reduces false positives without hiding the attack.
Read the worked answer
Rule: aggregate 4625 by source IP over a 10-minute window; alert when distinct target users >= 20 and failures per user <= 5, excluding internal scanner and NAT ranges, and excluding accounts that are disabled or expired. Why: spraying is wide and shallow; counting distinct users catches it, while per-user thresholds avoid missing it and reduce noise from one user mistyping a password. Add a second condition for successes: 4624 type 3 or 10, or 4768, from the same IP within 30 minutes of the spray, especially for service accounts.
Exclusions: known vulnerability scanners, VPN concentrators, and NAT egress IPs, but log them; do not exclude whole /24s without an owner. Enrich with geo-IP and ASN, and alert on impossible travel. Keep the old five-failures rule but raise it to 20 per user in 10 minutes and make it low severity. Why not just raise the threshold: a single-user brute force can still succeed below 20; pair the two rules. Test against 30 days of historical data, require analyst feedback, and review weekly.
3. Prioritize the three successful accounts for investigation. What evidence would you pull for each, and which is most urgent?
Read the worked answer
Most urgent: svc_helpdesk, because a service account authenticating from a VPN IP is a high-privilege anomaly and may indicate credential theft with broad access; pull 4624 logon type, 4672 special privileges, 4768/4769, VPN session details, and all actions in the session. Next: jdoe or finance, whichever has 4624 type 3; check the source workstation, accessed shares, 5140/5145, and mailbox or SharePoint access. For the account with 4648 (explicit credential use), pull 4648 and 4624 for the target account and host, and check for lateral movement.
For each: reset the password, revoke sessions, require MFA re-registration if suspicious, and review mailbox rules and OAuth grants. Check whether the three accounts share a password or were in a prior breach. Also check 4625 for the remaining 57 users to see whether any later succeeded. The 4648 event is urgent because it indicates a process using alternate credentials, often a precursor to lateral movement; if it targets a privileged account, escalate above svc_helpdesk.