Home > Security and Compliance Blog > Cybersecurity Risk Management > 81 Million Azure CLI Password Spray Attempts. The Attackers Weren’t Trying to Break MFA. They Were Going Around It.

81 Million Azure CLI Password Spray Attempts. The Attackers Weren’t Trying to Break MFA. They Were Going Around It.

by Patrick Spencer updated July 2, 2026 Cybersecurity Risk Management

Reading Time: 11 minutes

Eighty-one million password spray attempts. Seventy-eight compromised accounts. Thirty-nine organizations affected. Those are the numbers Huntress published on July 1, 2026, from an active campaign targeting Microsoft Azure environments – and the most important number isn’t any of those. The most important number is zero, which is how many MFA prompts the attackers triggered.

This wasn’t a campaign built around breaking MFA. It was built around going around it entirely. The technique is not new – security researchers have documented ROPC-based authentication attacks before – but the scale of this campaign and the specificity of the Azure CLI targeting make it the clearest recent example of what happens when legacy authentication flows coexist with modern identity controls in the same enterprise environment.

Table of Contents

The Huntress research documents how attackers used the Resource Owner Password Credentials OAuth 2.0 flow to authenticate directly to Azure AD without triggering conditional access policies or MFA requirements. Understanding why this works requires understanding what ROPC is, how it differs from modern authentication flows, and why it’s still accessible in most Azure tenants despite Microsoft’s deprecation of the protocol.

Key Takeaways

1. Huntress documented 81 million Azure CLI password spray attempts, compromising 78 accounts across 39 organizations.

The campaign targeted a legacy OAuth 2.0 flow called Resource Owner Password Credentials (ROPC), which transmits credentials directly to Azure AD and bypasses modern MFA and Conditional Access Policy enforcement entirely.

2. ROPC is deprecated by Microsoft but remains widely functional.

The OAuth 2.0 ROPC flow was designed for legacy systems that can’t redirect users to a browser for authentication. Microsoft deprecated it in favor of modern flows, but because it’s still technically operational in most Azure tenants, attackers can use it to authenticate without triggering MFA or Conditional Access Policy controls.

3. Conditional Access Policy misconfiguration is the root enabler.

Even organizations that have deployed Conditional Access Policies often have coverage gaps – specific applications, user groups, or location-based conditions that leave ROPC traffic unprotected. The Azure CLI is a common exception, meaning developer credentials authenticated via ROPC can reach production resources.

4. The attack pattern exploits the authentication gap between policy intent and technical enforcement.

Organizations believe MFA protects their Azure environment because it protects browser-based authentication. ROPC authentication doesn’t go through the same flow. This is not a vulnerability in MFA itself – it’s a misconfiguration that leaves a legacy authentication path open alongside the modern one.

5. The fix requires more than password hygiene.

Blocking the ROPC attack path requires a combination of: blocking legacy authentication protocols at the tenant level, auditing Conditional Access Policy coverage for gaps, rotating credentials on accounts with Azure CLI access, and implementing Identity and Access Management controls that flag ROPC authentication events as anomalous.

You Trust Your Organization is Secure. But Can You Verify It?

Read Now

What ROPC Is and Why It Still Exists

The OAuth 2.0 framework provides multiple authentication flows designed for different use cases. The modern standard for interactive user authentication is the Authorization Code flow with PKCE – it redirects users to an identity provider, collects credentials there, and returns an authorization code to the application. This flow is compatible with MFA and Conditional Access Policies because the authentication happens at the identity provider where those controls live.

ROPC was designed as an alternative for legacy applications that can’t perform browser-based redirects. Instead of sending users to a login page, ROPC accepts credentials directly from the application and passes them to the identity provider as a POST request. The application itself handles the credential exchange.

Microsoft deprecated ROPC because it’s architecturally incompatible with modern security controls. Credentials flow through the application rather than through the identity provider’s authentication UI, which means MFA prompts can’t be injected into the flow. Conditional Access Policies that trigger on sign-in events don’t fire. Token issuance happens without the identity provider’s full conditional access evaluation completing.

The problem is that deprecation doesn’t mean disabled. ROPC is still functional in most Azure tenants. Microsoft has been moving customers toward modern authentication flows, but ROPC remains operational for backward compatibility with legacy systems. In the Huntress-documented campaign, attackers used ROPC to authenticate against Azure CLI – a common developer tool with access to Azure resources – because Azure CLI supports ROPC authentication and because most organizations haven’t explicitly blocked it. A formal risk assessment of authentication protocol coverage — specifically mapping which legacy flows remain enabled across which application scopes — is the starting point for closing this class of gap before it becomes a breach.

How the Attack Works in Practice

The Huntress-documented campaign follows a recognizable pattern: enumerate valid usernames, execute credential stuffing or spray against ROPC-accessible endpoints, harvest tokens from successful authentications, use those tokens to access Azure resources.

The Azure CLI piece matters because of what CLI access typically reaches. Developer accounts with Azure CLI access commonly have permissions to production environments, resource groups, storage accounts, and compute resources. The CLI is a management tool – it’s supposed to have broad access. When attackers compromise a CLI credential via ROPC, they don’t just get email access. They potentially get infrastructure access.

Brute force attacks against traditional authentication endpoints are noisy. They generate failed login events that SIEM platforms and identity protection systems detect and alert on. ROPC-based password sprays can be quieter: they don’t generate the same browser-session authentication events, and many organizations’ logging configurations don’t capture ROPC token issuance with the same fidelity as interactive sign-in events.

The 81 million attempt figure reflects the computational cost of credential spraying at scale – it’s a large number, but the 78 successful compromises (0.000096% success rate) also reflects how credentials are spread across many attempts before finding a match. The real threat model isn’t the raw attempt count. It’s that each successful ROPC authentication returns a bearer token that grants access to everything the compromised account can reach. A single compromised developer account that reaches production storage accounts, compute resources, and CI/CD pipelines is a data breach and an infrastructure-level incident simultaneously — the combination of intellectual property in code repositories and regulated data in cloud storage means the notification and remediation obligations can be significant.

Phishing and password reuse are the most common sources of the credentials used in spray campaigns. Once credentials appear in breach databases – and most do, eventually – they become inputs for automated spray tools. ROPC authentication at scale is largely a function of: (a) how many valid credentials attackers have obtained from prior breaches, and (b) how many tenant endpoints are accessible via ROPC without CAP enforcement.

The Conditional Access Policy Coverage Problem

Conditional Access Policies are the primary defense-in-depth control for Azure AD environments. They allow organizations to define conditions under which authentication succeeds – requiring MFA, blocking risky sign-in locations, restricting access to compliant devices. When correctly configured, CAPs make password sprays largely ineffective because even a valid credential won’t successfully authenticate without satisfying the policy conditions.

The coverage problem in ROPC attacks isn’t that CAPs don’t work. It’s that CAP coverage is rarely complete. Organizations deploy CAPs incrementally, often starting with high-priority applications and user groups, and accumulating exceptions over time. The Azure CLI is a common exception: developers need CLI access, CLI-based tooling often runs in automated pipelines that can’t handle MFA interruptions, and the result is a CAP exemption that makes CLI authentication a soft target.

Security misconfiguration in the identity layer is consistently one of the highest-leverage attack vectors. A single misconfigured policy exception can expose credentials to legacy authentication paths that circumvent otherwise robust MFA enforcement. The Huntress campaign is a direct consequence of that dynamic: 78 accounts compromised not because MFA is weak, but because 78 accounts had a CAP exception or were in an application scope that allowed ROPC authentication.

The audit question organizations should be asking is not “do we have Conditional Access Policies?” but “do our Conditional Access Policies cover all authentication paths, including legacy protocol endpoints, for all user accounts?” Most organizations have not audited this at the protocol level. Extending supply chain risk management disciplines to this question matters particularly for organizations that have granted Azure CLI access to third-party developers, contractors, or managed service providers — each external credential with CLI access is a ROPC exposure point that the primary organization’s CAP audit may not directly control.

Identity Governance Beyond MFA

The ROPC attack pattern makes a structural argument about identity security that MFA alone doesn’t address. MFA is a control that operates on interactive authentication flows. Legacy authentication protocols were designed to operate outside interactive flows. They are, by design, MFA-incompatible.

The architectural response requires working at the protocol level, not just the credential level. Blocking legacy authentication means configuring Azure AD to reject ROPC token requests entirely – a CAP can be created that blocks legacy authentication for all users or scoped user groups. This is the primary recommended mitigation from Microsoft’s own guidance and from the Huntress research.

Role-based access control and attribute-based access control frameworks that scope developer credentials to least-privilege access reduce the blast radius of a ROPC compromise. A developer account that can only read from specific storage containers and deploy to specific resource groups is less catastrophic to compromise than an account with Contributor access to a full subscription. Data minimization applied to credential scope — provisioning developer accounts with the minimum Azure permissions their current task requires, reviewed at defined intervals rather than accumulating over years of role changes — is the operational practice that makes least-privilege a runtime reality rather than a provisioning-time intent.

Identity and Access Management programs that treat developer credentials as a distinct risk category – with rotation schedules, access scope reviews, and anomaly detection for ROPC token issuance – are the enterprise-level response to this attack pattern. Most IAM programs were built around managing human-provisioned credentials in browser-based workflows. Developer credentials used in CLI tools and automation pipelines often fall outside those workflows.

Zero trust architecture applied to cloud identity requires continuous verification at the authentication event level, not just the application access level. When a token is issued via ROPC, zero trust principles say that token should be evaluated for risk signals – unusual source geography, credential reuse patterns, access velocity – before resources are served. That continuous evaluation is what CAP-based controls provide, which is exactly why ROPC’s CAP bypass is so significant.

The Kiteworks 2026 Data Security and Compliance Risk: Annual Forecast Report found that identity and access management gaps remain among the most common root causes in enterprise data breaches. The ROPC campaign Huntress documented is a precise example of that finding: not a sophisticated zero-day, but a legacy protocol gap that most organizations haven’t specifically addressed in their identity governance programs. Organizations that route sensitive content through a Private Data Network with policy-enforced access controls and immutable audit logging at the content layer have an additional containment boundary: even a compromised Azure credential with production access cannot reach content that Kiteworks’ own ABAC policies restrict to specific authorized identities.

Immediate Remediation Steps

The Huntress research offers specific guidance organizations can act on immediately. The core mitigations are:

Block legacy authentication at the tenant level. Azure AD Conditional Access Policies can block legacy authentication protocols including ROPC for all users, or scoped to user groups and applications. Microsoft provides a policy template specifically for this. Organizations that have delayed this step because of legacy application dependencies need to audit those dependencies and build a migration path.

Audit Conditional Access Policy coverage. Map every user account and application against the CAP policies that apply to them. Identify gaps – applications with no CAP applied, user accounts excluded from MFA requirements, service accounts with CLI access that bypass conditional access. Every gap is a potential ROPC exposure.

Rotate credentials for accounts with Azure CLI access. In the Huntress campaign, 78 accounts were successfully authenticated via ROPC before the campaign was detected. Organizations that can’t rule out exposure should rotate credentials for all developer accounts with CLI or programmatic Azure access.

Enable sign-in logging for ROPC events. Azure AD’s sign-in logs capture authentication events, including legacy authentication. Configuring SIEM alerts for ROPC authentication events provides early warning of future spray attempts – and establishes the audit log baseline needed for incident response.

Implement anomaly detection on token issuance. ROPC token requests that originate from unexpected IP ranges, geographies, or at unusual times are detectable signals. Identity protection tools that score authentication risk events can flag ROPC spray attempts before successful authentications multiply. The CISO Dashboard provides security leadership with real-time visibility into content access patterns across all governed channels — so that anomalous activity following a credential compromise is surfaced before it escalates to a reportable incident.

To learn more about how Kiteworks addresses identity governance, access controls, and cloud security misconfiguration in regulated environments, schedule a custom demo today.

Frequently Asked Questions

The Resource Owner Password Credentials (ROPC) flow is a legacy OAuth 2.0 authentication mechanism that passes user credentials directly from an application to the identity provider as a POST request, bypassing the browser-based redirect authentication used by modern flows. Because credentials flow through the application rather than the identity provider’s authentication UI, MFA prompts cannot be injected into the flow and Conditional Access Policy sign-in evaluations do not fire. Microsoft deprecated ROPC because of these security limitations, but the protocol remains functional in most Azure tenants for backward compatibility with legacy applications. Huntress documented attackers using this flow to execute 81 million password spray attempts against Azure CLI endpoints in 2026, successfully compromising 78 accounts without triggering a single MFA prompt. The security misconfiguration is not in MFA itself but in the continued availability of an authentication path that bypasses it. Organizations subject to regulatory compliance obligations — HIPAA, CMMC, GDPR, FINRA — should treat ROPC availability in their Azure tenant as a compliance gap, since unmonitored legacy authentication paths undermine the access control documentation those frameworks require.

An Azure CLI password spray attack using ROPC works as follows. Attackers obtain or compile a list of valid Azure AD user credentials – commonly from prior breach databases, phishing campaigns, or credential stuffing results. They then submit those credentials against Azure AD’s ROPC token endpoint using Azure CLI authentication requests. When credentials are valid and no Conditional Access Policy blocks the ROPC flow for that account, Azure AD issues an access token without triggering MFA. The attacker then uses that token to authenticate Azure CLI commands against the victim’s Azure resources. The attack is detectable via SIEM monitoring of legacy authentication sign-in events in Azure AD logs, but only if logging is enabled and alerts are configured. Zero trust architecture principles that require continuous verification at the token issuance level – including risk scoring for legacy authentication requests – provide detection coverage that MFA alone does not. A documented incident response plan that explicitly covers ROPC compromise scenarios — including the Azure activity log review steps and credential rotation sequence — gives security teams a defined path from detection to containment.

A Conditional Access Policy (CAP) in Azure AD defines conditions under which authentication succeeds – requiring MFA from specific locations, blocking risky sign-in events, or restricting access to compliant devices. When correctly configured and scoped, CAPs make password spray attacks largely ineffective because even valid credentials won’t authenticate without satisfying the policy conditions. The ROPC attack bypasses CAPs because CAP enforcement fires on interactive sign-in events; ROPC token requests don’t trigger the same sign-in event flow. Additionally, many organizations have CAP exceptions for developer tools, automation pipelines, and legacy applications that need ROPC-compatible authentication. These exceptions create the coverage gaps that the Huntress-documented campaign exploited. Identity and Access Management audits that specifically map authentication protocol coverage – not just application coverage – are required to identify these gaps. Applying access controls at the content layer — not only at the identity layer — provides a second enforcement boundary that remains effective even when an authentication gap allows token issuance to proceed.

Requiring MFA in Azure AD means that interactive authentication flows trigger an MFA challenge before issuing tokens. Blocking legacy authentication means that Azure AD rejects token requests that use legacy authentication protocols (including ROPC) entirely, regardless of credential validity. These are two separate controls with different effects. MFA alone does not protect against ROPC attacks because ROPC bypasses the interactive authentication flow where MFA fires. Blocking legacy authentication stops ROPC token requests before credential evaluation, preventing the attack at the protocol level. Microsoft recommends blocking legacy authentication as a baseline security configuration, and Azure AD provides a named CAP template for this purpose. Organizations should implement both controls: requiring MFA for all interactive authentication and blocking legacy authentication protocols for all user accounts and applications that have migrated to modern authentication flows. Role-based access control scoping developer credentials to least-privilege reduces the damage from any legacy authentication gap that remains. Third-party risk management programs should verify that managed service providers and contractors operating in the Azure environment have confirmed they have blocked legacy authentication in their own administrative tooling — an MSP account with ROPC-accessible CLI credentials creates the same exposure as an internal developer account.

Organizations that believe they may have been targeted by an Azure CLI ROPC password spray should take five immediate actions. First: pull Azure AD sign-in logs and filter for legacy authentication events over the past 90 days – ROPC token requests appear as legacy authentication sign-in events. Second: identify any accounts that successfully authenticated via legacy authentication and review their Azure activity logs for unauthorized resource access. Third: rotate credentials for all accounts with Azure CLI access, regardless of whether ROPC authentication is confirmed. Fourth: implement a Conditional Access Policy that blocks legacy authentication for all user accounts, or at minimum for all accounts with Azure CLI or programmatic API access. Fifth: review and close all CAP exceptions for developer tools and automation service accounts. Establishing a complete audit log baseline and configuring SIEM alerts for future ROPC authentication events should follow. The incident response process should document findings for any regulatory compliance notification obligations that apply. Organizations managing regulated data — PHI, CUI, PII — should additionally assess whether any storage accounts or data repositories accessible to the compromised Azure credentials contain content requiring data breach notification under applicable frameworks.

Additional Resources