Microsoft 365 Password Spraying Attack: How 81 Million Login Attempts Bypassed MFA

A massive two-week attack campaign exposed how legacy authentication flows like ROPC can slip past multi-factor authentication and compromise real Microsoft 365 accounts.

Eighty-one million. That’s how many login attempts hit Microsoft 365 tenants in a single two-week stretch this June, and the number alone tells you this wasn’t a bored teenager guessing “Summer2026!” on a handful of accounts. This was industrial-scale automation aimed squarely at Azure identity infrastructure, and it worked often enough that dozens of organizations lost control of real accounts before anyone noticed.

If your organization runs Microsoft 365 or Azure, this campaign deserves your attention for a reason that goes beyond the headline number. It exposed a Microsoft 365 password spraying attack technique that quietly sidesteps multi-factor authentication not by breaking MFA, but by walking around a door most security teams didn’t know was unlocked.

Inside the Microsoft 365 Password Spraying Campaign: What Happened

Between June 12 and June 26, 2026, cybersecurity firm Huntress tracked a coordinated password spray attack hitting Microsoft 365 and Azure environments across its customer base. The attackers weren’t randomly guessing passwords. They were feeding in username-and-password pairs pulled from older data breaches, betting correctly, in enough cases to matter that people had reused those same credentials on their current Microsoft 365 accounts.

The entry point was Azure CLI, the command-line tool administrators use to manage cloud resources, deploy applications, and automate operations. Once a valid credential pair was confirmed, the attackers authenticated using a legacy OAuth mechanism called ROPC, short for Resource Owner Password Credentials.

By the time Huntress finished counting, the campaign had compromised 78 Microsoft accounts spread across 64 organizations, with activity peaking sharply around June 22. Researchers traced the traffic to an IPv6 range tied to a provider called LSHIY LLC, though attribution beyond that remains unclear, and the abuse report filed with the provider went unanswered.

Why This Microsoft 365 Password Spraying Attack Bypassed MFA via ROPC

Here’s the part that should concern every security leader running Microsoft 365: many of the compromised organizations had multi-factor authentication enabled. MFA didn’t fail because it was broken. It failed because ROPC doesn’t ask for it.

ROPC is an older OAuth flow that sends a username and password directly to Microsoft’s token endpoint. There’s no browser redirect, no interactive prompt, and critically, no mechanism to enforce MFA or single sign-on during that exchange. A Conditional Access Policy written to cover the normal sign-in flow simply never gets triggered, because ROPC isn’t the normal sign-in flow.

This is the crux of most Azure CLI attack incidents involving Conditional Access misconfiguration. It isn’t that MFA policy doesn’t exist. It’s that the policy has a blind spot the organization never tested.

Conditional Access Misconfigurations Behind the Password Spray Attack

Huntress broke down the specific misconfigurations that allowed compromise across affected tenants, and the patterns are worth reading closely because they’re common, not exotic:

Scoped-down MFA policies. MFA was applied to specific applications rather than to All Cloud Apps, leaving Azure CLI and similar tools outside the enforcement boundary.
Group-limited enforcement. MFA was required only for administrators or a defined user group, while standard users often the easiest initial foothold went unprotected.
Location-based trust gaps. Policies exempted “trusted” IP ranges from MFA, and attacker traffic sometimes appeared to originate from within that trusted range.
Report-only mode left on. Some policies were configured to log violations rather than block them, meaning they existed on paper but enforced nothing.
No MFA policy at all. In a subset of cases, there simply wasn’t a Conditional Access Policy governing sign-ins to begin with.

Overall, Huntress recorded more than a 155-fold jump in password spraying activity industry-wide, with tenants now averaging close to 2,000 failed sign-in attempts every month. That’s not background noise anymore it’s a persistent, scaled attempt to find the one gap that lets an old, breached password walk through the front door.

Identity Security Lessons From the Microsoft 365 Password Spraying Attack

This campaign is a case study in something identity security practitioners have been saying for years: credential-based attacks don’t need to be sophisticated to succeed, they just need one overlooked Conditional Access rule. Standing privileged access, unmonitored service accounts, and MFA policies that were configured once and never re-tested are exactly the conditions that let a password spray attack turn into an account takeover.

Organizations that have moved toward a Zero Trust identity model where every identity, human or otherwise, is continuously verified rather than trusted by default are structurally better positioned to catch this kind of gap before attackers find it. Legacy auth flows like ROPC are precisely the sort of blind spot a mature Zero Trust posture is designed to close.

It’s also a reminder that identity platforms aren’t “set and forget.” Conditional Access policies drift, new apps get added outside existing scopes, and report-only settings get left behind after testing. Ongoing operational oversight through IAM managed services exists precisely to catch that kind of drift before it becomes a breach headline.

How to Protect Microsoft 365 Against a Password Spraying Attack

If you run Microsoft 365 or Azure, a few concrete steps close most of the gaps this campaign exploited:

Apply Conditional Access to All Cloud Apps, not a subset. Scoped policies are the single most common failure point in this campaign.
Block legacy authentication flows, including ROPC, unless a specific, documented business need requires them.
Extend MFA enforcement to all users, not just administrators standard accounts were a common initial entry point. CISA’s MFA guidance treats phishing-resistant, universally enforced MFA as one of the highest-impact controls an organization can deploy.
Remove location-based MFA exemptions or audit them rigorously; attacker traffic can appear to originate from trusted ranges.
Switch report-only policies to enforced mode once testing confirms they behave as expected.
Monitor failed sign-in volume as a leading indicator a spike in failed logins per tenant is often the earliest visible sign of a password spray attack in progress.

Key Takeaways on the Microsoft 365 Password Spraying Attack

An 81-million-attempt campaign succeeding through a legacy authentication flow is a hard reminder that identity security is only as strong as its least-tested policy. MFA that isn’t enforced everywhere isn’t really MFA it’s a false sense of coverage. Closing gaps like ROPC, auditing Conditional Access scope, and treating identity as a continuously monitored system rather than a one-time deployment is what separates organizations that read about campaigns like this from organizations that end up in the incident report.

Close the Identity Gaps Before Attackers Find Them

Password spraying attacks succeed because of misconfigured Conditional Access policies, legacy authentication, and unmanaged identities not because MFA is broken. Our Microsoft 365 Identity Security Assessment helps you uncover hidden risks and strengthen your Zero Trust posture.

Frequently Asked Questions (FAQs)

What is a password spraying attack?

A password spraying attack tests a small number of commonly used or previously breached passwords against many accounts, rather than repeatedly guessing many passwords against one account. It’s designed to avoid account lockout thresholds while still finding valid credentials at scale.

What is ROPC and why does it bypass MFA?

Resource Owner Password Credentials (ROPC) is an OAuth flow that sends credentials directly to an authentication endpoint without an interactive browser session. Because it skips that interactive step, it also skips modern authentication prompts like MFA and SSO unless an organization has explicitly blocked it.

How do I know if my organization is affected?

Review Azure AD/Entra sign-in logs for unusual volumes of failed authentication attempts, particularly through non-interactive or legacy protocols, and confirm your Conditional Access policies apply to All Cloud Apps rather than a limited scope.

Can blocking legacy authentication break existing workflows?

Sometimes, yes. Some automation scripts, older line-of-business apps, and service accounts still rely on ROPC or other legacy auth flows. Before blocking them outright, audit sign-in logs for legitimate legacy auth usage, migrate those workflows to modern authentication methods, and only then disable the legacy flow tenant-wide.

Is MFA alone enough to stop a password spraying attack?

Not on its own. This campaign proved that MFA only protects the sign-in paths it’s actually applied to. Without a Conditional Access Policy scoped to All Cloud Apps, blocked legacy authentication, and active monitoring of failed sign-in volume, MFA can look complete on paper while leaving real gaps attackers can walk through.