# Massive Azure CLI Password Spray Attack Breaches 78 Microsoft Accounts, Exposes MFA Misconfigurations Across 64 Organizations
An enormous, ongoing credential spray campaign has compromised at least 78 Microsoft accounts across 64 organizations by exploiting a deprecated OAuth authentication flow that bypasses multi-factor authentication protections. Between June 12 and June 26, 2026, threat actors orchestrated over 81 million login attempts against Azure CLI endpoints, according to security firm Huntress, which discovered and analyzed the campaign.
The attack underscores a critical vulnerability in modern cloud security posture: many organizations deploy MFA as a checkbox compliance exercise without properly configuring it to cover all authentication pathways—a gap that sophisticated attackers are now actively exploiting at scale.
## The Threat
The password spray attack originated from an IPv6 address range (2a0a:d683::/32) controlled by internet infrastructure provider LSHIY LLC (AS32167), with some IP addresses resolving to the United States and others to China. The campaign represents a coordinated, systematic effort to breach cloud infrastructure by reusing old leaked credentials from compromised password combo lists.
Attack Timeline and Impact:
The vast majority of the attack traffic originated from LSHIY LLC's infrastructure, though Huntress notes that credential spray attacks have surged across multiple autonomous system numbers (ASNs) during the same period. Across Huntress's customer base, credential spray attack volumes have increased by over 155 times compared to historical baselines, with a current mean of approximately 1,964 failed attacks per month per protected tenant.
What distinguishes this campaign from routine password spray attacks is its sophistication: the threat actors did not attempt to brute-force weak passwords indiscriminately. Instead, they weaponized historically compromised credentials—usernames and passwords from previous breaches that organizations had stored but never rotated—suggesting operational intelligence or access to dark web credential databases.
## Background and Context
To understand why this attack succeeds where defenses should fail, it's essential to understand OAuth 2.0 authentication flows and Azure's conditional access architecture.
OAuth 2.0 and the ROPC Flow
OAuth 2.0 is the industry standard for delegated authorization, allowing applications to access resources on behalf of users without storing passwords. Modern OAuth implementations use flows such as:
The ROPC flow, now deprecated in OAuth 2.1, was originally designed for trusted, first-party applications—like Microsoft's own CLI tools—where users have high confidence in the application. In ROPC, the application receives the user's credentials directly and exchanges them for an access token without user interaction or consent screens.
Microsoft's documentation explicitly discourages ROPC use, warning that it is "incompatible with multi-factor authentication (MFA)" and that organizations should only deploy it "when more secure flows aren't viable." Yet many organizations continue supporting ROPC for backward compatibility with legacy tools and automation scripts.
Conditional Access Policies and Their Gaps
Azure's Conditional Access Policies (CAPs) are a sophisticated security mechanism that enforces rules based on signal analysis—device compliance, user location, sign-in risk, and more. An organization might require MFA when users sign in from an unknown location, or block access entirely from high-risk countries.
However, CAPs operate at the authorization layer and depend on the authentication flow to trigger them properly. When ROPC is used, the threat actor's authentication request bypasses the interactive elements of Azure's authentication pipeline. No browser window opens. No device compliance check is initiated. No location-based signal is evaluated. The credentials are exchanged for a token silently, often before CAP rules can be enforced.
## Technical Details
Huntress's analysis reveals how attackers exploited this architectural gap:
The Attack Sequence:
1. Threat actors source old username/password combinations from compromised password databases
2. They target Azure CLI ROPC endpoints with systematic login attempts
3. Each successful login generates a valid access token without triggering MFA
4. Attackers gain legitimate-looking access to organizational Azure resources
5. The compromise remains undetected if organizations aren't monitoring for unusual token generation or API activity
Why MFA Failed to Protect Targeted Organizations:
Among the 64 compromised organizations, security configurations varied significantly:
| MFA Configuration | Number of Organizations | Result |
|---|---|---|
| No MFA policy at all | 8 | Complete bypass |
| MFA enforced for specific apps only (not Azure CLI) | Multiple | Azure CLI excluded from MFA |
| MFA enforced for specific user groups only (e.g., admins) | Multiple | Service accounts or non-admin users unprotected |
| MFA enforced only for non-trusted locations | Multiple | Attacker traffic routed through locations marked as "trusted" |
| MFA enforced for "All Cloud Apps" | Multiple | Still bypassed via ROPC's unauthenticated path |
The technical elegance of the ROPC exploitation lies in its legitimacy. The attacker is not injecting malware, forging tokens, or exploiting unpatched vulnerabilities. They are using an officially supported (if deprecated) OAuth flow, sending credentials to Microsoft's servers, and receiving valid tokens in return. From the perspective of API logs and token analysis, the activity is indistinguishable from a legitimate user login.
## Implications
The campaign highlights several critical vulnerabilities in cloud security practice:
1. Legacy Flows as Persistent Attack Surface
Organizations often maintain support for deprecated authentication methods for backward compatibility. ROPC persists in production environments despite Microsoft's explicit warnings, largely because:
This creates a permanently open door that MFA cannot fully close.
2. MFA as a Checkbox, Not a Strategy
Eight organizations in this campaign had no MFA at all—a failure of basic hygiene. But the more troubling finding is that organizations with MFA deployed still fell victim because:
MFA is not a binary protection; it's only as strong as its configuration.
3. Credential Reuse Remains High-Risk
The attack weaponized old breached credentials, suggesting that millions of users have never rotated their passwords after past breaches. This is a systemic industry problem: password breach notification works poorly, users ignore breach alerts, and organizations rarely mandate password rotation following external breaches.
4. Monitoring Gaps
The campaign persisted for over two weeks, generating 81 million login attempts, before being detected. Many organizations likely still don't know they were compromised. This suggests:
## Recommendations
For Security Teams:
1. Audit and Retire ROPC Immediately
- Search Azure AD logs for ROPC authentication flows
- Identify applications and scripts using ROPC
- Migrate to more secure alternatives (Authorization Code Flow, Device Code Flow, or Managed Identity)
- Set a sunset date for ROPC support and begin deprecation
2. Audit Conditional Access Policies
- Ensure MFA is enforced for "All Cloud Apps," not a subset
- Include service account and API authentication in MFA scope
- Test CAP rules against all authentication flows your organization uses
- Document and validate which flows are covered by which policies
3. Implement Advanced Monitoring
- Alert on spikes in failed login attempts from external IP ranges
- Monitor token generation patterns for anomalies
- Track authentication flows in use and alert on deprecated flow usage
- Correlate Azure AD logs with endpoint detection and response (EDR) data
4. Enforce Credential Hygiene
- Mandate password changes for users found in breach databases
- Deploy password breach monitoring that automatically invalidates leaked credentials
- Require MFA even for service accounts and automation
5. Enable Sign-In Risk Analysis
- Use Azure AD Identity Protection to flag high-risk sign-in patterns
- Configure risk-based conditional access policies to require additional authentication when risk is detected
For All Organizations:
---
## HackWire Analysis
This attack represents a critical inflection point in cloud security: defenders are losing the ability to protect users who have weak password hygiene through MFA alone. The campaign's success—despite many target organizations having MFA deployed—reveals a false confidence in MFA as a panacea.
What matters here is not that ROPC exists or that some organizations use it, but that security decisions made years ago (supporting legacy flows, narrowly scoped MFA) are now being weaponized at scale. The attackers aren't innovating; they're exploiting normal operational debt.
The pattern extends beyond this single campaign. Credential spray attacks have surged 155x across Huntress's customer base in recent months—a trend that suggests either improved threat actor capabilities or, more likely, that old breached credentials have finally accumulated enough coverage to make spray attacks profitable. As data breaches continue, the credential supply available to attackers grows. Eventually, the odds favor the attacker: if an organization has 10,000 users and an attacker has 100 million leaked credentials, the probability of intersection approaches certainty.
The most dangerous insight: organizations that believe they are "protected" by MFA are often the most vulnerable, because they've stopped worrying. Eight organizations in this campaign had no MFA at all, which is reckless—but the majority had MFA and still fell victim, which is worse. It suggests they were not continuously validating their security controls against new attack patterns.
The immediate fix is technical (retire ROPC, audit CAP rules). The long-term solution is organizational: treat security posture as a continuous verification process, not a checkbox exercise. Re-assess authentication flows annually. Test MFA coverage against real attacks. Monitor for breached credentials actively. The threat actors are using operational data on what actually works; defenders should be doing the same. — HackWire Editorial.
---
## Related Coverage