Credential Stuffing Lab
Every login endpoint is under credential attack — but the same defence does not stop every attack. Work a set of real patterns — distributed stuffing, low-and-slow, password spray, a residential-proxy botnet, MFA fatigue, a weaponised lockout, a freshly-phished valid credential — and for each one deploy the controls that actually address it: MFA, breached-password screening, rate limiting, lockout, device fingerprinting, CAPTCHA, bot/IP reputation, a stuffing-aware WAF. Lockout does not stop spray; MFA does. A breach list cannot flag a valid phished password. Per-IP limits fold against a distributed botnet, and residential proxies beat IP reputation. Over-apply a control and you pay; deploy one that backfires — a lockout DoS, a blanket CAPTCHA that tanks sign-ups — and you pay more. Match the defence to the attack.
The real job. More noise, a tighter clock.
Defend the login endpoint
For each attack, deploy the controls that actually address it — and leave off the ones that do not. Over-applying costs you; deploying one that backfires costs more.
Attack #1
High-velocity distributed stuffing
A breach combo-list replayed across a 50k-IP botnet
A leaked username:password combo-list from an unrelated site is being replayed against your login at huge volume. The traffic is spread across roughly 50,000 source IPs (a botnet), each IP making only a handful of attempts, mostly one correct-password attempt per account. Automated clients, no human in the loop.
- ·~50,000 distinct source IPs, many datacenter / known-bad ASNs
- ·Aggregate request rate is enormous; per-IP rate is low
- ·Credentials are exact pairs from a known third-party breach
- ·≈1 attempt per targeted account (they already have the password)
Deploy controls
Attack #2
Password spray
A few common passwords against thousands of usernames
Instead of many passwords against one account, the attacker tries a handful of very common passwords (Spring2026!, Password1, CompanyName123) against thousands of your usernames — one or two attempts per account to stay under any lockout threshold. Sourced from a small set of IPs/VPNs and aimed at a known tenant (SSO / VPN portal).
- ·Same 3–5 passwords seen across thousands of distinct usernames
- ·Only 1–2 attempts per account (deliberately under lockout limits)
- ·Low source-IP diversity — a few datacenter / VPN addresses
- ·Horizontal: one IP touches hundreds of accounts
Deploy controls
Attack #3
Low-and-slow stuffing
The same combo-list, deliberately throttled to stay invisible
The attacker has the same breach combo-list but plays it slowly: a few attempts per hour per IP, randomised timing, spread over weeks, specifically tuned to stay beneath every velocity and anomaly threshold you have. Low volume, patient, under the radar.
- ·A few attempts per hour per IP; no volume spike ever
- ·Randomised, human-like timing over weeks
- ·Tuned to sit under rate-limit and lockout thresholds
- ·Still replaying known-breach credential pairs
Deploy controls
Attack #4
Residential-proxy botnet
Stuffing laundered through clean home-IP proxies
The stuffing run is routed through a residential-proxy network (compromised home routers / proxyware). Every request exits from a clean, geographically-plausible residential IP, rotated per request, driven by real headless browsers with a CAPTCHA-solver integrated. The point of the service is to defeat IP-based defences.
- ·Clean residential IPs, geographically dispersed, rotated every request
- ·Real browser engines (headless) — valid TLS/JA3, real headers
- ·CAPTCHA-solving service wired in
- ·Still replaying the breach combo-list
Deploy controls
Attack #5
Weaponised account-lockout DoS
The attacker wants your users locked out, not in
The attacker is not trying to get in. They submit deliberately WRONG passwords against a list of known high-value usernames (executives, support, finance) to trip your aggressive "3 strikes → account locked until admin reset" policy and deny those users access — disruption / extortion. Your own lockout policy is the weapon.
- ·Intentionally incorrect passwords — no interest in a successful login
- ·Targeted at a curated list of high-value usernames
- ·Exploiting a hard "lock until admin unlock" policy
- ·Automated, repeating against the same victims
Deploy controls
Attack #6
MFA fatigue / push bombing
They already have the password — now they spam the prompt
The attacker holds a valid username+password (from an earlier stuffing/phishing hit). You have push/SMS MFA. They trigger approval prompts over and over — dozens at 3am — betting the user eventually taps "Approve" out of exhaustion or to make the buzzing stop (MFA fatigue / push bombing).
- ·Password is already valid — the login step succeeds
- ·A burst of repeated MFA push/SMS approval requests
- ·Relies on the human tapping Approve, not on breaking a factor
- ·Approval requests originate from an unrecognised device/geo
Deploy controls
Right control, right attack
Choose controls, then grade. So far 0/6 scenario(s) answered, 0 matched exactly, 0 harmful control(s) staged.
How it is scored
Each scenario is scored on the controls that match the attack.
Leaving an effective control off misses. Deploying an ineffective one is over-application. Deploying a harmful one (lockout DoS, blanket CAPTCHA) is penalised double.
Harder tiers add the subtle attacks where the obvious control is the wrong one — residential proxies vs. IP reputation, valid phished creds vs. breach screening.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based credential-stuffing defence lab: for each login-endpoint attack, deploy the controls that actually address it — and leave off the ones that only look reassuring.
- Attacks span high-velocity distributed stuffing, low-and-slow, password spray, residential-proxy botnets, MFA fatigue, weaponised account-lockout, and freshly-phished valid-credential replay.
- Controls to match: MFA, breached-credential screening, rate limiting / throttling, account lockout, device fingerprinting, CAPTCHA, bot detection / IP reputation, and a stuffing-aware WAF.
- You are graded on matching the right controls, penalised for over-applying ones that do not fit, and penalised harder for deploying ones that backfire — aggressive lockout that becomes a DoS, or blanket CAPTCHA that a solver clears while it kills real sign-ups.
- After grading, every scenario shows why each control does or does not address that specific attack — e.g. per-IP rate limiting is useless against a distributed botnet, and a breach-password list cannot flag a valid freshly-phished password.
Frequently asked questions
What is the Credential Stuffing Lab?
A free, in-browser exercise where you defend a login endpoint against real credential-attack patterns. For each attack scenario — distributed stuffing, low-and-slow, password spray, residential-proxy botnet, MFA fatigue, weaponised lockout, phished-credential replay — you choose which of eight defensive controls to deploy: MFA, breached-credential screening, rate limiting, account lockout, device fingerprinting, CAPTCHA, bot detection / IP reputation, and a stuffing-aware WAF. You are scored on how well your control set matches what actually stops that attack.
How is it graded?
Each scenario has a correct control set. You earn credit for deploying the controls that address the attack, lose points for over-applying controls that do not fit (friction without a matching threat), and lose double for deploying a control that backfires in that scenario — an aggressive lockout that becomes an account-lockout denial-of-service, or a blanket CAPTCHA that a solver service clears while it measurably hurts real sign-ups. A perfect run matches every scenario exactly: every effective control on, every ineffective or harmful one off.
What does it actually teach?
Which control addresses which attack — the part that is easy to get wrong. Account lockout does not stop password spray (spray is engineered to stay under the threshold) and MFA does; a breached-password list stops reused leaked creds but cannot flag a freshly phished valid password; per-IP rate limiting is defeated by a distributed or IP-rotating botnet; IP reputation collapses against residential proxies; CAPTCHA is defeated by solver farms. The lab makes you feel those distinctions by penalising the plausible-but-wrong choice.
Does it run anything or send my data anywhere?
No. There is no login, no network call, no real authentication and nothing uploaded. The attack scenarios and the correct control sets are authored static data bundled with the page, and all scoring runs in your browser — so the lab is deterministic and private. No account, no install.
Who is it for?
IAM, application-security and fraud/abuse engineers who own login endpoints, blue-teamers and SOC analysts triaging authentication attacks, and anyone prepping for a security interview who wants to reason crisply about why lockout fails against spray, why residential proxies beat IP reputation, and why phishing-resistant MFA is the one control that holds against freshly-stolen valid credentials.