Password Spraying: How Attacks Work and How to Detect Them

Password spraying is a brute-force technique in which an attacker tries one or a few common passwords against many different accounts before moving on to the next password. The attacker caps the guesses per account to stay under its lockout threshold. If a system locks users after 10 failed attempts, an attacker may try nine passwords per username.

Password spray attacks account for over 99% of the cloud initial access efforts Microsoft observed for its 2026 Digital Defense Report.

TL;DR:

• Sprays are paced to stay below per-account thresholds, so lockout policy alone rarely stops them.
• Detection works when it counts how many distinct accounts fail per source, network, or client fingerprint, over short and long windows, and compares failures with successes to filter out shared office networks.
• Sprays succeed on password-only paths, such as legacy protocols, OAuth sign-in flows that MFA policy doesn't cover, and VPN access without MFA. Closing those paths comes before tuning alerts.
• A successful sprayed sign-in is an incident, and deciding whether the attacker reached anything takes the mailbox, device, OAuth, and business context that sign-in logs don't hold.

How Password Spraying Works

Attackers start by gathering valid usernames from company websites, social media, and earlier breaches. In a May 2025 comparison against the Have I Been Pwned database, Microsoft found that 85% of usernames targeted in spray attacks appeared in known credential leaks.

Most spray attacks submit only a few of the weakest known passwords per account, enough to find an easy account quickly without tripping detection thresholds. Banned-password lists, such as the global list behind Entra Password Protection and the blocklist NIST requires, target those same passwords.

Attackers often target a few identities from each IP over long periods, then automate across many IPs to reach scale. The open-source o365spray tool builds that rotation in. It supports FireProx proxies to get past rate limits based on IP address, and it can cycle through more than 4,800 user agents.

CovertNetwork-1658, also called Quad7, is a network of compromised routers in homes and small offices. When Microsoft reported on it in 2024, most were TP-Link devices, and in about 80% of cases the network made one sign-in attempt per account per day, too few for per-IP or per-account failure counts to catch.

Password Spraying vs Brute Force vs Credential Stuffing

MITRE ATT&CK files all three under T1110 Brute Force, as Password Guessing, Password Spraying, and Credential Stuffing, and each needs its own detection logic.

In OWASP's credential stuffing cheat sheet, brute force tries many passwords against one account, spraying tries a single weak password against many accounts, and stuffing replays username and password pairs stolen in another site's breach.

Their log footprints differ too, though identity provider logs rarely record the password tried, so in practice the username and source patterns carry the detection.

Adversaries are increasingly combining spraying and stuffing, with target and password lists built from infostealer and breach data. Hybrid attacks also spray incremented versions of leaked passwords, such as Password1!, Password2!, Password3!, and so forth.

Each technique defeats a different control and leaves a different trail in the logs:

‍

Where Spraying Lands: Entra ID, Okta, and VPN Gateways

Sprays land on legacy and non-interactive paths into Microsoft 365, on identity provider sign-in endpoints where MFA isn't enforced, and on VPN gateways without MFA.

Microsoft Entra ID and Microsoft 365

Legacy protocols such as IMAP, POP, and SMTP with basic authentication don't support MFA, so blocking basic authentication shuts those sprays out.

The resource owner password credentials (ROPC) flow opens a similar gap by trading a username and password directly for a token. Microsoft advises against ROPC because the flow is incompatible with MFA, and the IETF's current OAuth security best practice says the grant must not be used.

ROPC sign-ins fail for users whom policy requires to complete MFA, so the exposure covers every account and app that policy leaves out. Between June 12 and June 26, 2026, a password spray aimed at Azure CLI sign-ins made more than 81 million login attempts against Huntress customers' accounts and compromised at least 78 Microsoft accounts.

Many affected organizations had Conditional Access policies requiring MFA that didn't cover the ROPC flow, so MFA never triggered, and eight affected businesses had no MFA policy at all.

The attacker appeared to replay old breached credentials that had never been rotated, picking them by how common each password was in leaked credential lists. The replay is credential stuffing by definition, so the campaign was a spraying and stuffing hybrid.

Entra smart lockout defaults to a threshold of 10 failures in public tenants and three in US Government tenants. The first lockout lasts one minute and grows longer if the account keeps locking, and familiar and unfamiliar locations keep separate counters.

Smart lockout slows guessing against any one account, which only partly blunts a spray spread across many. Microsoft's Zero Trust guidance says a threshold above 10 gives too little protection against automated sprays, so keep it at 10 or lower.

Okta

Okta ThreatInsight evaluates sign-in requests before authentication against IP activity aggregated across Okta orgs, and Okta doesn't guarantee it will catch every malicious IP. Configuration decides much of what it blocks.

During a 2024 credential-stuffing wave, the orgs where suspicious requests reached authentication were nearly always on the older Classic Engine, ran ThreatInsight in audit-only mode, and allowed requests from anonymizing proxies.

Okta also enforces a per-username limit of four requests per second on /api/v1/authn. The limit slows brute force against one user and does little against a spray spread across thousands of usernames.

SSL VPN and Remote Access Gateways

In an Akira ransomware case Huntress investigated, a spray against a SonicWall SSL VPN began on August 4, 2026, and found a working password about seven minutes later on an account with no MFA. Nearly two hours later the operator was hands-on and moved to the domain controller over RDP.

Sophos reports that successful VPN brute forcing almost always traces to a VPN that doesn't require MFA. Gateway lockouts also tend to count failures per source IP, and a distributed spray stays under that count.

In December 2024, NetScaler gateways faced sprays from dynamic IP ranges against older pre-nFactor login endpoints, the login pages that predate NetScaler's nFactor multifactor framework. Dynamic ranges blunt IP blocking and rate limiting.

How to Detect Password Spraying in Sign-In Logs

Count the distinct accounts failing per source IP, autonomous system number (ASN), and client fingerprint, such as the user agent and client app pair, within a time window.

ASN grouping often catches sprays that rotate IP addresses, since Microsoft's 2025 Digital Defense Report traced more than 80% of malicious spray traffic to just 20 ASNs, 0.04% of the ASNs that carry authentication traffic. Per-account failure counts mostly measure user error.

Entra ID Error Codes and Fields

Error code 50126 (invalid username or password) is the failure most spray rules count, and Microsoft's user-account guidance rates it Medium as an isolated event and High when many accounts show the same pattern.

Code 50053 means a locked account or a sign-in blocked because the IP has malicious activity, and the Failure reason field tells you which. Conditional Access blocks (53003) rate High on privileged accounts.

Watch interrupted sign-ins that end in strong-authentication-required codes such as 50074 and 500121. A large volume of them can mean the attacker has the right password and can't complete MFA.

Query SigninLogs and AADNonInteractiveUserSignInLogs together. Legacy-protocol attempts can appear in either, and token refreshes land in the non-interactive table.

Filter ClientAppUsed for IMAP, POP, SMTP, and Exchange ActiveSync, look for ropc in the AuthenticationProtocol field, and enrich with AutonomousSystemNumber.

Default user agents can expose tooling when operators don't rotate them. The Iranian actor Peach Sandstorm sprayed from Tor IP addresses using a go-http-client user agent. Elastic ships a detection rule for the hardcoded user agent of TeamFiltration, an open-source tool for enumerating and spraying Microsoft cloud accounts.

Okta System Log Signals

ThreatInsight writes security.threat.detected events, and Okta Security’s suspected spraying query is eventType eq "security.threat.detected" AND outcome.reason co "Password Spray". The events carry no username, because ThreatInsight runs before Okta identifies the user.

For your own rules, count distinct actor.alternateId values per client IP on user.session.start events with a FAILURE outcome and an INVALID_CREDENTIALS or VERIFICATION_ERROR reason.

Microsoft Sentinel's Okta password spray rule alerts at more than 15 distinct accounts per IP in five-minute bins. Bursts of user.account.lock events across users add evidence, and Okta Identity Threat Protection raises a Medium-severity detection named "Suspicious login using a valid sprayed password" when a sprayed password works.

Thresholds, Windows, and False Positives

Published thresholds range from 5 to 30 accounts per source. Microsoft Sentinel's Entra ID spray template uses 20-minute windows, alerts at five distinct failing accounts per IP and application, and keeps only IPs where failing accounts outnumber successful ones.

Splunk's O365 analytic fires above 10 unique accounts in five minutes, and its Azure AD analytic fires above 30.

Short windows miss the one-attempt-per-day pattern, so pair them with a long-window hunt. Microsoft's slow brute force query for the Sentinel data lake looks back 180 days for IPs with more than five failures across more than five users.

To catch a spray that ends in a success, correlate by source IP or ASN. Grouping failed-then-successful logins by user follows one account and misses a spray that succeeds on a different one.

Expect false positives from shared office NAT addresses, VPN concentrators, and applications replaying stale credentials. An office NAT after a password-expiry wave looks like a spray until its users start signing in, and the Sentinel template's success filter usually drops it at that point.

How to Respond When a Spray Produces a Valid Credential

Microsoft's password spray playbook separates password compromise, where the attacker guessed the password but MFA or another control blocked access, from account compromise, where the attacker got in. Account compromise needs the full sequence:

1. Contain the source and the account: Block the source ranges, tag the IPs in Defender for Cloud Apps so future use raises an alert, and block sign-in for the account while the investigation runs.
2. Revoke sessions and tokens: In Entra ID, call Microsoft Graph revokeSignInSessions to invalidate refresh tokens and browser session cookies. Access tokens already issued stay valid until they expire, 60 to 90 minutes by default. Services that support continuous access evaluation enforce revocation in near real time, with up to 15 minutes of propagation.
3. Reset the password and re-enroll MFA: A reset revokes only the refresh tokens and cookies issued through the password, so access tokens, sessions that didn't use the password, and any persistence survive it. Use a phishing-resistant method for the new enrollment, and remove any authentication method added after the compromise.
4. Hunt for persistence: Review inbox rules (Get-InboxRule -IncludeHidden shows hidden ones), forwarding settings, OAuth consent grants, and privileged role assignments. Attackers rely on the same mechanisms in business email compromise.
5. Scope access: List what the account could reach, including VMs, domain permissions, storage, and every downstream app behind SSO, then separate that from what the attacker accessed.
6. Close the path: Fix the legacy protocol, Conditional Access scope, or VPN MFA gap that let the spray succeed.

Steps 3 and 6 also apply to a password compromise, since the attacker still knows a working password.

Decision Criteria for Password Spraying Defense

If legacy authentication is still allowed anywhere in your tenant, block it with Conditional Access or security defaults before you tune any detection. Require MFA for every client app type as well, so ROPC sign-ins fall under the same policy.

If your current rules count failures per account or per IP, add a distinct-accounts-per-source rule with a success-versus-failure filter, plus a long-window hunt for low-and-slow activity.

If Okta ThreatInsight runs in audit-only mode, move it to log and enforce, and deny anonymizing proxies through Dynamic Zones where your license allows.

If any VPN or remote access account authenticates without MFA, treat it as your highest-priority spray exposure, given how fast the Akira case above reached the domain controller. Put phishing-resistant MFA there.

If your investigation provider sees only endpoint telemetry, ask how it would decide whether an attacker used a sprayed credential against mail, OAuth, or SaaS.

Why Context Decides Whether a Spray Became a Breach

After a spray, one successful sign-in from an unfamiliar ISP could be the attacker or an employee on a new laptop, and nothing in the sign-in record says which. Microsoft's Defender XDR guidance tells responders to check the ISP behind the sign-in, other accounts signing in from it, spikes in email and file activity, and inbox rules created during flagged sessions.

Endpoint-centric programs see little of that activity. The spray runs against the identity provider, and the follow-on steps, such as token replay, new inbox rules, and file access, happen in cloud services mostly outside an endpoint agent's view.

Identity alerts belong in the core investigation workflow next to endpoint, email, and business-system activity, since a separate identity queue splits apart the evidence an ITDR approach is meant to connect.

Daylight's MDR service investigates identity alerts in that single workflow. Before it reaches a verdict, it pairs sign-in activity with email, SaaS, and endpoint telemetry and with organizational and historic context.

Frequently Asked Questions About Password Spraying

Can Entra ID Protection's Password Spray Detection Replace a SIEM Rule?

No. The password spray detection, which requires an Entra ID P2 license, fires only after an attacker successfully validates a password, so it works as a compromise signal. To see a spray in progress, you'll usually want a failure-side rule in your SIEM. The detection runs in real time or offline, and offline detections can take up to 48 hours to appear.

If Nearly Every Attempt Ended in Lockout, Does the Spray Still Matter?

Yes. Lockouts show which accounts the attacker is targeting, and under a strict lockout policy, the spray can lock out legitimate users and keep them from working. Treat the targeted list as intelligence, and confirm those accounts have MFA on every sign-in path and aren't using passwords from known leaks, even when nothing succeeded.

Does Password Spraying Work Against On-Premises Active Directory?

Yes. Sprayers also target Kerberos, LDAP, SMB, and RDP, and LDAP and Kerberos attempts are less likely to trigger event 4625, the logon failure that failed SMB connections produce.

On domain controllers, look for one source failing against many accounts in Kerberos pre-authentication failures (event 4771) and NTLM validation failures (event 4776), and check event 4625 on the servers being targeted.

Does Enforcing MFA Make Spraying Irrelevant?

No, though it shrinks the problem. Password attacks fell 26% year over year, which Microsoft credits to MFA and passkeys, and attackers have shifted toward MFA fatigue and adversary-in-the-middle phishing to get past the second factor. A correct password that MFA blocked is still a live risk, because it's all an attacker needs to start an MFA fatigue attack.

Is Token Spraying the Same Attack?

No. Token spraying applies the spray pattern to stolen sign-in tokens, so the attacker never needs a password. In an October 2026 campaign, the attacker replayed stolen tokens at volume against Microsoft 365 accounts, and Huntress counted at least 497 successful sign-ins against more than 200,000 failed attempts across 79 organizations. Because the token is issued after MFA, detection depends on rogue device registrations, unusual user agents, and hosting-provider IPs.