Counting Distinct Compromised Accounts in Authentication Logs
The challenge
Overnight, one external address ran a credential-stuffing run against the login endpoint, and unlike the noisy scanner earlier that night, this one got in. Your incident report does not need the attacker's address, it needs the blast radius. Work out which external address actually succeeded, then count how many DISTINCT accounts it logged into successfully. Read carefully: one account was signed into twice from that address, so the number of successful login events is not the number of accounts, and one more account stopped at a second-factor prompt and was never signed in at all. Submit the number of distinct accounts.
What you'll learn
- Separate a failed spray from a successful credential-stuffing run
- Filter a SIEM table by combining field:value terms
- Count distinct entities rather than raw event rows
- Recognise that an MFA-blocked login is not a compromise
- Report blast radius as the number that drives incident response
Skills tested
Prerequisites
- Reading structured log rows
- Understanding of MFA and credential stuffing
How it works
Finding the attacker is the easy half of an intrusion. The half that drives the response is scope: how many accounts actually fell. Every downstream decision, from forced password resets to breach notification, is sized by that number, and it is a count of accounts, not a count of events.
Two external addresses appear overnight. 203.0.113.91 sprays generic usernames such as admin, root and jenkins, and fails on every one. It is loud and harmless. 198.51.100.24 works through real employee names, failing nineteen times and succeeding five, with the hits mixed in among the misses. Loud is not the same as dangerous, and the noisier address is the one that achieved nothing.
Filtering to src_ip:198.51.100.24 action:login result:success gives five rows, but only four distinct names, because j.arnold was signed into twice. A separate account, p.novak, appears twice with result:mfa_required: the password was correct, so it was in the same breach list, but the second factor stopped the sign-in. That account was attacked, not compromised. The correct blast radius is four, and the export events that follow corroborate it, since they only come from accounts that genuinely logged in.
Common mistakes
- Answering 5. That is the number of successful login events.
j.arnoldappears twice, so the distinct account count is one lower. - Answering 6. That counts
p.novak, whose result ismfa_required. The second factor blocked the login, so the account was never accessed. - Investigating 203.0.113.91. It generates the most events but never succeeds once. Volume is not impact.
- Counting internal successes. The
10.12.4.xrows are normal staff logins over the office VPN, before and after the incident window. - Filtering on result:success alone. That mixes legitimate office logins with the attacker's; the source address has to be part of the filter.
How to defend against it
Credential stuffing succeeds on reused passwords, so the controls that matter are the ones that make a correct password insufficient.
- Require a second factor for every account, and prefer phishing-resistant factors. In this incident MFA is the only reason the count is four rather than five.
- Screen new and existing passwords against known breach corpora, and force a reset on any match.
- Rate-limit and progressively delay authentication per source address and per account, so nineteen failures from one address never reach a twentieth attempt.
- Alert on the shape of the attack: many distinct usernames from one address in a short window, especially outside business hours.
- Instrument what happens after a login, since the export of
payroll_q3.xlsxminutes after a 02:31 sign-in is a stronger signal than the login itself. - Build scoping queries in advance that count distinct principals, so responders are not deriving blast radius by hand under pressure.