EtcSecBeta
🏢Active Directory☁️Entra IDAttack PathsPasswordMonitoring

Password Spraying: Detection and Prevention for Active Directory and Entra ID

Password spraying uses a small set of common passwords against many accounts to avoid lockouts and find weak identities. Learn how it works, how to detect it, and how to reduce exposure across AD and Entra ID.

ES
EtcSec Security Team
12 min read
Available inEnglishFrançais
Password Spraying: Detection and Prevention for Active Directory and Entra ID

What Is Password Spraying?

Password spraying is a brute-force technique that tests one password, or a very small list of common passwords, across many accounts instead of trying many passwords against one account. MITRE classifies it as T1110.003 under Brute Force.

That operating model matters because it is designed to avoid the obvious side effects of classic brute force. Rather than locking one account after repeated failures, the attacker spreads a few guesses across many identities and waits for the weak one.

For this article, the scope is hybrid identity: Active Directory, Microsoft Entra ID, and the cloud or remote access paths that still accept password-based authentication. Password spraying is not only an on-premises problem. CISA and Microsoft both describe it as a common initial-access pattern against federated, cloud-based, and internet-facing identity services.


How Password Spraying Works

MITRE's definition is the right starting point: adversaries use a single or small list of commonly used passwords against many different accounts to avoid account lockouts that would normally occur if they brute-forced one account repeatedly.

In practice, attackers build a target list first and spray the weakest candidate passwords second.

Common target sources include:

  • externally visible usernames or email addresses
  • naming conventions derived from LinkedIn, company websites, or breached address books
  • Global Address Lists after a first cloud account is compromised
  • synced hybrid identities that exist in both AD and Microsoft Entra ID

Common target paths include:

  • Microsoft 365 / Entra sign-in endpoints
  • federated authentication flows
  • VPN portals
  • Outlook Web or other externally exposed mail interfaces
  • RDP or externally published remote access workflows
  • LDAP, Kerberos, SMB, or other internal protocols once the attacker is already inside the network

MITRE also notes an important detection nuance: attackers may prefer LDAP and Kerberos authentication attempts because those can be less visible than failed SMB logons that commonly trigger event 4625.


Why Password Spraying Still Works

Password spraying is effective because it exploits scale plus predictability, not only one technical weakness.

Weak passwords still exist at enterprise scale

Microsoft Entra Password Protection documentation is explicit here: Microsoft blocks weak passwords based on real-world spray telemetry because weak passwords and their variants are still common enough to matter operationally.

Password-only paths remain exposed

CISA's brute-force alert and Microsoft's more recent cloud intrusion reporting both point to the same weakness: if a target still exposes single-factor password authentication, one success is enough to start reconnaissance, persistence, or lateral movement.

Legacy and federated paths increase the attack surface

CISA explicitly warns that password spray campaigns frequently target SSO and cloud applications using federated authentication. Microsoft's more recent reporting also shows password spray used as the initial step before broader Entra reconnaissance and persistence activity.

Low-and-slow tradecraft avoids noisy lockouts

The point of spraying is not speed against one account. The point is reliability across many accounts without crossing per-account thresholds too quickly.


Preconditions for a Successful Password Spraying Attack

Password spraying usually succeeds when several issues overlap.

1. The attacker can enumerate valid usernames

A spray campaign is far easier when usernames follow predictable patterns or are externally discoverable. Public email formats, predictable admin aliases, and reused cloud/on-prem identity names all help.

2. Password-based authentication is still exposed

If the tenant or environment still allows password-based access on valuable paths, attackers have something to spray. This includes cloud sign-in, VPN, remote access, federation, and internal authentication surfaces.

3. The password baseline is weak enough that a small candidate set will work

This is the control problem that Active Directory Password Security: Misconfigurations That Matter addresses. A spray works because some users still choose weak, guessable, or organization-themed passwords.

4. MFA coverage is incomplete or bypassable on the target path

Even when spraying only yields a valid password, the account becomes much less useful if strong MFA or phishing-resistant follow-up controls are in place. CISA explicitly lists lack of MFA as a common property of victim environments.

5. Monitoring is too weak to connect the pattern

A few failed attempts against one account are easy to dismiss. The real signal is many failures across many accounts from the same source, infrastructure family, or timing pattern. Without that correlation, password spraying stays easy to miss.


The Attack Chain

A typical password spraying intrusion chain looks like this.

Step 1 - Build the account list

The attacker collects usernames from public sources, prior breaches, address books, or previously compromised mailboxes.

Step 2 - Pick a small password list

The chosen passwords are usually season-based, organization-themed, or otherwise common enough to match enterprise complexity rules while still being predictable.

Step 3 - Spray across many accounts

Instead of hammering one user, the attacker tries a small password set across many users and spaces the attempts to avoid obvious lockout thresholds.

Step 4 - Use the first successful account for reconnaissance

Microsoft's Peach Sandstorm reporting shows the real risk here: even one successful account can be enough for tenant discovery, persistence attempts, or follow-on cloud reconnaissance.

Step 5 - Expand access

From there, the attacker may:

  • gather more usernames and roles
  • download mail or the Global Address List
  • target privileged users next
  • move into applications, subscriptions, or infrastructure tied to the compromised identity

This is why password spraying is not just a login failure problem. It is an initial-access problem that frequently becomes a privilege and persistence problem.


Password Spraying vs. Other Brute-Force Techniques

These terms are often blurred together, but they are not the same.

  • Password spraying = one or a few passwords against many accounts
  • Password guessing = trying passwords against a single account more directly
  • Credential stuffing = replaying known username/password pairs from other breaches
  • Classic brute force = many attempts against one identity or one secret until it breaks

That distinction matters operationally because the detection and lockout strategies are different.


Detection

There is no single universal detector for password spraying because the technique crosses cloud, federated, and on-prem paths. The useful detection model is again correlation.

Cloud and Entra-focused signals

For Microsoft Entra ID, the most useful signals include:

  • repeated failed sign-ins against many users from the same IP, infrastructure cluster, or user agent
  • the same candidate-password pattern being tested across many accounts over time
  • repeated Smart Lockout or blocked-sign-in behavior across many accounts from the same source
  • medium or high sign-in risk activity associated with repeated password failures or suspicious infrastructure
  • legacy authentication use on internet-facing identity paths

Microsoft's Smart Lockout documentation adds several important facts:

  • Smart Lockout is on by default for Microsoft Entra tenants
  • the default threshold is 10 failed attempts for Azure Public tenants and 3 for Azure US Government tenants
  • the default lockout duration starts at 60 seconds and increases after repeated failures
  • Smart Lockout tracks the last three bad password hashes so repeated use of the same bad password does not keep incrementing the counter
  • hash tracking is not available for pass-through authentication scenarios because authentication happens on-premises

Those details matter because defenders often overestimate what lockout alone will do in a hybrid environment.

AD and on-premises signals

For on-premises Windows monitoring, useful signals include:

  • spikes in 4625 failures from the same source against many accounts where SMB or similar paths are involved
  • 4771 Kerberos pre-auth failures across many users in a short period
  • LDAP or Kerberos failures that line up with a multi-account pattern even when they do not look like a classic SMB brute-force sequence
  • the same source or relay path touching many identities with a low-and-slow cadence

MITRE explicitly warns that LDAP and Kerberos attempts may be less likely to trigger the most visible Windows failed-logon patterns defenders rely on, which is why Active Directory Monitoring: Security Event IDs That Matter is directly relevant here.

What good correlation looks like

A strong password-spray detection is usually framed like this:

  • one IP, ASN, user agent, or small infrastructure set
  • many target usernames
  • very few attempts per account
  • a repeating candidate-password pattern or timing pattern
  • one or two successful accounts followed by discovery or privilege-oriented activity

Why smart lockout and logs are not enough on their own

Smart Lockout reduces risk, but Microsoft is clear that it does not guarantee a legitimate user is never locked out and it is not a replacement for stronger authentication and better password policy. Strong detection still depends on log review, alerting, and knowing which paths are exposed.


Remediation

Password spraying mitigation is not just a password-policy exercise. It is the combination of stronger passwords, fewer exposed password-only paths, stronger post-password controls, and better protection of hybrid authentication edges.

1. Enforce strong MFA on exposed identity paths

CISA and Microsoft both recommend MFA as a core mitigation. For public-facing identity systems, especially Microsoft 365, admin portals, VPN, and remote access, a sprayed password should not be enough to continue.

This is also why Azure Identity Security: Why MFA Alone Is Not Enough and Azure Conditional Access: MFA Bypass With Stolen Passwords sit next to this topic. MFA has to be present on the right paths and enforced correctly.

2. Use Smart Lockout correctly in Entra

Microsoft documents Smart Lockout as a default protection against brute-force and password spray activity, but hybrid teams need to tune it thoughtfully:

  • keep Microsoft Entra's threshold lower than the on-prem AD DS threshold
  • keep Microsoft Entra's lockout duration longer than the AD DS duration
  • understand that pass-through authentication changes some of the Smart Lockout behavior
  • review whether your on-premises account lockout policy is accidentally causing availability pain without materially reducing spray risk

3. Deploy Microsoft Entra Password Protection

Microsoft Entra Password Protection is one of the clearest anti-spray controls available because it is designed around real-world spray telemetry and blocks known weak passwords and their variants.

Important implementation points from Microsoft documentation:

  • cloud tenants get the global banned password list by default
  • custom banned passwords can be added for tenant-specific weak terms
  • on-premises AD DS can use the same control family through Microsoft Entra Password Protection agents
  • Microsoft recommends starting the on-prem deployment in Audit mode before switching to Enforced mode

That matters in hybrid estates where an attacker is just as happy to spray on-premises passwords as cloud passwords.

4. Reduce legacy authentication and exposed password-only surfaces

Legacy authentication remains attractive because it can preserve older password-based access paths and bypass some of the stronger controls that exist in more modern sign-in flows. If legacy authentication stays enabled, defenders are still leaving attackers cheaper paths to try.

This is directly related to Azure Tenant Hardening: Fix Insecure Default Settings and to your broader Conditional Access review.

5. Protect privileged identities differently from the rest of the population

One successful spray against a low-value user is bad. One successful spray against a privileged account is often the real incident. That means:

  • stronger MFA requirements for privileged roles
  • tighter sign-in restrictions for administrative identities
  • active review of stale privileged users and emergency accounts
  • rapid reset and investigation after any privileged account is targeted or locked

This is where Azure Identity Protection: Blocking Leaked Credentials and Stale Privileged Accounts: Hidden Risk in Active Directory become part of the same mitigation story.

6. Treat successful spray accounts as compromise, not only weak passwords

Microsoft's threat reporting is useful here: once a sprayed account succeeds, the actor often pivots quickly into reconnaissance, persistence, and lateral movement. Reset the password, but also revoke sessions, review MFA changes, inspect follow-on activity, and investigate whether the compromised account exposed more target data.


Validation After Hardening

Do not close password-spraying remediation because Smart Lockout is enabled or a new password policy was announced. Validate the exposed paths directly.

  • verify which internet-facing paths still accept password-only authentication
  • confirm MFA is enforced on those paths, especially for admin and high-value accounts
  • test Smart Lockout behavior and compare it with on-prem AD lockout settings in hybrid environments
  • review sign-in logs for broad multi-user failure patterns rather than only single-user lockouts
  • confirm Microsoft Entra Password Protection is active in the cloud and, where intended, on-premises
  • check whether tenant-specific weak terms such as company name, product name, or season-based patterns are addressed in the custom banned list

The real success criterion is simple: a small list of common passwords should no longer produce a useful foothold in the cloud or on-prem environment.


EtcSec does not need a fake password spraying taxonomy tag to be useful here. The value is in the surrounding controls that decide whether password spraying succeeds or fizzles.

The closest underlying findings are the ones that make a spray campaign practical in the first place: weak password policy on the AD side and missing MFA requirements on exposed Entra sign-in paths. Those are not the same thing as the attack technique, but they are the control failures that turn a broad spray into a usable foothold.

The most relevant related controls are:

Together, those findings tell you whether the environment still presents an easy spray target.


Password spraying is best reviewed together with password hygiene, MFA enforcement, smart lockout, identity-risk response, and monitoring. If you want to reduce real-world spray success rather than only reduce noisy failures, review this topic together with Active Directory Password Security: Misconfigurations That Matter, Azure Identity Security: Why MFA Alone Is Not Enough, Azure Identity Protection: Blocking Leaked Credentials, Azure Conditional Access: MFA Bypass With Stolen Passwords, How to Audit Microsoft Entra ID Security (Azure AD): Practical Review Guide, and Azure Tenant Hardening: Fix Insecure Default Settings.

Password Spraying in AD and Entra ID: Detection Guide | EtcSec