The Breach That Started With a Single Failed Login Per Account
A mid-sized financial services firm running Microsoft 365 noticed unusual activity on a Friday afternoon. A security engineer reviewing a routine report saw that 847 accounts had each recorded exactly one failed authentication attempt within a six-hour window. No account had more than two failures. The firm's existing alerting was tuned to trigger on five consecutive failures from a single source against a single account. Every threshold stayed green. By Monday morning, fourteen accounts were actively compromised, and two of them belonged to employees with access to wire transfer authorization systems.
This is how password spray attacks succeed in 2025. The technique is not new, but the infrastructure behind it has grown substantially more sophisticated. The FBI's recent seizure of the NetNut proxy platform and the 911 S5 botnet's documented legacy both illustrate how attackers access enormous pools of residential and datacenter IP addresses to distribute authentication attempts across thousands of source addresses simultaneously. The result is a volume of attempts that looks, from any single vantage point, like ordinary failed logins.
Understanding where detection actually catches these campaigns requires rethinking how authentication telemetry is aggregated, correlated, and interpreted. This article focuses on building detection logic that works against distributed, low-volume spray campaigns rather than rehashing threshold-based approaches that attackers abandoned years ago.
What a Modern Password Spray Campaign Actually Looks Like
Classic password spray involved one or a small number of IP addresses attempting a single common password against many accounts in rapid succession. Modern campaigns have moved well past that model. Threat actors using proxy networks now distribute attempts across hundreds or thousands of IP addresses, spacing requests to stay under per-IP rate limits and often respecting artificial delays that mimic human login timing patterns.
A typical campaign targeting an Entra ID or Active Directory environment might proceed as follows. The attacker acquires a list of valid usernames, which is often obtained through prior OSINT, leaked data sets, or harvest techniques including the kind of device code phishing recently documented against Microsoft environments. With usernames confirmed, the spray begins using a rotating pool of residential proxies sourced from botnet infrastructure. Each IP address submits one or two authentication attempts before rotating out. The password list is curated rather than exhaustive, focusing on seasonal patterns, organization-specific formats, and entries derived from prior breach datasets.
The 2024 student loan breach that exposed 2.5 million records is an example of the data that ends up in these curated lists. Attackers correlate leaked credentials with known organizational email formats, and then test whether employees reused passwords or adopted predictable variations. The spray itself may run over twelve to seventy-two hours to avoid time-based anomaly detection. Each account receives at most two or three attempts before the campaign moves on, keeping every account well below lockout thresholds.
Where Standard Detection Falls Short
Most SIEM deployments and identity protection tools apply account-centric logic first: too many failures against one account triggers an alert. That model assumes the attacker concentrates volume. Spray attacks invert the relationship, distributing volume broadly and concentrating success narrowly only after compromise occurs.
Source-IP alerting has the same structural weakness when attackers use proxy pools. A single IP address submitting two authentication failures looks identical to a legitimate user mistyping their password. Blocklists help but lag behind proxy pool rotation. Even intelligence-enriched blocklists, which flag known Tor exit nodes, hosting ASNs, or previously observed malicious infrastructure, capture only a fraction of residential proxy traffic because legitimate residential IPs are intentionally difficult to distinguish from compromised ones used as proxies.
Geolocation-based alerting catches some campaigns, particularly those using datacenter infrastructure that resolves to unexpected countries. However, proxy networks deliberately route through IPs that match the target organization's expected geography. A spray campaign targeting a US firm will preferentially use US residential IPs, making geolocation signals weak or misleading. This mirrors the broader problem security teams face when geolocation says traffic is domestic but the actual operator is abroad.
User agent and TLS fingerprint analysis catches automated tools that use default configurations, but commodity spray tooling now randomizes headers, uses browser-realistic TLS fingerprints, and in some cases operates through legitimate browser automation frameworks to produce authentication requests indistinguishable from a real browser session.
Building Detection Logic That Actually Works
Aggregate at the Tenant Level First
The foundational shift is moving aggregation up from the account level to the tenant level. Rather than asking how many times account X failed to authenticate, ask how many distinct accounts recorded at least one failed authentication within a rolling window. A spike in unique-account failure count, especially when individual per-account failure counts remain low, is one of the clearest behavioral signals for distributed spray campaigns.
In Microsoft Entra ID environments, this data is available through the Sign-in Logs exported to a Log Analytics Workspace or SIEM. A query grouping by time window, result type, and distinct user principal name count will surface this pattern. The threshold for alerting should be calibrated against the organization's baseline. For a 500-person organization with typical Monday morning authentication traffic, seeing 80 distinct accounts with failed logins over 30 minutes is unremarkable. Seeing 200 distinct accounts with exactly one failed login each over six hours on a Wednesday evening is worth investigating immediately.
KQL example for Entra ID Sign-in Logs:
SigninLogs
| where TimeGenerated > ago(6h)
| where ResultType != 0
| summarize FailedAttempts = count(), UniqueUsers = dcount(UserPrincipalName) by bin(TimeGenerated, 30m)
| where UniqueUsers > 50 and FailedAttempts / UniqueUsers < 2The second condition in that query is the critical one: a high unique user count with a low average failure count per user is the signature of a spray campaign rather than a service outage or bulk misconfiguration causing legitimate failures.
Track Success-to-Failure Ratios Across the Population
Spray campaigns succeed when some percentage of tested passwords match. After successful authentication, attackers typically generate a successful sign-in event from the same infrastructure. Correlating the population of IPs that generated failed logins with any subsequent successful logins from overlapping infrastructure can catch post-spray access even when the spray itself was low and slow.
This correlation is harder when proxy pools rotate IPs between failed and successful attempts, but attackers still often reuse infrastructure across sessions. Comparing the ASN distribution of failed authentication sources against the ASN distribution of successful authentications for the same time window can reveal anomalies. An unusually high proportion of successful logins sourcing from hosting ASNs or mobile carrier ASNs during a period of elevated failure volume warrants immediate review.
Leverage Authentication Context Signals Beyond IP
Modern identity platforms provide authentication context that goes well beyond source IP. Device compliance status, registered device presence, authentication method used, token type, and conditional access policy outcomes all contribute to a richer picture of whether a successful authentication represents a legitimate user session.
A spray attack that succeeds against an account configured for password-only authentication will produce a successful login with no device compliance signal, no registered device, and often an unusual user agent or client application. Correlating these signals together, particularly for accounts that had recent failed logins from the same session context, can detect post-spray access before the attacker establishes persistence.
Organizations running hybrid environments with both on-premises Active Directory and cloud identity should monitor both authentication planes. Attackers sometimes test credentials against on-premises endpoints like ADFS, legacy SMTP authentication, or VPN gateways because these surfaces may have weaker MFA enforcement than the primary cloud identity provider. The Vidar Stealer campaigns and credential-harvesting malware distributed through modified tooling demonstrate that attackers maintain diverse access paths and select the authentication endpoint with the weakest controls.
Behavioral Baselines for Each Account
Account-level behavioral baselines catch spray success that volume-based detection misses. When a compromised account logs in from a new country, a new device, at an unusual hour, or accesses resources outside its typical pattern, behavioral analytics surfaces the anomaly regardless of whether the initial authentication looked suspicious.
Entra ID Identity Protection and similar tools in Okta, Ping, and other identity platforms provide some of this out of the box. The challenge is ensuring that alert thresholds are tuned to the actual environment rather than vendor defaults, and that alerts route to a response workflow rather than an unreviewed queue. The nine-day detection gap documented in the healthcare password spray case referenced elsewhere in this publication illustrates the cost of alerts that generate tickets nobody acts on within hours.
Specific Detection Scenarios and Configurations
Legacy Authentication Protocols
SMTP AUTH, IMAP, POP3, and Basic Authentication endpoints remain spray targets because they bypass MFA in environments that have not fully disabled legacy protocols. Detection here requires log coverage of Exchange Online or on-premises Exchange that captures authentication method alongside the standard failure/success result. A policy that blocks legacy authentication at the conditional access level eliminates most of this attack surface, but organizations mid-migration often have exceptions for specific service accounts or devices that remain exploitable.
Querying Exchange message trace logs or the Azure AD Non-Interactive Sign-in logs for high-volume legacy protocol authentication failures, particularly from single source IPs, catches spray campaigns against these endpoints even when the primary sign-in log detection is tuned for distributed sources.
VPN and Remote Access Gateways
VPN gateways present a particular challenge because they often implement their own authentication stack separate from the primary identity provider. Syslog output from Fortinet, Cisco, Palo Alto, or similar VPN appliances needs to feed the SIEM alongside identity platform logs. Without this integration, a spray campaign targeting VPN credentials runs invisibly against the main detection stack.
Authentication logs from network devices frequently use different field names and formats than identity platform logs, requiring custom parsing. Once parsed, the same unique-account failure rate logic applies: unusually high counts of distinct accounts with low per-account failure counts signal spray activity.
Service Accounts and Non-Human Identities
Spray campaigns increasingly target service accounts because these accounts often have high privilege, rarely rotate passwords, and may have MFA exceptions. Detection for service account spray requires a separate baseline: these accounts should have predictable authentication patterns tied to specific source systems at specific times. Any authentication attempt from an unexpected source IP, especially with a failure result, is immediately worth investigating rather than filtering into a bulk threshold queue.
Response Workflows When Detection Fires
Detection logic that fires but connects to a slow or unclear response workflow loses much of its value. Password spray detection should trigger a defined playbook rather than a generic security alert. The first priority after detection fires is confirming whether any accounts in the sprayed population have subsequent successful logins. If yes, those accounts need immediate credential reset and session revocation regardless of whether MFA was enforced, because session tokens may have been captured by malware on the endpoint as seen in campaigns distributing stealers like CrashStealer, which masquerades as an Apple crash reporting tool to harvest credentials from macOS endpoints.
For accounts with only failed logins in the sprayed population, the priority shifts to assessing whether any of those accounts are high-privilege targets that warrant proactive credential rotation, and whether the spray campaign is ongoing. Blocking identified source infrastructure at the firewall or conditional access level slows ongoing campaigns but should not substitute for the tenant-level aggregate monitoring, since blocking one proxy pool causes the campaign to rotate to another.
Communicating with affected account holders requires care. A targeted notification explaining that an external actor attempted to access their account, followed by a prompted password change and MFA enrollment review, converts the incident into a user awareness moment without causing alarm that generates unnecessary help desk volume.
Organizational Controls That Reduce Spray Effectiveness
Detection catches campaigns that occur. Several controls reduce the probability that spray attempts succeed even when they go partially undetected.
Enforcing phishing-resistant MFA, specifically FIDO2 security keys or certificate-based authentication, makes spray attacks against the primary credential nearly irrelevant because password knowledge alone is insufficient. The tradeoff is deployment complexity and user experience friction, particularly for frontline workers or shared workstation environments.
Password policy modernization, aligned with NIST SP 800-63B guidance, focuses on length requirements and breach password checking rather than arbitrary complexity rules. Checking new passwords against known-breached password lists prevents users from setting passwords that appear in the curated lists spray campaigns rely on. Microsoft Entra ID Password Protection and similar tools implement this check on-premises and in the cloud.
Conditional access policies that require compliant devices, limit authentication from known hosting ASNs, and enforce continuous access evaluation reduce the window during which a sprayed credential can be used even if the initial authentication succeeds. The SMB cybersecurity resilience frameworks emerging across the industry specifically call out these baseline identity controls as the foundation from which more advanced detection builds upward.
Logging Requirements for Effective Detection
Spray detection is only as good as the log coverage feeding it. The minimum logging posture for effective detection includes Entra ID Sign-in Logs retained for at least 90 days with export to a SIEM or Log Analytics Workspace, Active Directory Security Event logs covering Event IDs 4625 (failed logon) and 4771 (Kerberos pre-authentication failure) from all domain controllers, authentication logs from all remote access gateways and VPN concentrators, and application-level authentication logs from any web application using its own identity layer rather than delegating fully to the enterprise identity provider.
Organizations that rely solely on the identity provider portal's built-in reporting without exporting to a centralized platform lose cross-source correlation capability and face retention limits that make forensic reconstruction of a multi-day spray campaign difficult or impossible. This is a particularly common gap in smaller organizations and is one of the core resilience gaps that SMB-focused security frameworks are working to address.
Measuring Detection Coverage Over Time
Detection logic built today needs validation against evolving attack techniques. Purple team exercises that simulate password spray campaigns using the same tools and proxy infrastructure that attackers use provide the most direct measurement of whether detection logic fires as expected. Running simulated sprays against a subset of test accounts, with logging confirmed to be in place, and validating that tenant-level aggregation alerts trigger within an acceptable time window, gives the security team confidence that the controls are operational rather than merely configured.
Red team reports from these exercises frequently surface gaps in legacy protocol coverage, VPN log ingestion failures, or SIEM parsing errors that cause authentication events to be dropped before correlation can occur. Finding these gaps through simulation is substantially less costly than finding them during an actual incident investigation.
Revisiting detection thresholds quarterly, or after any significant change to the authentication infrastructure, ensures that organizational growth, architectural changes, or new application onboarding does not silently invalidate the baselines that detection logic depends on.
Bringing It Together
Password spray detection in 2025 demands tenant-level aggregation, cross-source log correlation, and behavioral context that extends beyond the failed login event itself. The campaigns using proxy networks sourced from botnet infrastructure, rotating through residential IPs acquired from platforms like the recently seized NetNut, are specifically designed to stay invisible to per-account and per-IP detection logic. Shifting the detection frame to population-level patterns, combining authentication signals with device compliance and session context, and building response workflows that move within hours rather than days are the operational practices that close the gap between attack and response.
The financial services firm from the opening of this article rebuilt their detection stack after the incident. They implemented tenant-level unique-account failure rate alerting, integrated VPN authentication logs into their SIEM for the first time, disabled legacy authentication protocols that had been left open for a single line-of-business application, and ran a quarterly simulated spray exercise. Their mean time to detect the next spray campaign, which arrived four months later, was under two hours. Detection alone did not stop the attack, but it stopped the attacker from doing anything useful with the credentials before response teams revoked access.
