The Breach Nobody Saw Coming — Until the Damage Was Done
In early 2025, a mid-sized regional healthcare network discovered that an attacker had been systematically testing credentials across its Microsoft 365 tenant for nine days before triggering a single alert. The attacker had accessed billing records, patient scheduling data, and internal HR documents before a routine compliance audit — not a security tool — surfaced the anomaly. The method used was a password spray attack, one of the oldest techniques in the adversary playbook and still one of the most reliably successful.
This scenario is not an outlier. As cybercriminals increasingly flock to healthcare businesses — a trend confirmed by multiple threat intelligence reports in mid-2025 — password spray attacks represent a low-noise, high-yield entry method that security teams consistently underestimate. Unlike brute force attacks that hammer a single account with thousands of attempts, password spray distributes a small number of common passwords across a large number of accounts. The math works in the attacker's favor: most organizations enforce lockout policies after five to ten failed attempts on a single account, but they rarely enforce anything meaningful across accounts at the authentication layer.
Understanding why the healthcare network's defenses failed requires looking at what authentication logs actually captured, what detection logic was in place, and where the gaps between telemetry and action created a nine-day window of uncontested access.
What Password Spray Attacks Actually Look Like in Log Data
A password spray attack produces a distinctive but easily missed signature in authentication logs. The attacker attempts one or two passwords against dozens or hundreds of accounts in a short window, then waits before trying again. The waiting period is deliberate — it avoids triggering time-based lockout thresholds and, in many environments, causes log aggregation systems to treat each authentication attempt as an isolated event rather than a coordinated campaign.
In the healthcare case, the attacker cycled through approximately 400 accounts over six-hour intervals, attempting only two passwords per account per cycle. The passwords used — a season-year combination and a common corporate default — matched patterns flagged in credential dumps circulating on cybercriminal forums. The authentication logs showed failed sign-ins, but because each individual account never crossed the lockout threshold, no automated alert fired.
When reviewing authentication logs for spray indicators, security teams should look for the following patterns:
- Multiple distinct accounts experiencing failed authentication attempts within the same short time window, originating from the same IP address or ASN block
- Failed authentications spread across accounts in a way that suggests alphabetical or directory-order enumeration
- Consistent user-agent strings appearing across failures on accounts that would not plausibly share a device or client
- A ratio of failed-to-successful authentications that spikes across the user population rather than concentrating on individual accounts
- Authentication attempts targeting legacy protocols such as IMAP, SMTP AUTH, or basic authentication endpoints that bypass modern MFA enforcement
The last point deserves emphasis. In the healthcare network breach, the attacker specifically targeted the organization's legacy IMAP endpoint, which had been left enabled to support an aging email client used by the radiology department. Modern MFA policies applied to the Microsoft 365 portal did not extend to that legacy authentication path. The attacker never touched the MFA-enforced interface.
Why Detection Logic Breaks Down at the Cross-Account Level
Most SIEM deployments are configured to alert on per-account anomalies. A given account exceeding five failed login attempts in ten minutes triggers an alert. An account logging in from an unusual geography triggers a conditional access policy. These controls are necessary, but they operate on a single-account model that password spray is specifically designed to evade.
Effective spray detection requires correlation across accounts, and that requires intentional detection engineering. The query logic looks different from per-account thresholds. A useful starting point in most SIEM platforms is to aggregate failed authentications by source IP address within a rolling time window, then count distinct target accounts. An IP address that fails authentication against fifteen or more distinct accounts within thirty minutes, even with only one or two attempts per account, represents a high-confidence spray indicator.
Here is a simplified detection rule logic that translates across platforms:
- Filter for authentication failure events (EventID 4625 on Windows, sign-in logs in Azure AD / Entra ID, equivalent fields in Okta or other IdP logs)
- Group by source IP and a rolling 30-minute window
- Count distinct target usernames within that group
- Alert when distinct target count exceeds a configurable threshold, typically 10 to 20 accounts depending on environment size
- Suppress the alert if the source IP is a known internal NAT gateway, but flag it for review rather than dropping it entirely
The suppression caveat matters. Internal NAT gateways and VPN concentrators aggregate traffic from many users behind a single IP, which can generate false positives on a purely IP-based rule. Rather than blanket suppression, security teams should add a secondary check: does the failed authentication activity map to accounts from multiple departments or business units? Legitimate internal traffic producing failures tends to cluster around a single team or application context. A spray originating from inside the network via a compromised endpoint will often show broad account targeting across departments.
The Role of Identity Provider Telemetry
Organizations that rely exclusively on on-premises Active Directory logs for authentication visibility miss a significant portion of the attack surface. Modern hybrid environments generate authentication telemetry in multiple places: on-premises domain controllers, Azure AD / Entra ID sign-in logs, third-party IdP platforms, and application-level authentication logs for SaaS tools that handle their own auth flows.
In the healthcare breach, the nine-day gap existed partly because SIEM ingestion covered the on-premises domain controller logs but not the Entra ID sign-in logs for cloud workloads. The spray succeeded against a cloud-only account that had no corresponding on-premises object, so the activity never appeared in the monitored log source.
Security teams operating hybrid environments should audit log coverage specifically for:
- Entra ID / Azure AD interactive and non-interactive sign-in logs, which are separate log streams and require separate ingestion configuration
- Service principal sign-in logs, which attackers increasingly target when spraying application identities
- Okta System Log, if in use, with attention to the policy.evaluate_sign_on and user.authentication.auth_via_mfa event types
- Application-specific authentication logs for tools like Salesforce, ServiceNow, or Epic that handle their own session management
The Recorded Future Insikt Group and similar threat intelligence operations have repeatedly noted that attackers research their targets' IdP configurations before launching spray campaigns. When the 'Popa' botnet — recently linked to a publicly-traded Israeli firm — was analyzed, researchers found that its credential-testing modules included logic to detect IdP type from publicly observable authentication redirect behavior and adjust attack parameters accordingly. That level of operational sophistication means defenders cannot assume attackers are spraying blindly.
Behavioral Baselines That Make the Signal Stand Out
Static threshold-based detection is a floor, not a ceiling. An organization with 5,000 users will have a different baseline for failed authentication events than one with 200 users. Thresholds set too low produce alert fatigue; thresholds set too high let spray campaigns run undetected. The right answer involves building behavioral baselines for authentication failure rates and alerting on deviations from that baseline rather than fixed counts.
Most SIEM platforms and dedicated UEBA tools support this through statistical modeling. The implementation involves collecting 30 to 90 days of authentication failure data, computing a rolling mean and standard deviation for failure events per hour and per source IP, and triggering alerts when observed values exceed two or three standard deviations above the mean. This approach automatically adjusts for Monday morning login failures after a weekend password reset campaign and accounts for seasonal variation in authentication patterns.
The tradeoff is model drift. If an organization runs an undetected spray campaign for several days before detection logic fires, that activity becomes part of the baseline and suppresses future alerts. This is an argument for keeping a separate, anomaly-hardened baseline computed from known-clean historical windows rather than a continuously updating model that can absorb attack traffic as legitimate noise.
Protocol-Level Controls That Stop Spray Before It Reaches the Log
Detection is only part of the response. Prevention controls at the protocol level significantly reduce the spray surface before the attacker has a chance to succeed.
Disabling legacy authentication protocols is the highest-priority action for most organizations. Microsoft's Entra ID provides Conditional Access policies that block legacy authentication at the tenant level. Organizations that cannot immediately disable legacy auth due to application dependencies should enumerate every application using those protocols, prioritize migration, and apply compensating controls such as IP restriction for legacy auth endpoints during the transition period.
Smart lockout configurations warrant careful tuning. Azure AD Smart Lockout, for example, tracks familiar and unfamiliar sign-in locations separately. The default lockout threshold of ten attempts applies per location type. Security teams should lower this threshold in environments where user accounts are high-value targets, but should account for help desk call volume increases when doing so.
Password policies that prohibit predictable patterns reduce spray success rates materially. The Microsoft Entra ID Password Protection feature maintains a global banned password list and allows organizations to add custom banned terms. Common spray passwords include current year with a capital letter, season-year combinations, and the organization's name with a number suffix. Adding these to a custom banned list removes the lowest-hanging fruit from the attacker's list without requiring users to remember complex random strings.
Hunting Spray Campaigns That Already Have a Foothold
When detection fires late — or when a retrospective audit raises concerns — threat hunters need a structured approach to determine whether a spray campaign succeeded and what access was established.
The hunting workflow starts with identifying the source IP addresses and time windows associated with the spray activity, then pivoting to successful authentications from those same sources. A successful login following a spray pattern from the same IP is a high-confidence indicator of compromise. In the healthcare breach, the attacker successfully authenticated against three accounts; two were immediately used to establish persistence via OAuth application consent, and one was used to access SharePoint document libraries.
Hunters should examine OAuth consent grants created during or after the suspected spray window. Attackers who gain access through a sprayed credential frequently register a malicious OAuth application or grant an existing application elevated permissions, creating a persistence mechanism that survives a password reset. Reviewing the Entra ID audit log for Add OAuth2PermissionGrant and Consent to application events in the window following suspected spray activity is a standard part of this investigation.
Lateral movement indicators are the next layer. Successful spray authentication followed by access to file shares, email inboxes, or internal application APIs suggests the attacker moved beyond the initial account. Correlating authentication success with downstream resource access logs within a 30-minute window surfaces this pattern.
Integrating Threat Intelligence Into Spray Detection
Spray campaigns are rarely one-organization events. The same IP ranges, user-agent strings, and password lists frequently appear across multiple targets in the same campaign window. Organizations that integrate external threat intelligence into their authentication monitoring gain early warning from other victims' detections.
IP reputation feeds provide one signal, but their limitations are well-documented — attackers rotate infrastructure quickly, and many spray campaigns use residential proxies or compromised endpoint infrastructure that does not appear on traditional blocklists. ASN-level analysis provides a useful complement: spray activity from cloud hosting ASNs that have no legitimate reason to authenticate to a corporate identity provider warrants immediate investigation regardless of per-IP reputation scores.
Threat intelligence sharing through ISACs — particularly the Health-ISAC given the current targeting environment — provides timely indicators from peer organizations that allow defenders to build proactive detection rules before campaigns reach their own environment. The surge in healthcare-targeted attacks in 2025 makes this sharing infrastructure more valuable than it has been in previous years. Organizations that treat ISAC membership as a compliance checkbox rather than an active intelligence source miss the operational benefit entirely.
What the Healthcare Network Changed After Day Nine
Following the breach, the healthcare network implemented several changes that addressed both the detection gap and the prevention surface.
They centralized authentication log ingestion from all sources — on-premises AD, Entra ID interactive and non-interactive logs, and Epic's application authentication logs — into a single SIEM workspace. They built cross-account spray detection rules using a 30-minute rolling window with a distinct account threshold of twelve, tuned to suppress known internal NAT addresses while flagging them for weekly review. They disabled legacy authentication protocols across the tenant, migrating the radiology department's legacy email client to a modern alternative within three weeks of the incident discovery.
They also implemented a custom banned password list through Entra ID Password Protection, added user risk policies that require step-up authentication when Entra ID identity protection flags a user as medium or high risk, and enrolled in Health-ISAC for automated threat indicator sharing.
These changes addressed the specific failure modes the spray campaign exploited. The tradeoffs were real: disabling legacy auth generated two weeks of help desk escalations, the SIEM ingestion expansion increased storage costs, and the cross-account detection rule required four iterations of threshold tuning before false positive rates dropped to an acceptable level. Security improvements at this layer are operational as much as they are technical, and teams should plan for the change management burden alongside the technical implementation.
The Practical Takeaway for Security Teams Running Authentication Today
Password spray attacks persist because the detection gap they exploit is structural, not incidental. Organizations that monitor authentication on a per-account basis while ignoring cross-account patterns are building detection logic that matches what the attacker designed around. Closing that gap requires intentional correlation, complete log coverage across all identity providers and authentication endpoints, and behavioral baselines that distinguish normal failure rates from coordinated enumeration.
The healthcare case illustrates how long an attacker can operate inside that gap when the detection architecture has a blind spot. Nine days is long enough to establish multiple persistence mechanisms, exfiltrate sensitive data, and position for a follow-on ransomware deployment. The authentication logs captured everything. The problem was that nobody had built the logic to hear what those logs were saying.
