Skip to main content

Advisory: Azure CLI Password-Spray Account Takeover

Support
Support
Fluency Support

Attackers are spraying passwords from old breaches at Microsoft 365 accounts through the Azure command-line client (Azure CLI), whose password-only sign-in never shows an MFA prompt. Huntress reported one campaign that made more than 81 million sign-in attempts in two weeks of June 2026 and compromised 78 accounts at 64 organizations.

Any organization whose MFA policy leaves gaps (some users, some apps, trusted locations, report-only mode) is exposed. MSSPs should check every tenant they manage. On October 23, 2026, Fluency released to every instance a detection for the takeover that follows a blocked attempt. No action is needed to turn it on.

The playbook​

  • Breached passwords. The attacker tries username and password pairs from old breaches that were never rotated, across many accounts.
  • Azure CLI's password-only sign-in. The attempts go through Azure CLI's OAuth ROPC flow, which sends the password straight to Microsoft's token endpoint with no MFA prompt. If no Conditional Access policy covers Azure CLI, the right password is enough.
  • Low and slow, from rotating infrastructure. The campaign sprayed from a hosting provider's IPv6 range and from Tor exit nodes, and moved to other providers when the first one shut it down. In July it made about 900 attempts per address across some 12,800 addresses.
  • Blocked, then back. When a risk policy blocks an attempt, the attacker tries the same password again from somewhere else. In a customer tenant in October 2026, the successful sign-in came four minutes after the blocks, from a residential address in the user's own country, and Microsoft rated it risk-free.

Why MFA did not stop it​

Among the organizations Huntress saw compromised that had MFA, it did not apply because it was:

  • enforced for specific apps instead of all cloud apps, so Azure CLI was not covered;
  • required only for some groups, such as admins;
  • required only from untrusted locations, and geolocation placed the attacker's addresses in a trusted country;
  • left in report-only mode.

Eight of the 23 businesses Huntress analyzed had no MFA policy at all. And each record looks normal on its own: the block is the policy working, and the success is a routine sign-in.

Fluency's new detection​

DetectionFires whenNeeds
EntraID_SignIn_After_BlockA user signs in successfully within two hours after Conditional Access blocked a high-risk sign-in that presented their correct password, and the success comes from an address none of the blocked attempts came from.Entra ID sign-in logs (Azure Event Hubs or Microsoft Graph), and Entra ID P2 for Microsoft's sign-in risk rating

It raises a high-severity alert on the user. The release also sharpens EntraID_Valid_Password_Blocked, which alerts whenever Conditional Access blocks a sign-in that had the correct password: it no longer reports blocked attempts with a wrong password. Neither rule can catch an attacker whose very first attempt succeeds with nothing blocked before it. MFA is the control for that.

What we recommend​

For every organization​

  1. 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" group are the ones being taken over.
  2. 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.
  3. 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.
  4. Don't rely on location alone. IP geolocation is often wrong, and an attacker can come from an address in your own country.
  5. Treat a blocked sign-in with the correct password as a stolen password. Reset it and require MFA for that user, even though the attempt was stopped.
  6. Disable dormant accounts. An account nobody signs in to has no owner to notice a takeover.

For MSSP partners​

  • Audit MFA in every client tenant. Look for the gaps Huntress found: policies scoped to some groups or apps, trusted-location exceptions and report-only mode.
  • Hunt for Azure CLI sign-ins by users who are not administrators, and for successful single-factor sign-ins shortly after blocked ones.
  • Check coverage. Confirm which clients send Entra ID sign-in logs and which have Entra ID P2. Clients without P2 get EntraID_Valid_Password_Blocked but not the new detection.
  • Act fast when it fires. Revoke the user's sessions and reset the password, confirm the sign-in with the user, and review what the session changed: MFA methods, devices, app consents and mailbox rules.

If you find a match, raise a support ticket and Fluency will help with the investigation. The rule's full match conditions, what it does not cover, and triage steps are in the Password-Spray Account Takeover Detection release notes.

References​

Splash Summary

Attackers are spraying passwords from old breaches at Microsoft 365 accounts through the Azure command-line client (Azure CLI), whose password-only sign-in never shows an MFA prompt. Huntress reported one campaign that made more than 81 million sign-in attempts in two weeks of June 2026 and compromised 78 accounts at 64 organizations.

Any organization whose MFA policy leaves gaps is exposed. On October 23, 2026, Fluency released to every instance a detection for the takeover that follows a blocked attempt. No action is needed to turn it on.