Credential Stuffing
Also known as: Credential replay, Account takeover (ATO) via reused passwords, List cracking
An automated attack that replays username and password pairs leaked from other breaches against your login, succeeding wherever people reused a password.
Watch it in 60 seconds
How it works
Credential stuffing is the direct consequence of password reuse. When one site is breached, the leaked username and password pairs are collected into lists and replayed against unrelated sites, because many people use the same password in more than one place.
The attack is automated and distributed. Tooling tries each pair once, spread across thousands of IP addresses and residential proxies to stay under per-IP limits, so the tell is not many attempts against one account but a few attempts against very many accounts.
Most attempts fail, and that is expected. The attacker only needs the small percentage where a password was reused. Every success is a valid login, so it produces no malware and no exploit, which is why identity signals, not endpoint signals, catch it.
Once inside, the attacker validates the account, harvests value, and often sells confirmed working credentials. Because the login itself is legitimate, detection depends on behaviour: the rate and spread of failures, impossible travel, and new devices.
Walk through it
Target: Harborline Retail (you are the identity SOC analyst)
Stage 1: A wall of failed logins
Overnight the login service logged a huge jump in failures. Before you page anyone, work out what kind of attack this is. Read the spread, not just the count.
Spot it
- Failed-login volume spikes with a very high ratio of distinct usernames to attempts.
- Roughly one attempt per account, spread across thousands of source IPs or residential proxies.
- Elevated failures followed by a small number of successful logins from new devices or locations.
- Successful logins showing impossible travel or a user-agent not seen for that account before.
- A high share of attempted usernames appearing in known breach corpora.
Authentication service
ts=2026-10-11T02:14:09Z event=login result=fail user=a.ng@corp ip=203.0.113.44 ua=python-requests/2.x
ts=2026-10-11T02:14:09Z event=login result=fail user=b.ortiz@corp ip=198.51.100.9 ua=python-requests/2.x
ts=2026-10-11T02:41:55Z event=login result=success user=c.patel@corp ip=203.0.113.44 newdevice=truesplSplunk — distinct-username spike (stuffing signature)
index=auth action=failure
| bin _time span=5m
| stats dc(user) AS users dc(src_ip) AS ips count AS attempts by _time
| where users > 500 AND attempts/users < 3Many users, few attempts each, is the stuffing shape; brute force inverts the ratio.
kqlSentinel — success right after a failure wave, new device
SigninLogs
| where ResultType == 0 and DeviceDetail.isCompliant == false
| join kind=inner (SigninLogs | where ResultType != 0 | summarize fails=count() by UserPrincipalName) on UserPrincipalName
| where fails > 5Stop it
Turn on MFA, ideally phishing-resistant
A replayed password alone cannot complete a login when a second factor is required. This is the control that breaks credential stuffing even against reused passwords.
Screen passwords against breach corpora
Reject known-breached passwords at set and reset time so the pairs attackers hold stop matching. This attacks the root cause, password reuse, directly.
Rate-limit and add bot defences
Per-account and per-IP throttling, device fingerprinting, and challenges on anomalous volume raise the attacker's cost. Spread across proxies, per-IP limits alone are weak, so combine them with velocity rules across accounts.
Velocity rule (pseudo-policy)
Hardened
IF distinct_usernames_per_5min > 500 AND attempts_per_username < 3
THEN require_captcha AND step_up_mfa AND alert_socTrigger on the stuffing shape (many users, few tries) rather than per-IP counts.
- Require MFA for all accounts; prefer FIDO2 or passkeys.
- Block or challenge logins from known proxy and datacenter IP ranges.
- Monitor for impossible travel and new-device logins and step up authentication.
- Notify users on new-device sign-in and offer one-click session revocation.
- Never confirm whether a username exists in error messages.
If it already happened
Throttle and challenge the anomalous login volume, block the worst source ranges, and force step-up MFA on affected login flows.
Identify successful takeovers, revoke their sessions and tokens, and force password resets for confirmed and at-risk accounts.
Restore access through a verified channel, enable MFA on recovered accounts, and confirm no fraudulent changes were made during the takeover window.
Add breached-password screening if absent, tune the velocity detections, and report confirmed account takeovers per policy.
Check yourself
1. Authentication logs show about one failed attempt each across 40,000 usernames from 12,000 IP addresses. Which attack best fits?
2. Which single control most reliably stops a correctly replayed password from completing a login?
3. Why does per-IP rate limiting alone often fail against credential stuffing?