Password spraying is a login attack that tests a small set of likely passwords against many accounts. Instead of hammering one user until an alert fires, the attacker spreads the work across an organization and may pause between attempts. A quiet account-level dashboard can therefore coexist with a noisy organization-wide campaign.
This guide expands the Password Spraying branch of the Cyber Threat Tree. The central defensive idea is to correlate across identities and access paths, then reduce the opportunities for a successful guess to become a usable session.
How password spraying differs from other guessing attacks
MITRE ATT&CK T1110.003 describes password spraying as a brute-force sub-technique. The practical distinction is the distribution of guesses. A traditional targeted guessing attempt concentrates on an account; spraying concentrates a small password set across accounts. Credential stuffing instead reuses already exposed username-and-password pairs.
These patterns can overlap in one campaign. Classify the behavior to guide detection, not to force every event into a perfect box. A successful sign-in following a broad pattern of failures deserves investigation even if the exact password-guessing tool is unknown.
Map the authentication paths that matter
List externally reachable identity providers, VPNs, webmail, remote administration, application logins, and legacy interfaces. Include service accounts, dormant users, contractors, and separate local accounts on systems that appear to use central SSO.
For each path, record who owns it, whether MFA is enforced, what protocols remain enabled, and which logs are available. Test the actual requirement for a second factor. An enrollment report does not prove enforcement on every protocol, and an old endpoint can become the convenient side door around a newer sign-in policy.
Detect password spraying across accounts
Aggregate failures by time window, source characteristics, application, protocol, device context, and distinct targeted identities. Look for a source touching many users with few attempts each, similar patterns across several sources, or coordinated failures across multiple applications.
Do not expect authentication logs to reveal which password was guessed. Never add password collection to obtain that visibility. Investigate observable behavior instead: account breadth, timing, failure reasons, client patterns, and any later successful session.
Use both short and longer observation windows. A campaign can be slow enough to avoid a short burst rule, while a legitimate migration can produce a sudden spike. Correlate detection with change records and expected client behavior before blocking a business-critical source range.
Reduce the value of a successful password guess
Enforce MFA on reachable access paths, prioritizing phishing-resistant methods where the environment supports them. Microsoft’s identity security guidance places strong authentication within a broader identity-protection strategy. Protect enrollment and recovery too; a strong primary sign-in policy loses value if account recovery is weaker.
Retire authentication interfaces that are not needed, remove stale accounts, and use password controls that discourage common and compromised choices. Rate limits and lockout rules should be evaluated together. OWASP’s authentication guidance discusses throttling and lockout design; an aggressive global lockout policy can create an availability problem that the attacker is happy to trigger.
MFA reduces account-takeover risk but does not establish that a successful password guess is harmless. Review what the application logs consider a success and whether a session or token was actually issued. Related risks, including stolen session cookies, need separate controls.
Respond to suspected compromise
Preserve identity and application logs, establish a common timeline, and identify targeted accounts. Then separate unsuccessful guessing from evidence of usable access. Examine unfamiliar sessions, devices, mailbox changes, application consent, and administrative actions appropriate to the affected service.
For confirmed or reasonably suspected account compromise, use the platform’s session-revocation and recovery procedures from a trusted administrative session. Reset affected credentials, review recovery methods and enrolled factors, and investigate persistence. A password reset alone may not terminate every token or reverse attacker-made changes.
Apply source restrictions carefully. Distributed attacks can move between networks, and a shared provider address can carry legitimate traffic. Document why a block is necessary, its expected impact, and when it will be reviewed.
Validate the detection safely
Use an approved test plan with designated test accounts, a small controlled request volume, and an explicit stop condition. Coordinate with identity operations and the service desk. The goal is to confirm telemetry and response, not to reproduce a large attack against real employees.
Verify that the analyst can see the campaign across accounts, distinguish an expected failure from a later success, and identify the owner who can contain access. Save the test result and tune the rule with observed false positives rather than selecting an impressive-looking threshold.
Password spraying checklist
- Inventory all login paths and verify actual MFA enforcement.
- Correlate failures across users, applications, and meaningful time windows.
- Keep passwords and other secrets out of logs.
- Reduce legacy access, common-password exposure, and stale accounts.
- Investigate successful sessions and revoke access where compromise is suspected.
- Exercise detection with approved test accounts and record the outcome.
Password spraying exploits a gap between how attackers distribute requests and how defenders count them. Close that gap with organization-wide visibility and enforced controls, rather than asking every account to look suspicious on its own.
