Credential stuffing is an automated account takeover attack in which attackers take username and password pairs leaked from one service and replay them at scale against the login endpoints of other services. It succeeds because many people reuse the same password across sites, so a single breach unlocks accounts elsewhere.
Among malware & attacks, credential stuffing stands out because it requires no vulnerability in the targeted application: every login request is technically valid. The attack is driven by large combination lists, botnets and residential proxy networks, and it is a leading cause of compromised consumer accounts in retail, streaming, gaming, banking and software-as-a-service platforms.
How a credential stuffing attack works
The attack follows a repeatable pipeline. Attackers obtain combo lists of email and password pairs from data breaches, infostealer logs and underground markets, then configure an automation tool with the target’s login flow, success markers and proxy settings. The tool submits credentials in parallel, records the valid ones, and sells or exploits the verified accounts.
Because one combination is usually tried only once per account, the traffic looks very different from guessing attacks. Success rates are low, often estimated at a fraction of a percent to a few percent depending on list freshness, but lists with millions of entries still yield thousands of working accounts.
The stages of a typical campaign are summarized below.
| Stage | Attacker activity | Defender opportunity |
|---|---|---|
| Acquisition | Collect combo lists from breaches and stealers | Monitor for exposed employee and customer credentials |
| Configuration | Script the login flow and success checks | Change login flow details, add integrity tokens |
| Distribution | Spread requests over proxies and botnets | Detect automation, not just per-IP volume |
| Validation | Record successful logins | Flag unusual success-to-failure patterns |
| Monetization | Drain balances, resell accounts, commit fraud | Step-up checks for sensitive actions |
Credential stuffing compared with related attacks
Credential stuffing is often confused with brute-force attacks, but the decisive difference is that the attacker already knows a real password of the victim, just from another service. That difference changes which defenses work.
| Attack | Input used | Attempts per account | Effective defenses |
|---|---|---|---|
| Credential stuffing | Leaked real credential pairs | Usually one | MFA, breached-password checks, bot detection |
| Brute-force attack | Systematic password guesses | Many | Account lockout, rate limiting |
| Password spraying | A few common passwords across many users | One to a few | Banned password lists, MFA |
| Phishing | Credentials tricked from the user | One | Phishing-resistant MFA, training |
| Infostealer-based takeover | Stolen session cookies and saved passwords | One or none | Session binding, token revocation |
Because each account sees only one attempt, per-account lockout does not stop credential stuffing, and per-IP rate limits are weakened by residential proxy pools that rotate through hundreds of thousands of addresses.
Detection signals
Detection focuses on aggregate behavior across the login endpoint rather than on individual accounts. A sudden rise in login volume with an unusually high failure rate, many distinct usernames per client fingerprint, or logins from addresses never seen for the affected users are typical indicators.
| Signal | What it suggests | Caveat |
|---|---|---|
| Failure ratio spike | Large list being tested | Outages and password resets also raise failures |
| Unknown-user errors | List contains accounts that never existed here | Requires careful logging without enumeration |
| Identical client fingerprints | One tool behind many IPs | Sophisticated tools randomize fingerprints |
| Headless browser traits | Automation framework in use | Arms race with stealth plugins |
| Success from new devices | Valid credentials used by a third party | Travel and new phones cause false positives |
Detection works best when login telemetry from all channels is correlated, including web, mobile apps and partner APIs. Attackers deliberately shift to the least protected endpoint, so a sudden quiet period on the web login while mobile traffic rises is itself a signal worth investigating. Successful logins should be reviewed with the same care as failures, because they reveal which accounts are actually compromised.
Defending against credential stuffing
Effective defense is layered: it reduces the value of leaked passwords, raises the cost of automation, and limits damage after a takeover. Multi-factor authentication is the single most effective control, and passkeys based on FIDO2 remove reusable passwords entirely.
| Control | Effect on the attack | Trade-off |
|---|---|---|
| MFA or passkeys | Valid password alone is no longer enough | Enrollment effort, recovery processes |
| Breached-password screening | Blocks known leaked passwords at signup and login | Needs a privacy-preserving lookup |
| Bot management | Raises cost of automated requests | False positives, ongoing tuning |
| Risk-based authentication | Challenges unusual logins only | Requires good behavioral baselines |
| Uniform error messages | Hides whether a username exists | Slightly less helpful for real users |
| Step-up for sensitive actions | Limits fraud after takeover | Extra friction for payouts and changes |
Guidance such as NIST SP 800-63B recommends checking new passwords against lists of compromised values and avoiding arbitrary composition rules. CAPTCHAs alone are a weak control, because solving services and machine learning defeat many of them at low cost.
Business impact and common mistakes
The damage includes fraudulent purchases, stolen loyalty points, resold subscriptions, exposed personal data and support costs, along with regulatory scrutiny when personal data is accessed. Organizations sometimes treat these incidents as user negligence, but regulators increasingly expect reasonable anti-automation and MFA measures.
- Relying on IP blocklists misses attacks routed through residential proxies.
- Protecting only the web login leaves mobile APIs and legacy endpoints open.
- Logging only failures hides the successful takeovers that matter most.
- Forcing resets without notification leaves users unaware that their password is reused elsewhere.
A plain-language summary
Many people use the same password on many websites. When one website is hacked, criminals get a list of email addresses and passwords.
They then let computers try every pair on other popular sites, such as shops or streaming services. Whenever someone reused a password, the criminals get in. It is like finding one house key and trying it on every door the owner might have. A second login step, such as a code or a passkey, stops most of these attempts.
An example from practice
An online grocery chain notices that login traffic on its mobile API has tripled overnight while the failure rate jumped from 5% to 92%. The requests come from more than 40,000 residential IP addresses, each sending only a few attempts, so per-IP limits never trigger.
The security team enables bot detection on the API, forces a password reset for about 1,800 accounts that logged in successfully from new devices, and requires a one-time code before redeeming loyalty points. Within a week the attack traffic fades, and the company rolls out passkeys as a sign-in option to reduce future exposure.