Azure CLI as attack vector: 81 million login attempts expose a Conditional Access blind spot

In the second half of June 2026, one of the largest password spray campaigns specifically targeting Microsoft 365 environments took place. Attackers sent more than 81 million login attempts in fourteen days, used credentials from earlier data breaches, and managed to obtain a valid token for at least 78 user accounts across 64 organisations. What makes the attack distinctive is not the volume, but the vector: Azure CLI via the OAuth Resource Owner Password Credentials flow.

Many IT teams operate carefully constructed Conditional Access policies that cover browser and mobile app sign-ins. The ROPC flow falls structurally outside that coverage. That made this campaign more effective than a classic phishing attack, and exposed a configuration gap that remains open in countless tenants.

What is the ROPC flow and why does Azure CLI use it?

ROPC stands for Resource Owner Password Credentials and is an OAuth 2.0 flow in which the username and password are sent directly to the token endpoint of the identity provider. There is no browser redirect, no login page, and no interactive step. The client, in this case Azure CLI, exchanges the credentials directly for an access token.

Azure CLI has traditionally used ROPC for non-interactive scenarios: script automation, CI/CD pipeline tasks, and management scripts that run without human intervention. The flow is also supported by other Azure SDK clients and various legacy applications built before modern OAuth flows were widely available.

The crucial difference from an interactive sign-in is that Entra ID logs the ROPC sign-in as a non-interactive sign-in attempt. This places the session outside the scope of Conditional Access policies that apply only to interactive sign-ins, which is the case in most default configurations.

Why does MFA not fire with ROPC?

Multi-factor authentication such as entering a TOTP code or approving a prompt in the Authenticator app is an interactive action. With an ROPC sign-in there is no user interface and therefore no way for the user to supply that second factor. Entra ID accepts a valid username-password pair via ROPC and returns a token, unless you have explicitly configured ROPC to be blocked or required an authentication strength that ROPC cannot satisfy.

The common mistake is building Conditional Access policies with the goal of enforcing MFA on sign-ins from unfamiliar locations or requiring MFA for certain apps. If the policy only covers interactive sign-ins and not ROPC sign-ins for the same apps or users, there is a gap. The attackers in the campaign systematically tested whether ROPC worked per organisation before launching a larger spray round.

Which organisations were at risk?

The risk profile is broader than expected. Every organisation that has not explicitly blocked ROPC in Entra ID is at risk as long as accounts exist with a weak or leaked password. The campaign exclusively used credentials circulating in lists from earlier data breaches. Organisations without active password protection, without a smart lockout threshold, or with accounts of former employees still active in Entra were particularly vulnerable.

A second risk group are tenants with Conditional Access in report-only mode. In that mode, policies are evaluated but not enforced, meaning the logs show that a sign-in would have been blocked but the sign-in succeeds regardless. During Conditional Access implementation, report-only is a useful intermediate stage, but if that mode remains in place for months or years, the policy provides no protection at all.

Blocking ROPC in Entra ID: the configuration steps

The most direct defence is fully blocking the ROPC flow for user accounts. Do this via a Conditional Access policy that sets Authentication flows as a condition and explicitly blocks the Resource Owner Password Credentials flow. The policy applies to all users, all apps, and requires no exception unless you have a documented system that requires ROPC.

For the exception cases, automation and scripts currently using ROPC, the advice is to rewrite these to use client credentials with a managed identity or a service principal with certificate-based authentication. These are modern, secure alternatives that do not require a user password and are therefore not susceptible to credential stuffing.

In parallel with blocking ROPC, configure a Conditional Access policy that enforces Authentication Strength on all sign-ins. Choose the built-in Phishing-resistant MFA strength as the requirement, or create a custom strength that includes passkeys and Windows Hello for Business. A sign-in attempt via ROPC cannot meet this strength by definition and is therefore automatically blocked, even if you have not separately excluded the ROPC flow.

What do you see in the Entra logs?

To check whether ROPC is active in your tenant, open the Entra portal, navigate to Sign-in logs, and filter on Authentication protocol with the value ROPC. If you see results, you know that ROPC is being used. Then examine whether the sign-ins originate from legitimate automated processes or from unknown IP addresses and locations. Sign-ins from the same user across multiple geographically dispersed IP addresses within a short time window are a strong indicator of active spray activity.

Organisations with Microsoft Sentinel can build an analytics rule that alerts when more than fifty ROPC attempts from the same IP address are detected within a five-minute window. That pattern is characteristic of automated spray tooling and almost never the result of legitimate use.

Additional defence layers

Blocking ROPC is the direct measure, but a layered approach provides stronger protection. Microsoft Entra ID Protection, available from the P2 licence level, detects risky sign-ins based on behavioural patterns and breach detection. Configure sign-in risk policies to automatically enforce MFA or block the session at medium and high risk. This also catches attack vectors that do not run via ROPC.

Microsoft Entra Password Protection blocks commonly used and known weak passwords both in the cloud and in on-premises Active Directory. Given that the June campaign exclusively used leaked password lists, this helps limit damage for accounts that do not yet have a strong password.

The most definitive measure is eliminating passwords for user accounts. A passkey or Windows Hello for Business enrolment makes an account completely immune to every form of password spray, including ROPC, because there is simply no password left to crack or replay.

What do you do this week?

Three concrete actions you can schedule immediately. First action: open the Entra sign-in logs and filter on ROPC. Determine whether and by whom this flow is being used. This takes less than five minutes and gives you immediate insight into the exposed surface.

Second action: review your Conditional Access policies for coverage of non-interactive sign-ins. Check that policies are set to Enabled rather than Report-only and that all users and all apps are covered. A policy that makes exceptions for service accounts or legacy apps is a potential gap.

Third action: plan the ROPC block for all user accounts. Inform administrators who may be using Azure CLI in scripts so they can migrate their workflows to managed identities or service principals. The block itself can be configured in Conditional Access within ten minutes.

Want an independent audit of your Conditional Access configuration, help designing a passwordless strategy, or guidance migrating ROPC-dependent scripts? Contact Zarioh for a practical conversation without obligation.