The Problem Sitting Inside Your Authentication Infrastructure
Password spray attacks occupy an uncomfortable middle ground for most security teams. They are methodical enough to evade lockout thresholds, patient enough to defeat simple velocity rules, and common enough that every enterprise environment will face them repeatedly. Yet detection rates remain low across the industry, not because defenders lack the tools, but because the attack behavior deliberately mimics legitimate user activity at the individual account level.
The core mechanics are straightforward. Rather than hammering a single account with many passwords (the brute force approach that triggers lockouts), a spray attack rotates through a large list of valid usernames and tries one or two common passwords against each. From any single account's perspective, nothing unusual happened. The detection challenge lives at the aggregate layer, and that is precisely where most authentication logging setups fall short.
This matters now because credential exposure continues to accelerate. The FortiBleed campaign, which exposed credentials for over 73,000 FortiGate systems, illustrated how harvested credentials fuel follow-on attacks. Actors who obtain username lists from prior breaches, phishing campaigns, or OSINT work immediately attempt password spray operations against enterprise environments, knowing that a subset of those accounts will have weak or reused passwords.
What Password Spray Traffic Actually Looks Like in the Logs
Before building detection logic, you need a clear picture of the signal. Password spray attacks generate a distinctive pattern when you look at authentication data at the aggregate level rather than the per-account level.
The Horizontal Authentication Pattern
In a normal login environment, failed authentication events cluster around individual users who forgot their password, are locked out, or are hitting MFA friction. A spray attack inverts this entirely. You see a moderate number of failures distributed broadly across many accounts, often hundreds or thousands of distinct usernames, within a compressed time window. Each individual account might show only one or two failures, which falls well below any per-account lockout threshold.
The key metrics to track are the ratio of unique accounts touched per authentication source, the time delta between attempts against different accounts from the same source, and the consistency of the password attempts (sprayers typically try passwords like Season+Year formats, company name variants, or passwords confirmed as common in prior breach datasets).
Source Behavior Patterns
Less sophisticated spray campaigns originate from a single IP address or a small range. More advanced operators, including the nation-state affiliated groups documented in recent threat intelligence reporting, distribute their spray traffic across cloud-hosted infrastructure, residential proxies, and compromised endpoints to defeat source-based detection.
The FortiBleed credential exposure reinforces this concern directly. When threat actors obtain working VPN credentials, they can conduct spray operations from within trusted network ranges, making source IP reputation largely irrelevant as a detection signal. This is the scenario where behavioral detection logic must carry the load.
Building Detection Logic That Catches What Velocity Rules Miss
The most common gap in spray detection is the assumption that authentication anomalies will surface through per-account velocity rules alone. They will not. Effective detection requires layering multiple detection dimensions.
Aggregate Failure Rate Per Source
Start with the broadest signal. Across all authentication sources, calculate the number of unique accounts receiving failed login attempts per source IP, ASN, or user agent within a rolling time window. A threshold of fifteen or more distinct accounts failing authentication from a single source within sixty minutes is worth investigating immediately in most enterprise environments. Adjust this based on your baseline — some helpdesk-adjacent systems legitimately touch many accounts.
Implement this in your SIEM or log aggregation platform with a query that groups failed authentication events by source, counts distinct target accounts, and fires an alert when that distinct count crosses your threshold. The window matters. A sixty-minute rolling window catches faster sprayers; a four-hour or eight-hour window catches the slow-and-low operators who deliberately stay under short-window thresholds.
Password Frequency Analysis Across Accounts
This signal requires that your authentication platform logs the attempted password or, in Kerberos environments, the encryption type and ticket behavior. Where plaintext password logging is infeasible, focus on hash patterns or apply this logic to cloud identity provider logs where more context is available.
When the same password string appears across failed attempts against five or more distinct accounts within a time window, that is a high-confidence spray indicator. Even a single shared attempted password across ten or more accounts should trigger immediate investigation.
User Agent and Protocol Consistency
Spray tools often use consistent user agent strings or connect via legacy authentication protocols like IMAP, POP3, or basic authentication over Exchange Web Services. Legacy protocols are particularly valuable as a detection layer because modern users rarely authenticate through them, and attackers specifically target these pathways because they bypass MFA in many configurations.
Build a detection rule that alerts on any successful or failed authentication via legacy protocol from an account that primarily authenticates through modern flows. A user who authenticates via Outlook and the browser suddenly receiving authentication attempts via basic auth against Exchange Web Services represents a concrete signal worth investigating.
Active Directory and Azure AD Specific Indicators
The environment you are defending shapes which log sources carry the most signal. On-premises Active Directory and Azure AD each have specific event patterns that expose spray activity.
On-Premises Active Directory
Event ID 4625 (failed logon) is the primary signal, but the fields matter as much as the event code. Focus on Logon Type 3 (network logon) failures, which represent remote authentication attempts rather than local console activity. Within those events, track the Failure Reason field. A spray operation generates primarily code 0xC000006A (wrong password) rather than 0xC0000064 (username does not exist), because spray operators work from validated username lists.
A spray detection query against Active Directory Security logs should group 4625 events by source IP, filter for Logon Type 3 and Failure Reason 0xC000006A, count distinct target account names, and alert above your threshold. Correlate this with 4768 (Kerberos pre-authentication) and 4771 (Kerberos pre-auth failure) events for Kerberos-based spraying, which is increasingly common as attackers target environments that have disabled NTLM.
Azure AD and Entra ID
Microsoft's cloud identity platform logs spray activity in the Sign-in logs within the Azure portal, accessible via Microsoft Entra admin center or through the Log Analytics workspace if you have the diagnostic settings configured to forward. The relevant signals are the Result Type field (50126 for invalid password), the IP address of the authentication attempt, and the Client App field, which surfaces legacy protocol usage.
Microsoft also generates risk detections automatically. The detection type labeled Password Spray in Identity Protection is worth reviewing, but it should supplement your own detection logic rather than replace it. Microsoft's detection introduces latency, and the alert surface area it covers depends on your license tier.
Conditional Access policy gaps accelerate spray impact. If MFA is not enforced for all users, particularly for legacy authentication clients, a successful spray attempt yields immediate account access without any additional friction. Audit your Conditional Access policies quarterly with specific attention to authentication flows that bypass MFA.
What to Do Today, This Week, and This Quarter
Immediate Actions (Today)
Pull the last thirty days of authentication failure logs and run a manual aggregate query grouping failures by source IP and counting distinct target accounts. This single query will surface spray activity that may already have occurred in your environment. Many teams discover historical spray campaigns through this exercise that generated no alerts at the time.
Review your MFA enforcement posture for legacy authentication protocols. If any user in your environment can successfully authenticate to email, SharePoint, or any cloud application via basic auth or IMAP without MFA, that pathway needs to be blocked or MFA-enforced immediately. The spray operators actively enumerate these gaps.
Check whether your SIEM has an active rule for horizontal authentication failures. If it does, when did you last validate that it fires correctly? If it does not, write one today. It does not need to be perfect. A basic rule that alerts on twenty or more distinct account failures from a single source within an hour gives you something to work with and refine.
This Week
Implement or review your named locations and trusted IP ranges in Azure AD Conditional Access if you use Entra ID. Authentication from outside trusted ranges warrants additional scrutiny and can be configured to require stronger authentication factors. This does not prevent spray attacks, but it increases the friction for attackers operating from cloud infrastructure.
Enable and review Azure AD Identity Protection risk policies if they are not already active. Configure the user risk policy to require password change at high risk level and the sign-in risk policy to require MFA at medium and above. These policies add automated response to detections without requiring analyst intervention for every alert.
For on-premises environments, verify that audit policy settings generate the events your detection rules depend on. Specifically, confirm that Account Logon and Logon/Logoff audit subcategories are configured to capture both success and failure events. A common gap is SIEM rules built on event IDs that are never actually generated because the audit policy does not enable them.
This Quarter
Develop a spray-specific detection baseline for your environment. Run a two-week collection period where you capture daily metrics: total failed authentication events, unique accounts failing per source, and unique sources generating failures. This baseline tells you what normal looks like, which lets you set detection thresholds that reflect your actual environment rather than generic industry recommendations.
Evaluate whether your authentication infrastructure can support real-time alerts with sub-five-minute latency. Spray attacks often conclude or transition to exploitation within thirty to sixty minutes of a successful credential validation. Detection that takes hours to fire leaves you responding to a breach rather than preventing one.
Build a tabletop exercise around the scenario of a spray attack originating from a trusted VPN range (simulating the FortiBleed scenario), where the source IP bypasses geographic and reputation-based detection. Walk your team through which detection layers would still fire, which would not, and what the investigation workflow looks like when the source appears legitimate.
Responding When the Alert Fires
Detection without a clear response workflow creates alert fatigue and missed opportunities to interrupt attacks in progress. When your spray detection alert fires, the investigation sequence should be consistent and fast.
First, identify the scope. How many accounts were targeted? Which accounts received multiple failed attempts? Are any of those accounts privileged? Pull the full list of targeted accounts from the relevant time window and cross-reference against your privileged account inventory.
Second, determine whether any spray attempts succeeded. A failed spray still tells you an attack occurred; a partially successful spray tells you you have compromised accounts in your environment. Query for successful authentications from the same source IP or ASN within the spray window, and check whether any targeted accounts authenticated successfully shortly after the spray concluded, even from a different source (attackers sometimes use one infrastructure for spraying and different infrastructure for post-compromise access).
Third, enforce account protection. For accounts that were targeted by the spray (especially those with successful logins), initiate a forced password reset and MFA re-registration review. For privileged accounts that appeared in the spray target list, consider temporary additional controls regardless of whether authentication succeeded.
Fourth, preserve and document. Capture the full authentication log data associated with the spray window before log retention policies purge it. This data supports incident response, potential legal action, and retrospective analysis to improve your detection rules.
Where Spray Detection Breaks Down Under Pressure
Several real-world conditions reduce the effectiveness of spray detection logic even when it is well-constructed.
Distributed spraying across many source IPs defeats per-source thresholds entirely. Sophisticated actors using residential proxy networks or large botnets can distribute spray attempts such that no single source exceeds any reasonable per-source threshold. Detection at this level requires cross-source aggregation, looking at the pattern of targeted accounts across all sources simultaneously, which is computationally heavier but necessary for detecting advanced operators.
High user populations generate authentication noise that masks spray signals. In environments with tens of thousands of users, daily authentication failure volumes are substantial. Spray campaigns with conservative pacing can hide within that noise unless your detection specifically isolates the horizontal spread pattern rather than relying on failure volume alone.
Spray attacks that target accounts not yet in your identity management system (accounts created via shadow IT, deprecated service accounts, or external identities) may generate failures that your detection infrastructure does not capture, because those authentication events route through systems outside your central log collection.
The AI supply chain concerns surfacing in recent threat intelligence, including the kinds of attack chains highlighted in research around OpenClaw's emerging AI marketplace risks, add another dimension. As AI-assisted attack tools lower the barrier for sophisticated multi-phase campaigns, spray attacks are increasingly the initial phase of a longer kill chain rather than the primary attack vector. Defenders who detect and investigate spray activity thoroughly, rather than just blocking the source IP and closing the alert, have a better chance of interrupting the broader campaign before it progresses to data access or lateral movement.
Making Detection Sustainable
Password spray detection is not a project with a completion date. It requires ongoing tuning as your user population changes, your authentication infrastructure evolves, and attacker tactics adapt. The teams that sustain effective spray detection treat it as an operational discipline rather than a one-time configuration.
Review your spray detection rules quarterly against the latest threat intelligence. When new credential exposure events occur, update your assumptions about what usernames attackers might be working from. When new attack tooling surfaces, test your detection rules against the timing and distribution patterns that tooling uses.
Correlate spray detection with your broader threat intelligence workflow. A spray detection alert becomes significantly more actionable when the source IP maps to known malicious infrastructure, the targeted usernames align with a recent breach dataset, or the timing correlates with campaigns observed in threat intelligence feeds. Building these correlations into your investigation playbook rather than leaving them as manual analyst tasks reduces response time and improves consistency.
Password spray attacks succeed when defenders treat authentication failures as routine noise. The teams that consistently detect and respond to spray activity have made a deliberate choice to treat aggregate authentication behavior as a primary security signal, invested in the detection logic to surface that signal reliably, and built response workflows that move faster than the attack can complete.
