Credential Stuffing Attack Patterns and Infrastructure-Level Defenses

Credential stuffing works because leaked credentials are functionally unlimited and get restocked every day, supplying the raw material the attacks depend on. The Synthient corpus added 1.96 billion unique emails and 1.3 billion unique passwords to HaveIBeenPwned in November 2025 alone. The application sitting behind a login form is not the real target. The credential is the target. The application is just the door it happens to walk through.

Three separate datasets, gathered by three separate organizations using three separate methods, land on the same conclusion. A major vendor's annual breach report found stolen credentials were the top initial access vector in 22% of 12,195 confirmed breaches, the leading vector for the second year running. IBM's X-Force report found credential harvesting overtook every other outcome as the number-one observed impact on victim organizations. CrowdStrike's Global Threat Report found 82% of 2025 detections involved no malware. Adversaries are logging in rather than breaking in. When incident submissions, IR caseloads, and endpoint telemetry all point the same direction, that's three independent witnesses agreeing, not a stat someone went hunting for.

The old framing of credential stuffing as a low-skill, low-impact nuisance does not survive contact with this data. IBM puts the detection and containment window for credential-based breaches at roughly 292 days, far longer than many other breach types, which drives the overall cost of these incidents significantly higher. Slow to notice, expensive to fix. Call it a nuisance if the word still fits.

The attack anatomy: what a credential stuffing campaign looks like in traffic

Stripping out the marketing language shows a stuffing campaign breaks down into a handful of repeatable patterns, each with its own fingerprint in server logs.

Rotating proxies and identity spoofing sit at the center of the modern playbook. Residential proxy networks route requests through real household IPs, anti-detect frameworks randomize browser fingerprints on every session, and CAPTCHA-solving services clear the one obstacle most sites still lean on. Each request can look like a different device in a different city, even though it's the same script running the same list of stolen passwords.

API endpoint abuse is the quieter cousin, and the more dangerous one. Security researchers tracking the threat script market counted over 100 new tools published between late 2024 and mid-2025 with business-logic manipulation and API exploitation built in as standard features, not add-ons. These tools go after mobile API endpoints and third-party OAuth flows on purpose, because those paths don't get the scrutiny an HTML login form gets. A WAF tuned to watch for suspicious form submissions has a blind spot sitting right where the attacker is standing.

Then there's sheer volume. Verizon's SSO log analysis found that on a median day, 19% of all authentication attempts were credential stuffing. On a bad day, that number climbed to 44%. Traditional bots used to be easy to spot: fixed IPs, static user agents, requests fired at metronome intervals. AI-driven bots vary their timing, rotate realistic-looking user agents, and mimic mouse movement well enough that the traffic reads as a crowd of real people instead of a script.

Password reuse does the heavy lifting that makes any of this profitable. Verizon's data shows the median user's credentials are only 49% unique across the services they use. A password leaked from some forgettable mid-tier breach years back is still live ammunition against a bank login today. Per-attempt success rates are in the low single digits, but against Akamai's reported figure of roughly 26 billion credential stuffing attempts per month, even a 0.1% to 0.5% hit rate produces account takeover numbers that matter. And because the credentials match, the login succeeds, and the authentication log shows a normal, successful sign-in. No anomaly flag, nothing at the application layer to catch. It's a key turning in a lock the owner lost track of years ago.

Each of these four patterns (proxy rotation, API targeting, volume bursts, reuse economics) leaves a structural signature that infrastructure can catch before a single login attempt reaches the code that checks a password's correctness.

Why MFA doesn't stop stuffing at the infrastructure layer

The reflex response to credential stuffing is to bolt on multi-factor authentication. The data doesn't back that up as a complete answer, and treating MFA as the finish line is the single most common mistake in this whole discipline. Obsidian Security's analysis found more than 80% of compromised SaaS accounts had MFA enabled at the time of the compromise. The lock was on. It just didn't matter.

Part of the reason is fatigue. Push-notification bombing, where an attacker spams approval requests until an annoyed or confused user taps accept, showed up in 14% of incidents in the 2025 Verizon DBIR, alongside a documented rise in MFA bypass methods generally. Push-based MFA, once sold as a convenience upgrade over one-time codes by text, has turned into a liability in any environment facing real attack pressure.

What happens after MFA succeeds is the bigger issue. Token theft accounted for 31% of Microsoft 365 breaches. Adversary-in-the-middle attacks, run through reverse-proxy phishing kits like Evilginx, Modlishka, and Muraena and now available through commercial phishing-as-a-service platforms, are between the user and the real login page, let the MFA challenge complete normally, and steal the session token issued right after. MFA guards the moment of login. It does nothing for the token handed out once that moment passes, and a session token is a bearer token: whoever holds it is authenticated, no questions asked, no second look.

None of this argues against MFA. It argues that MFA is one lock on one door, and stuffing campaigns have learned to either pick that lock or climb through the window that opens right after it. If credentials are already compromised and MFA itself can be bypassed or its output stolen, the only defense layer still standing is the one that stops the traffic before it reaches the login form.

What infrastructure-level controls address each attack pattern

Match the control to the pattern. Each attack type above has a countermeasure that operates below the application, before business logic ever gets a vote.

Distributed bot traffic gets caught by IP reputation and network-level threat intelligence, and this only works at scale. A platform with visibility into a meaningful slice of global internet traffic can flag botnet infrastructure before it reaches any specific target, blocking known-bad addresses on arrival. Botnet IPs cycling through a stolen credential list against one target have usually already been flagged from hitting a dozen others first.

Rotating proxies and spoofed fingerprints are where rule-based defenses fall apart completely. Headless browser frameworks like Playwright and Puppeteer leak detectable markers, things like navigator.webdriver flags or missing browser plugins, but anti-detect frameworks exist specifically to randomize those markers session by session, and CAPTCHA solver services mop up the rest. Machine-learning behavioral analysis sidesteps the fingerprint arms race by watching request cadence, navigation flow, and session coherence instead. A randomized fingerprint fakes a static signature far more easily than it fakes believable behavior across an entire session. The volume involved isn't small either: one bot management vendor's network recorded nearly 8 billion AI agent requests in the first two months of 2026 alone.

API endpoint abuse needs API-aware rate limiting and schema validation, because stuffing tools go after mobile APIs and OAuth flows precisely because generic WAF rules are built around HTML forms. Controls that understand the expected shape of an API call, the token flow, the normal pace of requests for a given endpoint, catch anomalies that look perfectly clean to a generic rule set. AWS WAF's support for aggregation keys beyond IP, including custom headers, query arguments, cookies, and label namespaces, combinable up to five at a time, lets rate limits apply per IP per URI path, catching endpoint-specific abuse a flat per-IP limit misses. Static thresholds don't survive contact with attackers who tune their request rate to sit just under the line, so limits need to move with the session rather than sit fixed forever.

High-volume authentication bursts call for velocity controls and staged challenges: CAPTCHA or step-up MFA applied to suspicious traffic only, not to every user, which keeps the experience clean for real customers while making each attempt cost the attacker more. Checking login attempts against known-breached credential lists at the infrastructure layer intercepts stuffing before the application ever processes the request. None of this needs to make an attack impossible. It needs to make the compute and time cost per attempt high enough that the campaign's economics stop working at scale.

Edge controls give the earliest detection window and take load off application infrastructure. Application-layer controls add the business context edge systems can't see. Serious authentication volume demands both, and picking one over the other is how the gap gets found and used.

Why WAFs alone cannot carry the load

A WAF was built to catch malformed or malicious requests: SQL injection, cross-site scripting, protocol violations. Credential stuffing doesn't do any of that. It uses the site exactly as designed, sending syntactically valid requests to real endpoints, sometimes with a credential that's actually correct. There's no vulnerability for a WAF to find, because there isn't one to find. The WAF inspects the request, sees nothing wrong with its shape, and waves through some of the most damaging traffic the site will see all day. Expecting a WAF alone to stop this is like asking a bouncer checking IDs to also spot the guy who legitimately has one, stolen off someone else's dresser.

The evasion toolkit exists specifically to exploit that gap. Headless browsers present clean fingerprints, anti-detect frameworks rotate them, solver services clear CAPTCHAs, all engineered against rule-matching logic. The structural limitation is well recognized: a WAF without dedicated bot management treats scrapers, credential stuffers, and inventory hoarders the same as ordinary customers, because as far as its rule set is concerned, they are the same.

Closing the gap takes dedicated bot management running machine-learning behavioral analysis instead of static rules, breached-credential intelligence checked at the point of authentication, session integrity monitoring that catches token theft after login succeeds, and API-specific controls tuned to how an authentication API is actually supposed to behave. One publicly documented approach bundles WAF, bot management, API security, and DDoS protection into a single adaptive engine that uses machine learning to tune its own detection rules, which vendor reporting credits with cutting false positives meaningfully. Whichever specific product a given organization lands on, the design principle holds: bolting a bot management tool onto an existing WAF as a separate box creates data silos and adds latency to every decision. A setup where WAF signals, bot signals, and API signals all inform each other in the same place makes faster calls and more accurate ones. That's the real case for consolidation. Not fewer vendors for its own sake, but fewer blind spots between them.

The DDoS dimension: when credential stuffing scales into volumetric attack territory

A stuffing campaign doesn't have to stay polite. When the request volume gets pushed high enough, the traffic turns into a denial-of-service attack aimed straight at the login page rather than a credential attack. Login infrastructure goes down, and an account takeover attempt turns into a full availability outage, which is a worse day for everyone involved.

Financial services sits at the intersection of both problems. It's a top target for both web and API DDoS attacks and credential stuffing campaigns, with the same high-value login pages drawing both attack shapes. Same attacker economics, same high-value login pages, two different attack shapes converging on the same door.

Defending against this takes network capacity built to absorb volumetric attacks: global anycast routing and scrubbing at real scale. That capacity is the precondition for everything else working, because bot analysis and behavioral detection can't run on traffic the edge has already dropped from being overwhelmed. It's the precondition for everything else working, because bot analysis and behavioral detection can't run on traffic the edge has already dropped from being overwhelmed.

What a defense architecture built for this threat model requires

Credential stuffing now operates across four layers at once: network, transport, application, and identity. A defense that's strong at three of those and absent at the fourth doesn't get partial credit. Attackers go straight for the gap, every time.

Global anycast infrastructure with shared threat intelligence has to sit at the base of the architecture. IP reputation only helps if it's current, and a platform that only sees its own customers' traffic only sees a fraction of any given botnet's activity. On top of that sits machine-learning bot management rather than static rule sets, since rules built to catch last year's bots don't catch this year's AI-driven evasion, and behavior over a session is a far more durable signal than a fingerprint that gets randomized in a line of code.

API-aware controls with rate limits that adjust per session close the gap that generic WAF rules leave open around mobile endpoints and OAuth flows. Breached-credential screening at the authentication layer stops known-compromised logins before the application ever processes them. Volumetric DDoS capacity keeps the rest of the stack standing when a campaign decides to stop being subtle and just flood the door.

None of these pieces substitutes for another. Skipping the network layer because the application layer looks solid is how a well-defended login form still ends up compromised. Stopping credential stuffing means reading the traffic itself for its shape, not just its passwords, and building infrastructure that recognizes that shape before anyone gets close enough to try one.