What is it?
Password spraying reverses the usual brute-force pattern. Instead of many passwords against one user, an attacker tries one likely password against many users, pauses, and repeats. The wide distribution and low rate help it stay below account-lockout and alert thresholds.
How it works in plain English
Use this three-part model to understand the attack without memorizing a tool name.
The system accepts a credential, token, ticket, recovery decision, or identity assertion as proof of who the requester is.
The attacker obtains, guesses, forges, replays, or changes that authentication material.
Focus on how the identity was acquired, where it was used, what device and network context changed, and what happened immediately after success.
Worked example: how the sequence may look
A list of likely usernames or email addresses.
Choose one password likely to satisfy complexity rules.
Windows 4625 failures and a later 4624 success.
Count distinct usernames per source in a sliding window.
If successful, the attacker may continue with Cloud Account Takeover. This is a possibility, not a guaranteed next step.
This is a defensive learning scenario. Real incidents vary, and the listed outcome is only one possible path.
Why do attackers use it?
Gain initial access through exposed identity services.
Find weak passwords without locking a single account.
Blend into normal failed-login noise by throttling attempts.
Validate usernames and identify accounts without MFA.
Prerequisites
A list of likely usernames or email addresses.
A reachable service such as VPN, OWA, SSO, RDP gateway, SSH, or SaaS.
Likely passwords based on season, organization, locale, or breach data.
Time or distributed infrastructure to keep the attempt rate low.
Attack path possibilities
Attack chains are not fixed. These links show common possibilities to investigate before and after this behavior.
Common or targeted passwords are tested against one account.
Concept PretextingA fabricated scenario persuades a target to disclose information or act.
T1078.001 Default Account AbuseBuilt-in or vendor-default accounts are used for unauthorized access.
Concept PharmingName resolution or local configuration redirects users to a fraudulent site without a deceptive message.
Stolen credentials, tokens, or recovery paths control a cloud identity.
T1621 MFA FatigueRepeated push prompts pressure a user into approving an attacker login.
T1021 Remote ServicesRDP, SMB, SSH, WinRM, VNC, or similar services are used to access remote systems.
T1537 SaaS Data ExfiltrationLegitimate APIs or compromised accounts export cloud data.
Step-by-step attack flow
Obtain or enumerate valid-looking account names.
Study exposed login services and password conventions.
Choose one password likely to satisfy complexity rules.
Try that password once across many accounts.
Pause to remain below lockout and rate thresholds.
Repeat with another password or source.
Use successful access against email, VPN, cloud apps, or internal services.
MITRE ATT&CK mapping
ATT&CK is updated over time. Verify the live technique before operationalizing a detection.
Logs and artifacts
Windows 4625 failures and a later 4624 success.
Kerberos 4771 pre-authentication failures and NTLM 4776 validation failures.
Identity-provider sign-ins showing one source targeting many users.
VPN, OWA, SaaS, SSH, reverse-proxy, conditional-access, and MFA logs.
Realistic log examples
These records use realistic field names and formats but synthetic organizations, users, addresses, and identifiers. A single event is not proof; correlate time, identity, source, target, and the resulting action.
Failed authentication; useful for guessing, spraying, exposed remote services, and account targeting.
2026-07-16T14:22:31Z EventID=4625 Computer=DC01.corp.example
TargetUserName=j.singh TargetDomainName=CORP LogonType=3
AuthenticationPackageName=NTLM WorkstationName=WKSTN-442
IpAddress=203.0.113.48 IpPort=51842
Status=0xC000006D SubStatus=0xC000006A FailureReason="Unknown user name or bad password"Count distinct usernames per source in a sliding window.
Cloud sign-in context including identity, application, source, result, device, and conditional access.
2026-07-16T14:24:51Z UserPrincipalName=j.singh@corp.example
AppDisplayName="Office 365 Exchange Online" IPAddress=203.0.113.48
ResultType=50126 ResultDescription="Invalid username or password"
ClientAppUsed=Browser ConditionalAccessStatus=notApplied
DeviceDetail.operatingSystem=Windows Location=SGDetect one failure pattern across many users even when each user has few failures.
Remote authentication and PAM outcome with source address and account.
Jul 16 14:22:33 web02 sshd[24817]: Failed password for invalid user backup
from 203.0.113.48 port 51842 ssh2
Jul 16 14:22:37 web02 sshd[24817]: Failed password for deploy
from 203.0.113.48 port 51842 ssh2Correlate the failure wave with later success from the same IP, ASN, agent, or device.
- Who or what identity acted?
- From which device, process, IP, or workload?
- What target and operation were involved?
- Did it fail, succeed, or change state?
- What correlated event happened immediately before and after?
Detection logic / SIEM queries
Count distinct usernames per source in a sliding window.
Detect one failure pattern across many users even when each user has few failures.
Correlate the failure wave with later success from the same IP, ASN, agent, or device.
Group distributed sources by hosting provider, fingerprint, and synchronized timing.
SigninLogs
| where TimeGenerated > ago(30m)
| where ResultType != "0"
| summarize Attempts=count(), Users=dcount(UserPrincipalName),
UserList=make_set(UserPrincipalName, 20) by IPAddress, bin(TimeGenerated, 10m)
| where Users >= 10 and Attempts >= 15
| order by Users descindex=auth action=failure earliest=-30m
| stats count as attempts dc(user) as users values(user) as targets by src_ip
| where users>=10 AND attempts>=15
| sort - usersMitigations
Require phishing-resistant MFA for remote and privileged access.
Use smart lockout, risk-based conditional access, and edge rate limits.
Block legacy authentication and protocols that cannot enforce modern controls.
Reset known exposed credentials and block breached passwords.
Use long unique passwords and passwordless authentication where possible.
Real-world examples
APT28 has used throttled password spraying against public-facing services.
APT29 and APT33 have used password spraying for initial access.
Silent Librarian has sprayed accounts in education and private-sector targets.
Common questions
01How is it different from brute force?
Traditional brute force concentrates many guesses on one account. Spraying spreads a few guesses over many accounts.
02Why might no account be locked?
The attacker spaces attempts so each account remains below the lockout threshold.
03What is the strongest clue?
One source or coordinated source group failing against an unusually high number of users.