The Scale of the Problem

Credential stuffing is no longer a niche threat — it is the dominant automated attack on the authenticated web. Akamai's 2024 Securing Apps research observed roughly 26 billion credential stuffing attempts every month across the networks it monitors, up nearly 50% in 18 months. To put that in perspective, that is more login attempts from attackers than there are legitimate logins across most industries combined.

Imperva's 2024 Bad Bot Report paints a complementary picture: account takeover (ATO) attacks grew 10% year over year, and crucially, 44% of all ATO attacks now target API endpoints rather than user-facing login forms. Attackers have followed developers to the API layer. The Ponemon Institute puts the annual cost of credential stuffing at between \$6 million and \$54 million per organisation, depending on the industry and the severity of the breach.

If you run a website with user accounts, you are being attacked right now. This post explains what credential stuffing actually is, how modern attackers run it, and the layered defences that work — with a particular focus on IP-based signals that let you catch the attack early.

What Credential Stuffing Actually Is

Credential stuffing is the automated testing of leaked username/password pairs against login endpoints. The attacker does not guess passwords; they have the passwords. They obtained them from one of the billions of records exposed in past data breaches — LinkedIn, Yahoo, Dropbox, Collection #1, you name it.

The attacker's assumption is simple and depressingly accurate: people reuse passwords. If a breach from 2019 exposed someone's Netflix credentials, there is a meaningful chance those same credentials also work on their bank, their email, their Shopify store, or their cloud account. The attacker's job is not cryptography — it is logistics. How do you test millions of credential pairs against a target without getting blocked?

This is where the IP layer becomes important.

How the Attack Actually Runs

A modern credential stuffing operation has three pieces:

1. The credential list. This is usually a combo list sold on underground forums, typically containing tens of millions of plaintext email:password pairs scraped from past breaches. A good list is refreshed monthly and filtered to remove already-tried pairs.

2. The automation tool. OpenBullet, SilverBullet, STORM, and Sentry MBA are the popular ones. They let an attacker define a "config" for a specific target site — which endpoints to hit, what payload shape, how to parse the response to distinguish success from failure, and which CAPTCHA solvers to chain in. A single config can be shared across thousands of attackers.

3. The proxy network. This is the part defenders often underestimate. To defeat IP-based rate limiting, the attacker routes their requests through a proxy pool with hundreds of thousands of distinct source IPs. Historically that meant datacenter proxies from cloud providers. Today, it increasingly means residential proxies — traffic tunnelled through compromised or rented consumer devices, making each login attempt look like it is coming from a different household on a different ISP.

The result: a botnet that can submit millions of login attempts per hour, each one from a fresh IP, each one looking (on the surface) like a legitimate user.

Why Traditional Defences Fail

Password complexity requirements do nothing against credential stuffing, because the passwords already work — they were created by real users who then reused them elsewhere.

CAPTCHA slows attackers but does not stop them. Modern solving services charge fractions of a cent per solve and maintain 99%+ accuracy against reCAPTCHA v2 and hCaptcha. Attackers bake solving into their configs and the marginal cost is trivial compared to the value of a successful account.

Rate limiting by IP is defeated by proxy rotation, as discussed above. If you only allow 5 login attempts per IP per minute and the attacker has 50,000 IPs, they can still submit 250,000 attempts per minute without tripping a single rate limit.

Fingerprinting (user-agent, device, browser quirks) helps, but sophisticated tools rotate fingerprints alongside IPs and can match realistic distributions sampled from real browser telemetry. Fingerprinting is a useful layer, not a complete defence.

What actually works is multi-signal detection that looks beyond the single request and factors in the network origin of each attempt.

The IP Intelligence Layer

IP data is the one thing attackers cannot fully fake. They can rotate IPs, but every IP they use belongs to a real network — and real networks have characteristics that expose them when you look closely.

Datacenter IPs — even when layered through commercial VPNs — are a strong signal. Almost no legitimate login to a consumer SaaS product originates from an AWS EC2 instance or a Hetzner VPS. Blocking or challenging logins from classification.is_datacenter: true ASNs catches a large fraction of attacks with minimal collateral damage.

Residential proxy detection is harder but possible. A residential proxy pool has telltale behavioural patterns: many distinct identities logging in from the same residential IP over short windows, simultaneous sessions in geographically incompatible locations, and high velocity of traffic from ISPs that normally see low volumes. Specialised IP reputation feeds track known residential proxy networks and flag them.

Threat feed correlation — IPs that have previously shown up in scraping, spam, or credential stuffing against other sites tend to reappear in new attacks. A shared threat database where sites contribute observed attacker IPs is one of the fastest ways to block returning offenders.

Community scoring — Predax's community threat network aggregates WAF and login-failure events from every protected site in real time. When one customer reports blocks for an IP, every other protected site gets an elevated risk score for that IP within seconds. This is how you catch a campaign in its early stages rather than after it has already burned through your user base.

A Layered Defence Playbook

The strongest credential stuffing defence is four layers deep. Each layer is incomplete on its own; together they stop the overwhelming majority of attacks at acceptable false-positive rates.

Layer 1: Block known-bad IPs pre-auth. Before the password is even checked, run the source IP through an IP reputation API. If the IP is Tor, a commercial VPN datacenter, or has a community block count above zero, reject the request with a generic error. This eliminates 40–60% of credential stuffing traffic with essentially zero false positives on real users. Predax's /check/ip endpoint returns in ~5ms cached so this adds no meaningful latency.

Layer 2: Challenge medium-risk traffic. For requests from datacenter-ish ASNs, residential proxy networks, or high-velocity IPs, require step-up authentication — a CAPTCHA, an email OTP, or a WebAuthn prompt. Legitimate users on corporate VPNs or hotel Wi-Fi pass the challenge without friction; automated attackers stall out on the solve cost.

Layer 3: Detect failures, not just successes. Most credential stuffing runs burn through failed attempts hitting "wrong password" for 99% of the list. Monitor the failure rate per IP, per /24 subnet, and per ASN. When failure rates spike, rate-limit that subnet aggressively even if individual IPs haven't tripped their own limit. Trigger alerts when sustained campaigns exceed baseline.

Layer 4: Invalidate compromised passwords proactively. When a user's email appears in a new breach (haveibeenpwned has a free API for this), force a password reset on their next login. You cannot stop every attack, but you can stop the same password from being weaponised twice.

What Predax Returns for Credential Stuffing Defence

The single /check/ip call exposes every signal you need:

{
  "ip": "185.220.101.1",
  "version": 4,
  "classification": {
    "risk_score": 92,
    "risk_level": "high",
    "is_vpn": true,
    "is_proxy": false,
    "is_tor": true,
    "is_datacenter": true,
    "flags": ["tor", "vpn", "datacenter"]
  },
  "network": {
    "asn": 4224,
    "as_name": "Tor exit node"
  },
  "location": {
    "country_code": "DE"
  }
}

A sensible default: classification.risk_score >= 70 means hard-block; classification.risk_score >= 40 or any classification.flags containing community means challenge. Tune to your false-positive tolerance.

Monitoring and Response

Measure everything. The metrics that matter: login attempts per IP subnet over time, failure rate over time, percentage of login attempts from datacenter vs residential, community block count for IPs hitting your login endpoint. Build a simple dashboard. When any of these move, you are either under attack or the attacker is trying a new pool.

When you detect a campaign, block early and widely. A /24 block that catches 50 legitimate users is worth it to stop a campaign that would otherwise compromise thousands of accounts. Notify affected users proactively if you see any successful logins from suspicious IPs.

Credential stuffing is a volume game. The attacker's cost per attempt is a fraction of a cent; your cost per compromised account is much higher. The defender's job is not to stop 100% of attempts — it is to raise the cost per compromised account high enough that you are no longer worth targeting.

Related guides

• Account takeover prevention — the natural next-step playbook once stuffing has succeeded.
• Stop fake signups — same attacker, different funnel stage.
• How IP risk scoring works — the score behind the rate-limit rules in this guide.
• How to detect VPN users — stuffing campaigns almost always rotate via VPN/proxy infrastructure.

See pricing to put IP-based stuffing defence in front of your login endpoint today.