What Is Credential Stuffing?

Last verified on Nov 8, 2026.

Credential stuffing is an automated attack that takes username and password pairs stolen from one service and tries them on another. OWASP defines it as mass log in attempts used to verify the validity of stolen username and password pairs. It works because people reuse passwords.

MITRE ATT&CK describes the same technique (T1110.004): credentials from breach dumps of unrelated accounts are used to get into target accounts through credential overlap.

How It Differs From Brute Force and Spraying

The OWASP cheat sheet draws the lines between three attacks that are often confused:

OWASP's automated threat entry adds the key point: unlike credential cracking, credential stuffing does not involve brute-forcing or guessing values. Each pair is a real credential that worked somewhere. The attacker only learns whether it works here.

The pairs may come from the attacker's own breach, a criminal marketplace, or public breach data. OWASP lists other names for it, including account checking and credential replay. A successful hit leads to account takeover.

What It Looks Like in Logs

Every attempt appears as a normal failed login, so one line is unremarkable. The shape is in the aggregate. ATT&CK's detection note describes multiple failed authentication attempts using distinct username and password pairs from a single IP address or session in a short window. Illustrative application log lines:

{"ts":"2026-11-08T02:14:09Z","event":"login","outcome":"failure","user":"a.ramirez@example.com","ip":"203.0.113.50","ua":"python-requests/2.31"}
{"ts":"2026-11-08T02:14:09Z","event":"login","outcome":"failure","user":"j.okafor@example.com","ip":"203.0.113.50","ua":"python-requests/2.31"}
{"ts":"2026-11-08T02:14:10Z","event":"login","outcome":"failure","user":"m.tanaka@example.com","ip":"203.0.113.50","ua":"python-requests/2.31"}
{"ts":"2026-11-08T02:14:11Z","event":"login","outcome":"success","user":"p.nguyen@example.com","ip":"203.0.113.50","ua":"python-requests/2.31"}

Three things stand out: many distinct usernames from one address, one attempt per username (a person mistyping retries the same account), and a success among the failures. A query for that shape:

SELECT ip,
       count(*) AS attempts,
       count(DISTINCT user) AS accounts,
       count(*) FILTER (WHERE outcome = 'success') AS successes
FROM login_events
WHERE ts > now() - INTERVAL '15 minutes'
GROUP BY ip
HAVING count(DISTINCT user) >= 20
ORDER BY accounts DESC

Distinct accounts per source is the field to watch. Attackers who rotate IPs defeat a per-IP count, so also chart failures per minute across the whole login endpoint and distinct usernames with no prior success. The successes after a burst are the accounts to treat as taken over first. The full set of login checks, including spraying and impossible travel, is in authentication anomalies. For automation signals such as user agents and request rates, see bots and scraping and abuse and fraud.

Defenses

OWASP calls multi-factor authentication by far the best defense against most password attacks, and notes it also helps against credential stuffing and password spraying. Where MFA cannot be required for everyone, the cheat sheet suggests asking for a second factor only in suspicious cases: a new device or IP address, an unusual country, an address on a denylist or tied to anonymizing services, an address that has tried many accounts, or traffic that looks scripted.

ATT&CK's mitigations add:

• Set lockout after failed attempts, but know that strict lockout can create a denial of service when attackers lock many accounts out.
• Follow NIST guidelines for password policy.
• Proactively reset accounts known to be in breached credentials.
• Use MFA on externally facing services.

OWASP also recommends layering defenses and measuring each one. Client-side controls such as device fingerprinting can be bypassed, so each defense should report how much attack volume it detected and mitigated, filterable by IP.

Where It Hits Besides Web Logins

ATT&CK notes that stuffing commonly targets management services over standard ports, among them SSH (22), Telnet (23), FTP (21), SMB (139 and 445), LDAP (389), and Kerberos (88). It also warns that stuffing is risky for the attacker because it causes many authentication failures and lockouts, depending on policy. That noise is your opening.

After a breach elsewhere, a spike in login failures against your service is a reason to check. cve.now, a free feed from Sazabi, lists vendor breaches as early warnings, which is one way to hear about them.

In Sazabi

Sazabi, an AI-native observability and security platform, can receive the Okta System Log to monitor sign-ins, MFA changes, and admin actions, so failed-login bursts and the successes after them sit in the same place as your other logs.