Password Spraying (T1110.003) is a sub-technique of Brute Force in the credential access tactic. MITRE lists containers, ESXi, IaaS, identity providers, Linux, network devices, Office suites, SaaS, Windows and macOS.
It flips the usual approach. Instead of many passwords against one account, which trips lockout, it tries one or a few common passwords against many accounts.
How attackers use it
MITRE describes using a single password, or a small list of common ones, that may satisfy the domain's complexity policy. Logins are attempted with that password across many accounts to avoid the lockout that brute forcing a single account would cause.
The usual targets are management services on common ports, as in other brute force techniques: SSH, Telnet, FTP, SMB, LDAP, Kerberos, RDP, HTTP and HTTPS management services, MSSQL, Oracle, MySQL and VNC. Adversaries may also target single sign-on and cloud applications that use federated authentication, and externally facing email such as Office 365.
Two points from MITRE matter for detection:
- To avoid detection thresholds, adversaries may deliberately throttle attempts. Slowing down defeats rules that count failures per minute.
- They may use LDAP and Kerberos authentication attempts, which are less likely to trigger high-visibility events such as Windows logon failure event ID 4625 that failed SMB connections commonly produce.
How to detect it
MITRE's strategy is Distributed Password Spraying via Authentication Failures Across Multiple Accounts. Its analytics cover many platforms:
- A high volume of authentication failures using one password, or a small set, across many accounts within a time window.
- Failures across different accounts through SSH or the PAM stack in a short window.
- Failed logins across users with common password patterns.
- Sign-in failures across SSO and SaaS apps from the same address using the same password against multiple identities.
- Repeated use of default or common passwords against several accounts on routers and switches.
- Failed attempts against container APIs, control planes or login shells across many user names.
- Failures across mailboxes using identical or common passwords, such as against Outlook Web Access.
The shape to build is: group failures by source, count distinct accounts, and flag a source that touches many accounts with few tries each. Then widen the window to catch throttled activity. A source that tries one account per day for weeks is still a source.
Include the logs that attackers prefer, not only SMB. Kerberos pre-authentication failures and LDAP bind failures belong in your pipeline.
How to reduce the risk
MITRE lists three mitigations:
- Account use policies. Set lockout after failed attempts, noting that a policy that is too strict can create denial of service. Use conditional access to block non-compliant devices and logins from outside defined IP ranges, and consider blocking risky requests such as those from anonymizing services or proxies.
- Multi-factor authentication, including on externally facing services.
- Password policies following NIST guidelines. Banning common passwords directly counters spraying.
Because spraying avoids per-account lockout, MFA and banned common passwords do the most work.
Why spraying works against well-run organizations
Spraying is aimed at a statistical weakness, not a technical one. In any large set of accounts, some people will have chosen a predictable password that still passes the complexity rules. MITRE's own example, a password like Password01, shows how a value can satisfy a complexity policy and still be one of the first things anyone would try.
That has two consequences for defenders.
First, the number of accounts matters. The more accounts an attacker can list, from directory data, email addresses or earlier reconnaissance, the better the odds. Reducing what is publicly guessable, such as consistent and predictable username formats on public sites, helps at the margin, but it is not a control you can rely on.
Second, the failure is spread out. Each account sees one failed login, which looks like a user mistyping. Only a view across accounts shows the pattern. This is why per-account alerts miss it and why detection has to group by source, by password pattern where your logs allow, and by time window.
A reasonable response plan when you do see a spray:
- Identify the source addresses and the accounts they touched.
- Find any successes from those sources, since those accounts are now suspect.
- Force a password reset and review sessions and registered MFA devices for those accounts.
- Block or challenge the sources through conditional access or at the edge.
- Look back across a longer window for slower, throttled activity from related sources.
Check your own environment
- Do you detect many accounts failing from one source, not just many failures on one account?
- Is your detection window long enough to see throttled attempts?
- Are Kerberos and LDAP failures logged and searchable?
- Is MFA required on webmail, VPN and SSO?
- Do you block known common passwords at creation?
# Windows (PowerShell): recent failed logons with account names for a quick look at spread (needs admin)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 200 |
ForEach-Object { $_.Properties[5].Value } | Group-Object | Sort-Object Count -Descending | Select-Object -First 10
Many different names with count 1 or 2 each is the shape of spraying.
Quick check
Why does spraying avoid lockout?
It tries one or a few passwords per account across many accounts, so no single account reaches the lockout threshold.
How can an attacker evade a failures per minute rule?
By throttling, spacing attempts out. MITRE also notes LDAP and Kerberos attempts are less likely to raise event 4625.
Which mitigations do the most work against spraying?
MFA and password policies that block common passwords, since per-account lockout does not stop it.
Sources
- MITRE ATT&CK, Brute Force: Password Spraying (T1110.003)
