Password Spraying Still Works

Account lockout is the control most teams assume handles this, and it is aimed at the wrong axis. Lockout counts failed attempts against a single account inside a time window, then freezes that account. Its whole logic is per-user. A spray never triggers it, because a spray makes one attempt per account before moving on. From any single account's point of view, there was one failed login this morning, which is indistinguishable from a person mistyping their own password.

Microsoft Entra smart lockout raises the bar a little by tracking sign-in failures more intelligently and treating familiar locations differently from unfamiliar ones, but it is still reasoning about pressure on individual accounts. A patient attacker respects your lockout threshold on purpose. If the policy locks an account after ten failures in ten minutes, the spray stays well under that, often at one attempt per account per hour, sometimes per day. This is what low and slow means in practice: the attacker sets their tempo below your alarm threshold and simply accepts that the run takes longer.

Distributing the source makes it quieter still. Attempts arrive from a rotating pool of cloud and residential addresses, so no single IP racks up a volume worth blocking, and a per-IP rate limit sees nothing unusual either. The attack is loud only in aggregate, and aggregate is exactly the view that per-account and per-IP controls are not built to give you.

Spraying works because password choice is predictable in bulk even when any one person feels original. The winning guesses are rarely random. They follow the shape that complexity rules accidentally teach people to produce: a capital letter, some lowercase, a number and a symbol, arranged the way a human reaches for when a policy demands all four.

The reliable categories are worth knowing so you can test yourself against them:

A valid password only becomes a breach where it can be used, and the endpoints attackers spray are chosen precisely because multi-factor authentication often does not fire there. Modern interactive sign-in through a browser usually prompts for a second factor. The older protocols underneath frequently do not.

Legacy authentication is the standing example. Protocols that authenticate with just a username and password, older mail protocols and basic SMTP among them, complete without ever invoking MFA. Microsoft has disabled basic authentication for most Exchange Online protocols, but tenants keep exceptions alive for an old scanner, a line-of-business app or a shared mailbox, and each exception is a door where a sprayed password is enough on its own. The same gap shows up on VPN gateways without MFA enforced, on legacy federation endpoints, on Exchange autodiscover, and on any internet-facing portal that was stood up before conditional access covered everything.

This is why a spray and an MFA rollout are answering different questions. MFA decides what happens after a correct password is entered on a path that enforces it. Spraying hunts for the paths that do not. The two only meet once every authentication surface sits behind the second factor, the browser sign-in included.

In the Entra sign-in logs the evidence is present but scattered. Each attempt is a failed sign-in with an error code that distinguishes a wrong password from a correct password stopped by a later control, and that distinction matters enormously. A wave of wrong-password failures spread thinly across many accounts is the signature of a spray in progress. A correct password that then failed MFA or a conditional access check is a louder signal: it means the credential is already known and the attacker is now testing whether the second factor holds.

The reason sprays go unnoticed is that nobody is looking at the aggregate. Per-account, the noise is one failure among thousands of normal logins. The tell only appears when you group failures by time and ask a different question: how many distinct accounts saw a failed sign-in from unfamiliar infrastructure in the same window. That view comes from a query and an alert you build deliberately rather than from any default dashboard, and building it is one of the highest-value detections a small team can add.

The event that should never pass quietly is the successful sign-in that follows the failures, especially from a new location or an unusual client. That is the moment a spray stops being noise and becomes an intrusion, and it is the line most log reviews are not watching for.

The point of testing this is to learn which accounts and endpoints are exposed, without becoming the incident yourself. That constraint shapes the whole exercise. A test that trips lockouts across the workforce has cost a morning of help desk calls and told you little. The discipline is to stay below the thresholds a careful attacker would also respect.

That means agreeing the lockout policy up front and pacing attempts to sit comfortably underneath it, spacing rounds so no account approaches its failure limit, and coordinating timing with whoever watches the logs so a genuine attack during the same window is not masked by the test. A good exercise measures more than whether a password was guessed. It maps which authentication surfaces enforce MFA and which do not, whether the sign-in logs actually surfaced the activity, and whether anyone noticed. The finding that a spray reached a legacy endpoint and no alert fired is often worth more than the list of weak passwords itself.

What that produces is an honest picture of your exposure and the specific gaps behind it. Turning that picture into a safe, scoped exercise across every authentication surface, and reading the results without tripping the controls you are testing, is the part we do under engagement. The value is in running it carefully and in interpreting what the silence in your logs actually means.

None of the defences here are exotic. Most exist already in a Microsoft-stack tenant, waiting to be turned on or extended to the surfaces that slipped through.