Credential stuffing

Credential stuffing is the cheapest and most prevalent attack against authenticated services on the internet. The economics improved for attackers in 2025 when Synthient’s stealer-log database added 23 billion records to public credential corpora, and 22% of all data breaches that year started with credential stuffing. The defense has not gotten harder so much as the attack has gotten cheaper. This article covers the attack’s structure, the tools attackers actually use, and the controls that meaningfully reduce success rates.

This is one half of the ATO story. The other half is in account takeover prevention, and the broader fraud framing is in ecommerce fraud prevention.

What credential stuffing is

Credential stuffing is the automated process of testing username-password pairs from one breached service against another service to find accounts where the user has reused the same credentials. The mechanics:

Acquire a “combo list” of email-password or username-password pairs from past breaches or stealer-log dumps.
Load the list into a credential-stuffing framework (OpenBullet, SilverBullet, Sentry MBA, Snipr).
Configure the framework with a “config” describing the target site’s login flow.
Run the framework. It iterates through the combo list, attempts each pair, and logs the successful logins.
Sell the successful logins, or use them directly to extract value.

The success rate per combo pair is low, typically 0.1% to 2% depending on the target and the freshness of the combo list. The volume is enormous: a single attacker running a moderate operation may attempt millions of pairs per hour. Even at a 0.5% hit rate that produces tens of thousands of compromised accounts per day.

The credentials are cheap and the combo lists essentially free, so the only cost left for the attacker is the infrastructure to run the attempts and the time to convert successful hits into money.

Why it works: the password-reuse problem

The behavioral assumption credential stuffing exploits is that users reuse passwords, and the data bears it out: a 2025 study of 19.03 billion leaked passwords found that 94% were reused or duplicated (deepstrike.io: Password Statistics 2026). Studies of work-vs-personal password reuse put the rate above 60%.

The Synthient credential-stuffing dump added to Have I Been Pwned in October-November 2025 is the largest single addition in the project’s history: 23 billion records, with 1.96 billion unique email addresses and 1.3 billion unique passwords (HIBP: Synthient Credential Stuffing Threat Data Breach). That is enough material to mount continuing credential-stuffing campaigns against every consumer-facing service on the internet for years.

The Synthient corpus is also notable because it contains stealer-log data: credentials harvested by infostealer malware on the user’s own machine. Stealer-log credentials are higher-quality than breach data because they are typically current (not just historical), they include sessions, and they often include the originating URL so the attacker knows exactly which site the credential opens. A combo list from breach data tells the attacker what passwords users have set. A stealer-log corpus tells the attacker exactly which accounts on which sites are currently accessible with those passwords.

Data The credential corpus available to attackers in 2025

53.3B

SpyCloud (recaptured, 2024)

23B

Synthient (HIBP, Oct 2025)

16B

HIBP credential DB (mid-2025)

1.8B

Infostealers (2025)

17.3B

Session cookies (2024)

Records, in billions. Categories overlap; not additive.

Source: SpyCloud 2025 Identity Exposure Report, Have I Been Pwned, Verizon DBIR 2025

These corpora overlap significantly (an infostealer credential often ends up in HIBP later). The point is order of magnitude: there are tens of billions of working credentials and session cookies in circulation, enough material to keep credential-stuffing campaigns running for years.

The tools attackers actually use

The credential-stuffing tooling ecosystem is small and stable. Four products dominate.

OpenBullet 2

The most popular credential-stuffing framework, openly distributed as “penetration testing software” on GitHub but used overwhelmingly for ATO (SpyCloud: New Cracking Tools). Configurable per-target via “config” scripts that describe the login flow. The community shares thousands of configs for popular targets through Telegram channels and underground forums.

OpenBullet uses a domain-specific scripting language called LoliCode. A config script describes:

The HTTP request sequence for the login.
The expected responses for “valid,” “invalid,” “banned,” and other outcomes.
Any anti-bot tokens to extract from prior pages (CSRF tokens, JavaScript-derived challenge tokens, fingerprints).
The proxy rotation strategy.

A new attacker downloads OpenBullet, pulls a config for their target from a shared repository, plugs in a combo list, and starts; none of this requires any particular skill. Where a target’s anti-bot stack requires full JavaScript execution, configs switch from raw HTTP requests to driving a real browser in headless mode, at which point headless browser detection becomes the relevant control.

SilverBullet

A fork of OpenBullet with broader proxy support and an updated UI. Sometimes used interchangeably with OpenBullet by attackers.

Sentry MBA

An older tool, still in active use, with similar capabilities. Less actively developed than OpenBullet.

Snipr

A commercial product with subscription pricing. Polished UI, professional support, regular config updates. The existence of a paid tier in this space tells you something about the maturity of the market.

The configs themselves are the interesting product. A working config for a specific target represents the reverse-engineering of that target’s anti-bot stack: which CSRF tokens to grab, which fingerprint values to send, which proxy types still work, which response shapes correspond to which outcomes. Configs for popular targets are sold for $50 to $500 each. Configs for new targets get released within days of any anti-bot deployment that breaks the previous one.

Residential proxies have changed the math

Five years ago credential stuffing was easy to mitigate by rate-limiting per IP. Attackers came from datacenter IP ranges, blocked easily, and could not afford the volume of unique IPs needed to bypass rate limits.

Residential proxy services changed this. A residential proxy network routes traffic through tens of millions of consumer devices (typically users who installed a “free VPN” app that turned their device into an exit node, or compromised IoT devices, or contributed devices in exchange for ad revenue). The attacker pays per gigabyte of traffic and gets exit IPs from real consumer ISPs.

The pricing as of 2026 ranges from $1 to $15 per GB depending on quality. A credential-stuffing campaign with one HTTP request per attempt at ~5 KB per request can mount roughly 200,000 attempts per dollar of residential proxy traffic.

Per-IP rate limiting therefore catches almost nothing. Per-session rate limiting catches more, but residential proxies rotate sessions trivially. The defense has to move to per-account and per-device signals rather than per-IP signals. Residential proxy detection covers the signals that survive the rotation.

How a credential-stuffing attack looks at your endpoint

If you have not seen one against your own service, this is the pattern:

Login attempts surge from 10,000/hour to 1,000,000/hour over a few minutes.
The IPs are distributed across thousands of residential ASNs in many countries.
Each IP attempts only a handful of logins, never enough to trip a per-IP rate limit.
The User-Agent strings are realistic but show characteristic clustering: a handful of slightly outdated Chrome versions on Windows make up an unrealistic share of the attempts.
The TLS fingerprints, if you are checking, show patterns consistent with tls-client or curl-impersonate builds rather than real Chrome.
The behavioral signals are empty: no page interaction, immediate submit, no time between page load and credential submission.
The success rate is exactly the breach-data success rate for your user base (often 0.1% to 2% on a fresh combo list, lower on stale ones).

The pattern is recognizable to a sufficiently instrumented monitoring system. The challenge is having the instrumentation in place before the attack starts.

Defenses that work

Three layers, in order of cost and value.

Layer 1: Make the password less load-bearing

The single highest-yield change you can make is to move users off password-only authentication.

Passkeys. FIDO2-based authentication using on-device biometrics. The user does not type a password, the credential cannot be reused across sites by definition, and credential-stuffing attempts on passkey-only accounts return zero hits. Adoption is growing fast; major consumer services are seeing 30%+ passkey adoption within months of deployment.
Magic links. Email-based one-time login. Useful as a primary mechanism for low-trust accounts and as a step-up for higher trust.
OAuth via identity providers. “Sign in with Apple,” “Sign in with Google.” Inherits the IDP’s security. Still vulnerable to ATO of the IDP account.
Breached-password rejection at signup and password change. Check candidate passwords against Have I Been Pwned’s API (api.pwnedpasswords.com/range/... is a k-anonymity-friendly endpoint that lets you check without sending the full hash). Reject any password that appears in known breaches.

Passkeys are the most consequential of these. Their adoption is what will eventually retire credential stuffing as a viable attack on retail consumer services.

For accounts that still use passwords (the majority for the foreseeable future), the defense is to risk-gate the credential check.

Risk score before password check. Compute the device intelligence, behavioral and network signals before validating the password. If the session looks automated, return invalid-credentials regardless of whether the password is correct. The ordering matters for timing-leak reasons; see the password-check ordering trap.
Device-velocity rate limits. Limit logins per device, not per IP. A residential proxy rotates IPs but the device identity is stable.
Per-account velocity limits. Limit failed logins per account regardless of source.
Proof-of-work on automated-looking sessions. Sessions failing the behavioral check get a PoW challenge before the password check is even allowed.
Block known credential-stuffing TLS fingerprints. Many OpenBullet configs use tls-client builds with characteristic JA4 signatures. Blocking them at the edge is a cheap initial cut.

F5 Labs has detailed write-ups of the credential-stuffing attack lifecycle and the per-signal patterns (F5 Labs: Credential Stuffing Tools and Techniques).

Layer 3: Detect what got through

No defense catches everything. Layer 3 catches the credentials that survived layers 1 and 2.

Monitor for stealer-log appearances. Services like SpyCloud, Constella, and Have I Been Pwned’s enterprise tier alert when accounts on your service appear in new credential dumps. Force a password reset proactively.
Adaptive MFA on new devices. Even if the password is correct, a successful login from a new device should trigger step-up. See account takeover prevention.
Post-login monitoring. A “successful” credential-stuffing hit will exhibit behavior inconsistent with the legitimate user (different device, different navigation patterns, immediate value-extracting actions). Detect and intervene.

What not to do

Three failure modes:

CAPTCHA on every login. Credential-stuffing operations include CAPTCHA-solving as a budget line item. Cloud-based CAPTCHA-solving costs $1 to $5 per 1,000 solves. Adding CAPTCHA to every login costs the attacker pennies per hit and costs every real user a few seconds, which is a net negative. If login needs an automation check at all, CAPTCHA alternatives put the cost on the attacker instead of the user.

Block-by-country. Real users travel and use VPNs. Country-level blocking damages the legitimate user base more than it damages credential-stuffing operations that buy proxies in your target country.

Trust the User-Agent. OpenBullet configs ship realistic User-Agent rotation by default. The User-Agent does not help.

How Foil supports the defense

Foil’s contribution to credential-stuffing defense is the device identity and per-session classification that makes layer 2 effective. The SDK collects fingerprint and behavioral signal during the login form interaction; the API returns:

A stable visitor fingerprint (visitor_fingerprint.id) for per-device velocity limiting.
A verdict (bot, human, or inconclusive) with a risk score and attribution labels naming the framework or agent, so the application can risk-gate before the password check.
The fired signals and connection fingerprint (for example a TLS-versus-User-Agent mismatch surfaced as connection_fingerprint.user_agent_alignment) that the application logs for audit.

The application uses these to implement risk-based authentication. A typical integration is sketched in account takeover prevention.

For the broader account-abuse picture, the sibling posts are fake account prevention and promo abuse prevention.