The Assumption That Gets Organizations Compromised First
Most security teams assume password spray attacks are noisy. The logic feels sound: an attacker cycling a handful of common passwords across thousands of accounts should generate visible authentication failures, trigger lockout policies, and surface in SIEM dashboards within minutes. That assumption is precisely why password spray campaigns succeed as often as they do against organizations that consider themselves well-defended.
Password spray is not a loud attack. Executed correctly, it is one of the quietest credential access techniques in the modern threat actor playbook. The volume of failed logins per account stays below lockout thresholds deliberately. The timing is stretched across hours or days. The source IPs rotate through residential proxies, cloud egress nodes, and compromised infrastructure that does not appear on standard blocklists. What looks like normal authentication noise to a tired analyst on a Tuesday afternoon is, in fact, a methodical enumeration campaign working toward its first valid credential.
This disconnect between how teams expect password spray to look and how it actually behaves is the core detection problem. Solving it requires rethinking which signals matter, where to collect them, and what correlation logic actually catches the pattern before the attacker reaches a valid account.
Why Password Spray Thrives in the Current Threat Environment
Several converging factors have made password spray more attractive to threat actors in 2025 and 2026. The proliferation of cloud-hosted identity providers, particularly Microsoft Entra ID and Okta, means that a successful spray against a single identity platform can yield access to dozens of downstream applications simultaneously. Attackers understand this leverage point well.
The recent advisory from the Australian Cyber Security Centre warning of a global campaign targeting vulnerable CMS platforms is a useful reference here. Many of those CMS environments rely on the same identity backends as corporate infrastructure, and the credential enumeration techniques overlap significantly. Attackers probing CMS login endpoints with sprayed passwords are often using the same tooling and infrastructure they would deploy against Entra ID or Okta tenants.
Ransomware operators have integrated password spray into early-stage intrusion sequences as well. Groups that previously relied on phishing for initial access have shifted toward credential-based entry because it generates fewer endpoint alerts, skips the need for a user to click anything, and leaves a much shorter forensic trail. When ransomware attacks continue rising quarter over quarter, some of that growth traces back to credential access improvements, and spray is a meaningful contributor.
The emergence of sophisticated attack frameworks, including the Xdr33 variant of the CIA's HIVE kit that surfaced recently, reinforces a broader pattern: modern intrusion tooling is modular, well-maintained, and designed to blend into legitimate traffic patterns. Password spray modules within these frameworks include native rate throttling, proxy rotation, and user-agent spoofing that defeats basic detection heuristics.
What the Authentication Logs Actually Contain
Before building detection logic, security teams need a clear picture of what password spray generates in authentication logs and where that data lives. The signals are present. The challenge is that they are distributed across multiple sources and require correlation to become meaningful.
In a Microsoft 365 or Entra ID environment, password spray activity appears in the unified audit log under the UserLoginFailed operation, with error codes that distinguish between valid usernames with wrong passwords (AADSTS50126) and invalid usernames (AADSTS50034). This distinction matters enormously for detection. An attacker in the username enumeration phase generates AADSTS50034 codes. Once they have confirmed valid accounts and are spraying passwords, the failure signature shifts to AADSTS50126. Monitoring for that transition is a reliable early indicator.
On-premises Active Directory environments log failed authentication attempts under Event ID 4625. The sub-status codes within those events carry the same kind of signal. Sub-status 0xC000006A indicates a wrong password for a valid account. A spray campaign that has moved past enumeration will generate clusters of 4625 events with 0xC000006A sub-status codes spread across many different accounts from the same source or small set of sources within a defined time window.
Legacy authentication protocols deserve particular attention. SMTP AUTH, IMAP, POP3, and basic authentication endpoints do not enforce multi-factor authentication in most configurations. Attackers who understand this target legacy protocol endpoints specifically because successful spray attempts there yield usable credentials without triggering MFA challenges. Authentication logs for these protocols are often collected separately from modern authentication logs, which creates a visibility gap if correlation is not built across both streams.
Building Detection Logic That Matches the Attack Pattern
Effective password spray detection centers on two core analytical perspectives: the per-source view and the per-account view. Most teams implement one but not both, and the gaps between them are where attacks slip through.
Per-Source Analysis
The per-source view asks: how many distinct accounts is a single IP address, ASN, or user-agent attempting to authenticate against within a rolling time window? A legitimate user authenticating from a single IP will touch one account, possibly two if they manage a service account alongside their primary identity. An attacker spraying across the organization will touch dozens or hundreds of accounts from the same source.
The detection threshold here should not be static. A ratio-based threshold works better in practice. If a source IP attempts authentication against more than a configurable percentage of your total active account population within a two-hour window, that is spray behavior regardless of whether any individual attempt succeeded or failed. Start with 5 percent of total accounts as a trigger threshold and tune based on your environment's normal authentication patterns.
IP rotation complicates this view, which is why per-source analysis alone is insufficient. Attackers using residential proxy networks or cloud exit nodes cycle through source IPs rapidly enough to keep any single IP's attempt count low. When per-source thresholds alone are the detection mechanism, distributed spray campaigns stay invisible.
Per-Account Analysis
The per-account view asks: how many distinct source IPs are attempting to authenticate to a single account within a rolling time window? A legitimate user authenticating from a home IP, a corporate VPN, and a mobile carrier IP might generate three distinct sources. An account being sprayed from a rotating proxy pool might see twenty or thirty distinct source IPs within the same window, all with failed authentication outcomes.
Combining per-source and per-account views gives detection logic that catches both concentrated spray (few sources, many accounts) and distributed spray (many sources, few accounts per source). This combination approach is necessary in environments where attackers have invested in proxy infrastructure specifically to defeat single-dimension detection.
Temporal Pattern Recognition
Password spray campaigns have a rhythm. The attacker sets a delay between attempts to stay below lockout thresholds and to avoid velocity-based alerting. This creates a statistical regularity in attempt timing that is detectable if you are looking for it. Attempts spaced at intervals of 30 to 90 seconds across multiple accounts from the same source, or attempts that arrive in bursts with consistent inter-burst timing, are strong indicators of automated spray tooling.
Building a detection rule that flags authentication failures with statistically regular inter-attempt intervals requires more sophisticated query logic than a simple count threshold, but the result is significantly more precise. In a SIEM with time-series aggregation capabilities, you can calculate the standard deviation of inter-attempt intervals per source IP and flag sources with unusually low deviation as candidate spray infrastructure.
Platform-Specific Detection Configurations
Microsoft Entra ID and Microsoft 365
Microsoft Entra ID's Identity Protection module includes built-in spray detection, but relying on it exclusively creates blind spots. The built-in detection is tuned for high confidence and therefore misses low-and-slow campaigns that stay below Microsoft's internal thresholds. Supplementing it with custom detection rules in Microsoft Sentinel gives security teams control over sensitivity levels.
In Sentinel, a KQL query against the SigninLogs table that groups failed authentications by IPAddress over a one-hour window and filters for ResultType values 50126 and 50053, with a distinct account count greater than 10, provides a solid baseline spray detection rule. The threshold should be adjusted based on your organization's user population size. A 500-person company and a 50,000-person company need different absolute count thresholds even though the underlying attack pattern is identical.
Enable the Smart Lockout policy in Entra ID and configure it to use familiar location awareness. This setting maintains separate lockout counters for locations the user has authenticated from before versus new locations, which makes spray from novel IP ranges more likely to trigger lockout while reducing friction for legitimate users authenticating from known locations.
Okta
Okta's system log provides event types that map directly to spray detection needs. The user.session.start event with outcome FAILURE and reason INVALID_CREDENTIALS is the primary signal. Building a detection query that groups these events by actor.alternateId (the target account) and client.ipAddress over a rolling 30-minute window, then flagging combinations where a single IP touches more than 15 distinct accounts, covers the concentrated spray pattern.
Okta's ThreatInsight feature provides automated IP reputation analysis and can be configured to challenge or block authentication attempts from IPs associated with known malicious infrastructure. Enable it in audit mode first to understand the baseline false positive rate before switching to enforcement mode.
On-Premises Active Directory
Windows Security Event ID 4625 is the foundation, but the collection pipeline matters as much as the detection logic. Ensure that failed authentication events from all domain controllers are forwarded to your SIEM with no sampling or filtering at the collection layer. Sampling failed authentication events is a common cost-cutting measure that creates meaningful detection gaps precisely in high-volume spray scenarios.
Event ID 4771 captures Kerberos pre-authentication failures and carries similar signal to 4625 for environments using Kerberos authentication. Both event types should feed into spray detection logic. The combination covers NTLM-based and Kerberos-based authentication failure patterns.
Detecting Spray Against Legacy Protocol Endpoints
Legacy protocol spray is increasingly common because attackers understand that MFA enforcement gaps exist on older authentication pathways. A recent analysis of email account compromise techniques, consistent with the broader reporting on why cybercriminals prioritize inbox access, shows that IMAP and SMTP AUTH spray against Microsoft 365 tenants remains a viable attack path in organizations that have not completed their legacy authentication deprecation project.
Detection for legacy protocol spray requires visibility into Exchange Online authentication logs or on-premises Exchange IIS logs depending on your deployment model. In Exchange Online, the MailboxAuditLog and the unified audit log capture legacy authentication events separately from modern authentication flows. A spray attempt against IMAP will appear as a cluster of failed EWS or IMAP connection attempts from a single source against multiple mailboxes within a short window.
The remediation for legacy protocol spray is straightforward: disable legacy authentication protocols in your tenant using Entra ID Conditional Access policies. Authentication policies that block basic authentication for all users except those with documented legacy system requirements eliminate this attack surface entirely. If that deprecation project has stalled internally, use the detection signal from spray attempts against legacy endpoints as the business justification to accelerate it.
Responding to a Confirmed Spray Campaign
When detection logic fires with high confidence on a spray campaign, the response sequence matters. The first priority is confirming scope before taking containment actions that might alert the attacker prematurely.
Pull authentication logs for the past 72 hours with no filtering applied, looking for the source IPs and user-agent strings identified in the initial alert. The goal is to determine whether any authentication attempts succeeded during the campaign window. Failed attempts confirm the attacker was active. Successful authentications from the same source IPs or user-agent patterns indicate potential compromise and require immediate account suspension and session revocation.
For accounts that were targeted but show no successful authentications, force a password reset as a precaution and enroll them in MFA if that was not already in place. Targeted accounts that lack MFA are the ones the attacker will return to once they have refined their password list.
Preserve the raw log data from the campaign window before any log rotation or archiving occurs. Spray campaigns are frequently precursors to broader intrusion activity, and investigators working a subsequent incident will need the authentication log record to establish the initial access timeline.
Engage your threat intelligence resources to profile the source infrastructure. Residential proxy networks, cloud provider exit ranges, and Tor exit nodes all carry different implications for attribution and follow-on risk assessment. Understanding whether the spray originated from commodity proxy infrastructure versus a specific ASN associated with known threat actor activity shapes the urgency and scope of the broader response.
Hardening Posture to Raise the Cost of Spray Attacks
Detection is necessary but not sufficient. Controls that increase the cost and reduce the yield of spray attacks should run in parallel with detection investments.
Phishing-resistant MFA is the highest-leverage control available. WebAuthn and FIDO2-based authentication, including hardware security keys and platform authenticators, eliminate the credential-plus-password attack model entirely for enrolled users. A successfully sprayed password is useless if the account requires a FIDO2 authenticator to complete authentication. The technical work involved in adding WebAuthn to authentication flows has become substantially more accessible, and the security payoff against credential-based attacks including spray is significant.
Conditional Access policies that require compliant devices and trusted locations for authentication add friction to spray attempts originating from external infrastructure. An attacker spraying from a cloud proxy cannot present a compliant, Intune-enrolled device, which causes authentication attempts to fail at the policy evaluation layer rather than the credential validation layer. This separation means that even a correctly guessed password does not yield access.
Password policies should enforce a minimum length of 16 characters without complex character requirements that drive users toward predictable substitution patterns. NIST SP 800-63B guidance, which has been widely adopted by security teams as the practical standard, recommends length over complexity and mandates checking new passwords against known-compromised credential databases. Accounts whose passwords appear in breach compilations are disproportionately vulnerable to spray because attackers seed their password lists from those same compilations.
Integrating Spray Detection Into Broader Threat Hunting
Password spray detection should feed into a broader threat hunting workflow rather than existing as a standalone alert. A spray campaign that generates a detection alert is an opportunity to hunt for related activity across the kill chain.
Hunt for reconnaissance activity preceding the spray. DNS lookups for Autodiscover, mail, and authentication endpoints from the same source IP ranges in the days before the spray window began can confirm that the attacker performed systematic reconnaissance. This context changes the severity assessment from an opportunistic spray attempt to a targeted intrusion sequence.
Hunt for post-authentication activity if any successful logins occurred during the spray window. Mailbox rules created immediately after a first successful login, OAuth application consent granted in the hours following authentication, and large data exports from SharePoint or OneDrive during the spray window are all indicators that the attacker moved quickly from initial access to objective execution.
The Cavern Manticore reporting on Iran-linked modular C2 frameworks is a useful reference for understanding how credential access fits into a broader intrusion sequence. Sophisticated threat actors do not stop at obtaining a credential. They use that credential as a staging point for persistence, lateral movement, and data collection. Treating spray detection as the start of a hunting workflow rather than the end of an investigation is the operational posture that catches intrusions before they compound.
What Mature Detection Actually Looks Like
Organizations that detect password spray reliably share a few structural characteristics. Their authentication logs from all sources feed into a centralized analysis platform without gaps or sampling. Their detection rules cover both per-source and per-account dimensions. They maintain baselines of normal authentication behavior per user and per application so that deviations surface quickly. Their response playbooks distinguish between spray-with-no-success and spray-with-confirmed-access scenarios because the urgency and scope of response differs significantly between those two outcomes.
They also test their detection regularly. Running simulated spray attempts using tools like MSOLSpray or Spray in a controlled test window, with detection rules active, confirms that the logic fires as designed and that the alert reaches the right people within an acceptable timeframe. Detection logic that has never been tested against realistic spray behavior is detection logic that will fail at exactly the wrong moment.
Password spray works against organizations that built their detection posture around the assumption that attackers would be loud. Building detection that matches how spray actually behaves, quiet, distributed, patient, and methodical, is what closes the gap between assumption and reality.
