A large password-spray campaign is targeting Microsoft 365 tenants through Azure CLI authentication, and the important lesson is not just the volume. Huntress says it observed more than 81 million login attempts between June 12 and June 26, 2026, with at least 78 Microsoft accounts compromised across 64 organizations.[1] The campaign matters because several impacted businesses already had Conditional Access policies, but those policies did not fully cover the legacy OAuth path used by the attackers.
The activity was traced mainly to IPv6 space under `2a0a:d683::/32`, associated with LSHIY LLC / AS32167, according to Huntress and follow-up reporting by The Hacker News.[1][2] Huntress described the campaign as ongoing and automated, with a visible spike on June 22, when 30 identities across 23 businesses were affected. The targeting did not appear to be limited to one industry; the attackers seem to be testing username and password pairs from older breach data.
The technical wrinkle is Resource Owner Password Credentials, or ROPC. In that OAuth flow, an application sends a username and password directly to the token endpoint and receives tokens when the credentials are valid. Microsoft’s own documentation warns that ROPC is incompatible with multifactor authentication and recommends more secure alternatives when possible.[3] In this campaign, that gap let attackers validate credentials through Azure CLI paths where some tenant policies did not force the same controls administrators expected from normal browser sign-ins.
That does not mean MFA is useless. It means Conditional Access coverage has to be broad enough to include all users, all cloud apps, and relevant client app types. Huntress specifically called out weak patterns such as enforcing MFA only for admins, only for selected applications, or only outside trusted locations. Those settings can look reasonable on a policy dashboard while still leaving a path for password replay.
For howtofix.guide readers, the story connects directly to two recurring problems: old credentials remain useful far longer than defenders expect, and token-focused Microsoft 365 abuse keeps finding edges around familiar controls. Recent incidents involving Microsoft AiTM phishing, stolen credential markets, and OAuth app abuse point to the same operational reality: defenders need to audit the authentication path, not just the presence of MFA.
What administrators should check now
Start with sign-in logs for Azure CLI and suspicious ROPC-style activity around the June 12-26 window, then continue monitoring because Huntress described the activity as ongoing. Prioritize successful sign-ins from the reported ASN or unfamiliar IPv6 ranges, repeated failures followed by a success, and accounts where MFA was not challenged as expected. Microsoft’s password-spray investigation playbook recommends confirming the timeline, identifying source IPs, checking successful sign-ins during the same period, and reviewing unusual device, OS, or location changes.[4]
Next, review Conditional Access scope. A practical policy review should answer four questions: are all users covered, are all cloud apps covered, are legacy and non-browser client flows handled, and are emergency or service accounts isolated with compensating controls? If Azure CLI is not needed by ordinary users, restricting it for non-admin accounts can reduce the blast radius. Where ROPC is still required for legacy automation, treat it as a high-risk exception and migrate to managed identities, service principals with certificate credentials, or interactive broker-based authentication where appropriate.[3]
Finally, rotate passwords for impacted accounts, revoke refresh tokens, inspect mailbox and cloud-app activity, and check whether the same passwords were reused elsewhere. Password-spray campaigns succeed quietly when old credentials remain valid and policies only cover the most visible login path. The fix is less about one emergency switch and more about closing the difference between what administrators think Conditional Access enforces and what every token-issuing route actually accepts.
References
- Huntress, “No (Bad) CAP: Inside an Ongoing LSHIY Password Spray Attack,” July 2026.
- The Hacker News, “Azure CLI Password Spray Hits at Least 78 Microsoft Accounts in 81M+ Attempts,” July 1, 2026.
- Microsoft Learn, “Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials,” last updated February 7, 2025.
- Microsoft Learn, “Password spray investigation,” Microsoft incident response playbook.
Leave a Comment