How the attack works

An attacker obtains large lists of real credentials from a data breach at another service, from phishing, or from password-dump sites. Using automated tools (e.g. Sentry MBA), these pairs are sent en masse against the login API of many websites.

Because these are real, actually valid passwords used elsewhere, the hit rate is significantly higher than with blind guessing. Successful logins show the attacker a valid, reused account pair - the taken-over account is then drained, spied on, abused for spam/phishing, or resold.

Distinction (according to OWASP):

  • Brute force: tries many passwords from a dictionary against ONE account (guessing).
  • Password spraying: tries ONE weak password against very many accounts.
  • Credential stuffing: by contrast, uses known, already-leaked username/password PAIRS against other services - nothing is guessed, password reuse is exploited.

OWASP classifies credential stuffing as a subtype of the brute-force category; the decisive difference is the use of known pairs.

Typical weaknesses that make the attack worthwhile in the first place:

  • No rate limits, or ones that are too simple (a fixed, predictable volume limit per IP, which is bypassed with proxy networks).
  • No multi-factor authentication.
  • No bot/headless-browser defenses.
  • No checking against known leaked passwords.

Since the tools usually only send direct POST requests and don't execute JavaScript, detecting headless browsers also helps.

1. Starting pointLists of leaked credentials
→
2. AttackTry them automatically against the login API
→
3. ResultTaken-over accounts (account takeover)

Reused passwords plus missing limits lead to account takeover.

Example

Anatomy of an attack (following the OWASP Credential stuffing article), using the example of a leaked pair spongebob@example.com / Sommer2023:

  1. The database of acme.com is compromised; the list includes, among others, spongebob@example.com with the password Sommer2023.
  2. The attacker feeds an automated tool with the leaked list and points it at the login API of other services (social media, marketplaces, B2B portals).
  3. The tool sends one login request per pair, schematically: POST /api/login HTTP/1.1 Host: portal.example-b2b.de Content-Type: application/json {"username":"spongebob@example.com","password":"Sommer2023"}
  4. Response for a reused password: HTTP/1.1 200 OK with a valid session/auth token - the hit. For a password that wasn't reused: HTTP/1.1 401 Unauthorized.
  5. The attacker now knows the account is valid (account takeover). Follow-up steps according to OWASP: drain stored balances or make purchases, harvest sensitive data, abuse the account for phishing/spam, or resell the confirmed credentials.

(The email, password, host, and the specific 200/401 HTTP scheme are chosen for illustration; the substantive flow - obtaining the pairs, automated testing against many services, exploitation of successful hits - follows the OWASP article.)

Impact

Successful credential stuffing leads to account takeover: unauthorized access to other people's accounts and their data. According to OWASP, it is one of the most common account takeover techniques and is dangerous for both consumers and businesses, since a single data breach triggers follow-on attacks (a ripple effect) against many other services.

Concrete consequences from the OWASP article:

  • Draining stored balances or fraudulent purchases.
  • Access to sensitive information (credit card numbers, private messages, images, documents).
  • Abuse of the account to send phishing/spam.
  • Reselling the verified credentials.

OWASP cites real-world examples such as Sony 2011, Yahoo 2012, and Dropbox 2012, in which reused passwords enabled the attack chain.

Note: the original text's additional claim about using phone numbers/security questions/recovery emails from the breach for password resets is not supported by the three sources and has been removed.

How to protect against it

  • Use multi-factor authentication (MFA) - according to OWASP, by far the most effective measure; a Microsoft analysis suggests MFA would have prevented 99.9% of account takeovers. Where it can't be enforced for all users, apply it at least for administrators and as 'step-up' authentication for high-risk actions or suspicious logins (denylisted/anonymizing IPs such as proxy/VPN).
  • Check entered/new passwords against known leaked datasets (OWASP ASVS v4.0, Provision 2.1.7), e.g. via the free Pwned Passwords service (self-hosted or via API) - this prevents the reuse of compromised passwords.
  • Apply tiered, intelligent IP mitigation instead of a single fixed volume limit: consider both short (burst) and long time windows, factor in IP classification (residential vs. hosting) and geolocation, and use hosting/proxy IP intelligence (tools such as Sentry MBA distribute requests across proxy networks and bypass simple rate limits). Always keep lockouts temporary.
  • Bot defenses and anti-automation: device and connection fingerprinting (e.g. JA3, HTTP/2 fingerprinting, header ordering) to detect scripts; CAPTCHA - ideally only for suspicious/high-risk logins, so as not to disrupt genuine users.
  • Enforce JavaScript execution and block headless browsers: since most attack tools only send direct POST requests and don't execute JS (to generate tokens), this makes the attack harder (mind accessibility - blocking users without JS can exclude screen-reader users).
  • Make the login process harder: a multi-step login (username and password one after another, fetching a CSRF token first) doubles the number of requests needed; but avoid user enumeration while doing so. Optionally use 'degradation' (proof-of-work, artificial delays) to throttle rate.
  • Make username reuse harder: require a dedicated, unpredictable username instead of the email address, since many leak lists only contain emails.
  • Defense in depth and metrics: combine multiple layers (client-side defenses can be spoofed), capture and monitor volume metrics per defense mechanism for detected/blocked attacks.
  • Notify users of unusual security events (e.g. correct password but failed MFA check); after repeated password resets from different devices/IPs, block further access to the account until the user is verified.

Sources

Keep reading
OverviewOWASP API Security Top 10 AttackCORS Misconfiguration