Password Spray and Credential Stuffing Defense: Stopping the Attack That Hits Every Azure AD Tenant

Password spray and credential stuffing are frequently grouped together as 'brute force attacks,' but they have meaningfully different attack mechanics and require different detection logic. Conflating them leads to detection gaps because the signatures are different.

Password spray is the many-to-one pattern: a small number of common passwords tested against a large number of accounts. The attacker's goal is to find any account using a predictable password, and the attack is specifically designed to avoid triggering per-account lockout policies by staying below the failed login threshold per account. In a tenant with 10,000 users and a lockout threshold of 10 failed attempts, an attacker can test one password against all 10,000 accounts before any account locks. Then they wait a few minutes and test another password. At scale, with automated tooling, they can test dozens of passwords against a full tenant without triggering a single lockout event. The detection signature is: many unique accounts with one or two failed login attempts each, within a compressed time window, often from shared infrastructure.

Credential stuffing is the one-to-many pattern: a large database of username-password pairs obtained from prior breaches, tested against the target service. The attacker already knows the password associated with each account from a prior breach and is testing whether the user reused that same password at the current target. The detection signature is different: individual accounts with single failed login attempts followed by either a successful login or continued failures, and the username-password pairs are sourced from public breach databases that you can actually check against. HIBP and similar services let you verify whether a specific credential pair has appeared in a known breach.

Understanding this difference matters for detection tuning. Spray attacks are caught by looking at the distribution of failed logins across accounts in a time window. Stuffing attacks are caught by comparing login attempts against breach databases and looking for single-attempt failures from known malicious IP infrastructure. Building detection rules that conflate the two produces both false positives and false negatives.

Microsoft Entra ID Smart Lockout is a valuable control, and you should configure it correctly, but understanding its limitations prevents the dangerous assumption that enabling it makes you immune to spray attacks. Smart Lockout locks an account after a configurable number of failed authentication attempts, with the default threshold set at 10 failed attempts. The problem is that spray attacks are specifically engineered to operate below this threshold.

A sophisticated spray campaign will test one or two passwords per account per hour, spread across hundreds of IP addresses from compromised infrastructure or residential proxy networks. From Smart Lockout's perspective, each account has only one or two failed attempts, which never triggers lockout. The attack is invisible to the lockout mechanism because the mechanism operates at the per-account level and the attack distributes its probing across thousands of accounts simultaneously. Smart Lockout also has a secondary limitation: it operates on the IP dimension as well, which means attackers using IP rotation across a large proxy pool can circumvent the source-based blocking component entirely.

Smart Lockout is still worth configuring correctly because it stops unsophisticated spray tooling that does not implement throttling. Set the lockout threshold to 3 to 5 failed attempts for high-security environments, rather than accepting the default of 10. Set the lockout duration to at least 60 seconds and preferably longer for repeat lockout events. Configure Named Locations in Entra ID to exclude your corporate IP ranges from lockout counting, since internal IT helpdesk password reset attempts should not contribute to lockout counters. These configuration changes improve Smart Lockout's effectiveness against less sophisticated attackers while you deploy the detection and Conditional Access controls that address the sophisticated campaigns.

The detection query for password spray in Azure AD sign-in logs targets the distribution of failed logins across accounts within a compressed time window. A normal day of authentication activity shows many failed logins concentrated in a small number of accounts, typically users who forgot their password or are on a new device. A spray attack shows a large number of accounts each with a small number of failed logins, which inverts the normal distribution.

In Microsoft Sentinel or Log Analytics, the core query builds a histogram of failed logins by UserPrincipalName over a rolling 10-minute window, then alerts when the count of distinct UserPrincipalNames with failed logins exceeds a threshold. A starting threshold for a mid-size organization is 20 distinct accounts with failed logins within 10 minutes from the same source IP or IP block. Adjust the threshold based on your baseline: run the query against 30 days of historical sign-in log data to establish what the normal distribution looks like before setting alert thresholds.

The query also needs to look for spray from distributed IP infrastructure, where no single IP exceeds the threshold. Add a secondary query that looks for accounts with failed logins from more than 3 distinct IP addresses within a 30-minute window that then succeeds from a new IP or device. This pattern catches spray activity where the attacker uses IP rotation to stay below per-IP thresholds. Supplement these queries with Microsoft Entra ID Protection's built-in spray detection, which uses behavioral models trained on Microsoft's global telemetry and will detect spray campaigns that individual tenant queries miss because they rely on cross-tenant signals.

For credential stuffing specifically, enable the Entra ID Protection leaked credentials detection feature, which checks user credentials against Microsoft's breach database, sourced from monitoring dark web credential dumps and paste sites. Accounts flagged by leaked credentials detection should trigger an automatic password reset and MFA challenge, not just an alert. An alert without an automated response means a human has to act within a narrow window before the attacker tries the breached credential.

Legacy authentication protocols, SMTP, POP3, IMAP, Basic Auth over Exchange Web Services, are the spray attacker's preferred vector because they do not support MFA. An attacker who successfully identifies a valid username-password pair can authenticate via these protocols and completely bypass MFA enforcement in Conditional Access policies that target modern authentication flows. Microsoft's own data indicates that over 97% of credential stuffing attacks target legacy authentication endpoints specifically because of this MFA gap.

Blocking legacy authentication with Conditional Access is one of the highest-value controls you can deploy against both spray and stuffing attacks. Create a Conditional Access policy scoped to all users and all cloud apps that blocks all legacy authentication client types. The condition in Entra ID is 'Client apps: Exchange ActiveSync clients' and 'Other clients' (which covers legacy auth protocols). Before enabling the block, run the policy in report-only mode for two to four weeks and review the sign-in logs for legitimate legacy authentication usage. Common legitimate sources are older Outlook clients, conference room systems with calendar integration, and automated email workflows. These need to be migrated off legacy authentication before the block is enforced, because the block will break them.

The second Conditional Access configuration is risk-based sign-in policies through Entra ID Protection. These policies evaluate each sign-in against Microsoft's behavioral models and assign a risk score of low, medium, or high. Configure a Conditional Access policy that requires MFA re-authentication for medium-risk sign-ins and blocks access entirely for high-risk sign-ins until the risk is remediated. High-risk sign-ins from Entra ID Protection typically indicate that the sign-in matches known malicious IP infrastructure, anonymous proxy usage, or known spray campaign patterns. Blocking high-risk sign-ins stops spray campaigns that successfully guess a password from completing the authentication by requiring additional verification the attacker cannot provide.

Entra ID Password Protection addresses the root cause of spray attack success: users choosing predictable passwords from the attacker's shortlist. Even with all the detection and Conditional Access controls in place, an organization where users can set passwords like Spring2024! will eventually have a spray victim. Password Protection prevents those passwords from being set in the first place.

Entra ID Password Protection consists of two components: a global banned password list maintained by Microsoft, updated based on real-world spray attack data from across the Microsoft tenant ecosystem, and a custom banned password list that you define. The global list automatically blocks the passwords that appear most frequently in Microsoft's spray telemetry. The custom list lets you block organization-specific predictable passwords: your company name, your city, your products, your CEO's name, which are all commonly used by employees and commonly tested by attackers who have done basic OSINT on the target.

For hybrid environments with on-premises Active Directory, Password Protection can be deployed via a proxy agent that enforces the banned password policy on on-premises AD domain controllers. This is important because a significant portion of enterprise environments still use hybrid identity where passwords are set on-prem and synced to Entra ID. Without on-prem enforcement, a user can set a banned password on-prem and it will sync to Entra ID despite the cloud policy.

Breach password detection through HaveIBeenPwned integration provides an additional layer that catches passwords that appear in breach databases but are not on the spray attacker's common password shortlist. The HIBP k-anonymity API lets you check whether a password hash prefix has appeared in known breaches without sending the full hash. For organizations with development resources, integrating HIBP checks into your password reset workflow ensures that users cannot set passwords to values already present in known breach databases, which closes the credential stuffing attack surface independent of whether the specific breach database the attacker is using is in HIBP's coverage.

When a spray or stuffing attack succeeds and an account is compromised, the investigation workflow differs from a typical malware incident in important ways. The initial access was authenticated, which means most security controls that look for malicious processes or network connections were not triggered at the point of entry. The investigation starts from identity signals rather than endpoint signals.

Begin with the Entra ID sign-in logs for the compromised account. Review the full sign-in history for the 30 days preceding the compromise detection, looking for unusual sign-in locations, device types, or times. Note the first sign-in from the attack infrastructure: that timestamp is your earliest possible start of the compromise window. Review the Microsoft 365 audit log for all actions taken by the account during the compromise window, including email access, file access, SharePoint activities, Teams messages sent, forwarding rules created, and OAuth applications consented to by the account.

Mail forwarding rules and OAuth application consent are the two most common first actions an attacker takes after compromising a Microsoft 365 account. An inbox forwarding rule to an external address silently copies all incoming email to the attacker without triggering any standard alert. An OAuth consent to a malicious application grants the application persistent access that survives a password reset if the consent is not also revoked. Check both explicitly before declaring the account remediated.

Remediation requires more than a password reset. Revoke all active sessions for the account, remove any forwarding rules or inbox rules created during the compromise window, review and remove any OAuth application consents granted to unfamiliar applications, review and remove any added authentication methods (phone numbers, authenticator apps) that were added after the compromise timestamp, and review any configuration changes the account made if it had administrative privileges. Password reset without the session revocation and cleanup steps leaves the attacker with active access through existing sessions and persistence mechanisms.

Organizations running Okta as their primary identity provider have an equivalent set of controls to configure for spray and stuffing defense. The Okta-specific implementations differ from Entra ID but provide comparable protection when properly configured.

Okta ThreatInsight is the platform's primary spray detection control. When enabled, ThreatInsight evaluates each authentication request against Okta's global threat intelligence network, which aggregates attack telemetry across all Okta tenants. This cross-tenant visibility is a significant advantage: an IP address conducting spray attacks against another Okta tenant before targeting yours will already be flagged by the time it reaches your environment. ThreatInsight can be configured in audit-only mode, which logs detections without blocking, or in enforcement mode, which either challenges suspicious sign-ins with MFA or blocks them outright. Configure enforcement mode with MFA challenge rather than outright block as a starting point to avoid false-positive lockouts while collecting baseline data.

Okta's org-wide rate limiting adds a second layer by setting a global threshold on authentication requests per second at the organization level. When the threshold is exceeded, Okta returns a 429 response to authentication requests, which throttles automated spray tooling without impacting individual users. Configure rate limiting thresholds based on your normal authentication volume during peak business hours, with headroom above the peak but well below what automated spray tooling would generate. Review your rate limiting logs monthly to detect attempts to probe the threshold boundaries.

Okta Identity Threat Protection (ITP), the premium tier offering, adds continuous session evaluation that monitors authenticated sessions for risk signals beyond the initial authentication event. If a session generates risk signals post-authentication, such as accessing from a new location or device fingerprint change, ITP can re-challenge the session with MFA or terminate it entirely. This addresses the scenario where an attacker authenticates during a normal working day and then shifts their activity pattern in ways that suggest account compromise, which standard per-login controls would miss entirely.