Skip to content
Start with Identity
SWI-T006 · Authentication

Credential stuffing

Attackers replay username and password pairs leaked from one breach against every other login page they can reach, betting on the well-documented habit of password reuse.

WidespreadModerate
First observed: 2014ATT&CK T1110.004 ↗

How it works

Credential stuffing replays username and password pairs leaked from one service against the login pages of other services, betting that some of those people reused the same password. It needs no exploit, no phishing page and no contact with the victim. Each success is a normal, valid login.

Billions of pairs circulate as combolists on criminal forums. A typical run:

  1. Acquire and clean a list. The attacker buys or downloads a combolist, removes duplicates and filters for email domains or regions that match the target's user base.
  2. Script the target's login. Tooling replays the web form or, often, the mobile app or API endpoint, which tends to have weaker bot defenses. Solver services handle CAPTCHAs.
  3. Spread the load. Attempts go out through botnets or residential proxy networks so each source IP makes only a few requests. Each username is usually tried once, with the one password the list holds for it.
  4. Sort the hits. Successes are checked for value (stored card, loyalty balance, tax documents, admin role), then used or resold.

That pattern is different from password spraying, which tries a few common passwords across many usernames, and from brute force, which tries many passwords against one account. Stuffing tries a known, once-valid pair per account. MITRE ATT&CK describes it as adversaries using "credentials obtained from breach dumps of unrelated accounts" and lists identity providers, SaaS, IaaS and network devices among the affected platforms.

Network devices matter. In the FortiBleed campaign documented in June 2026, an initial access broker got administrative access to exposed FortiGate firewalls through credential stuffing and brute force, then ran a sniffer on the device to capture authentication traffic. Fortinet told BleepingComputer it involved "previously compromised credentials rather than a new vulnerability."

Why it works

The attack needs no weakness in the target system, only password reuse and leaked credentials that stay valid for years.

Three control assumptions fail:

  • Lockout assumes repeated failures on one account. Stuffing makes one attempt per account, so per-account lockout rarely trips. Microsoft Entra smart lockout, for example, defaults to 10 failed attempts in Azure public cloud tenants before a first one-minute lockout, a threshold a stuffing run never approaches for any single user. Lockout implementations can also be bypassed outright: CVE-2025-6004 let attackers reset HashiCorp Vault's lockout counter by changing the case of a username.
  • Password-only login for customers. Consumer services often skip MFA to avoid friction. New York's regulator found PayPal did not require MFA and did not use controls such as "CAPTCHA or rate limiting" before attackers used compromised credentials to reach unredacted Social Security numbers.
  • One account sees only its own data. Features that let one account view others multiply the impact. At 23andMe, attackers logged in to about 14,000 accounts, and through DNA Relatives and Family Tree those accounts exposed roughly 6.9 million profiles.

Any second factor stops the replayed password alone, even phishable MFA such as SMS codes. That is why stuffing concentrates on accounts with no MFA at all.

How to detect it

  • Failure-reason mix. In Entra SigninLogs, a stuffing run shows up as many ResultType 50126 (InvalidUserNameOrPassword) failures and, for addresses not in the directory, 50034 (UserAccountNotFound), spread across many users. Microsoft notes you should expect some 50126 errors from ordinary typos, so the volume and the user spread are the signal. Error 50053 (IdsLocked) is returned when the account is locked or when Entra blocks a sign-in from a known malicious IP.
  • Okta System Log. user.session.start with outcome FAILURE across many users, security.threat.detected (ThreatInsight flagging a malicious IP, with outcome.result of ALLOW, DENY or RATE_LIMIT), security.attack.start (ThreatInsight concluding the org is under attack) and security.breached_credential.detected (a password linked to a known breach used during authentication) in Okta.
  • Leaked-credential risk. Entra ID Protection raises leakedCredentials when a user's valid credentials appear in a breach and match the current password hash. It is calculated offline and available without a P2 license.
  • Low success rate at high volume. A steady trickle of successes scattered across unrelated accounts, each from a different IP, is the shape of a list being worked.
  • Post-login behavior. Successful logins followed straight away by a payment method change, gift card or balance redemption, data export, or an email or password change.

The false-positive problem is real. Carrier NAT and corporate proxies put many real users behind few IPs, typos are constant, and residential proxies make attacker traffic look like home broadband. Detection works on the combination of scale, IP diversity, low success rate and what happens after login, not on one threshold.

How to stop it

Ranked by effect:

  1. Require a second factor, or move to passkeys. A correct password stops being enough. Roku's fix after about 576,000 accounts were hit in a second wave was to enable two-factor authentication for all accounts. For workforce accounts, prefer phishing-resistant MFA so the same accounts are not simply phished instead.
  2. Screen passwords against breach corpuses. NIST SP 800-63B Revision 4 requires verifiers to compare new passwords against a blocklist that includes compromised values, and to force a change when there is evidence of compromise. Check at signup, reset and login.
  3. Bot management on every login surface, including mobile and API endpoints. The OWASP cheat sheet rates connection fingerprinting such as JA3 as potentially more accurate than IP blocking, and warns that IP blocking alone is easy to get around and CAPTCHAs can be broken.
  4. Rate-limit by more than account. Limit by IP, ASN, device fingerprint and tenant-wide failure rate, not only per user. NIST caps consecutive failures per authenticator at 100; set lower limits where you can.
  5. Step up before value moves. Require reauthentication before redeeming balances, viewing tax documents or changing payout details.
  6. Network restrictions for admin and workforce logins, so device and VPN admin interfaces are not reachable with a password from the internet.

Do not answer stuffing with forced periodic password changes. NIST 800-63B says verifiers shall not require them; change on evidence of compromise instead.

Seen in the wild

  • Chick-fil-A One, 2023: automated attacks from December 18, 2022 to February 12, 2023 used credentials "obtained from a third-party source" and affected more than 71,000 people.
  • Chick-fil-A One, 2026: a second run between June 17 and June 19, 2026 hit 13,322 loyalty accounts. See our coverage.
  • PayPal, 2022-2023: 34,942 accounts accessed with reused credentials; New York DFS imposed a $2 million penalty in January 2025.
  • Norton LifeLock, 2022-2023: stuffing against Norton accounts, with possible exposure of Password Manager vaults where the vault key matched the account password.
  • 23andMe, 2023: about 14,000 accounts accessed, about 6.9 million profiles exposed.
  • Roku, 2024: two waves; fewer than 400 accounts saw unauthorized purchases with stored payment methods.
  • FortiBleed, 2026: stuffing and brute force against FortiGate admin access, followed by on-device credential sniffing. See our coverage.
  • Snowflake customer tenants, 2024 and the teardown: a related but distinct pattern. UNC5537 used credentials that infostealers took from employee and contractor machines against the same accounts, not a cross-site combolist. Snowflake was a shared-platform campaign, not a fan-out breach: each tenant was entered separately.

Sources

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.