How to detect password spray attacks

Threat snapshot

Password spraying is the art of staying invisible. Where a classic brute force attack hammers one account with hundreds of attempts and triggers lockout within minutes, a spray campaign does the opposite: it tests one or two passwords against every account in the directory, keeps the attempt rate well below the lockout threshold, and waits. An attacker targeting a 5,000-user organization with a lockout policy of five failures per 30 minutes needs only one attempt per account per hour to operate completely beneath the detection surface of standard lockout-based alerting.

The password chosen is rarely random. Attackers select candidates based on common enterprise patterns: seasonal passwords ("Summer2024!"), company-name variants ("Acme@2024"), and passwords identified in prior breach datasets that match the target organization's known password policy requirements. In many organizations, a meaningful percentage of accounts will match at least one of these patterns at any given time.

What makes spraying particularly dangerous is not just that it evades lockout policies, but that a successful spray produces a successful logon that is nearly indistinguishable from a legitimate user authenticating for the first time that day. Without behavioral baseline context, the compromise event itself does not look like an attack at all.

Password spraying, at a glance

How password spraying works

Password spraying exploits a fundamental tension in enterprise security policy: lockout thresholds that are set high enough to tolerate legitimate user mistakes create a window wide enough for an attacker to attempt multiple passwords against every account without triggering lockout on any single target.

The mechanics of a spray campaign

A typical spray campaign operates in three phases. In the reconnaissance phase, the attacker enumerates valid account names from the target environment, either through LDAP queries if they have internal access, or through public sources such as LinkedIn, company websites, and prior breach databases that reveal email formats. Valid account enumeration is critical because spraying against invalid accounts wastes attempts and may trigger username-enumeration detection.

In the spray phase, the attacker tests their chosen password list against every valid account, observing the lockout policy timing. Most enterprise Active Directory policies use a 30-minute observation window. An attacker who observes this will attempt one password per account every 31 minutes, resetting the window counter before it ever reaches threshold. Tools like Kerbrute make this particularly dangerous because they operate at the Kerberos pre-authentication level: instead of generating Event 4625 (failed logon) which most SOCs monitor, Kerbrute generates Event 4768 with a result code of 0x18, a signal that many environments do not alert on at all.

In the exploitation phase, the attacker identifies successful authentications from the spray results, validates access to the compromised account, and begins post-compromise activity: directory enumeration, lateral movement planning, or data access, depending on the campaign objective.

The Kerberos blind spot: Kerbrute's deliberate avoidance of Event 4625 is the reason why detecting the tool itself via process creation logs (Sysmon Event 1) is more reliable than trying to detect the spray from authentication failure counts alone. A Kerbrute spray against 10,000 accounts leaves no Event 4625 entries, but leaves a clear Sysmon process creation record on the machine where Kerbrute ran.

Real-world campaigns

APT28 (Fancy Bear): sustained M365 and on-premises spray campaigns

APT28, the Russian GRU-affiliated threat group, has conducted sustained password spraying campaigns against government agencies, defense contractors, energy companies, and political organizations across the US and Europe. Their operational signature is patience: campaigns run for weeks at one to two attempts per account per day, targeting M365 and on-premises Exchange simultaneously. The group uses Tor exit nodes and compromised residential routers as spray infrastructure, making source IP blocking minimally effective. The passwords used are updated seasonally and reflect awareness of common enterprise password policy requirements, typically including an uppercase letter, a number, and a special character.

Iranian APT groups: Citrix and VPN gateway spraying

Multiple Iranian state-affiliated groups have been documented conducting password spraying campaigns specifically targeting VPN gateways, Citrix NetScaler appliances, and other remote access infrastructure. The objective is remote access to enterprise networks rather than cloud identity compromise. The technique is the same: low-volume attempts across a large account list, timed to avoid lockout. These campaigns have been particularly successful against organizations with inconsistent MFA enforcement on remote access infrastructure, where a valid username and password is sufficient for VPN authentication.

CVE reference table

Business impact

• Dwell time before detection. Because spraying does not trigger lockout or generate the high-volume failure bursts that standard SIEM rules look for, campaigns can operate for weeks before being detected, if they are detected at all. Each day of undetected access increases the probability that the attacker has established persistence, enumerated the domain, and identified high-value targets for the next phase.
• High value targets are the objective. Spray campaigns rarely care about the first account they compromise. They care about finding the account with the right access: a domain admin, a finance executive, an IT service account with broad permissions. A spray across 10,000 accounts is a systematic search for that one account with a weak password and high privilege.
• Initial access for ransomware and APT operations. Password spraying is documented as the initial access technique in a significant portion of ransomware incidents and many APT intrusions. It is preferred precisely because it produces valid credentials, which in most environments grant significantly more access than exploitation of a vulnerability in a single system.
• Compliance exposure. Organizations subject to PCI-DSS Requirement 8.3 must implement account lockout after a defined number of failed attempts. Password spraying by definition evades lockout controls. Evidence that a spray campaign succeeded while in-scope systems lacked adequate detection and response controls can constitute a compliance failure independent of whether data was accessed.

Detecting password spraying with Log360

Log360 ships three detection rules that target password spraying specifically. Two of them detect the tools most commonly used to execute sprays (Kerbrute and Hydra) via process creation logs, providing coverage even when the spray itself generates no authentication failure events. The third detects the aggregate lockout pattern that high-volume sprays produce across multiple accounts. For these rules to fire, Sysmon process creation logs (Event 1) must be forwarding to Log360 from domain-joined endpoints, and Windows Security event logs including Event 4740 must be collected from domain controllers.

Note that slow, disciplined spray campaigns operating precisely at one attempt per account per observation window will not trigger the Notable account lockouts rule. In those cases, detection depends on either catching the spray tool at execution time (Kerbrute, Hydra) or on UEBA behavioral anomaly detection identifying the pattern of distributed low-volume failures across accounts, which deviates from the normal failure baseline for the environment.

Attack chain visibility

A password spray is rarely the end of the story. The sequences below show what the attack looks like in the logs from the first spray attempt through to post-compromise activity.

Sequence A: Kerbrute spray (no Event 4625 generated)

Sequence B: Low-and-slow manual spray (no tool signature)

Investigation playbook

When a password spray detection rule fires in Log360, the core investigative question is identical to any brute force scenario: did any attempt succeed? A detected spray with no successful logon is a blocked attack. A detected spray with a successful logon from the same source is an account compromise that requires immediate response. The steps below structure that determination.

Step 1: Triage - identify which rule fired and what it means

Step 2: Determine if any attempt succeeded

• Using Log360's log search, query for Event 4624 (successful logon, logon type 3 or 10) from the same source IP as the spray alert, within the spray time window and the 24 hours following it. A successful logon from the spray source is the most critical finding in the investigation.
• For Kerbrute specifically: query Event 4768 on domain controllers for TGT issuances (result code 0x0) from the same source IP as the Kerbrute execution. A successful TGT is equivalent to a successful logon for the purposes of determining compromise.
• For M365 spray indicators: query Microsoft 365 sign-in logs for successful authentications from the spray source IPs. Pay attention to whether MFA was completed or bypassed, as a successful password authentication without MFA completion on an MFA-enrolled account indicates MFA was not enforced at the relevant authentication endpoint.

Step 3: Investigate using the Incident Workbench

• If a successful logon is confirmed, click on the compromised username in the alert or log search results to open the Incident Workbench. Use the User analytics tab to pull the account's full activity overview: recent logon history, resources accessed, and UEBA risk score. A compromised spray victim will often show a sudden change in logon source geography or an immediate access to resources the account has never previously touched.
• Use the Process analytics tab if the spray originated from an internal host (indicating Kerbrute or Hydra running on a machine already inside the network). The process tree will show what spawned the spray tool, which helps determine how the attacker got onto that machine in the first place.
• Use Advanced Threat Analytics on the source IP to pull threat feed risk scores. IPs used for spray campaigns frequently appear in threat intelligence feeds as known attack infrastructure, Tor exit nodes, or compromised hosts in prior campaigns.
• Save the Incident Workbench session directly to an incident for tracking. The user activity timeline and process tree captured at this stage become the evidence record for the incident.

Step 4: Scope the exposure

• List every account that received an authentication failure from the spray source. This is the full targeted population, not just the accounts that were locked out or compromised.
• For each compromised account (successful logon from spray source), check downstream activity: LDAP queries, file server access, email access, Group Policy reads. Each of these indicates how far post-compromise activity has progressed and what data may have been accessed or exfiltrated.
• Determine whether the spray originated externally or from an internal host. An internal spray source indicates the attacker already has a foothold and is using a compromised machine for lateral expansion, which changes the scope significantly.
• Check whether multiple source IPs targeted the same account list. Distributed sprays from many IPs are a sign of an infrastructure-backed campaign rather than an opportunistic single-host attack, and typically indicate a more determined threat actor.

Step 5: Collect evidence and build the timeline

• Export the Event 4625, 4768, 4740, and 4624 records for all affected accounts from Log360's log search. This is the primary forensic record showing the spray window, accounts targeted, and the moment of compromise if one occurred.
• If Kerbrute or Hydra was detected, preserve the Sysmon Event 1 log with the full command-line field. The command line shows the password tested, the account list used, and the target, which may identify additional compromise vectors not visible in the authentication logs.
• Record all source IPs, their geographic location, ASN, and any threat intelligence context gathered from the Incident Workbench Advanced Threat Analytics tab.
• Export the investigation timeline from Log360 as the compliance artifact for NIST CSF DE.AE-5 (incident analysis) and PCI-DSS Requirement 10.7 (detecting failures of critical security controls).

Response and remediation

Immediate containment

• Disable compromised accounts immediately. If a successful logon from the spray source is confirmed for any account, disable it in Active Directory or suspend it in M365 before any further investigation. An active compromised account can be used for lateral movement while the investigation continues.
• Block the source IP at the perimeter. For external spray sources, add the IP and its associated subnet or ASN to the deny list on the perimeter firewall or VPN gateway. For distributed campaigns using many IPs, consider blocking authentication attempts from the geographic regions or ASNs the spray originated from, if those regions have no legitimate user base.
• Revoke active M365 sessions for any compromised cloud accounts. Password reset alone does not invalidate existing session tokens in M365. Use the Revoke-MgUserSignInSession PowerShell cmdlet or the equivalent admin portal action to force re-authentication.
• Force a password reset for all accounts included in the spray target list. Any account that received a spray attempt may have been compromised using a credential that did not appear in the local authentication logs, particularly if the spray operated across a longer time window than the log retention period covers.

Response actions by trigger

Hardening

• Enforce MFA on all authentication paths. Password spraying succeeds when a correct password is sufficient for access. Enforcing MFA on Active Directory (via Azure AD joined devices and Conditional Access), M365, VPN, and all remote access portals breaks the attack at the point of successful credential validation. An attacker who correctly guesses a password but cannot complete MFA cannot proceed.
• Enable Microsoft Entra ID Smart Lockout for M365 environments. Smart Lockout applies lower lockout thresholds for authentication attempts from unfamiliar locations while maintaining higher thresholds for trusted locations, reducing the effectiveness of distributed sprays without increasing false positives for legitimate users.
• Deploy Azure AD Password Protection on-premises (for hybrid environments) to block common passwords and custom banned password lists at the domain controller level. This eliminates the category of seasonal common passwords that spray campaigns depend on, such as "Summer2024!" or "Company@123".
• Enable Kerberos pre-authentication logging on domain controllers to ensure Event 4768 is captured and forwarded to Log360. Without this, Kerbrute sprays are invisible at the authentication layer and detection depends entirely on the Sysmon process creation rule.

False positive tuning