Credential Stuffing Attack Patterns and Infrastructure-Level Defenses

Credential stuffing has stopped behaving like a hacking technique and started behaving like a supply chain, with acquisition, tooling, and execution running as separate, specialized stages the way a factory separates sourcing from assembly from shipping. A 16-billion-credential database compiled from stealer logs and prior breaches surfaced in mid-2025, and a 24-billion-record credential dump followed in July 2026, and that works out to roughly three username-password pairs for every person on the planet. That stockpile feeds a sustained, global operation: roughly 26 billion credential stuffing attempts hit organizations every month. The volume is the headline; the specialized stages of acquisition, tooling, and execution are the actual story. Verizon's DBIR, IBM's X-Force report, and SecureW2's synthesis of both drew on entirely separate data sets, but they all landed on the same conclusion: stolen credentials are the leading initial access vector into enterprise systems. Three unrelated measurement efforts converged on the same answer, so this is not a coincidence. It reveals a problem built into the plumbing of how people authenticate.

Infostealers turned the credential supply from stale to live

The old model of credential theft ran on breach dumps, static files of usernames and passwords that sat around for years, and breach-monitoring tools often flagged them before anyone thought to use them. That model is dead. Infostealer malware now harvests login data in real time, straight from a browser where the victim is still logged in. The credential an attacker holds this afternoon may have been typed by its owner this morning. Specops found that malware stole 6 billion passwords in 2025 alone, up sharply from the year before. IBM's X-Force 2026 report found that credential harvesting was the most common impact across victim organizations, ahead of every other outcome tracked. So the harvesting pipeline feeding the stuffing attacks runs at industrial scale, upstream of anything a defender sees at the login screen. The session-cookie detail matters beyond the theft itself: a cookie lifted straight from an active browser session is a ticket already punched, not a password to be guessed or verified, and that fact reappears later when the subject turns to why multi-factor authentication doesn't stop everything it's assumed to stop.

Password reuse as the structural condition enabling stuffing at scale

The supply only matters because it converts into account takeovers, and password reuse is why that happens. A large-scale study of leaked passwords found that 94% were reused or duplicated, and only a small sliver were genuinely unique to one account. Verizon's SSO data put a number on the exposure: the median share of a user's passwords that were unique across services was only about half, so a breach anywhere in that person's service footprint puts every connected account at risk. It doesn't matter to the reuse pattern whether an account is trivial or important. Social media logins, email, bank accounts, and home Wi-Fi routers all sit in the same target set, so a password lifted from a forgotten forum account becomes a working key for a bank login if the user typed the same string twice. Any single stuffing attempt has a low success rate, but when you run tens of billions of attempts a month, even a thin success rate produces an enormous volume of compromised accounts. One might object that password managers are catching on and reuse is fading as a problem. Adoption remains far from universal, and password policies on the books fail to stop reuse, with a majority of IT professionals, the people paid to know better, reusing passwords themselves, and reuse persists even in these security-aware populations, showing that better habits alone will not stop it.

How modern stuffing campaigns evade existing defenses

Attackers built the current generation of stuffing campaigns specifically to beat the controls most companies already have in place: IP blocking, rate limiting, CAPTCHA. A 2026 authentication threat landscape report found that the large majority of credential stuffing attempts now route through residential proxy networks, so traffic appears to originate from ordinary home internet connections, and IP-based blocking cannot distinguish attacker traffic from legitimate users in these regions. That is the whole trick: IP-based blocking depends on telling attacker traffic apart from legitimate traffic, and residential proxies erase the distinction at the source. CAPTCHA fares no better. Analysis of active credential-stuffing groups found that most used CAPTCHA-solver services paired with residential proxies, and when the breach happened, a large share of the organizations they hit already had bot detection running. Having a lock on the door doesn't help much when the lock has a known bypass sold as a subscription service.

Where web login forms at least carry some CAPTCHA and WAF coverage, APIs mostly don't, and attackers have noticed. Salt Security's research into production APIs found more than two-fifths had authentication problems, and more than a quarter showed active credential stuffing or brute-force activity already underway. APIs have become the preferred surface precisely because the defenses bolted onto the login page rarely extend to the API layer behind it. All of this adds up to a structural blind spot rather than a series of unlucky breaches. A defense operating only at the application layer evaluates each request as its own isolated event, with no cross-network visibility into the distributed botnet orchestrating "normal-looking" requests across thousands of IP addresses simultaneously.

Why MFA does not close the gap

Multi-factor authentication is the default answer organizations give when credential stuffing comes up, and it's necessary, but necessary is not the same as sufficient. A significant share of MFA-protected accounts get compromised anyway, through techniques that operate above the credential layer entirely. Obsidian Security found that more than 80% of compromised SaaS accounts in 2025 had MFA enabled at the moment of compromise. MFA locks the front door at the moment someone tries to walk through it, but it has nothing to say about the session token issued once they're inside. Verizon's DBIR broke down how Microsoft 365 accounts actually got breached despite MFA: token theft accounted for nearly a third of breaches, MFA fatigue and prompt bombing for roughly a fifth, and adversary-in-the-middle attacks for about a tenth.

The adversary-in-the-middle technique is the cleanest illustration of the problem. An attacker-controlled reverse proxy sits between the victim and the real identity provider, and it relays the credentials and the MFA response exactly as entered, so the MFA challenge completes successfully. The attacker simply captures the session token on its way back and now holds a fully authenticated session, no password cracking required. Eleven AitM phishing kits are currently in wide circulation, including commercial platforms like Tycoon 2FA and EvilProxy sold as a service, alongside open-source frameworks such as Evilginx, Modlishka, and Muraena. None of this requires the attacker to write a line of code. And the infostealer pipeline described earlier closes the loop from a different angle: session cookies harvested by LummaC2 are already-authenticated tokens, so MFA never even enters the picture, since authentication already happened on the victim's own machine before the malware grabbed the result. MFA raises the cost of an attack, and that's worth having. But it is a per-session control bolted onto the application layer, and it can't see the botnet infrastructure, the proxy network, or the token-theft pipeline feeding traffic toward it.

What infrastructure-level defenses can do that application controls cannot

Because the problem is volumetric, distributed, and running through a supply chain the application layer can't see, the fix has to operate on the network the traffic actually travels across. An edge network with distributed points of presence absorbs and inspects a volumetric stuffing campaign across aggregate capacity no single origin server could match, so the origin never sees the attack traffic at all. That's the clearest way to separate "infrastructure-level" from "application-level": one stops the flood before the building, the other mops up after it's already inside.

A global network carries traffic across sites where bots make up 65 to 75% of all web traffic on average, so it accumulates bot fingerprints, proxy signatures, and behavioral patterns no single company's server logs could ever assemble, and that intelligence gets applied to every incoming request before it reaches the application layer. This is where the API gap from the evasion section gets closed rather than just described. A WAF blocks known attack signatures in HTTP traffic, but a Web Application and API Protection layer adds positive security enforcement built for APIs specifically, machine-learning-driven bot detection, and ongoing vulnerability remediation, covering the exact ground a WAF-only setup leaves open against API endpoints that never got the same protection as the login form.

No single mechanism does this alone. Progressive delays on repeated failed logins, device fingerprinting, machine-learning anomaly detection, and IP reputation scoring each fail on their own against a well-funded attacker, but stacked together they raise the cost of evasion past what residential proxy rotation and CAPTCHA-solving subscriptions can afford to overcome. Rate limiting only helps if you enforce it at the edge with breach-intelligence feeds behind it, because that catches failed-login patterns spread across thousands of IP addresses even when each request looks normal on its own. That cross-request visibility simply doesn't exist for a control that evaluates one request at a time. There's an organizational cost to ignoring this, too: treating a WAF and bot management as separate products creates policy inconsistencies and operational overhead, while a unified platform delivers consistent enforcement with lower management burden for teams that cannot staff separate security tool sets.

Zero Trust identity controls close the gap network defenses leave open

Network-layer defenses cut the volume of attack traffic dramatically, but they can't bring the success rate to zero, and if a stolen credential or hijacked session token slips through, it still needs somewhere to go once it's inside. Zero Trust identity controls are what shrink the damage that token can do. The problem with static, long-lived credentials is structural: a valid session token stolen by an infostealer or captured through an adversary-in-the-middle attack looks, at the network layer, identical to a legitimate session, so containing the damage requires something that checks identity on every request, not just at the login screen. Under a Zero Trust model, every access request gets verified continuously against identity, device posture, and context, so a token replayed from an unfamiliar device or an unexpected country triggers re-authentication or outright denial, even when the credential behind it is technically valid.

The sharpest version of this idea appears in frameworks like SPIFFE, which issue short-lived, workload-scoped identities, called SVIDs, that expire on a time-based TTL, typically one hour, and rotate automatically without a human in the loop. That one design choice changes what a stolen token is worth. Instead of granting access to everything a compromised principal could ever touch, it grants access to one transaction, for a few seconds, and then the door closes on its own. That is the correct architectural answer to token theft, because it treats the credential itself as disposable rather than precious, which is the opposite of how most systems have handled authentication for the last two decades.