Detect credential stuffing by examining how login attempts spread across accounts and what happens after authentication. A rise in failures is a starting point. It is not enough to establish that stolen credentials are being tested.
What credential stuffing is
Credential stuffing is automated login testing with username-and-password pairs stolen from another site. OWASP catalogs it as OAT-008 Credential Stuffing: "mass log in attempts used to verify the validity of stolen username/password pairs." It works because people reuse passwords, so a pair leaked by one service can open an account on another.
It is often confused with two other login attacks. OWASP's credential-stuffing cheat sheet separates them by what the attacker tests. The last column is our reading of what each one tends to look like in login records:
| Attack | What is tested | Shape to expect in login records |
|---|---|---|
| Credential stuffing | Pairs from a breach of another site | Many accounts, few attempts on each |
| Brute force | Many passwords against one account | One account, many attempts |
| Password spraying | One weak password against many accounts | Many accounts, few attempts on each |
Brute force and spraying guess. OWASP files both under OAT-007 Credential Cracking, while stuffing "does not involve any brute-forcing or guessing of values." Stuffing and spraying can look alike from the account side, because neither needs many attempts per account.
That matters for detection. NIST SP 800-63B requires a verifier to cap consecutive failed attempts on one account at no more than 100. A per-account cap like that does little against an attack that tries each account once or twice, so the source and outcome views below matter more. Your logs may support “suspected automated credential attack” before they support a more precise label.
Start with outcomes, not a list of bad IPs
Choose a bounded time window and a known login route. Include password login on the web, equivalent mobile endpoints, and older API routes still in use. Keep federated login failures separate if a different identity provider owns their meaning.
Collect timestamps, pseudonymous account references, the trusted network observation, outcome categories, challenge decisions, and a request correlation ID. Do not record passwords, reset tokens, or session cookies. You do not need the attempted password to begin an account-spread investigation.
Separate invalid credentials from account locks, missing second factors, dependency failures, and application errors. Combining those outcomes into “failed login” can turn an identity-provider outage into an apparent attack.
Compare the account and source views
An account view asks whether one account is receiving attempts from many sources. A source view asks whether one client or source is touching many accounts. Neither should disappear inside a combined account-and-IP counter.
OWASP's bot-management guidance describes independent account and source budgets. That distinction also helps investigation: one source can spread attempts across accounts, while a distributed attack can concentrate on one account.
| Observation | Investigate | Alternative explanation |
|---|---|---|
| Many accounts, similar failed outcomes | Automated credential attempts | A broken enterprise integration |
| One account, many sources | Targeted distributed attempts | Shared account or unusual client behavior |
| Failures followed by a new successful session | Whether the session is legitimate | User corrected a saved password |
| More second-factor failures | Authentication-stage abuse | Delivery or authenticator problem |
| Failures after a deployment | Changed request handling | Client or identity-service regression |
Treat the alternatives seriously. They determine whether the response should target an attacker, an integration, or your own release.
Inspect the successful sessions
A detection process that reviews only failures misses the event that matters most: a suspicious attempt that obtains usable access. Follow the successful authentication into the resulting session where your retention policy and investigation authority permit.
Check whether the session performs sensitive actions such as changing recovery details or requesting unusual bulk data. Those actions warrant review; they do not independently prove compromise.
Keep the classification and the evidence together. “Known stolen credentials” requires evidence of that fact. “Automated attempts followed by a disputed session” may be the more accurate incident description.
Contain narrowly and preserve recovery
Start with the affected authentication path and the available account/source controls. Consider stronger authentication for risky transitions, and coordinate session handling with the identity team when compromise is suspected. OWASP calls multi-factor authentication "by far the best defense" against credential stuffing and password spraying, and NIST SP 800-63B requires checking new passwords against a blocklist that includes passwords from previous breaches.
Do not turn attacker-generated failures into permanent account lockouts without a recovery design. A response that makes real users unable to sign in may accomplish the attacker's disruption goal.
Track ordinary login completion alongside rejected attempts. Check password managers, mobile clients, a user correcting a typo, and a shared-network population. A falling failure count can also mean the route is broken for everybody.
The account takeover use case frames the automation-control discussion. For the broader account lifecycle, use account-takeover prevention; this investigation should feed that plan rather than replace it.