Credential stuffing: how one leaked password becomes account takeover

What credential stuffing is

Credential stuffing is an attack in which stolen username-and-password pairs from one breach are automatically tried against many other services. The distinction from brute forcing is precise and worth keeping: brute forcing guesses a password by trying many candidate values against one account. Credential stuffing guesses nothing. It replays a pair that was real somewhere, betting that the person reused it.

NIST uses its own term for the same thing in SP 800-63B: "The use of distinct passwords is important to avoid ‘password stuffing’ attacks in which an attacker uses a compromised password from one site to access the user’s account on other sites." That single sentence is the whole reason a password manager is a security control rather than a convenience.

The economics make it relentless. A stuffing run is a script, a proxy pool and a file. A success rate well below one percent still pays when the input is billions of pairs, so there is no threshold below which you become uninteresting.

The chain, step by step

1. A service is breached, or an infostealer harvests saved logins from someone’s browser. Either way, working credentials leave the building.
2. The pairs are aggregated with older leaks into combolists and distributed — sold, subscribed to, or given away as samples.
3. Automated tools replay the pairs against other sites — email, banking, retail, corporate SSO — spread across many IP addresses and browser fingerprints so no single source looks abusive.
4. Wherever the password was reused, the login succeeds. That is account takeover, and it looks like a normal successful login in the logs.
5. The hijacked account is monetised directly, used to phish the victim’s contacts, or resold as initial access into the organisation behind the email domain.

Where the credentials come from

The word "combolist" suggests a static file passed between hobbyists. The Verizon 2025 Data Breach Investigations Report describes a distribution industry, with four tiers that differ in price and freshness:

• Marketplaces — logs posted for sale together with the associated domains, so a buyer can search for credentials belonging to a specific target.
• Premium channels — paid access to logs inside private chat rooms, ahead of the open market.
• Live logs — backend access to the infostealer databases themselves, giving buyers credentials before they ever reach a marketplace.
• Free samples — daily or weekly drops posted publicly on Telegram to advertise the paid tiers.

Some threat actors have built their entire attack process on leveraging these free samples for account takeovers.— Verizon 2025 Data Breach Investigations Report

The free tier matters more than it sounds: the barrier to running a stuffing campaign is not money or contacts, it is a Telegram client.

The same report shows how much of this material is corporate. 30% of the compromised systems appearing in infostealer credential logs can be identified as enterprise-licensed devices. And 46% of the compromised systems that had corporate logins in the stolen data were non-managed devices holding both personal and business credentials — a personal laptop with a work login saved in the browser, or a company machine used outside policy. Your employer’s security controls never touched that browser profile.

Why this matters to your employer

Credential stuffing is usually framed as a consumer nuisance. The DBIR 2026 has the number that reframes it: matching ransomware victims from the two previous years against credential-leak data, 73% had an infostealer or other credential leak in the year before they were publicised as a victim — and half of those saw it within 95 days of the attack.

That is the access-broker economy, visible in the data: leaked credentials are not an endpoint, they are the inventory a ransomware crew shops from. It lands hardest on smaller organisations — ransomware was present in 48% of breaches overall, up from 44%, and of the ransomware victims whose size the DBIR could determine, about 96% were small and medium businesses.

What actually breaks the chain

Every control below stops a different step, and each has a real limit. Stacking two or three is what makes the attack uneconomic:

The second row surprises people. App-based one-time codes and push notifications beat a password alone, but CISA does not classify them as phishing-resistant: the user can be induced to hand the code over in real time. FIDO/WebAuthn and PKI-based authenticators are the phishing-resistant tier, because the credential is bound to the origin and never leaves the device as something replayable.

The UK’s NCSC frames the same hierarchy for organisations: mandating strong authentication — device-based passwordless with a FIDO token, or MFA — is how you "entirely mitigate the threat of credential theft" on services you control, with password managers covering the sites you do not.

What NIST actually says about passwords

Most password policies still in force were designed for a threat model that stuffing has replaced. NIST SP 800-63B is direct about it.

• Verifiers SHALL require a minimum of 15 characters for a password used as a single factor; 8 characters is permitted when the password is only one factor in an MFA process.
• Verifiers SHALL NOT impose other composition rules — no mandatory mixtures of character types.
• Verifiers SHALL NOT require subscribers to change passwords periodically. "However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
• When a password is set or changed, verifiers SHALL compare it against a blocklist of known commonly used, expected or compromised values, including "passwords from previous breach corpuses".

On why composition rules backfire, NIST is blunt: "a user who might have chosen ‘password’ as their password would be relatively likely to choose ‘Password1’ if required to include an uppercase letter and a number or ‘Password1!’ if a symbol is also required." The rule adds no entropy an attacker’s wordlist does not already model.

Read the rotation and blocklist clauses together and you have the case for breach monitoring, written by a standards body. Scheduled 90-day expiry is out; forcing a reset on evidence of compromise is mandatory — which means you need a way to obtain that evidence.

What people get wrong

• "It was an old, unimportant account." Age is irrelevant — the account that leaked matters far less than the password that leaked.
• "I changed that password." Changing it on the breached site does nothing for the other nine places you used it. The reuse is the vulnerability, not the original site.
• "I have MFA, so I am fine." True against a plain replay, weaker against a relay kit or a stolen session token — and worth checking which kind of MFA you actually have.
• "I would notice." A stuffing login uses your correct password and looks normal. Unrequested reset emails and MFA prompts you did not trigger are often the only signal.

If your credentials have already turned up in a leak, work through what to do after a data breach, and see what counts as a data breach for what else may have leaked alongside them.