Why Azure CLI Makes Your MFA Irrelevant
Between June 12 and June 26, attackers made 81 million login attempts against Microsoft 365 tenants and compromised 78 accounts across 64 organizations. Most of those organizations had MFA enabled. The attackers did not bypass MFA. They used a path that MFA was never designed to cover.
The gap in the story about MFA
The attack abuses the Resource Owner Password Credential (ROPC) OAuth 2.0 flow, which allows an application to authenticate directly using a username and password without redirecting through the normal browser-based consent flow. This means no login page, no push notification, no TOTP prompt.
Azure CLI is registered in Microsoft Entra ID as an implicitly trusted first-party application. It is not subject to the OAuth consent restrictions that apply to third-party apps. And by default, Conditional Access policies that require MFA do not apply to ROPC sign-ins unless the policy is explicitly written to cover them.
Most organizations' Conditional Access policies were not explicitly written to cover ROPC.
What Huntress found
Security firm Huntress tracked the activity to infrastructure registered to LSHIY LLC, a mix of US-registered and China-resolving IP addresses. The targeting was not strategic: the attackers worked from compromised password combo lists and attempted logins based purely on password prevalence. No particular industry or business type was targeted.
The result was steady: two to four compromised accounts per day from June 12 to 21, with a spike on June 19 (12 accounts) and another on June 22 (30 accounts across 23 organizations). By June 26, 78 accounts were confirmed compromised across 64 organizations.
Why organizations with MFA were still hit
ROPC authenticates using the credential directly, not through the interactive login flow that triggers MFA challenges. If a user's password appears in a combo list and ROPC is not blocked by Conditional Access, the attacker authenticates as that user. The only protection is the password itself.
This is not a novel attack. ROPC has been a documented risk in Azure AD environments for years. The ConsentFix framing adds a social engineering layer, but the credential spray variant documented by Huntress is simpler: just username, password, and the Azure CLI OAuth endpoint. The only novel element in 2026 is the scale: 81 million attempts in two weeks is operationally significant.
What to do
Three things need to happen.
First, create a Conditional Access policy targeting the Azure CLI application ID that requires either a compliant device or hybrid Azure AD join, or use an Authentication Strength policy that explicitly excludes password-only authentication flows. Test it in report-only mode first, since ROPC blocking can break legitimate automation.
Second, search your Azure AD sign-in logs for entries with grant_type=password. If you have never looked for these, you may find activity you did not expect.
Third, audit service accounts and automation pipelines that use ROPC for legitimate purposes. Migrate them to client credential flows or managed identities before blocking ROPC tenant-wide.
The broader lesson
MFA protects the interactive login flow. Attackers go around the login flow. This is not a new pattern: device code phishing, token theft, and ROPC spray are all variations on the same theme. The perimeter is not the password anymore. The perimeter is the scope of your Conditional Access coverage, and most organizations have gaps they have not audited.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if your organization needs help auditing Conditional Access coverage or closing OAuth authentication gaps.