On June 12, 2026, attackers launched a massive password-spray campaign against Microsoft Azure CLI accounts, generating over 81 million login attempts and compromising 78 accounts across 64 organizations, according to a Huntress investigation. The alarming discovery: 15 of the 23 businesses hit on a single day had multi-factor authentication (MFA) enforced through Conditional Access Policies, yet the attackers still slipped through. The intrusion exploited a legacy authentication flow that many assumed was covered by their MFA defenses, exposing a dangerous gap between security policy intentions and enforcement reality.

The attackers didn't need malware or zero-days. They relied on old username-and-password pairs harvested from breach data, replaying them against the OAuth Resource Owner Password Credentials (ROPC) grant—a flow that sends credentials directly to Microsoft's token endpoint without ever triggering an interactive MFA prompt. Because ROPC is incompatible with modern authentication, it bypasses Conditional Access policies that aren't explicitly configured to block it.

The Attack by the Numbers

The campaign, linked to infrastructure provider LSHIY LLC (AS32167), predominantly used the IPv6 range 2a0a:d683::/32. Huntress noted that attacks from this range ended on July 2, after LSHIY suspended the user's service tied to the activity. The scale is staggering:

  • 81 million login attempts over roughly two weeks.
  • 78 compromised accounts across 64 organizations by late June.
  • On June 22 alone, 30 accounts at 23 businesses were breached in a single day.

Huntress, which was tracking the campaign across its customer base, observed that credential spray attacks have increased by over 155 times in the past six months, with an average of nearly 2,000 failed attempts per tenant each month. This campaign is not an isolated spike; it's part of a growing, industrialized threat.

Why MFA Didn't Help

The most unsettling detail: among the 23 businesses hit on the peak day, 15 had MFA implemented and enforced via Conditional Access Policy. So why did the attacks succeed? The Huntress report dissects the common misconfigurations:

  • MFA scoped only to specific apps, such as admin portals, leaving other cloud apps unprotected.
  • MFA enforced only for admins, not standard users. Regular accounts became the soft entry point.
  • Trusted location exceptions that relied on IP geolocation—an unreliable defense when an attacker's IP can appear in different regions depending on the look-up service.
  • Report-only mode: two organizations had MFA policies that were configured but never enforced, a feature meant for testing that inadvertently left them exposed.
  • No MFA at all: eight compromised businesses simply lacked any MFA policy.

The common thread is that none of these organizations specifically blocked the ROPC flow. This legacy OAuth grant type predates modern interactive sign-in, so it bypasses the authorization endpoint where Conditional Access policies typically reside. Attackers sent credentials straight to the /token endpoint, receiving a valid token without ever seeing an MFA challenge.

The Forgotten Door: ROPC and Azure CLI

The Resource Owner Password Credentials grant has long been deprecated by the OAuth community and explicitly advised against by Microsoft. It exists because of backward compatibility—scripts, automation, and older tooling still rely on it. Azure CLI, a command-line tool used by developers and admins to manage cloud resources, accepts ROPC-based authentication. That makes it a high-value target: a compromised Azure CLI account can grant access to storage, compute, Kubernetes clusters, and more.

For many organizations, Azure CLI usage is a blind spot. They treat it as a trusted technical tool rather than an attack surface that must be governed. If a user doesn't need programmatic Azure access, leaving CLI authentication open is an unnecessary risk.

How We Got Here: The Conditional Access Complexity Trap

Conditional Access is a powerful rules engine, but its flexibility breeds complexity. Policies are built on layers—users, groups, apps, platforms, locations, risk levels—and gaps emerge when those layers don't cover every possible authentication path. Organizations often start with a partial rollout to reduce support tickets, then never close the gaps. The result is a policy surface that looks robust in a dashboard but leaves legacy flows like ROPC unprotected.

Microsoft has been tightening identity defaults for years, pushing passkeys and phishing-resistant MFA, but it can't forcibly block legacy flows without breaking countless customer integrations. That last mile is the enterprise's responsibility. This campaign proves that attackers thrive on those edge cases.

Immediate Actions for Microsoft 365 and Azure Admins

The fix isn't mysterious, but it demands precision. Here's a checklist based on Huntress's recommendations and Microsoft's security guidance:

  • Review Conditional Access Policies for coverage gaps. Ensure policies apply to all users, all cloud apps, and—critically—all client app types. Huntress specifically calls out the need to cover legacy authentication clients in your policies.
  • Block ROPC at the tenant level. Enable the userStrongAuthClientAuthNRequired setting, which forces strong authentication for all client applications and prevents password-only token acquisition. This is the most direct kill switch for the attack vector.
  • Restrict Azure CLI access. Limit its use to users who genuinely need it. For everyone else, remove the ability to authenticate via Azure CLI, reducing the blast radius if credentials are compromised.
  • Enforce MFA broadly. Don't limit it to admins or specific apps. Make sure there are no report-only policies lingering from a trial period. If you can't enforce MFA everywhere, consider using Conditional Access to block all legacy authentication outright.
  • Improve detection logic. Don't rely on volume-based alerts alone. Look for successful authentications following a pattern of failed attempts, especially when they use ROPC, originate from unfamiliar IP ranges, or target Azure management tools. Huntress notes that prioritizing by credential validity rather than spray volume catches the real breaches.
  • Audit service principals and automation. Azure CLI can use workload identities (service principals) that aren't subject to user MFA. Review scripts and tools that leverage these identities to ensure they aren't overly permissive.

What Comes Next

The LSHIY-linked spray campaign ended when the infrastructure provider took action, but the vulnerability remains. Tenants with the same Conditional Access blind spots are still exposed to the next wave of attacks from any IP range. Microsoft is unlikely to deprecate ROPC abruptly, given the enterprise dependencies. Instead, the onus shifts to admins to proactively lock down legacy authentication and adopt continuous identity security testing.

The lesson is clear: MFA is not a binary property of a tenant. It's a configuration that must be validated against every possible sign-in flow. For organizations serious about identity security, the time to audit those flows isn't after the next 81 million attempts—it's now.