Automated Password Spray Attacks Target Microsoft Azure CLI

Key Takeaways

• An extensive automated password spray campaign is targeting Microsoft Azure CLI and Entra ID accounts.
• The attackers exploit legacy OAuth Resource Owner Password Credentials (ROPC) flows to bypass multi-factor authentication (MFA) protections.
• Over 81 million login attempts were observed, compromising at least 78 accounts across 64 organizations within a two-week period.
• The campaign leverages previously exposed credentials and originates primarily from IP ranges linked to LSHIY LLC, an internet infrastructure provider with suspected ties to China.
• Organizations must reconfigure Conditional Access Policies (CAPs) to block ROPC and enforce MFA broadly across all users, applications, and client types.

A sophisticated, large-scale automated password spray campaign is actively exploiting Microsoft’s Azure Command-Line Interface (CLI) and outdated OAuth mechanisms to compromise Entra ID accounts. This ongoing threat circumvents multi-factor authentication (MFA) in many affected organizations, posing a significant risk to cloud environments.

Cybersecurity firm Huntress has been monitoring this persistent password and token spraying activity, specifically targeting Microsoft 365 and Azure CLI logins. A notable surge in this campaign was observed between June 12 and June 26, 2026.

Campaign Scope and Impact

During this two-week period, the attackers initiated more than 81 million login attempts against Huntress’s customer tenants. This relentless assault resulted in the successful compromise of at least 78 Microsoft accounts spanning 64 distinct organizations.

Initially, the daily rate of compromises remained relatively low, typically affecting two to four accounts per day. However, this escalated sharply on June 22, when 30 user identities across 23 businesses were compromised, signaling a significant intensification of the campaign.

This attack is part of a broader trend of escalating credential spraying. Huntress reports a staggering 155-fold increase in credential spray volume across its customer base over the last six months. Currently, tenants experience an average of 1,964 failed attacks monthly, with a median of 804.

Target selection in this campaign appears opportunistic, driven by the availability of username-password combinations in existing breach data rather than specific industry verticals. This suggests attackers are leveraging previously compromised credentials that have not been rotated by users.

Attack Origins and Infrastructure

The majority of the observed attack traffic originates from the IPv6 address range 2a0a:d683::/32, which is advertised under autonomous system AS32167. This ASN is attributed to LSHIY LLC, an internet infrastructure provider. LSHIY operates at least two ASNs—AS32167, registered in June 2021, and AS955, registered in June 2022. Third-party telemetry consistently links their IPv6 prefixes to Chinese origin.

Corporate registration documents further connect LSHIY to factory addresses in Hong Kong and Wuhan, as well as a shared office space at 42 Broadway in New York. This complex setup likely serves to obfuscate the true operational ownership of the entity. Huntress has submitted abuse reports to LSHIY regarding the observed malicious activity but has not yet received a response.

Exploiting Legacy OAuth Flows

The threat actor’s methodology involves replaying old username-password pairs, previously exposed in data breaches but never updated, and validating them through the OAuth Resource Owner Password Credentials (ROPC) flow utilized by Azure CLI.

ROPC, a flow deprecated in OAuth 2.1, directly exchanges a raw username and password at the token endpoint to issue user-delegated access tokens without requiring an interactive authorization step. This is critical because Conditional Access Policies (CAPs) typically enforce MFA at the authorization endpoint. By bypassing this endpoint, ROPC can circumvent inadequately configured policies, allowing tokens to be issued without an MFA challenge.

Huntress found that many compromised tenants had MFA and CAPs deployed but suffered from critical configuration gaps. Common misconfigurations included scoping MFA to specific cloud applications instead of “All Cloud Apps,” restricting MFA enforcement solely to privileged groups like administrators, limiting MFA to non-trusted geographical locations, and leaving policies in a report-only mode, which logs events but does not enforce controls.

In several instances, geolocation inaccuracies erroneously identified attacking IPs as U.S. addresses. This allowed them to bypass “trusted location” logic, even when other telemetry clearly indicated their true origin in China.

What You Should Do

• Block ROPC and Legacy Authentication: Treat Azure CLI and ROPC as high-risk surfaces. Disable legacy grants and authentication protocols within your tenant.
• Enforce MFA Broadly: Configure Conditional Access Policies (CAPs) to require MFA for “All users,” “All cloud apps,” and “All client app types.” Do not scope MFA only to specific applications or privileged groups.
• Strengthen Client-Level Authentication: Implement strong authentication at the client level using settings like userStrongAuthClientAuthNRequired to prevent ROPC-based token grants.
• Restrict Azure CLI Access: Where feasible, restrict Azure CLI access to only those non-admin users who genuinely require it, or explicitly block it via dedicated CAP rules.
• Refine Named Locations: Continuously review and tighten named locations within your CAPs to accurately reflect trusted network boundaries and prevent geolocation bypasses.
• Test CAP Configurations: Regularly test the behavior of your CAPs using tools such as Microsoft’s “What If” simulator to identify any report-only or excluded policies that might leave gaps in your security posture.
• Monitor for Anomalous Activity: Implement robust logging and monitoring for failed login attempts, unusual access patterns, and token issuance via ROPC flows.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.