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. If the same password is still valid and other controls do not stop the attempt, the attacker can obtain a session. A correct password alone does not guarantee access when MFA or risk-based checks apply.
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. These findings highlight the risk of business credentials being stored outside the organisation’s managed-device controls.

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

The controls below address different parts of the attack. Combining them reduces opportunities for account takeover; effectiveness depends on coverage, configuration and response:

Defences against credential stuffing, and where each one stops

Control	Where it breaks the chain	Limits
Unique passwords via a password manager	Step 4 – stops reuse of that password at other accounts that have distinct passwords.	Only protects accounts you have already migrated; the breached password still works everywhere you reused it.
MFA via authenticator app or push	Step 3 – the replayed password alone no longer completes a login.	Not phishing-resistant. A real-time relay kit or a stolen session token gets past the prompt; push fatigue gets past the user.
Phishing-resistant MFA (FIDO/WebAuthn, passkeys, PKI)	Step 3 – the authenticator does not provide a reusable password or one-time code to a phishing site.	Needs enrolment and secure recovery. Compromised endpoints and stolen session tokens remain risks.
SMS or voice one-time codes	Step 3, partially.	CISA rates SMS and voice OTP the weakest form of MFA. Better than a password alone, but interceptable and relayable.
Breach and infostealer monitoring	Can reveal credentials present in the monitored sources, supporting account investigation and resets.	Coverage is incomplete and the alert may arrive after misuse. Check affected accounts and revoke compromised sessions as needed.
Rate limiting and bot detection	Step 3 – raises the cost of high-volume automation.	Distributed, low-volume attempts can evade simple thresholds. Device, network and account behaviour signals can improve detection.

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 recommends strong authentication on services an organisation controls and password managers for other services. Phishing-resistant authentication greatly reduces password replay and relay risks, but account recovery, endpoint compromise and session theft still need attention.

What NIST actually says about passwords

NIST SP 800-63B-4 sets requirements for systems following its digital identity guidance. Its password provisions include:

• 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.

For verifiers following NIST’s guidance, evidence of compromise triggers a required password change. Such evidence can come from service alerts, authentication logs, user reports, an investigation or breach intelligence. The standard does not require an organisation to buy a breach-monitoring service – what breach monitoring can and cannot tell you sets out what one adds and what it misses.

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 correct password may avoid an obvious failed-login warning. Review unexpected device and login alerts, MFA prompts, account changes and session activity; the absence of an alert does not prove that an account is safe.

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. The account-habits checklist is a quick way to find which of these applies to you.