The Threat Landscape That Makes Password Spray So Persistent
Password spray attacks have outlasted countless defensive improvements because they exploit a fundamental tension in authentication design: locking accounts after repeated failures creates a denial-of-service opportunity, while leaving accounts unlocked keeps them exposed to low-and-slow guessing. Attackers learned this constraint years ago and built their campaigns around it.
The ESET Threat Report for H1 2026 highlights credential-based attacks continuing to dominate initial access vectors across enterprise environments. This tracks directly with patterns observed after large-scale breaches. The Unlimited Technology Systems breach impacting 3.8 million people and the student loan breach exposing 2.5 million records are not isolated incidents. They feed a secondary market where valid usernames from one breach become the spray target list for the next campaign.
Password spray works by attempting a single password or a small set of common passwords across a large number of accounts, rotating through targets slowly enough to avoid triggering per-account lockout thresholds. A campaign that tries one password against 10,000 accounts over 48 hours leaves almost no traditional lockout-based fingerprint. The failure rate per account stays below detection thresholds while the attacker works through an entire directory.
Cybercriminals selling access to Chinese surveillance cameras and similar compromised infrastructure give these campaigns a distribution layer that makes source-based blocking ineffective. A spray campaign originating from hundreds of residential IPs and IoT devices scattered across legitimate ISPs looks nothing like the obvious botnet traffic from a decade ago.
What Detection Teams Get Wrong About the Signal
Most detection logic for password spray focuses on failed authentication events. This is accurate but incomplete. By the time a successful authentication appears in the logs, the spray campaign has already worked. The challenge is identifying the pattern before that successful login occurs, or catching it so quickly afterward that lateral movement has no time to develop.
Failed logins are noisy. A mid-size organization with 5,000 users might generate thousands of failed authentication events daily from users mistyping passwords, locked mobile devices, and stale cached credentials. Spray detection that relies purely on failed login volume will either flood analysts with false positives or, once tuned down, miss the real thing entirely.
The more useful signals live in the relationship between accounts, source addresses, timing, and user agents. A spray campaign typically shows a consistent password being attempted across many accounts within a defined time window. The source addresses rotate but often share ASN characteristics or show geographic clustering that does not match the organization's user population. The user agent strings may be consistent or slightly randomized, and the authentication attempts hit accounts alphabetically or in batches that reflect directory enumeration order.
Building a Detection Model That Catches the Spread
Effective spray detection requires correlating events across accounts rather than monitoring accounts individually. The following framework addresses the key detection layers.
Authentication Source Profiling
Every user in your directory has a behavioral baseline for where they authenticate from. Mobile users authenticate from cellular carriers, remote workers from residential ISPs or known VPN exit points, and office workers from corporate egress addresses. When an authentication attempt comes from an IP address or ASN that appears across dozens of accounts in a short window and matches none of their historical baselines, that is a primary indicator.
This profiling does not require machine learning at the outset. A rolling 30-day window of source ASN and IP address ranges per user gives enough baseline to flag anomalies. When a single ASN generates authentication attempts against more than 20 distinct accounts within an hour, that crosses a threshold worth investigating regardless of whether those attempts succeed or fail.
Time-Window Correlation Across Accounts
Set detection logic to count distinct accounts receiving authentication attempts from the same source IP or IP subnet within sliding time windows. Recommended windows for initial tuning are 15 minutes, 1 hour, and 6 hours. A threshold of more than 10 distinct accounts from a single /24 subnet within 15 minutes, or more than 50 within an hour, will catch most spray campaigns while staying above the noise floor for legitimate infrastructure like password reset services.
Adjust thresholds based on your environment. Organizations using single sign-on federated across cloud services may see higher legitimate cross-account traffic from specific infrastructure IPs. Exclude those documented ranges explicitly rather than raising global thresholds.
Password Field Consistency Detection
Some identity providers log the submitted password or its hash during failed authentication, particularly in on-premises Active Directory environments where event ID 4625 captures authentication failures. Where this data is available, correlation across failed attempts can directly identify spray behavior when the same credential string appears across multiple accounts.
In environments where password content is not logged, proxy or federation layer logs may capture request body patterns or token characteristics that indicate repeated use of identical credentials. This requires careful legal and privacy review before implementation but provides the strongest direct evidence of a spray pattern.
User Agent and Client Fingerprinting
Spray tools often present consistent or templated user agent strings. Even when attackers randomize user agents, the range they draw from tends to be limited. Seeing 40 different accounts receive authentication attempts from clients claiming to be four different browser versions over a 20-minute period, none of which match those users' historical client profiles, is a behavioral outlier worth alerting on.
Office 365 and Azure AD environments generate rich sign-in log data including client application identifiers, legacy protocol flags, and conditional access outcomes. Legacy protocol authentication, specifically Basic Auth over protocols like IMAP, POP3, and SMTP, remains a major spray vector because it bypasses modern authentication and multi-factor requirements. Filtering sign-in logs for legacy protocol attempts across multiple accounts is a high-confidence detection path.
Detection Checklist for Security Operations Teams
- Enable and centralize authentication logs from all identity providers, including cloud identity platforms, on-premises Active Directory domain controllers, VPN gateways, and federated SSO services.
- Correlate failed authentications across accounts by source IP, source ASN, and time window. Alert when a single source contacts more than a defined threshold of distinct accounts within 15 and 60-minute windows.
- Build per-user source baselines covering historical authentication IP ranges and ASNs. Flag authentications from sources outside a user's baseline when they appear across multiple accounts simultaneously.
- Monitor legacy protocol authentication explicitly. Create separate detection rules for IMAP, POP3, SMTP, and Basic Auth attempts. These protocols bypass MFA and generate a distinct log signature.
- Alert on geographically impossible authentications where the same account shows authentication attempts from locations that could not be reached within the time delta between requests.
- Correlate user agent strings across failed authentications. Flag sessions where the same user agent appears across more than 10 accounts in a short window without a documented infrastructure justification.
- Integrate breach data feeds so that usernames appearing in recently published credential dumps receive elevated monitoring priority.
- Review successful authentications that follow a failed spray pattern. If a spray campaign generates alerts and then goes quiet, check whether any accounts from the target list show new successful authentications from unusual sources in the following 24 hours.
- Audit service accounts and shared mailboxes separately. These accounts often lack MFA and appear frequently in spray target lists because their usernames follow predictable naming patterns.
- Test your detection logic quarterly using controlled spray simulations against test accounts to verify alert thresholds and log pipeline integrity.
The Infrastructure Attackers Use and Why It Matters for Detection
Modern spray campaigns rarely originate from a single IP address or even a single autonomous system. The infrastructure underlying these campaigns increasingly includes compromised residential devices, VPS instances spread across dozens of cloud providers, and, as recent news highlights, exposed IoT devices including surveillance cameras being sold as proxy access by criminal operators.
This distribution means that traditional IP-reputation-based blocking catches only a fraction of spray traffic. A campaign distributing one attempt per IP across 10,000 compromised residential addresses will not trigger blocklist hits for most of those source addresses, because the IPs themselves have no prior abuse history.
This does not make source-based controls useless. It means they work best as a secondary signal rather than a primary gate. Combining IP reputation data with behavioral signals produces far higher detection confidence than either approach produces independently. An authentication attempt from a clean IP that still shows the behavioral fingerprint of a spray campaign should be treated as suspicious, while a clean IP showing completely normal behavioral patterns for that user should not be flagged just because it appears on a threat feed.
Microsoft Entra, Okta, and On-Premises AD: Detection Differences by Platform
Detection implementation varies significantly depending on the identity platform in use. Understanding platform-specific log sources prevents gaps.
Microsoft Entra ID (formerly Azure AD)
The Entra sign-in logs available through the Azure portal and via Microsoft Graph API provide rich spray detection data. Key fields include the IP address, user agent, client application identifier, conditional access outcome, risk level assigned by Microsoft's identity protection engine, and whether the authentication used legacy protocols. Entra Identity Protection already applies its own spray detection models and surfaces results as risk detections, but these should feed into your SIEM rather than operate as a standalone control.
Enable the non-interactive sign-in logs in addition to the interactive logs. Service principal sign-ins and application authentication events appear in separate log tables and are missed entirely when teams only ingest the primary sign-in log.
Okta
Okta's System Log captures authentication events with outcome reason fields that distinguish between credential failures, account lockouts, and policy-based denials. Spray detection in Okta environments benefits from Okta ThreatInsight, which applies cross-tenant behavioral signals to authentication requests. Ensure ThreatInsight is enabled and configured to log or block based on your risk tolerance.
Okta's event types user.session.start and user.authentication.auth_via_mfa should both feed into spray detection correlation. Watching for a high volume of user.authentication.authenticate failures with outcome reason INVALID_CREDENTIALS across multiple users from consistent source patterns is the primary detection path.
On-Premises Active Directory
Active Directory generates event IDs 4625 (failed logon) and 4776 (credential validation failure) on domain controllers. Both should be forwarded to your SIEM with source workstation name and IP address fields intact. A common logging gap occurs when these fields are empty because the authentication attempt came through Kerberos or NTLM in a way that does not capture the originating client address. Verify your log forwarding preserves these fields before relying on them for detection.
The sub-status codes in event 4625 distinguish between wrong password, account not found, and account locked. Spray campaigns generate a high volume of sub-status 0xC000006A (wrong password) while the account-not-found sub-status indicates the attacker is also doing username enumeration, which often precedes a spray campaign and is itself a detection opportunity.
Threat Hunting for Spray Campaigns That Have Already Succeeded
Detection before or during a spray campaign is the goal, but forensic hunting for campaigns that succeeded without triggering alerts is equally important. The following hunting queries and methods help identify post-compromise accounts in environments where detection controls may have gaps.
Search for accounts that show their first-ever successful authentication from a new country or ASN within 24 hours of a failed authentication spike. Even when the failed attempts did not trigger an alert, the successful follow-on login from a different source may be visible in historical logs.
Review accounts that authenticated successfully but did not complete MFA, indicating either a MFA bypass technique or a legacy protocol authentication path. In environments where MFA is supposed to be enforced for all users, any successful authentication without a corresponding MFA event is an anomaly regardless of spray context.
Look for accounts with sudden changes in email forwarding rules, inbox delegation additions, or new OAuth application authorizations shortly after their source profile changed. These post-compromise actions follow successful spray logins quickly and leave traces in mail audit logs and OAuth consent logs that persist even if the attacker later attempts to clean up.
Implementation Pitfalls That Undermine Spray Detection
Even well-designed detection logic fails when the underlying implementation has common gaps. The following pitfalls account for the majority of spray detection failures observed in real incident investigations.
Log Forwarding Latency
Authentication logs that arrive in the SIEM with a 15-minute or greater delay make real-time spray detection impossible. If your correlation windows are 15 minutes but your logs arrive with 20-minute latency, the spray campaign may have moved on before the alert fires. Measure your actual log ingestion latency for each authentication source and adjust detection window thresholds to account for pipeline delay.
Incomplete Log Coverage
Organizations frequently have excellent logging on their primary SSO platform while missing authentication events from legacy applications, on-premises systems, and SaaS tools that authenticate independently. An attacker who finds one application using local authentication rather than federated identity has a vector that generates no events in the central SIEM. Conduct a full authentication surface inventory before assuming detection coverage is complete.
Threshold Tuning Paralysis
Teams that receive high false-positive rates from initial spray detection rules often respond by raising thresholds until alerts stop appearing. This creates a false sense of security. A better approach is to add specificity rather than raise raw thresholds. Instead of alerting when any source contacts more than 50 accounts per hour, alert when a source contacts more than 10 accounts per hour AND those accounts have no prior authentication history from that source's ASN. Adding conditions reduces false positives while maintaining sensitivity.
Alert Without Context
A spray detection alert that fires without immediately surfacing the list of targeted accounts, the source addresses involved, and the time window of activity forces analysts to reconstruct context manually. By the time context is assembled, the response window has narrowed. Alert templates should pre-populate with account lists, source summaries, and links to pre-filtered SIEM queries so analysts begin triage with full context rather than starting from a raw alert.
MFA as a Sole Control
Multi-factor authentication significantly raises the cost of a successful spray campaign, but it does not eliminate spray as a threat. MFA fatigue attacks, SIM swapping, and adversary-in-the-middle phishing frameworks all exist specifically to defeat MFA. Treating MFA deployment as a reason to reduce spray detection investment leaves organizations exposed when MFA is bypassed. Detection and MFA function as complementary layers, not substitutes.
Missing Cloud-to-On-Premises Correlation
Organizations running hybrid identity environments often monitor cloud identity events and on-premises AD events in separate workflows. A spray campaign that starts against cloud identities and pivots to on-premises resources, or vice versa, may escape detection because neither team sees the full picture. Unified correlation across both environments requires either a single SIEM ingesting both log sources or a dedicated correlation workflow that shares indicators between the two monitoring contexts.
Closing the Detection Gap Before the Next Campaign Arrives
Password spray is not a sophisticated technique. Its persistence comes from the consistent failure of detection programs to correlate across accounts rather than monitoring accounts individually, and from the continued existence of legacy authentication paths that bypass modern controls. The breach headlines that dominate security news in 2026 keep reflecting the same pattern: valid credentials obtained through spray or stuffing campaigns enable initial access that then escalates through standard post-exploitation paths.
The organizations that detect spray campaigns early share a common characteristic. They treat authentication telemetry as a behavioral dataset rather than a compliance log. They correlate across accounts, across time windows, and across authentication sources. They test their detection logic against real spray simulations rather than assuming the rules work. And they close legacy authentication paths aggressively, because those paths exist primarily to help attackers rather than users.
Building that capability does not require a large tooling budget. It requires complete log coverage, correlation logic that spans accounts, and analyst workflows that give responders immediate context when an alert fires. Most environments have enough data to detect spray campaigns. The gap is usually in how that data gets used.
