Password Spraying

Password spraying inverts password guessing. Instead of trying many passwords against one account, which locks that account out almost immediately, the attacker takes one password (or two, or a small seasonal handful) and tries it against every account they know about. Each individual account sees a single failed attempt, which is indistinguishable from a typo, and no account gets anywhere near a lockout threshold.

The arithmetic is what makes it work. An attacker does not need a particular person's password; they need any one person's. In a directory of a few thousand accounts, a single common password is very likely to be correct for at least one of them, and one is enough. Nothing is exploited and nothing is malformed: every request the attacker sends is a valid authentication attempt that the system is designed to answer.

Spraying is an early-access technique. It needs no foothold, only a list of account names (from a data breach, from public sources, or from an earlier enumeration step) and something that will answer an authentication request: a domain controller, a VPN concentrator, a webmail portal, an identity provider.

The attacker's constraint is the lockout policy, and everything about the technique's shape follows from it. They budget attempts per account, spread the pass out in time if the policy counts over a window, and then they wait before the next pass. That is why a spray looks the way it does rather than like ordinary failed logins: it is wide and shallow, it comes from one place, and it happens all at once.

It is also worth being precise about what a spray does NOT look like, because the generic brute-force picture misleads here. A spray is one pass across a list. It does not build, it does not accelerate, and it does not abandon the list partway through. Where the evidence lands is decided by the protocol the attempts negotiate, not by the attacker's intent, which is why the same attack can leave a completely different trail on two estates.

Data source: Windows Security event log, grouped by source address rather than by account -- failed logons (Event 4625), credential validations (4776) or Kerberos pre-authentication failures (4771), by protocol

Prebuilt Elastic rule: Multiple Logon Failure from the same Source Address

The unit of the hunt is the source, not the account. Filter authentication failures over a short window, group by source address, and rank by the number of DISTINCT accounts that source touched. A source with hundreds of failures against a single account is a stuck credential; a source with a modest number of failures fanned out across dozens of accounts in one burst is a spray, and the second has by far the smaller event count.

Count failures as LOGGED, not as attempted. Client libraries and protocol stacks commonly retry a bind or a logon once, so one issued attempt can land as two or more logged failures. That matters twice: it inflates a failure-count threshold, and it halves your assumed headroom under the lockout policy, so a spray that looks safely under the threshold on paper may not be.

Do not expect the failures to taper off. A spray is a single pass across an account list, paced to stay under lockout, and it does not accelerate or abandon the list partway; a detection built around a failure stream that decays will not fire.

Then reconcile: take the accounts that failed from that source and compare them against the accounts that authenticated successfully from the same source in the same window. Neither list is the finding on its own.

Finally, scope the account list before you count it. Machine accounts (the ones ending in $) fail pre-authentication routinely for clock-skew and replication reasons and will inflate a distinct-account count that is supposed to mean something.

Stale cached credentials are the dominant false positive, and they are noisier than the attack. A user who changed their password with a mapped drive, a scheduled task or a mobile client still holding the old one produces sustained failures from one source for days. Expect the busiest failing source in your environment to be benign, and expect it to out-produce a real spray by an order of magnitude. This is why a detection keyed on the source address alone does not survive contact with a real estate, and why the distinct-account count is the discriminator that does: stale-credential noise concentrates on one or two accounts, a spray fans out across many in a single short window.

Two more benign shapes worth recognising. A vulnerability scanner or an authenticated monitoring probe with a rotated credential produces a spray-shaped burst on a schedule, from a fixed host, against a fixed account list. And on Active Directory, a Kerberos pre-authentication failure whose recorded client address is a domain controller is usually a referral artifact, one DC re-checking a bind at another, not a domain controller attacking you; attribute to the address only after ruling that out.

The absence of account-lockout events is not evidence that nothing happened. A spray is sized to stay under the lockout threshold by design; locking accounts out is the failure mode it exists to avoid.

• MITRE ATT&CK: T1110.003 Brute Force: Password Spraying
• Elastic Security: Multiple Logon Failure from the same Source Address

1 scenario in this catalog covers T1110.003. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →