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 to detect
First observed: 2014ATT&CK T1110.004

How it works

Billions of username and password pairs from historical breaches circulate as combolists on criminal marketplaces and forums. Credential stuffing takes one of these lists and automates login attempts against a target service, using botnets or proxy networks to spread the attempts across many source IPs so no single address looks like an obvious abuser. Unlike password spraying, which tries a few passwords across many usernames, stuffing tries known, previously valid username-and-password pairs one at a time, betting that a meaningful share of people reused the same password across multiple sites. Any account where that bet pays off authenticates successfully with no exploit, no phishing page, and no interaction with the victim at all.

Chick-fil-A's loyalty program has been hit by this exact pattern twice: a March 2023 incident affecting roughly 71,000 customer records, and a second one in June 2026 that compromised 13,322 accounts over three days, both using credentials obtained from unrelated third-party breaches, not any flaw in Chick-fil-A's own systems, against accounts that reused a password exposed elsewhere. The 2024 Snowflake customer breaches are a related but distinct pattern worth separating from classic stuffing: a threat actor logged into roughly 165 customer environments using credentials that infostealer malware had harvested directly from contractor and employee machines years earlier and that were never rotated, which is stolen-credential reuse against the same accounts they were stolen from, not blind replay of a leaked list across unrelated sites betting on reuse. Either way, no MFA and no network restrictions meant a correct password was the only thing standing between the attacker and the account.

Why it works

The attack does not depend on any weakness in the target system. It depends entirely on the fact that people reuse passwords across services, and that credentials leaked from an unrelated breach, sometimes years old, remain valid because nobody rotated them. A username and password pair that was never even the target's own creation, just something they typed into a different site once, becomes a working key to an account they think is unrelated. Where MFA and network restrictions are absent, there is nothing left in the login path to stop a correct password from working.

How to detect it

  • Large volumes of login attempts distributed across many source IPs or a rotating proxy pool, each making relatively few attempts.
  • A high ratio of failed to successful logins overall, with successes scattered rather than concentrated, consistent with a low hit rate against a stuffed list.
  • Successful logins immediately followed by unusual account behavior (data export, mailbox rule changes, password changes) rather than the normal first actions of that user.

Be honest about the limits: shared corporate proxies and mobile carrier NAT can also produce many logins from a small set of IPs, and a large user base will always show a background rate of failed logins from people who mistype passwords. The distinguishing signal is the combination of scale, IP diversity, and a stuffing-consistent low success rate, not any single metric alone.

How to stop it

  • Enforce MFA everywhere, with no exceptions for legacy, contractor, or service accounts, since a correct password stops being sufficient the moment a second factor is required.
  • Add network allowlists or risk-based access rules so credentials alone cannot be used from arbitrary, unexpected locations.
  • Screen new and existing passwords against known-breached credential lists at signup, login, and reset.
  • Rotate credentials on a real schedule and prefer short-lived, federated access over long-lived passwords wherever possible.
  • Deploy bot and rate-limiting controls on login endpoints, and monitor for credentials appearing in infostealer dumps tied to your users.

Seen in the wild

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Seeing this technique used differently, or have a detection rule that works better? Email [email protected]. 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.