A Monday Morning, Forty Accounts, and One Alert That Almost Nobody Saw
At 6:47 AM on a Monday, an authentication platform serving a mid-sized financial services firm recorded forty-three failed login attempts spread across forty-three distinct user accounts. Each attempt used a different source IP. Each came within a twelve-minute window. The passwords tried were variations of Summer2024! and Welcome1@. The SIEM generated a low-severity alert that sat in a queue behind nineteen other items. By 9:15 AM, two accounts had authenticated successfully. The attacker was already inside.
This scenario plays out across industries every week. The ESET Threat Report H1 2026 confirms that identity-based attacks have surpassed vulnerability exploitation as the leading entry vector for ransomware deployments. The 0ktapus campaign, which compromised over 130 organizations, leaned heavily on password spraying as its initial foothold mechanism before pivoting into phishing and session hijacking. Understanding how spray campaigns operate at the infrastructure level, and how detection logic needs to be constructed to catch them, is no longer optional for security operations teams.
What Password Spraying Actually Looks Like in Authentication Telemetry
Password spraying differs from credential stuffing and brute force in a specific and consequential way. Where brute force attacks hammer a single account repeatedly, and credential stuffing replays known username-password pairs from breach datasets, password spraying applies one or a handful of commonly used passwords across a large number of accounts. The goal is to stay beneath per-account lockout thresholds while still achieving successful authentication against statistically probable weak credentials.
The signature in authentication logs reflects this structure. You will see a pattern where a single password appears across many usernames in a compressed time window, originating from either a single IP or a distributed set of IPs if the attacker is using proxy infrastructure. The volume per account is low. Typically one to three attempts per account before moving on. The velocity across accounts is what creates the detectable signal, but only if your detection logic is looking at the population of accounts rather than the behavior against any individual account.
Many organizations configure their SIEM alerts around per-account thresholds. Five failed attempts on a single account triggers a lockout and an alert. That logic is designed for brute force. Against spray, it generates nothing, because no single account ever crosses the threshold. The attacker knows this. It is a deliberate design choice in how spray tooling works.
The Infrastructure Attackers Use to Distribute Spray Attempts
Modern spray campaigns rarely originate from a single IP address. Threat actors operating at scale use residential proxy networks, compromised cloud infrastructure, and in some cases botnets assembled from IoT devices. The recent disclosure that cybercriminals are actively selling access to Chinese surveillance cameras points directly at the kind of infrastructure that ends up in botnet pools used for distributed authentication attacks. A compromised camera with an outbound connection becomes one more node in a spray grid.
When spray attempts are distributed across dozens or hundreds of IPs, per-IP rate limiting and IP reputation blocking catch only a fraction of the traffic. Each individual source IP may send one or two authentication attempts, well below any threshold that would trigger a block or alert. The detection surface shifts from the IP layer entirely to the application layer, specifically to the authentication event data itself.
VPN and proxy services add another layer of obfuscation. Attackers route attempts through residential proxies specifically because residential IP addresses carry lower suspicion scores in most threat intelligence feeds and IP reputation databases. A spray campaign routed through residential proxies will look, from a raw IP perspective, like authentication attempts from legitimate users across multiple geographies. Your threat intelligence feed will not flag those IPs. Your geo-blocking rules will not fire. The signal is buried entirely within the authentication event pattern.
Building Detection Logic That Catches Spray Patterns
Effective spray detection requires shifting the analytical frame from individual account behavior to aggregate authentication behavior across your user population. The following detection approaches provide meaningful coverage when implemented correctly.
Horizontal Authentication Failure Counting
The core detection query for password spraying counts the number of distinct accounts that experience authentication failures within a sliding time window. A threshold of twenty or more unique accounts failing within a fifteen-minute window, originating from any source IP or small IP range, warrants immediate investigation. This logic catches single-source spray attempts directly.
For distributed spray, you extend this logic to look at the credential side rather than the source side. If the same password string appears in authentication failures across fifteen or more accounts within an hour, regardless of the originating IPs, that is a spray signature. Most SIEM platforms support this query structure, but it requires that your authentication logs capture the attempted credential, not just the account name and result code. Verify that your identity provider is logging attempted passwords in a format accessible to your SIEM before building this detection.
Time-of-Day and Baseline Deviation Analysis
Authentication events have predictable population-level patterns. Failed authentication attempts during business hours follow a distribution shaped by users mistyping passwords after coffee. Failed attempts at 3 AM on a Sunday against forty accounts in twelve minutes do not match that baseline. Behavioral baselining that tracks authentication failure rates by hour of day and day of week, then alerts on deviations exceeding two or three standard deviations from the baseline, catches spray campaigns that operate outside normal working hours. Attackers targeting US organizations from overseas infrastructure frequently operate during hours that are business hours in their time zone but off-hours for the target.
User Agent and Client Fingerprint Analysis
Automated spray tooling often presents consistent user agent strings across authentication attempts, or presents no user agent at all against APIs that accept direct authentication requests. Collecting and analyzing user agent diversity across authentication failures provides a supplementary signal. A wave of failures sharing an identical user agent string across dozens of accounts points toward automation even when the source IPs vary. This is not a standalone detection, but it enriches the case when combined with horizontal failure counting.
Password Commonality Scoring
If your authentication logs include attempted passwords, you can score incoming authentication attempts against a list of commonly sprayed credentials. Passwords like Welcome1, Password1!, Summer2024, Company@2024, and seasonal variants appear repeatedly in spray campaigns because they match default password policies at many organizations while remaining guessable. A detection rule that fires when a known spray-pattern password appears against more than ten accounts in a short window provides early warning before the attacker achieves any successful authentications.
What Your Identity Provider Logs Must Contain
Detection quality is entirely dependent on log fidelity. Many organizations discover during incident response that their authentication logs lack fields that would have made detection straightforward. Before building spray detection, audit what your identity provider is actually logging and confirm that the following fields are present and flowing into your SIEM.
- Source IP address at the application layer, not just the network layer. When authentication requests pass through load balancers or reverse proxies, the network-layer source IP may be the proxy, not the client. Confirm that the X-Forwarded-For header or equivalent is being captured and parsed.
- Account identifier for both successful and failed attempts. Some configurations only log the account on success.
- Authentication result code with enough granularity to distinguish invalid password from invalid account, account locked, and MFA failure. These distinctions matter for triage.
- Timestamp with millisecond precision to support accurate velocity calculations in detection queries.
- Application or service identifier when your environment has multiple authentication endpoints. Spray campaigns often target specific services like VPN portals, email gateways, or remote desktop gateways where MFA may not be enforced uniformly.
- Device or client identifier where available, including user agent strings for web-based authentication and client certificate information for certificate-based flows.
Organizations running Microsoft Entra ID should verify that the SignInLogs and NonInteractiveUserSignInLogs tables in Log Analytics are both flowing. Spray attempts against legacy authentication protocols like SMTP AUTH and basic authentication over Exchange show up in NonInteractiveUserSignInLogs and get missed entirely if that table is not being monitored. This is a documented gap that threat actors targeting Exchange environments actively exploit.
MFA Does Not Eliminate the Risk, It Reshapes It
A common assumption is that MFA deployment renders password spraying irrelevant. MFA substantially reduces the impact of a successful spray, but it does not eliminate the attack or the detection requirement. Spray campaigns against MFA-protected environments still cause account lockouts, consume help desk resources, and generate noise that can obscure other malicious activity. More importantly, several factors allow spray attacks to succeed even against MFA-protected accounts.
Legacy authentication protocols frequently bypass MFA entirely. If your organization allows basic authentication against Exchange Online, IMAP, or POP3, those endpoints remain vulnerable to credential-only authentication regardless of your MFA policy for modern authentication flows. Attackers specifically target legacy protocol endpoints for this reason.
MFA fatigue attacks pair with spray to convert a successfully sprayed credential into a session. The attacker authenticates with the correct password, triggers an MFA push notification, and sends repeated push requests until the user accepts out of confusion or frustration. The 0ktapus campaign used exactly this technique after obtaining credentials through phishing and credential spraying operations.
Conditional access policies with gaps leave some authentication paths unprotected. Service accounts, break-glass accounts, and applications integrated before MFA enforcement was standardized may have authentication paths that bypass your MFA policies. A thorough audit of conditional access policy coverage should be part of any spray defense posture review.
Response Actions When Spray Detection Fires
When a spray detection alert triggers, the response sequence needs to move faster than most organizations default to for medium-severity alerts. The window between first spray attempt and first successful authentication can be very short, particularly if your user population includes accounts with passwords matching common spray patterns.
Immediate Triage Steps
Pull the full list of accounts targeted in the detected spray window. Check each account for successful authentications occurring after the failed attempts. A successful authentication following spray activity against the same account is the highest-priority finding and should immediately escalate to incident response. Run the source IPs through threat intelligence lookups, but treat clean results cautiously. Residential proxy IPs and recently provisioned cloud instances frequently show no reputation history even when actively used for malicious activity.
Examine the targeted accounts for commonalities. Spray campaigns sometimes target specific organizational units, roles, or account naming conventions. If the spray is concentrated against accounts with a particular prefix or belonging to a specific department, that information shapes both the immediate response and the broader investigation into how the attacker obtained the account list.
Containment Actions
For accounts that authenticated successfully during or after a spray window, initiate immediate session revocation and force password reset. In Microsoft Entra ID, this means revoking refresh tokens as well as invalidating the current session, since refresh tokens can persist and be used to obtain new access tokens even after a session is terminated. Notify affected users through an out-of-band channel, not through email if email access may have been compromised.
Block the identified source IPs at your edge and within your identity provider's named locations or conditional access policies. Simultaneously, implement a temporary block on the specific passwords used in the spray campaign within your identity provider's banned password list if your platform supports dynamic updates to that list.
Review conditional access policies for any authentication paths that the spray campaign used successfully. If the attacker got in through a legacy authentication endpoint, disable that protocol for the affected accounts and initiate a broader review of legacy authentication exposure across the tenant.
Post-Incident Analysis
Once immediate containment is complete, analyze the spray campaign data to build detection improvements. Identify which detection rules fired and at what point in the campaign timeline they produced an alert relative to when the first attempt occurred. Identify whether any successful authentications occurred before any alert fired, and trace that gap back to specific log fields or threshold configurations that need adjustment.
Document the password patterns used in the campaign and add them to your banned password list and to your spray detection keyword watchlist. Spray campaigns frequently reuse password patterns across multiple targets, so the passwords observed in one campaign are likely to appear again in future attempts against your environment or environments in your industry.
Connecting Spray Detection to Your Broader Identity Threat Program
Password spray detection does not operate in isolation. It sits within a broader identity threat detection program that should include monitoring for credential stuffing, account takeover indicators post-authentication, privilege escalation following successful login, and anomalous session behavior. The shift in the threat landscape documented in recent reporting confirms that identity compromise is the dominant initial access technique for ransomware operators. Spray detection is one control layer in a defense-in-depth identity program, and its effectiveness depends on the other layers functioning correctly.
Organizations running mature threat hunting programs can use spray detection data proactively. When a spray campaign is detected and blocked, the account list targeted by the attacker has intelligence value. That list tells you which accounts the attacker considered worth targeting, which can reveal information about reconnaissance activity that preceded the spray, whether through employee directory scraping, LinkedIn enumeration, or prior breaches exposing your username format.
As AI-assisted attack tooling becomes more capable, spray campaigns will become more adaptive. AI agents used by threat actors can adjust password lists in real time based on partial success signals, modify timing to evade velocity-based detection, and rotate proxy infrastructure at a pace that outstrips manual IP blocking. Security teams need detection logic built around behavioral invariants of the attack technique rather than specific tools or infrastructure, because the infrastructure will change faster than blocklists can track. The behavior of attempting low-frequency authentication across a wide account population remains constant regardless of the tooling used to execute it.
Practical Hardening Steps That Reduce Spray Exposure
Detection catches spray campaigns in progress. Hardening reduces the probability of successful authentication and shrinks the window in which the campaign can operate before being detected and stopped.
- Enforce a banned password list that includes seasonal patterns, company name variations, and known spray-campaign passwords. Microsoft Entra ID's custom banned password list supports this directly. Active Directory environments can implement similar controls through third-party password filter solutions.
- Disable legacy authentication protocols across your environment. If SMTP AUTH, basic authentication, and similar protocols are not required for business operations, block them at the identity provider level. This eliminates the authentication paths that bypass MFA.
- Implement smart lockout with extended observation windows. Standard lockout policies trigger on per-account thresholds within short windows. Smart lockout features in modern identity providers can extend the observation window and apply lockout based on risk signals beyond simple failure counts.
- Deploy passwordless authentication where possible. FIDO2 hardware keys and platform authenticators eliminate the password as an authentication factor entirely, making spray attacks structurally irrelevant for protected accounts.
- Require MFA for all authentication paths including service accounts where feasible, and implement certificate-based or workload identity federation for service-to-service authentication to eliminate password-based service account exposure.
- Conduct regular password audits against your Active Directory using tools that hash and compare existing passwords against known spray-pattern wordlists. Accounts carrying passwords matching common spray patterns are your highest-risk population and should be prioritized for forced resets.
Password spray detection is not a single rule and a dashboard. It is a detection discipline that requires log fidelity, population-level analytical logic, response playbooks tested against realistic timelines, and hardening controls that reduce the attack surface the spray campaigns are working against. The organizations that caught spray campaigns on day one share a common characteristic: they built their detection around how the attack actually behaves, not around how they assumed it would behave.
