Credential stuffing is the automated testing of stolen username and password pairs against a login endpoint, at scale, until a valid match turns up. For defenders, it is less a single attack to block. It is an ongoing traffic problem: telling real users apart from scripted logins that already hold correct passwords.
The anatomy of the attack from a defender’s view
A credential stuffing run usually has three moving parts, and each one leaves a different kind of trace in your logs.
- The credential list. Combolists compiled from old breaches and infostealer logs, often millions of lines of email:password pairs, sometimes narrowed to a specific domain if the attacker suspects reuse there.
- The automation layer. Off-the-shelf stuffing tools accept a target’s login form as a “config” and fire requests through it in bulk. The rate is usually tuned to sit just under naive rate limits.
- The proxy layer. Requests get routed through residential or mobile proxy pools so each attempt carries a different, plausible-looking IP address rather than one obvious source.
None of this needs a software vulnerability. The login form works exactly as designed, the attacker is just supplying credentials that happen to be real.
Signals that separate credential stuffing from normal traffic
Volume alone is a poor signal, since legitimate traffic spikes too. What holds up better is shape.
- Request fingerprints. TLS and HTTP/2 fingerprinting (JA3, JA4, and similar) can flag clients whose handshake does not match the browser their user-agent string claims.
- Behavioural timing. Real users pause, mistype, and vary their pace. Scripted attempts often show near-identical timing between requests, even when proxies rotate the source IP.
- Success ratio anomalies. A normal login funnel has a fairly stable success rate. Watch for a sudden run of low-probability successes spread across many accounts, rather than repeated failures on one. That pattern is a strong stuffing indicator.
- Header and JavaScript execution gaps. Bots that skip full browser rendering often miss cookies, headers, or JavaScript-set values a genuine session would carry.
Verizon’s 2025 Data Breach Investigations Report backs up why this matters. Across the SSO provider logs it analysed, credential stuffing made up a median of 19% of all daily authentication attempts. That figure climbed to 25% at larger enterprises and spiked to 44% on the worst day recorded. It is not background noise. It is a substantial share of login traffic that needs its own detection logic, not just a blanket rate limit.
Why password reuse keeps the attack profitable
Stolen credentials were the initial access vector in 22% of confirmed breaches in Verizon’s 2025 dataset, the single largest category. The supply behind that number keeps expanding. Infostealer malware, spread through phishing and pirated software, harvests saved browser passwords wholesale. Researchers at DeepStrike tracked roughly 2 billion unique leaked credential pairs compiled from dark web combolists in 2025 alone. Each new leak re-tests every account that reused a password anywhere it appears.
A real-world source of raw material: the 24 billion record leak
In June 2026, researchers at Cybernews found an unsecured Elasticsearch cluster exposed online. It held 24 billion credential records, over 8.3 terabytes pulled from 36 separate sources. Most of it was infostealer logs: usernames, email addresses, plaintext passwords, and the login URL each pair belonged to. Roughly 1.7 billion records had previously circulated on hacking-focused Telegram channels before landing in this one compiled dump.
The cluster carried no password and no authentication layer, so anyone who found it could read or copy the entire set. It went offline within days, but from a detection standpoint the exposure already happened. Datasets like this feed the combolists that show up as credential stuffing traffic weeks or months later, often against services with no relationship to whichever site the credentials first leaked from.
For a defender, the practical takeaway is timing. A leak like this does not translate into an attack instantly, it gets processed, filtered, and packaged first. Elevated monitoring in the weeks following a major disclosure like this one is not paranoia, it tracks how these lists actually get used.
Building a layered defence
OWASP’s Credential Stuffing Prevention Cheat Sheet frames multi-factor authentication as the strongest single control, since it stops an attacker even when the password itself checks out. Around that core, a working defence usually layers several of these:
- Risk-based MFA. Require a second factor only when a login looks anomalous (new device, new location, known-bad IP range) rather than forcing friction on every session.
- Breached password screening at signup and reset. NIST SP 800-63B now requires verifiers to check new passwords against a blocklist of values from prior breach corpuses. Any match gets rejected outright.
- Device and connection fingerprinting. Track attributes a genuine browser would produce and challenge anything that does not fit, rather than relying on IP address alone.
- Multi-step login flows. Splitting username and password into separate steps, with CSRF tokens between them, raises the request count and complexity an automated tool needs to succeed.
- Graduated IP and network response. Slow or challenge traffic from proxy and hosting ranges instead of an outright block, since attackers adapt fast to hard cutoffs.
Treat these as a stack, not a checklist. A determined operator will get through any single control eventually, but each additional layer raises the cost of the attack and cuts the success rate.
What good looks like operationally
Teams that handle this well instrument the login endpoint the same way they would any other high-value API. That means structured logging of fingerprint and timing data, alerting on success-rate deviation rather than raw volume, and a feedback loop where confirmed stuffing traffic retrains the detection rules. Waiting for a spike in support tickets about “someone logged into my account” means the detection already failed.
It also helps to separate the login endpoint from password reset and account recovery flows in your monitoring. Attackers who fail at the login form sometimes pivot straight to password reset. Those flows are occasionally less protected, and they can leak whether an email address has an account at all. Treat both surfaces as part of the same threat model, not two unrelated features.
Frequently asked questions
Can WAF rate limiting alone stop credential stuffing?
Rarely on its own. Distributed proxy pools mean attackers stay under most per-IP thresholds, so rate limiting needs to pair with fingerprinting or behavioural analysis to catch the pattern.
Do CAPTCHAs actually work against this?
They add friction and stop unsophisticated tools, but well-resourced attackers use CAPTCHA-solving services. Best used selectively on risky logins, not as the sole defence.
Is credential stuffing illegal?
Yes, it constitutes unauthorised computer access under laws like the US Computer Fraud and Abuse Act and the UK Computer Misuse Act, even though it uses correct passwords.
How is this different from an API scraping bot?
Both are automated, but a scraping bot reads public data. Credential stuffing specifically targets authentication endpoints to gain account access.
Should we notify users after blocking a stuffing attempt?
Yes, where the attempt reached the password stage. It flags that the user’s password is circulating in a breach list, even if this particular login failed.
