Skip to main content

Password-Spray Account Takeover Detection

Sysadmin
Sysadmin
Fluency Sysadmin

A detection release for password-spray account takeover in Microsoft 365, published October 23, 2026. A new high-severity behavior rule, EntraID_SignIn_After_Block, alerts when an attacker who holds a user's password gets into the account after Conditional Access blocked their earlier attempts. It catches the Azure CLI password spraying that Huntress has reported since June 2026, when a risk policy stops the sprayer once and they come back from another address. A precision fix to EntraID_Valid_Password_Blocked ships with it.

No action is needed: the rules sync to every instance automatically.

Rollout and requirements​

  • Rollout. Both rules are published to the default rule set and reach each instance through resource sync within about two hours. No configuration is needed.
  • Data sources. Both rules read the Entra ID sign-in logs, collected by Entra ID Audit via Event Hubs or Microsoft Graph. Interactive sign-ins are enough.
  • Entra ID P2. EntraID_SignIn_After_Block needs Microsoft's sign-in risk rating, which the sign-in logs carry only for tenants with an Entra ID P2 licence. Other tenants get the value hidden, and the rule cannot arm. The improved EntraID_Valid_Password_Blocked works without P2.
  • Expected volume. EntraID_SignIn_After_Block is built to be rare. It needs a correct password, a block rated high risk and a success from somewhere else, all within two hours, so password typos, travel and moves between office and home do not trigger it. Over the 14 days before release it would have fired once across the Fluency fleet: on the real compromise described below. Its severity is high for now and will be reviewed against the first weeks of live alerts.

The attack​

Password spraying against Microsoft 365 grew fast in 2026: Huntress saw credential spray attacks against its customers rise over 155 times in six months. One campaign made more than 81 million sign-in attempts between June 12 and June 26 against the Azure command-line client (Azure CLI), and compromised 78 accounts at 64 organizations. It signs in through Azure CLI's password-only flow (OAuth ROPC), which sends the password straight to Microsoft's token endpoint with no MFA prompt. The actor sprayed from a hosting provider's IPv6 range and from Tor exit nodes. When the provider shut it down, it moved to other providers and kept spraying low and slow: in July, about 900 attempts per address across some 12,800 addresses.

The passwords come from old breaches that were never rotated. Accounts fall when MFA does not cover the sign-in: MFA required only for admins or some groups, only for some apps, only from untrusted locations, or left in report-only mode.

Fluency saw the same pattern in a customer tenant in October 2026:

  1. Microsoft blocked four attempts that used the user's correct password, from Portugal, Singapore and Russia, because it rated them high risk.
  2. Four minutes later the attacker used the same password from a residential address in the user's own country. Microsoft rated that sign-in risk-free, and it succeeded without MFA.

Each record looks normal on its own: the block is the policy working, and the success is a routine sign-in. Before this release, the blocked attempts raised EntraID_Valid_Password_Blocked alerts, but nothing tied them to the successful sign-in that followed.

New and changed detections​

IDRuleChangeSeverityFires when
102185EntraID_SignIn_After_BlockNewHighA user signs in successfully within two hours after Conditional Access blocked a sign-in of theirs that Microsoft rated high risk and that presented their correct password, and the success comes from an IP address none of the blocked attempts came from.
102127EntraID_Valid_Password_BlockedImprovedMediumConditional Access blocks a sign-in that presented the user's correct password. It now matches Microsoft's "Correct password" result exactly, so a blocked sign-in with a wrong password ("Incorrect password") is no longer reported as a known password.

For both rules, a block is a sign-in Conditional Access stopped by policy (result 53003 or 530032) or because the device was not compliant or not managed (53000, 53001).

EntraID_SignIn_After_Block does not fire for:

  • a success from an address one of the blocked attempts came from, such as the user getting through on a compliant device after a non-compliant one;
  • a blocked attempt with a wrong password, or one Microsoft did not rate high risk;
  • a success more than two hours after the last blocked attempt;
  • non-interactive sign-ins, blocked or successful;
  • sign-ins that carry no session ID;
  • tenants without Entra ID P2;
  • an attacker whose very first attempt succeeds, from an address Microsoft does not flag, with nothing blocked before it. No sign-in log can tell that apart from the real user; MFA is the control for that case.

It is keyed on the user and alerts at most once per user in two hours. Each alert names the successful sign-in (IP address, network, country, application, resource, user agent, session and sign-in IDs) and the blocked attempts before it (their addresses and count, result code, risk level, country and sign-in ID), with the seconds between the last block and the success.

Triage guidance​

Treat an EntraID_SignIn_After_Block alert as a likely account takeover until you show otherwise.

  1. Contain first. Revoke the user's sessions and reset the password in Entra ID. Disable the account if the user does not need it.
  2. Confirm with the user. Ask whether they signed in at that time, from that place, with that application. Admin and scripting clients such as Azure CLI or PowerShell are a strong signal when the user is not an administrator.
  3. Check what the session did. Review the user's sign-ins after the success, including non-interactive ones, and directory changes made by or for the account: MFA methods, devices, app consents, mailbox rules.
  4. Look for other targets. The same campaign usually sprays many users in the tenant. Make sure they are all covered by MFA.

An EntraID_Valid_Password_Blocked alert on its own means someone else knows the password, even though that attempt was stopped. Reset it and require MFA for that user.

To find these alerts, search behavior events by rule name. Each rule is also listed by name on the Behavior Rules page.

Hardening to recommend​

Detection shortens an attacker's window; MFA closes it. These steps follow Huntress's guidance and what we saw in the field:

  • Require MFA for all users, all cloud apps and all client app types, with no group, app, location or report-only exceptions. Accounts outside an "admins" or "knowledge workers" group are the ones being taken over.
  • Restrict Azure CLI and Azure PowerShell to the people who need them. Require assignment on the Microsoft Azure CLI enterprise app and assign it to an IT group, or block Azure management for everyone else.
  • Turn off password-only (ROPC) sign-in where nothing depends on it. Conditional Access has no separate setting for it: requiring MFA for all client app types makes ROPC sign-ins fail, and restricting Azure CLI takes away the client this campaign uses.
  • Don't rely on location alone. IP geolocation is often wrong: Huntress found spray addresses that geolocation placed in the U.S., which passed trusted-location rules. In the case above, the successful sign-in came from a residential address in the user's own country.
  • Disable dormant accounts. An account nobody signs in to has no owner to notice a takeover.

References​