eCDFP study materials
eCDFP study resources

A Password Spray That the SIEM Never Saw

eCDFP · Put your knowledge to work in context.

All case studies

A Password Spray That the SIEM Never Saw

Your SIEM contains Okta, VPN, and Windows Security logs for 4,000 employees. A detection rule fires when a single user has more than 10 failed logons in 5 minutes, generating roughly 300 alerts per day, 85% from three service accounts. Last week, an attacker used 12 residential IPs to try three passwords each against 900 accounts over two hours, then logged in successfully to one account from a new ASN. The existing rule produced no alert. Okta logs include device fingerprint and geo; VPN logs include assigned IP; Windows 4625 events include sub-status codes. The SIEM retains 90 days. The SOC has one analyst per shift and a 15-minute triage target for high-severity alerts. Leadership wants fewer false positives without missing the next spray.

1. Explain why the existing rule missed the spray. What aggregate signal was present but not used?

Read the worked answer

Why the rule missed it: the logic was per-user, with a threshold of 10 failures in 5 minutes. The spray used three attempts per account, below the threshold, and spread 900 accounts across 12 source IPs over two hours. Per-user aggregation cannot see a low-and-slow, distributed pattern. The rule also drowned in 300 alerts per day, 85% from three service accounts, so analyst attention was consumed by noise. The successful login from a new ASN was never correlated with the failures.

The missed signal is the aggregate: 2,700 failures across 900 accounts from 12 IPs in 120 minutes. At any single user, that looks like three typos. At the source-IP or ASN level, it is a campaign.

Also check sub-status codes: 4625 with 0xC000006A means bad password against a valid account, while 0xC0000064 means the username does not exist. A spray producing mostly 0xC000006A across many accounts is enumerating real users and guessing passwords; a burst of 0xC0000064 is noisier but still informative.

2. Design replacement detection logic with tiers, data sources, and suppression rules. Be specific about thresholds and joins.

Read the worked answer

Proposed detection, tiered:

  • High: successful Okta or VPN authentication from a source IP or ASN that had at least 15 distinct failed accounts in the prior 30 minutes.
  • Medium: at least 25 distinct accounts failing from one IP or ASN within 10 minutes, regardless of success.
  • Medium: one account failing from at least 8 distinct IPs in 10 minutes, a distributed spray against a single user.
  • Low/informational: new ASN for a user, enriched with geo and device fingerprint.

Use identity logs (Okta, VPN) as the primary source because they see the authentication attempt even when Windows logs do not. Join on username and time window, not on host. Include the sub-status breakdown as an enrichment field.

Suppression discipline: do not blanket-allowlist the three service accounts. Allowlist only their documented source IPs; if a service account authenticates from a residential ASN, that is exactly the alert you want.

3. How would you validate and tune the new logic without simply making alerts disappear? What tradeoff matters most with one analyst per shift?

Read the worked answer

Validate before tuning down. Replay the last 90 days of logs against the new logic and measure: alerts per day, true positives (known incidents or red-team tests), and whether last week's spray would have fired. If the new rule still produces more than one analyst per shift can triage, raise the distinct-account threshold, not the per-user threshold.

Tuning tradeoffs: catching a three-attempt spray across 900 accounts requires aggregation by source, which is cheap. Raising per-user thresholds reduces noise from forgotten passwords but does nothing for sprays. The goal is fewer alerts per true positive, not fewer alerts in absolute terms.

Operational check: a 15-minute triage target means the high-severity rule must be actionable in one screen: source ASN, number of accounts, success flag, and a link to disable the session. Run a quarterly purple-team spray using a known test account and confirm the alert fires and is triaged within target.