The Azure CLI Password-Spray Campaign: Misconfiguration Exploited by Malicious Actors

Overview

From 12 to 26 June 2026, cybersecurity company Huntress observed a campaign of automated password-spraying targeting Microsoft Entra ID accounts by way of the signing path for the Azure CLI. During this time, the operator made about 81 million login attempts. The operator was successful in compromising at least 78 accounts, representing 64 different organizations. This campaign became notorious not for the volume of attempts, since password-spraying attacks are ubiquitous, but for the fact that several of the victim tenants had some form of multi-factor authentication (MFA) protection, as well as some form of Conditional Access (CA) policy, formally enabled. The attacker was still able to gain access by traversing an authentication flow which was not evaluated by the MFA or CA controls.

What Happened

The automated password-spraying attack originated almost exclusively from a specific IPv6 range (2a0a:d683::/32) operated by the LSHIY LLC infrastructure (AS32167), with a very small number of addresses allocated in the United States and China. The operator displayed opportunistic targeting, which is not evident within a specific industry, and replayed login attempts using previously compromised password lists or “combo” lists.

The attack occurred in a series with 12 to 21 June, yielding a small number of successful login attempts (between 2 and 4; 12 successful logins on 19 June, with a notable increase). On 22 June, the operation expanded significantly resulting in the compromise of 30 accounts across 23 different companies. Of special note, at least eight of the compromised companies had no MFA policy in force.

Why It Worked: ROPC and the Conditional Access Gap

The campaign’s method incorporated ROPC (Resource Owner Password Credential), which is an old method of OAuth 2.0 that allows clients to send their username and password straight to the token endpoint. Microsoft is very clear that ROPC should not be used, instead use Entra ID MFA and Conditional Access Policy in such a way that does not leave gaps that can be exploited by attackers using stolen credentials and ROPC. 

This was the goal of the attack. Because ROPC cannot present an MFA claim, a Conditional Access policy that requires MFA never lets a ROPC sign-in "pass" for any given sign-in, the policy either applies and denies the request outright, or it does not apply at all. There is no third outcome where ROPC succeeds under an MFA-requiring policy when this policy leaves gaps. Huntress found that in the affected tenants, the sign-ins sampled fell into the second case: the Conditional Access policy in force simply did not apply. For example, MFA was required for certain cloud apps but not configured for All resources, or MFA was required only for admin users, or MFA was only enforced when the user was outside a trusted location. An ordinary user running the Azure CLI from a trusted location fell outside every one of those narrowed conditions, so no policy applied, and the ROPC request went through on a correct password alone. In the smaller number of cases where the Conditional Access policy was actually scoped to cover the sign-in of all users, all resources, all locations & for these the ROPC request was denied, because it could never satisfy the MFA requirement.

What This Is — and What It Is Not

This is not a vulnerability in Azure or a zero-day in Microsoft’s platform, and there is no CVE to patch. Entra ID behaved exactly as documented. This is a misconfiguration problem. The Conditional Access policies that were enabled but incompletely scoped is a vulnerability in the landscape. The fix is configuration and identity hygiene, not waiting on a vendor update.

How to Protect Yourself

The following maps directly to Microsoft's own guidance and closes the gaps this campaign exploited.

Check whether you were affected:

• Hunt and respond by credential validity. Review sign-in logs for ROPC / Azure CLI sign-ins during 12–26 June, especially from the 2a0a:d683::/32 range. Treat any account that authenticated successfully via ROPC in that window as compromised: revoke refresh tokens and sessions, reset the password, and check for follow-on activity such as new app registrations or mailbox rules.

  
  

If you have Microsoft Entra ID P1 or P2 (Conditional Access is available):

1. Enforce a baseline MFA policy with no gaps: Enable Require MFA via Conditional Access for All users, All resources (formerly All cloud apps), and all client app types. Azure CLI is a first-party Microsoft public client application, and it is automatically in scope whenever a policy targets All resources, it is left uncovered only when a policy is scoped to specific named apps instead of All. Avoid per-application or per-group carve-outs that leave the Azure CLI sign-in uncovered, the single most common reason this campaign succeeded against MFA-enabled tenants.

   
   

2. Turn on the managed “Require MFA for Azure management” policy. This Microsoft-managed Conditional Access policy explicitly names the Azure portal, Entra admin center, Azure PowerShell, and the Azure CLI as covered resources, so it closes this specific gap directly even before a full "All resources" baseline (#1) is rolled out. Enable both: #1 the comprehensive baseline, and #2 the fastest, most direct control for this exact attack surface.

   
   

If you don't have P1 or P2 (Microsoft Entra ID Free):

3. Enable Security Defaults. Conditional Access requires a Microsoft Entra ID P1 or P2 license. Tenants without one can still close this gap at no extra cost by turning on Security Defaults: it requires MFA for sign-in to the Azure portal, Microsoft Entra admin center, Azure PowerShell, and the Azure CLI, by name, for every user. Because Security Defaults is all-or-nothing — it cannot be scoped to specific apps, groups, or locations — it is not exposed to the kind of partial-coverage gap this campaign relied on.

   
   

 For everyone, regardless of license:

4. Restrict who can use the Azure CLI. Limit the Microsoft Azure CLI enterprise application (app ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46) to the users and groups who genuinely need it, and disable it for everyone else. Assigning individual users, or disabling the app for everyone else, does not require a premium license; only group-based assignment requires Microsoft Entra ID P1 or P2. Do not rely on the “Block legacy authentication” toggle alone — it targets basic-auth protocols such as IMAP/POP/ActiveSync and will not necessarily stop ROPC, which reaches the modern token endpoint.

   
   

5. Kill reused and leaked credentials. Force password resets for accounts whose passwords may appear in breach corpora, enable Microsoft Entra Password Protection with a banned-password list.  Also review Entra ID Protection leaked-credential and sign-in risk signals (requires P2 license). Move to passwordless authentication with FIDO2 security keys or passkeys where possible.

   
   

Bottom Line

MFA did not fail in this campaign, it simply wasn’t in effect for the sign-ins attackers used. Where you land depends on your license:

• Entra ID P1 or P2 licenses: Enable the baseline “All users, All resources, all client app types” MFA policy or at least Microsoft’s managed “Require MFA for Azure management” policy. 

• Entra ID Free (everyone, no need for P1/P2 licenses): Turn on Security Defaults. It requires MFA for the Azure portal, Entra admin center, Azure PowerShell, Azure CLI, and because it can’t be partially scoped it isn’t vulnerable to the gap this campaign exploited.

• Everyone, regardless of license: Restrict further who can sign in to the Azure CLI, force resets on any reused or leaked password. Treat any account that authenticated via ROPC during 12–26 June as compromised until proven otherwise. Rotate the credentials.

• For applications and scripts: Switch to Service Principal / Managed Identity for automated scripts, apps, CICD etc. 

• Users with CLI: When MFA is enabled users can switch to the interactive  az login (browser/WAM/device-code) and Entra ID will prompt for MFA. 

  
  

MFA protects sign-ins only where it is in use, and legacy flows like ROPC will use any seam that is not closed. Broaden the MFA scope, retire the legacy flow, and rotate the credentials that the attackers already hold.

Learn how InviGrid Intelligent Cloud platform helps you implement these controls:

Contact us: info@invigrid.com  or Contact Us using this form.

References

1. Huntress — “No (Bad) CAP: Inside an Ongoing LSHIY Password Spray Attack” (June 2026). https://www.huntress.com/blog/lshiy-password-spray-attack

2. The Hacker News — “Azure CLI Password Spray Hits at Least 78 Microsoft Accounts in 81M+ Attempts.” https://thehackernews.com/2026/07/azure-cli-password-spray-hits-at-least.html

3. SecurityWeek — “Massive Password Spray Campaign Targeting Azure CLI.” https://www.securityweek.com/massive-password-spray-campaign-targeting-azure-cli/

4. Microsoft Learn — “Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials.” https://learn.microsoft.com/entra/identity-platform/v2-oauth-ropc

5. Microsoft Learn — “Authentication flow support in the Microsoft Authentication Library (MSAL).” https://learn.microsoft.com/entra/identity-platform/msal-authentication-flows

6. Microsoft Learn — “Require multifactor authentication for all users.” https://learn.microsoft.com/entra/identity/conditional-access/policy-all-users-mfa-strength

7. Microsoft Learn — “Microsoft-managed Conditional Access policies.” https://learn.microsoft.com/entra/identity/conditional-access/managed-policies

8. Microsoft Learn — “Commonly used Microsoft first-party services and portal apps.” https://learn.microsoft.com/power-platform/admin/apps-to-allow