One Attempt Per Account, 380 Accounts
A SIEM rule alerts on "5 or more failed logons for a single account within 5 minutes." Overnight, a single internal IP (10.20.44.9, the second-floor print server) made 1,140 failed authentications against a domain controller, spread across 380 distinct accounts at roughly one attempt each. The rule never fired. Two minutes after the last failure, the print server's service account authenticated successfully from the same IP; that account is a member of Domain Admins. No other host shows unusual traffic. The SOC lead wants to close the ticket as a vulnerability-scanner false positive.
1. Explain why the rule stayed silent and describe the analytic that would have caught this.
Read the worked answer
The rule aggregates per account. A password spray is deliberately designed to stay under per-account thresholds: 1,140 attempts over 380 accounts is about three attempts per account, so no single account ever approaches five failures in five minutes. The signal exists only in the aggregate view of the source.
An effective analytic pivots to the source: count distinct target accounts per source IP in a window (for example 20 or more distinct accounts failing within 10 minutes), and pair it with the failure-to-success ratio. The highest-value rule is a correlation: a successful authentication from the same source within a short window after a spray burst - that converts a noisy authentication event into a probable-compromise alert. Baselining also matters: a print server authenticating to a domain controller at all, let alone across 380 accounts, is off-baseline.
2. Is the "scanner false positive" explanation credible? Give the evidence for and against, and state the single most decisive indicator.
Read the worked answer
For a benign explanation: one internal host, no external infrastructure, and vulnerability scanners do perform authenticated and unauthenticated credential checks against directory services.
Against: a scanner enumerates services and ports, not 380 user accounts at one attempt each; a spray's shape (many accounts, few attempts, uniform timing) is the opposite of a scanner's (few accounts, many protocols). A print server has no legitimate reason to speak authentication protocols to a DC across the whole user population. Roughly three attempts per account also suggests multiple passwords per account or repeated passes rather than a single check.
The decisive indicator is the successful authentication by a Domain Admins service account from the same IP two minutes after the burst. A scanner does not hold working Domain Admin credentials, and a print server should never hold Domain Admin rights at all. This is not a scan; it is either credential harvesting succeeded or a grossly over-privileged service account being used. Treat as probable compromise with successful privilege use.
3. Recommend the immediate containment actions and flag the main risk of acting too fast.
Read the worked answer
- Isolate 10.20.44.9 at the switch port and via EDR, not just with a firewall block, so the host cannot reach the DC or the internet. Printing breaks; accept that.
- Preserve volatile state first - memory image, running processes, network connections - because the print server is the best evidence of how credentials were obtained (memory scraping, cached admin creds, an injected service).
- Contain the Domain Admin credential. Reset it (twice) and audit every use of that account in the DC logs: logon type, source host, ticket requests, new service creation. If there is any sign of ticket forging, plan a krbtgt reset.
- Scope laterally: check whether the other 379 accounts had any success, and hunt for the same source pattern elsewhere.
Main risk of moving fast: a mass password reset or visible account disablement before the host is isolated tells the adversary they are burned and they accelerate or wipe. Coordinate with the incident commander so isolation, credential rotation and forensic capture happen in a deliberate sequence rather than as three simultaneous reactions.