Password Spraying and Credential Stuffing Guide

Password spraying, credential stuffing and brute force all turn a password-only login into an open door, and each one is built to slip past the controls most organisations rely on. Spraying tries a few common passwords across thousands of accounts so no single account locks; stuffing replays username and password pairs leaked elsewhere; distributed brute force rotates through proxy networks so per-IP limits never trigger. This guide goes deeper than the wider Account Takeover Prevention Guide: it covers credential stuffing defence and password spraying in Active Directory and the cloud, account lockout policy, Entra smart lockout, login rate limiting, detection and response. It is written for identity engineers, SOC analysts and application owners who protect workforce or customer sign-in.

Key takeaways

• Know which attack you are facing. Brute force hits one account with many passwords, spraying hits many accounts with one password, stuffing tests known pairs; signals and controls differ.
• Lockout alone cannot stop spraying. A spray stays under any sensible threshold by design, and a low threshold hands attackers a way to lock out the whole organisation, so pair lockout with rate limiting, risk signals and MFA.
• Remove the easy paths first. Microsoft reports that more than 99 percent of password spray attacks and more than 97 percent of credential stuffing attacks use legacy authentication; blocking it and banning common passwords removes most of the attack surface.
• Detect across accounts, not per account. Spraying shows as many accounts failing from related sources over hours or days; stuffing shows as a falling login success ratio.
• A correct password with a failed MFA prompt is a compromise. Treat it as a confirmed password leak: reset the password, review the account and check for the same source elsewhere.

Brute force, password spraying and credential stuffing compared

MITRE ATT&CK groups these brute force credential attacks under T1110 Brute Force: T1110.001 Password Guessing, T1110.002 Password Cracking (offline, against stolen hashes), T1110.003 Password Spraying and T1110.004 Credential Stuffing. OWASP names credential stuffing OAT-008, "Mass log in attempts used to verify the validity of stolen username/password pairs", mapped to CWE-799 Improper Control of Interaction Frequency.

Low and slow password spraying spaces attempts so each account sees perhaps one try per lockout observation window, and the attacker rotates source addresses. Microsoft described the Midnight Blizzard actor tailoring sprays "to a limited number of accounts, using a low number of attempts to evade detection" from distributed residential proxy infrastructure; the Midnight Blizzard breach began when one such spray hit a legacy test tenant account without MFA.

Credential validation attacks are the step where attackers check which leaked or guessed pairs work before using or selling them. Credential stuffing tools such as OpenBullet and Sentry MBA are automation frameworks that combine a login definition, credential pairs and a proxy list. Defenders should recognise their traffic rather than any one tool: scripted request patterns, mismatched client fingerprints and a flood of unknown usernames. See the Bot Management Guide for the wider automated threat picture.

Where the attacks land

ATT&CK lists SSH (22), FTP (21), SMB (139 and 445), LDAP (389), Kerberos (88), RDP (3389) and MSSQL (1433) among the services sprayed. Targets fall into a few groups, each with its own log source.

• Cloud identity providers: Entra ID, Microsoft 365 and SaaS sign-in, especially legacy protocols that cannot prompt for MFA.
• Federation services: AD FS and similar extranet login pages, where failed attempts are validated against on-premises Active Directory and can lock domain accounts.
• Password spraying in Active Directory: from inside the network, attackers use Kerberos pre-authentication, NTLM or LDAP binds against domain controllers. ATT&CK notes LDAP and Kerberos attempts are less likely to trigger the high-visibility logon failure event 4625, so domain controller events 4771 and 4776 matter more.
• Remote access: VPN portals, RDP gateways and exposed RDP. Valid credentials alone were enough in the SonicWall SSL VPN account compromises.
• SSH brute force: internet-facing Linux hosts and network devices see constant password guessing against root and common account names. Disabling password authentication in favour of keys or certificates (the OpenSSH PasswordAuthentication setting) removes the target entirely; MaxAuthTries limits attempts per connection but not per source.
• Customer login and API endpoints: the main credential stuffing target, often via mobile APIs or reset flows weaker than the web form.

Account lockout, smart lockout and login rate limiting

Account lockout and rate limiting are the brute force protection every authentication system needs, but they stop brute force login attempts on one account, not spraying across many. OWASP frames the design as balancing lockout threshold, observation window and lockout duration without creating a denial-of-service lever.

Active Directory account lockout policy

The account lockout threshold lives at Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy, alongside Account lockout duration and Reset account lockout counter after. The default is 0 (never lock). Microsoft's guidance cites the Windows security baselines' value of 10 as an acceptable starting point and warns plainly that a threshold enables denial of service: an attacker who exceeds it against every user can lock the whole domain without authenticating. Lockout duration must be greater than or equal to the reset counter value. Fine-grained password policies allow different settings for privileged groups and service accounts.

Entra smart lockout

Entra smart lockout is an adaptive account lockout: it locks a cloud sign-in after 10 failed attempts by default (3 in Azure US Government tenants) for an initial 60 seconds, then lengthens the lockout after each further failure, at a rate Microsoft deliberately does not disclose. It keeps separate counters for familiar and unfamiliar locations, so an attacker abroad does not lock out the employee in the office, and ignores repeats of the last three bad password hashes. Locked sign-ins return AADSTS50053. Customising the threshold and duration needs Entra ID P1. With pass-through authentication, hash tracking does not apply, and Microsoft requires the Entra threshold to be lower than AD DS (AD DS two or three times higher) and the Entra duration longer, so the cloud locks the attacker out before the domain account locks. For federated sign-in, AD FS 2016 and later offer Extranet Smart Lockout with the same aim.

Login rate limiting

NIST SP 800-63B-4 section 3.2.2 requires verifiers to limit consecutive failed attempts on an account to no more than 100, and allows bot challenges, wait times that increase as the account approaches the limit, and risk-based techniques using IP address, geolocation, timing and browser metadata. OWASP recommends tying the failure counter to the account rather than the source IP, because proxy networks defeat IP block lists and per-IP rate limits.

Prevention: making guessed and leaked passwords useless

• MFA everywhere a password is accepted: OWASP calls MFA "by far the best defense against the majority of password-related attacks", making it the core credential stuffing mitigation. See the Phishing-Resistant MFA Guide.
• Block legacy authentication: in Entra, a Conditional Access policy targeting All users and All resources, with the Client apps condition set to Exchange ActiveSync clients and Other clients and the grant set to Block access. Microsoft recommends starting in Report-only mode and excluding a break-glass account.
• Ban common and breached passwords: NIST SP 800-63B-4 requires comparing new passwords against a blocklist of commonly used, expected or compromised values, with a 15-character minimum for single-factor passwords. Entra Password Protection applies a global banned list automatically, adds a custom list of up to 1,000 terms (P1 or P2), normalises substitutions such as @ for a, and can be enforced on domain controllers through the DC agent. It removes the very passwords sprays try.
• Check credentials against leak corpora: at registration, password change and, for customer apps, at login. Entra ID Protection's Leaked credentials detection validates leaked material against current password hashes and raises high user risk. ATT&CK mitigation M1018 says to proactively reset accounts known to be in breached credentials. See the Leaked Credential Response Playbook.
• Stop user enumeration: spraying needs valid usernames. OWASP advises identical responses, status codes and timing whether or not the username exists.
• Protect the second factor: NIST requires rate limiting for OTP and out-of-band secrets shorter than 64 bits, states that sending a new code must not reset the failure count, and requires each OTP to be accepted only once. These close off MFA brute force and OTP brute force.
• Bot defences for customer identity: connection fingerprinting (JA3, HTTP/2), device signals, multi-step login and proof-of-work raise the cost of stuffing; OWASP warns client-supplied signals can be spoofed, so layer them.

For password policy as a whole, including length, managers and service account passwords, see the Password Security Guide.

Detection: log sources, event IDs and signals

Password spraying detection and credential stuffing detection both depend on aggregating failures across accounts. A failed login spike is the easy case; the hard case is a campaign spread over days.

Detection logic, described

• Spray shape: one source, or a cluster sharing an ASN, user agent or TLS fingerprint, failing against many accounts with one or two attempts each. Microsoft adds failures in directory order, a repeated target application and regular intervals.
• Low and slow: run the same aggregation over 24 hours and 7 days, not only 15 minutes.
• Success after failures: success from a source that failed against other accounts is the top alert (ATT&CK detection strategy DET0463).
• Correct password, failed MFA: Microsoft and OWASP both single this out; alert and notify the user.
• Stuffing shape: rising unknown usernames and a falling login success ratio, often with normal per-IP volume.

The Windows Event Log Guide covers audit policy and collection for these events.

Responding to a spray or stuffing campaign

1. Confirm and scope: start time, source addresses, targeted accounts; enable verbose AD FS auditing.
2. Prioritise accounts: Microsoft's order is successful sign-ins from attacker sources, then interrupted sign-ins (correct password, MFA challenge), then failures, then other unusual successes.
3. Contain compromised accounts: reset passwords, revoke sessions and refresh tokens, mark the user compromised in ID Protection, and review MFA methods registered since the attack began.
4. Block sources temporarily: at the edge, AD FS or WAF, knowing residential proxies make IP indicators unreliable.
5. Close the gap used: block legacy authentication, enforce MFA on the targeted accounts, add sprayed passwords to the custom banned list.
6. Check impact: mailbox access, downloads, OAuth consents and inbox rules for any account that authenticated; for customers, force resets and notify.

Implementing defences in phases

1. Phase 1, visibility (weeks 1 to 2): enable Audit Logon, Audit Kerberos Authentication Service and Audit Credential Validation on domain controllers, verbose AD FS auditing and Entra sign-in log export; baseline failure rates.
2. Phase 2, remove easy paths (weeks 2 to 6): deploy the legacy authentication block in Report-only, review which clients would break, migrate them, then switch On. Run Entra Password Protection on domain controllers in audit mode first, review rejections, then enforce.
3. Phase 3, tune lockout (weeks 4 to 8): set the AD DS threshold (10 is a reasonable start), configure smart lockout below it in hybrid estates, and use fine-grained policies for privileged and service accounts. Pilot on one OU or ring and watch help desk lockout tickets.
4. Phase 4, MFA and risk policies: require MFA for all users, phishing-resistant MFA for administrators, and sign-in and user risk policies where licensed. Exclude only named break-glass accounts.
5. Phase 5, customer and API endpoints: per-account brute force rate limits, breached-password checks and bot defences on every login path.

Rollback: Conditional Access policies can return to Report-only, Password Protection can return to audit mode, and lockout thresholds are a single GPO value, so each phase can be reversed in minutes if it disrupts users.

Choosing the right mix

• Workforce versus customer: workforce sign-in can mandate MFA and block legacy clients; customer sign-in usually cannot, so it leans on breached-password checks, bot defences and risk-based step-up.
• Lockout threshold trade-off: a low threshold (3 to 5) stops guessing faster but turns every spray into a mass lockout; around 10 plus adaptive lockout and detection suits most estates.
• Small organisations: MFA for all, legacy authentication blocked, no password-based RDP or SSH on the internet, and the provider's built-in lockout.
• Large or hybrid organisations: cloud and AD DS threshold ordering, on-premises Kerberos and NTLM spray detection, low and slow SIEM rules and a tested runbook.

Metrics that show it is working

• Legacy authentication sign-ins: per week, trending to zero.
• Accounts without MFA: share of enabled human accounts that can sign in with a password alone.
• Banned password rejections: at change and reset.
• Login success ratio: on customer endpoints, alerting on sudden drops.
• Time to contain: first spray alert to reset of any account that validated a password.
• Lockout tickets: help desk volume, which should fall as smart lockout replaces blunt thresholds.

Common failure patterns

• Relying on lockout: a spray at one attempt per account per hour never trips a threshold of 10. The 23andMe breach showed how stuffing against accounts without MFA scales quietly into a large exposure.
• Forgotten accounts outside policy: test tenants, legacy accounts and service accounts excluded from MFA and Conditional Access are exactly what sprayers find, as the Midnight Blizzard case shows.
• Per-IP thinking: limits and detections keyed on source IP miss distributed attacks through residential proxies.
• Weak side doors: the web form is protected but the mobile API, legacy protocol or reset endpoint is not.
• Ignoring MFA failures: correct passwords followed by denied or failed MFA prompts sit in logs without an alert, so the leaked password is never reset.
• Infostealer credentials treated as low risk: valid pairs from infostealer logs bypass every guessing control; the Snowflake breach turned such credentials on accounts without MFA into mass data theft.

Framework mapping

Practitioner checklist

• Block legacy authentication through Conditional Access after a Report-only review, keeping a monitored break-glass exclusion.
• Enforce a banned password list in the cloud and on domain controllers, including organisation-specific terms and recently sprayed passwords.
• Require MFA on every interactive sign-in and phishing-resistant MFA for administrators; remove accounts that can sign in with a password alone.
• Set an AD DS lockout threshold around 10, with Entra smart lockout lower than AD DS and a longer duration in hybrid estates.
• Apply per-account rate limits and increasing delays to every login, API and reset endpoint, not just the main web form.
• Collect 4625, 4771, 4776, 4740, AD FS 411/342/516/1203 and Entra sign-in logs centrally, with 24-hour and 7-day spray aggregations.
• Alert on correct password plus failed MFA, and on success from any source that failed against other accounts.
• Check new and existing passwords against breach corpora and reset matches proactively.
• Keep a tested runbook: scope, prioritise, reset, revoke sessions, block temporarily and close the gap used.

Standards and references

• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• MITRE ATT&CK: T1110 Brute Force
• OWASP: Credential Stuffing Prevention Cheat Sheet
• OWASP: Authentication Cheat Sheet
• Microsoft Learn: Protect user accounts from attacks with Microsoft Entra smart lockout
• Microsoft Learn: Password spray investigation playbook
• Microsoft Learn: Block legacy authentication with Conditional Access
• Microsoft Learn: Eliminate bad passwords using Microsoft Entra Password Protection

Related NHI Mgmt Group resources: Account Takeover Prevention Guide · Password Security Guide · Bot Management Guide · ITDR Guide · MFA Fatigue and Bypass Guide