Security researchers at Huntress have uncovered a massive, sustained password spray campaign targeting Microsoft 365 and Azure CLI accounts that successfully bypassed multi-factor authentication (MFA) protections. Over a 14-day window between June 12 and June 26, 2026, the threat actors made more than 81 million login attempts against Huntress customer tenants, compromising at least 78 Microsoft accounts across 64 organizations. The scale of the campaign reflects a broader trend: Huntress reports credential spray volume across its customer base has increased by more than 155 times over the past six months.
How the Attack Works: Exploiting Legacy OAuth Flows
The key to the campaign’s success lies in its exploitation of the OAuth Resource Owner Password Credentials (ROPC) flow, a deprecated authentication method still supported by Azure CLI. Unlike modern interactive OAuth flows, ROPC allows an application to exchange a raw username and password directly at the token endpoint and receive access tokens — without ever triggering an interactive authorization step where MFA would be enforced.
Conditional Access Policies (CAPs) in Microsoft Entra ID enforce MFA at the authorization endpoint. Since ROPC bypasses this endpoint entirely, poorly configured policies that do not explicitly account for legacy authentication flows can be silently circumvented. The result: attackers can authenticate successfully and receive valid Microsoft 365 access tokens, even in organizations that believe MFA is fully enforced.
Scale and Attribution
Daily compromise counts during the campaign initially stayed low — typically two to four accounts per day — before surging dramatically on June 22, 2026, when 30 user identities across 23 businesses were compromised in a single day, marking a clear escalation event.
The bulk of attack traffic originates from IPv6 address range 2a0a:d683::/32, announced under autonomous system AS32167 and attributed to internet infrastructure provider LSHIY LLC. Corporate registration records link LSHIY to addresses in Hong Kong and Wuhan, with third-party telemetry consistently associating their IPv6 prefixes with Chinese origin. Huntress has submitted abuse reports to LSHIY but had not received a response at the time of publication.
Target selection appears opportunistic rather than industry-specific. The attackers appear to be replaying username-password pairs from prior data breaches and combo lists, focusing on credentials that were never rotated after previous compromises.
Why MFA Failed: Common Misconfiguration Patterns
Huntress investigators found that many impacted organizations had MFA and Conditional Access deployed — but with critical gaps that allowed the ROPC-based attack to slip through. The most common failure modes included:
- MFA scoped to specific apps: CAP enforced MFA only for certain named cloud apps, leaving Azure CLI sign-ins uncovered.
- MFA restricted to privileged groups: Non-administrator identities were outside the MFA enforcement scope, giving attackers an easy path through standard user accounts.
- Trusted location misclassification: Inaccurate IP geolocation marked attacking IPv6 addresses as US-based, bypassing location-based conditional access rules.
- Report-only CAP policies: Policies set to report-only mode logged events but did not block or prompt — providing a false sense of security with no actual enforcement.
- Legacy ROPC left enabled: Because ROPC never hits the authorization endpoint, MFA was never invoked during the token issuance process.
Recommended Mitigations
Huntress and the broader security community recommend treating Azure CLI and legacy ROPC as high-risk surfaces requiring explicit CAP coverage. Specific steps organizations should take immediately include:
- Require MFA for All Cloud Apps: Set Conditional Access Policies to apply to all cloud apps, not a named subset. Azure CLI must be included.
- Block or restrict ROPC: Where Azure CLI access is not needed by regular users, block it explicitly via dedicated CAP rules. Consider requiring the
userStrongAuthClientAuthNRequiredsetting to prevent ROPC-based token grants. - Disable legacy authentication protocols: Use Entra ID sign-in logs to identify ROPC and other legacy auth flows still active in your environment, then disable them.
- Audit named locations: Verify that trusted location definitions are based on accurate IP data and do not inadvertently exclude known threat actor infrastructure.
- Test CAP coverage proactively: Use Microsoft Entra’s “What If” policy simulator to identify gaps, report-only policies, or excluded groups that attackers could exploit.
- Rotate credentials from prior breaches: The campaign specifically targets unrotated credentials from old data breaches. Regular credential hygiene significantly reduces exposure.
Broader Implications
The 155-times increase in credential spray volume observed by Huntress over just six months reflects a growing industrialization of account compromise attacks targeting Microsoft cloud infrastructure. As organizations continue migrating to Microsoft 365 and Azure, attackers are investing heavily in automated tooling to exploit legacy authentication gaps that were less relevant in on-premises environments.
The campaign also highlights a critical lesson: enabling MFA is necessary but not sufficient. Organizations must also ensure that CAP configurations cover all authentication flows, including legacy protocols like ROPC that were designed before MFA existed and remain active in many tenants by default.