Skip to content
Start with Identity
Join free
SWI-T005 · Authentication

Password spraying

Instead of guessing many passwords against one account and triggering a lockout, the attacker guesses a few common passwords against many accounts, staying under the threshold for each one.

WidespreadModerate
First observed: 2015ATT&CK T1110.003 ↗

How it works

Standard brute forcing tries many passwords against one account and quickly hits an account lockout policy. Password spraying inverts the approach: the attacker picks a small list of common or seasonal passwords ("Summer2026!", "Password1", a company name plus a year) and tries each one against a large list of usernames. Each individual account sees only one or two attempts per round, well under any reasonable lockout threshold, and the attacker waits between rounds so the per-account counter resets. Given a large enough population, a small percentage of users will have chosen one of the sprayed passwords, and that is enough for at least one hit.

The username list is the easy part. Corporate email formats are predictable, employee names come from LinkedIn and breach data, and many cloud identity providers will confirm whether an account exists through differences in their login or discovery responses, so the attacker can validate the list before spraying it. Open-source tooling automates the rest: rotating source IPs across cloud providers or residential proxies, pacing attempts, and recording which accounts accepted the password.

The attempts go wherever a password is accepted without a second factor or a device check. In Microsoft Entra ID and Microsoft 365 that historically meant legacy protocols (IMAP, POP, SMTP AUTH, Exchange ActiveSync and older Office clients) that cannot perform modern MFA, plus any account excluded from conditional access. VPN portals, Citrix gateways, ADFS extranet endpoints and SaaS apps with local passwords are the other common targets. Attackers aim first at legacy or forgotten accounts: old test tenants, functional mailboxes, service accounts, and accounts predating a password policy change, because these are the accounts most likely to sit outside MFA enforcement and outside routine review.

A successful guess is then used directly, or the attacker moves on to MFA fatigue if a push factor stands in the way.

Why it works

Password policies and lockout thresholds are built around single-account brute force, and spraying stays outside the pattern those defenses were designed to catch. The control assumption that fails is that the lockout counter is the defense. It is per-account by design, and an attack distributed across thousands of accounts never fills any single counter. Smart lockout features that track familiar and unfamiliar locations separately help, but a slow spray from many IPs still stays under them.

The attack also exploits a population-level certainty rather than a single-target guess. With enough usernames, a handful of people will always have picked a weak or predictable password, regardless of how strong the organization's complexity rules look on paper. Complexity rules even encourage the pattern: "Season + Year + !" satisfies most of them.

The deeper failure is coverage. Spraying only matters where a correct password is sufficient on its own, so its success rate is a direct measurement of how many login paths and accounts are outside MFA. The technique is cheap, requires no exploit, and scales to any directory an attacker can enumerate, which is part of why it recurs against organizations that consider themselves otherwise well defended.

How to detect it

  • Entra sign-in logs. In the SigninLogs table, count distinct UserPrincipalName values per IPAddress or AutonomousSystemNumber with ResultType 50126 (invalid username or password) in a short window. A rise in 50053 (account locked, or sign-in from a known malicious IP) across many users is a second signal. Check ClientAppUsed for legacy protocols, which are where many sprays land.
  • Entra ID Protection. The passwordSpray risk detection is raised only when an attacker successfully validates a user's password, so treat every instance as a confirmed compromise of that password rather than an attempt.
  • Okta. In the Okta System Log, security.threat.detected events mark requests from IPs that Okta ThreatInsight classifies as malicious, including brute force and password spray. Also watch user.account.lock volume across many users, and security.breached_credential.detected for logins using a password known from a breach.
  • AWS. CloudTrail ConsoleLogin events with responseElements.ConsoleLogin set to Failure and errorMessage "Failed authentication", grouped by sourceIPAddress across distinct user names. A later Success with additionalEventData.MFAUsed set to No is the event to page on.
  • Google Workspace. The Login audit records login_failure and login_success events per user with the source IP. Group failures by IP across users, and review suspicious_login events Google raises on its own.
  • Dormant accounts that suddenly succeed. Successful logins on accounts that have not authenticated in months, particularly legacy, test, or service accounts.

Be honest about the limits: shared VPN egress points, campus networks, and enterprise proxies produce many logins from one IP as ordinary behavior, and modern sprays rotate across hundreds of cloud IPs so no single source looks heavy. Per-IP thresholds alone miss distributed sprays. The distinguishing signal is broad targeting with a low per-account attempt count, measured across the whole tenant, and it is far more useful to alert on the one success than on the thousand failures.

How to stop it

  • Enforce MFA on every login path with no exceptions, and hunt for the accounts excluded from policy, since spraying's favorite targets are the accounts MFA forgot. Block legacy authentication protocols that cannot do MFA.
  • Move to phishing-resistant MFA, starting with privileged and administrative accounts, so a sprayed password alone is never sufficient and cannot be pushed through with an approval prompt. The MFA matrix shows which SaaS apps let admins require it.
  • Remove interactive sign-in from functional and service accounts, or put them behind MFA and a network restriction. Rotate any default or provisioned password that was never changed.
  • Ban common and previously breached passwords at creation and reset time. NIST SP 800-63B requires verifiers to reject passwords on a blocklist of commonly used, expected, or compromised values, rather than relying on composition rules.
  • Decommission unused and legacy tenants and accounts. An account nobody remembers is exactly the account without current controls. See orphaned account abuse.
  • Tune lockout and threat-intelligence blocking (Entra smart lockout, and Okta ThreatInsight set to enforce rather than only log) so that obviously malicious sources are refused before they reach the password check.

Seen in the wild

In the Identity Breach Report 2026, 15 of the 16 incidents with MFA absent began with a password that simply worked, two of them sprayed; the sixteenth was a self-registered account at DigiCert. The report's eighth control, MFA on every login path with no exceptions, is the one that addresses them.

Sources

Related identity CVEs and breaches

Last reviewed By SWI Community TeamSuggest a correctionHow we research

In the Identity Breach Database

Real incidents in our sourced breach database where this technique was used.

Browse the full database

Seeing this technique used differently, or have a detection rule that works better? Email community@startwithidentity.com. See all briefs in the technique catalog, or volunteer as a CVE Analyst.
Mapped to MITRE ATT&CK where a technique ID exists. Independent, community-driven analysis, not a substitute for the ATT&CK knowledge base. See the disclaimer.