Credential Stuffing (T1110.004) is a sub-technique of Brute Force, under credential access. MITRE lists containers, ESXi, IaaS, identity providers, Linux, macOS, network devices, Office suites, SaaS and Windows as platforms.
The attacker does not guess. They already hold real username and password pairs from somewhere else, and they test whether your users reused them.
How attackers use it
MITRE describes using credentials from breach dumps of unrelated accounts to gain access to target accounts through credential overlap. Large numbers of username and password pairs are sometimes dumped online after a website or service is compromised. They are useful to an adversary because people tend to reuse the same password across personal and business accounts.
MITRE also notes the approach is risky for the attacker, since it can produce many authentication failures and account lockouts depending on login failure policy.
The usual targets are management services on common ports: SSH, Telnet, FTP, SMB and NetBIOS, LDAP, Kerberos, RDP, HTTP and HTTPS management services, MSSQL, Oracle, MySQL and VNC. MITRE adds single sign-on and cloud applications that use federated authentication, and externally facing email such as Office 365.
The key difference from spraying is that each attempt uses a distinct, real pair, so lists of common passwords and banned password lists do not help much. The only defenses are knowing which pairs are exposed, MFA, and limiting reuse.
How to detect it
MITRE's strategy is Credential Stuffing Detection via Reused Breached Credentials Across Services. Its analytics span many platforms:
- Many failed authentications with distinct username and password pairs from one address or session in a short time, against services such as RDP or SMB.
- Rapid login failures across different users from one address against SSH or PAM.
- A burst of failures with rotating usernames against loginwindow or a remote management service on macOS.
- The same address trying known breached username and password combinations across identities in cloud identity platforms such as Entra ID, Okta or Duo.
- Many sign-in failures against cloud apps using pairs leaked from unrelated domains.
- Router, firewall or syslog entries showing failures with unique usernames from one source.
- Attempts against the Kubernetes API or containerized login shells using leaked credentials.
- Attempts against Outlook Web Access, Microsoft 365 or Exchange from a single client address with multiple failures.
- A burst of failed logins across virtual machine instances in public cloud.
The common signature is a single source cycling through many different usernames. Group failures by source address and ASN, count distinct users, and look at the ratio of failures to successes. A low but nonzero success rate is typical, because only some reused pairs are valid.
Also watch for successes after a burst. Those are the accounts that need action first.
How to reduce the risk
MITRE lists four mitigations:
- Multi-factor authentication, including on externally facing services. A reused password alone then fails.
- User account management. Proactively reset accounts known to be part of breached credentials, either immediately or after detecting brute force attempts.
- Account use policies. Lockout after failed attempts, balanced against denial of service, plus conditional access that blocks non-compliant devices and logins outside defined IP ranges, and blocking of risky requests such as those from anonymizing services.
- Password policies following NIST guidelines.
The second item takes a process. Subscribe to a breach notification source, compare exposed addresses against your directory, and force a reset for matches. NIST guidelines include checking new passwords against lists of known compromised values, which closes the gap at creation time.
Credentials your own teams leak count too. API keys, tokens and passwords committed to repositories and build logs are the same kind of exposure, and they get stuffed and replayed in the same way.
Check your own environment
- Do you know which of your accounts appear in public breach data?
- Do you block passwords found in known breach lists at password creation?
- Is MFA enforced for every external login, including legacy protocols?
- Can you detect one source cycling through many usernames?
- Are legacy authentication paths that skip MFA turned off?
- Do your repositories and pipelines get scanned for committed secrets?
# Windows (PowerShell): group recent failed logons by source address (needs admin; IpAddress is property index 19 on event 4625)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 500 |
ForEach-Object { $_.Properties[19].Value } | Group-Object | Sort-Object Count -Descending | Select-Object -First 10
One address with a very high count and many usernames is the shape to chase.
Try it yourself
Exposed secrets in code are a close cousin of exposed passwords in breach dumps. This demo shows how secrets scanning finds credentials before they leave a repository.
Click through it at your own pace, or open it full screen.
Quick check
What makes credential stuffing different from password spraying?
Stuffing uses real username and password pairs from breaches of other services, one per account, while spraying tries a few common passwords across many accounts.
Why is MFA so effective here?
The attacker holds a real password that may be valid, so only a second factor stops the login.
What is the first account action MITRE suggests?
Proactively reset accounts known to be in breached credentials, either right away or after detecting brute force attempts.
Sources
- MITRE ATT&CK, Brute Force: Credential Stuffing (T1110.004)
