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.
Credential stuffing reuses username-and-password pairs obtained elsewhere. Password spraying tests a small set of passwords across many accounts, while brute force concentrates guesses differently. OWASP distinguishes these patterns. 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.
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.