Monday Morning, 7:43 AM
A financial services company's SOC analyst pulls up the morning report. Nothing looks alarming at first glance. Fourteen failed logins across eleven different accounts, spread across two hours. No account triggered a lockout. No alert fired. By 9:15 AM, three of those accounts are actively sending internal emails to finance staff requesting wire transfer approvals. The attacker had been inside since 6:52 AM.
This is the canonical shape of a password spray attack, and the reason so many detection strategies fail against it is that they were built to catch brute force, not surgical volume distribution. Understanding how these attacks operate, what signals they actually leave behind, and how to build detection logic that catches them before accounts are compromised is the operational challenge this article addresses directly.
What Password Spray Actually Looks Like From the Attacker's Perspective
A password spray attack tests a small number of passwords, often just one or two, against a large number of valid usernames. The goal is to find accounts using common or default credentials without triggering account lockout policies, which typically fire after multiple failed attempts against a single account.
Attackers source valid usernames from multiple vectors. Corporate directories exposed via LinkedIn, leaked email lists from previous breaches, enumerated usernames from misconfigured login pages, or data purchased on criminal forums are all common starting points. The LACMA data breach from last year, which exposed social security numbers and medical data, is a concrete reminder of how credential and identity data from a single incident circulates through underground markets long after the initial headlines fade.
The spray itself is methodical. An attacker tests Password1! against 5,000 accounts, waits 30 minutes, then tests Welcome2024! against the same list. Some actors use distributed infrastructure to further reduce per-source volume. The AnonyMousKIT PhaaS platform, which recently drew attention for using voice AI agents to phish iPhone passcodes, illustrates the degree to which modern threat actors combine automation, distributed infrastructure, and social engineering to acquire and validate credentials at scale. Password spray is often the validation step after initial credential harvesting, not the harvesting mechanism itself.
The Log Sources That Actually Matter
Detection starts with log collection, and the sources that reveal password spray activity are specific. Generic server logs are rarely enough.
Authentication Event Logs
Windows Security Event Log Event ID 4625 captures failed logon attempts. Event ID 4624 captures successful logons. The ratio and pattern between these two events, across accounts rather than per-account, is where spray activity becomes visible. Active Directory environments should have audit policies configured to log both success and failure for logon events, account logon events, and account management events.
For cloud environments, Azure AD Sign-In Logs, AWS CloudTrail authentication events, and Google Workspace Login Audit logs serve equivalent roles. Each of these logs contains fields that are critical for spray detection: timestamp, source IP, target account, authentication method, and result code.
Application-Layer Authentication Logs
Many spray campaigns target web-facing authentication endpoints rather than direct domain controller authentication. Office 365 and Exchange Online are frequent targets because legacy authentication protocols like SMTP AUTH and Basic Auth over Exchange Web Services bypass modern conditional access policies. Webmail portals, VPN login pages, and HR self-service portals are also common targets because they are accessible from the internet and often have weaker monitoring than core directory services.
Ingesting application-layer authentication logs into your SIEM alongside directory logs allows correlation that reveals spray activity even when no single source shows meaningful volume.
Network Flow Data
NetFlow or similar flow telemetry from perimeter devices captures source IP to destination IP relationships at the network layer. During a spray campaign, flow data often shows a single external IP or a small IP range making repeated short-duration connections to your authentication infrastructure over a compressed time window. This is a behavioral signature that survives even when authentication logs are sparse or delayed.
Building Detection Logic That Works
Most out-of-the-box SIEM rules for password spray look at failed login counts per source IP over a fixed time window. This approach catches unsophisticated attacks and misses every moderately well-executed spray campaign, because modern attackers rotate source IPs, use legitimate-looking residential proxy infrastructure, and keep per-source volume well below threshold.
Horizontal Failure Analysis
The correct detection axis for password spray is horizontal: multiple accounts, low per-account failure count, narrow time window. A rule that fires when more than 20 distinct accounts experience at least one failed authentication attempt within a 30-minute window, from any combination of source IPs, will catch spray activity that per-IP rules miss entirely.
In Splunk SPL, this looks roughly like:
index=auth sourcetype=WinEventLog:Security EventCode=4625
| bucket _time span=30m
| stats dc(Account_Name) as unique_accounts, count as total_failures by _time
| where unique_accounts > 20Adjust thresholds based on your organization's baseline. A large enterprise may see 20 failed logins across distinct accounts in 30 minutes as a normal Monday morning pattern. A 200-person company seeing the same volume should treat it as high-confidence spray activity.
Password Field Correlation
Some authentication systems, particularly those using RADIUS or legacy Kerberos configurations, log the password value or a hash in failed authentication events. Where this data is available, grouping failed authentications by the literal password attempted reveals spray patterns immediately. Multiple accounts failing with the same password in a short window is definitionally a spray attack.
Most modern systems do not log plaintext passwords in failure events, but some network access controllers and legacy VPN appliances do. Audit your log pipeline for this data and exploit it when present.
Velocity and Cadence Analysis
Spray attacks have a distinctive temporal cadence. Automated spray tools authenticate at a consistent rate, often hitting authentication endpoints every 10 to 90 seconds across the target account list. Human login behavior clusters around working hours and has irregular inter-event timing. Machine learning models trained on your authentication baseline can surface spray activity as a statistical anomaly even when no individual threshold is crossed.
Building a simple statistical baseline using mean and standard deviation of per-hour unique account failure counts, then alerting on deviations beyond two or three standard deviations, requires no commercial ML tooling and catches spray campaigns effectively. Update the baseline monthly to account for organizational change.
Credential Stuffing Versus Spray
It is worth operationally distinguishing credential stuffing from password spray, because they require slightly different detection approaches. Credential stuffing uses username-password pairs sourced from previous breaches, with a different password per account. Spray uses the same password across many accounts. Both appear as distributed low-volume failures, but credential stuffing shows higher per-account variation in the password being tested. When your logs allow password correlation, this distinction matters for attribution and response.
Infrastructure Signals That Precede the Spray
Reconnaissance often precedes spray campaigns. Attackers enumerate valid usernames before spraying, and this enumeration leaves detectable signals depending on how your authentication infrastructure responds to invalid usernames.
If your login portal returns a different error for an invalid username versus a valid username with a wrong password, it is vulnerable to user enumeration. An attacker probing this will show a pattern of rapid sequential single-attempt authentications across a wide range of usernames, many of which will fail with the invalid-user error code. This reconnaissance phase in your logs often precedes the spray by hours or days and gives you earlier warning than the spray itself.
Similarly, attackers operating through residential proxy infrastructure or commercial anonymization services will sometimes query your public-facing webmail or autodiscover endpoints to validate that email addresses correspond to active accounts. HTTP 200 responses to autodiscover XML queries confirm account existence. Monitoring for unexpected volume on your autodiscover or similar endpoints is an early indicator that enumeration is in progress.
The recent news that LG is moving to ban residential proxies from Smart TV apps reflects the broader abuse of residential proxy infrastructure. Attackers route spray campaigns through these same proxy pools to distribute authentication attempts across thousands of legitimate-looking IP addresses, making per-IP blocking ineffective as a primary control. Detecting the behavioral pattern rather than blocking the source IP is the correct response architecture.
Response Steps When Spray Activity Confirms
Detection without a practiced response workflow leaves accounts at risk even after the alert fires. Response to a confirmed password spray follows a sequenced set of actions.
Immediate Account Risk Triage
Identify which accounts in the spray target list experienced successful authentications following failed attempts. These are your highest-priority investigation targets. Pull their authentication event timelines and look for post-authentication activity: new mail rules, forwarding configurations, file downloads, privilege escalation attempts, or lateral movement. Accounts with successful authentications after failed spray attempts should be treated as compromised until investigation proves otherwise.
For accounts that received spray attempts but show no successful authentication, assess password policy compliance. Accounts using passwords that match common spray wordlists are at continued risk even if the current campaign did not succeed. Force password resets for high-value accounts in the spray target list regardless of whether their authentication events showed success.
Session Termination and Token Revocation
In cloud environments, a successful spray authentication may have resulted in the issuance of OAuth tokens or session cookies that persist beyond a password reset. Force token revocation through your identity provider's administrative console. In Azure AD, this is the Revoke-AzureADUserAllRefreshToken PowerShell command. In Google Workspace, session termination is available through the Admin Console. In AWS, active sessions tied to compromised IAM credentials require explicit revocation of active session tokens.
Legacy Protocol Disablement
If the spray succeeded through a legacy authentication protocol, disable that protocol immediately for the affected accounts and evaluate organization-wide disablement. Basic Auth and legacy SMTP AUTH are the most common vectors. Microsoft deprecated Basic Auth for Exchange Online in 2022, but many hybrid environments and third-party integrations continue to enable it for specific connectors. Audit these and disable where operationally possible.
Communication and Escalation
Notify affected account holders immediately with specific instructions: change your password now, review your sent mail folder for unauthorized messages, check your account forwarding and mail rule settings. Vague security notifications are ignored. Specific, actionable ones drive compliance.
Escalate to management and legal if the spray resulted in confirmed account compromise and any data access. Depending on your jurisdiction and industry, regulatory notification requirements may apply. The LACMA breach notification timeline demonstrates that delayed response to confirmed access events carries significant regulatory and reputational consequences.
Hardening Controls That Reduce Spray Success Rates
Detection is not the complete answer. Reducing the attack surface makes spray campaigns less likely to succeed even when detection is delayed.
Enforce multi-factor authentication across all externally accessible authentication surfaces without exception. MFA does not prevent a spray attempt, but it prevents a successful credential validation from becoming an account compromise. The most effective implementation combines phishing-resistant authenticators like FIDO2 hardware keys with conditional access policies that require MFA for all non-trusted network locations.
Implement password blacklisting against known spray wordlists. Azure AD Password Protection offers this natively for cloud and hybrid environments. On-premises solutions can implement similar controls using custom password filter DLLs. Blocking common passwords like Password1!, Summer2024!, and Welcome1 removes the highest-yield targets from any spray campaign immediately.
Configure smart lockout policies that distinguish between distributed and single-source attacks. Azure AD Smart Lockout and similar capabilities in other identity platforms can lock out an account from specific source IPs while allowing legitimate access from trusted locations, reducing the operational impact of lockout-based defenses without removing them entirely.
Integrating Spray Detection Into Broader Threat Visibility
Password spray rarely operates in isolation. APT groups routinely use spray as an initial access technique before deploying post-compromise tooling. The HoneyMyte APT group's recent upgrade of CoolClient with a kernel-level Windows rootkit illustrates how initial access gained through relatively simple credential attacks enables sophisticated persistent access. The entry point may be a spray-compromised account; the persistent threat is an implant operating at privilege levels that standard monitoring misses entirely.
Linking your spray detection alerts to your broader threat hunting workflows means that when a spray alert fires, hunting queries run automatically against endpoint telemetry, lateral movement indicators, and network flow data for the accounts and source IPs involved. This correlation is the difference between catching a credential attack and catching the campaign behind it.
Feed confirmed spray source IPs into your threat intelligence platform and compare them against known malicious infrastructure, VPN exit nodes, and residential proxy ranges. Correlating authentication attack sources against broader threat intelligence context helps distinguish opportunistic criminal spray campaigns from targeted intrusion attempts, which drives prioritization and response depth.
Metrics That Confirm Your Detection Is Working
Build reporting that tracks spray detection performance over time. Useful metrics include: mean time from spray initiation to first alert, the percentage of spray campaigns that resulted in at least one successful authentication before detection, the ratio of true positive to false positive spray alerts, and the time from alert to forced password reset for targeted accounts.
Review these metrics quarterly. A rising mean time to detection or an increasing percentage of campaigns reaching successful authentication before alert are signals that your detection logic needs recalibration, your log pipeline has gaps, or attacker techniques have evolved beyond your current rule parameters. Treat these metrics as operational indicators with the same discipline you apply to patch cadence or vulnerability closure rates.
Password spray detection is fundamentally a data problem. The signals exist in every environment. The organizations that catch spray campaigns early collect the right logs, correlate across the right dimensions, and run detection logic oriented around account population behavior rather than source-IP volume. The ones that find out three weeks later are still waiting for a lockout threshold that was never going to fire.
