How it works
Credential stuffing replays username-password pairs exposed elsewhere, relying on reuse. Password spraying inverts the ratio, trying a small set of likely passwords across many accounts to stay under per-account lockout thresholds. Both are authentication abuse rather than exploitation: the credentials are valid or the guesses are ordinary.
Two shapes of the same abuse
Both attacks submit ordinary login requests with plausible credentials. Neither requires a vulnerability. What separates them is which axis the attacker spreads across, and that difference determines which defences see them.
Credential stuffing takes pairs exposed in one breach and replays them elsewhere, betting on reuse. The password is often correct on the first attempt, because it is the user's actual password — just from a different service. Per-account lockout never triggers, since there is no repeated guessing.
Password spraying has no stolen pairs. It tries a handful of likely passwords — seasonal patterns, the company name with a year, defaults — against a large list of accounts, with long gaps between attempts on any single one. Lockout thresholds are designed for repeated failures against one account, so a campaign touching each account twice a day passes underneath them indefinitely.
The shared property is that per-account controls are the wrong instrument. Both attacks are only visible in aggregate.
Why per-address limits fail
The intuitive control is to rate-limit by source address, and it has been ineffective for years because attackers rent residential proxy networks. Traffic is distributed across tens of thousands of consumer addresses, each making a handful of requests.
That defeats per-address accounting completely: no address exceeds any reasonable threshold, and the addresses themselves are indistinguishable from real users because they are real consumer connections — frequently belonging to people whose devices were enrolled through a bundled application without meaningful consent.
Blocking such addresses also carries real cost. They are shared, so blocking one removes legitimate users behind the same connection, and address reputation for a residential range is a poor proxy for the intent of any individual request from it.
The signals that do work
Both attacks distort ratios that are remarkably stable in normal traffic, and this is where detection should live.
- Failure distribution across accounts. Genuine traffic concentrates failures on a few accounts — people mistyping their own password. Stuffing produces a single failure across an enormous number of distinct accounts, which is the inverse and is unmistakable in aggregate.
- Password reuse across accounts. The same password failing against many different usernames is spraying, and no legitimate process produces that pattern.
- Overall authentication success rate. A campaign drags the population-wide success rate down long before any individual account is affected.
- Client uniformity. Large-scale automation clusters tightly in TLS fingerprint, header ordering and capability support in ways a real browser population never does.
- Timing regularity. Human login is irregular; automation retains a recognisable distribution even when jitter is added.
- Endpoint choice. Attackers gravitate to whichever authentication path enforces least, so unusual volume on a legacy or non-interactive endpoint is itself a signal.
Controls that change the outcome
Phishing-resistant MFA is the highest-leverage measure, because it breaks the link between a correct password and a session. Both attacks then produce nothing of value even when the password is right. The caveat matters, though: MFA only helps on paths that enforce it, and legacy endpoints that accept a password alone are where these campaigns concentrate. Closing that gap is the first task and frequently the only one that is genuinely urgent.
Compromised-password screening addresses the root cause directly. If a password appears in a breach corpus, it will eventually be tried; rejecting it at set time and re-screening existing credentials removes the fuel rather than filtering the fire.
Rate limiting must operate on the dimension the attacker is spreading across — per account, per credential pair, and on aggregate failure rate across the population. Per-address limits remain worth having for other reasons but should not be relied on here.
And detection has to be tenant-wide. A per-user view cannot see a campaign in which no user is attacked more than twice.
After a successful login
Because the credential is valid, the authentication decision cannot distinguish the attacker from the user. What follows has to.
Score the context of a successful login as well as its correctness: a new device, a new region and a new network arriving together on an account with no history of any of them warrants a challenge regardless of which factors were satisfied.
Watch what happens next. Takeover has a characteristic post-login sequence — changing the password, adding a recovery address, enrolling a new factor, disabling notifications, then acting. Alerting on that sequence catches compromise even when the login itself looked ordinary, and it is often the only detection that fires.
Also known as
What defenders may observe
- Login failures distributed thinly across very many accounts
- One password pattern failing across a large user set
- Low attempt count per account but high aggregate volume
- Legacy or non-interactive authentication endpoints showing unusual failures
- Successful logins from unfamiliar device and network clusters
Prevention and mitigation
- Deploy phishing-resistant MFA and disable legacy authentication paths
- Screen new and existing passwords against compromised-credential corpora
- Rate-limit per account and on aggregate failure rate, not only per address
- Ban common and organisation-specific weak passwords
- Detect across the whole identity population rather than per user
- Score device, network and behavioural signals alongside the credential
Initial response priorities
- Revoke sessions and reset the affected authentication factors.
- Review identity-provider and mailbox audit logs.
- Verify sensitive requests through a separate trusted channel.
Use your approved incident-response plan and adapt decisions to your environment. This is educational guidance, not a substitute for live incident leadership.