Azure CLI Password Spray Bypasses MFA

An Azure CLI password spray campaign made more than 81 million login attempts against Microsoft accounts over two weeks and successfully compromised 78 accounts across 64 organizations — a meaningful share of which believed multi-factor authentication already protected them. The attackers did not break MFA. They found a legacy authentication path that most Conditional Access policies never account for, and walked straight past it.

What Happened

Between June 12 and June 26, Huntress tracked a threat actor, with activity linked to internet infrastructure provider LSHIY LLC (AS32167), running a sustained password spray campaign against Microsoft accounts. Volume peaked around June 22, when 23 businesses were compromised in a single day. Across the full window, attackers compromised two to four accounts per day and reached at least 78 accounts across 64 organizations.

The technique exploits Resource Owner Password Credentials (ROPC), a deprecated OAuth 2.0 flow originally intended for legacy scripts and command-line tools. ROPC sends a username and password directly to Microsoft’s token endpoint, with no interactive prompt — which means no interactive MFA challenge and, in many tenant configurations, no Conditional Access Policy (CAP) enforcement either. Targeting was opportunistic, driven by password prevalence in breach-combo lists rather than industry or company size.

The most important finding is not the volume of attempts — it is where MFA failed. Of the 23 organizations compromised on June 22, 15 had MFA implemented and enforced through Conditional Access. But in each of those cases, MFA was scoped to specific applications (for example, “Microsoft Admin Portals”) rather than to “All Cloud Apps.” Azure CLI sign-ins using ROPC simply were not covered by the policy. Huntress also reports that credential-spray attack volume across its customer base has increased more than 155-fold over the past six months.

Why It Matters

This is not a Microsoft product vulnerability and there is no patch to apply. It is a Conditional Access scoping gap that exists in a meaningful number of Microsoft 365 and Azure tenants right now, including ones where security teams would confidently report “MFA is enforced everywhere.” For DACH Mittelstand organizations — where Microsoft 365 and Azure are near-universal — this is a governance and configuration issue, not a technical one. An attacker with 81 million login attempts and no exploit code found a gap that most internal reviews would have missed, because the review question was “do we have MFA” rather than “does MFA cover every authentication path, including legacy and command-line flows.”

What You Should Do Now

1. Audit your Conditional Access Policies today: confirm MFA (or a block rule) is applied to “All Users, All Cloud Apps, All Client App Types” — not scoped to a subset of applications.
2. Enable the userStrongAuthClientAuthNRequired setting to enforce strong authentication at the client level and block ROPC sign-ins outright.
3. Restrict Azure CLI access to users who genuinely need it; remove it as a default capability for standard accounts.
4. Set up detection for the specific pattern this campaign used: bursts of failed logins, unusual Azure CLI sign-in activity, repeated attempts across many accounts in a short window, and successful logins immediately following spray activity from unfamiliar ASNs.

If you cannot answer with confidence whether your MFA policy covers ROPC and other legacy authentication flows, that answer is itself the finding.

DIESEC Perspective

We see this pattern repeatedly in Mittelstand environments: a security control is deployed, verified once at rollout, and then treated as permanently complete. MFA scoped to “Admin Portals only” was very likely correct and deliberate at the time it was configured — for whatever set of applications existed then. Legacy and command-line authentication flows like ROPC are rarely part of that original review, and they don’t announce themselves as a gap until 81 million login attempts find them. It is the same failure class we flagged in the FortiBleed credential campaign in June: a control everyone assumed was complete, with one uncovered path nobody had checked. Identity configuration needs the same periodic review cycle as patch management, not a one-time setup task.

Not sure whether your Conditional Access policies have this gap? Contact DIESEC for a rapid identity configuration review.

Sources: Huntress | The Hacker News
Published: 2026-07-03 | Category: Compliance & Governance | ~4 min read