Microsoft 365 Password Spraying Campaign Amplifies to 81 Million Login Attempts

A Quiet Flood of 81 Million Login Attempts

You know the drill: you get an alert, maybe a few false positives, then nothing. You assume it’s noise—old credentials in the dark net, a forgotten test script, something harmless. But what if that quiet was actually thunder waiting to crack?

Last month, security team Huntress watched the storm build: more than 81 million login attempts hammering Microsoft 365 environments in just two weeks. No data breach in the traditional sense—no exfiltration server, no ransom note left behind. Just relentless, methodical guessing. The attacker had something the best of us often forget: valid username/password pairs, dug out of past breaches and old leaks. And they weaponized them with Microsoft’s own Azure CLI, using a flawed authentication flow called ROPC that silently sidesteps MFA.

This wasn’t clever in the cinematic, Hollywood-hacker sense. It was stupidly effective: brute force with a polite prefix and an insecure policy loophole as the backdoor. And when they hit—78 accounts across 64 organizations—it wasn’t because the password was weak. It was because the rules weren’t.

Let’s unpack how it happened, who was vulnerable, and why your MFA badge might not be as waterproof as you think.

How the Password Spraying Attack Unfolded

The attack playbook wasn’t new—but the scale sure was. From June 12 to June 26, attackers churned through over 81 million authentication attempts against Microsoft 365 tenants. The source? A valid, stolen credential list from past data breaches, compiled and pre-screened for known username patterns. Then came the tool: Azure CLI, the official command-line interface Microsoft administrators use daily to deploy VMs, spin up databases, and automate cloud infrastructure.

Here’s the critical misstep: instead of interactive login flows with prompts for MFA, the attackers used ROPC—the Resource Owner Password Credentials OAuth grant type. This legacy mechanism lets scripts pass the username and password directly to Microsoft’s token endpoint without any user interaction. And yes, that includes no MFA prompt at all.

“ROPC is considered problematic for several reasons, but one of those reasons is that it doesn’t offer support for modern auth flows like MFA or SSO,” Huntress explains. “That means, as we saw in this campaign, ROPC sends the password straight to the /token endpoint with no interactive MFA prompt.”

Think of ROPC as a backdoor door: the lock (MFA) is there, but only if someone remembers to turn the knob. In this campaign, many doors were left unlocked—not because attackers broke the lock, but because the lock wasn’t locked in the first place.

The Three Fatal Policy Gaps in Conditional Access

Huntress traced the attack back to three recurring misconfigurations in Azure’s Conditional Access Policies (CAPs). They’re easy to miss if you haven’t audited your policies recently, especially in environments where security teams are lean or permissions delegated loosely.

1. MFA applied only to specific apps Many organizations configured MFA to enforce on a handful of high-profile applications—say, SharePoint or Exchange Online—but left the token endpoint (where ROPC lives) off the list. Attackers bypassed MFA not by circumventing the app, but by hitting an unsecured endpoint.

2. MFA limited to select groups or locations A conditional access rule like “Require MFA only for admins” leaves every other user wide open. Even more dangerous: policies that require MFA only from untrusted locations. If an attacker spoofs a trusted IP—or sources traffic from a range that looks like it’s coming from your office—the policy never triggers.

3. Report-only mode on fire Some orgs left their CAP in “report only” mode—monitoring and logging attacks but taking no enforcement action. It’s the digital equivalent of installing an alarm that only tweets photos of intruders.

One more thing: in several impacted organizations, there was no MFA policy at all. The assumption that “MFA is on by default” is deadly wrong in Azure—conditional access rules are opt-in, not baked into the platform.

All it took was one of these gaps—and the attacker had a green path to authenticated sessions, not just credentials floating in the dark.

Who Was Hit—and Why It’s Hard to Trace

By the time Huntress had compiled their findings, 78 Microsoft accounts across 64 organizations had been compromised. That’s a disturbingly high success rate for what looked, at first glance, like routine noise.

The attacker’s IP range traced back to LSHIY LLC (AS32167), an IPv6 block that’s often used by legitimate cloud providers—making attribution fuzzy at best. Huntress did reach out through the provider’s abuse portal but received no response by publication time.

What’s more concerning is how the campaign grew organically. Huntress noted a 155-fold increase in password-spraying activity compared to previous months. Organizations averaged over 1,964 failed login attempts per tenant each month—enough to drown in alerts, yet enough to find the one weak hole.

It’s a haunting reminder: attackers don’t need zero-day exploits to cause damage. They just need patience, valid passwords, and a platform policy that looks the other way.

How to Lock Down Conditional Access—Before the Next Flood

If your current CAP feels like a suggestion box rather than a firewall, here’s what to do now:

• Universal MFA coverage Ensure your Conditional Access policy applies to all cloud apps—not just the ones you’ve manually selected. The Azure Active Directory token endpoint must be included.

• Enforce location-agnostic MFA If you use named locations, don’t assume external IPs alone are risky. Combine location rules with device compliance or signin risk to catch spoofed IPs and high-risk signs regardless of origin.

• Turn off report-only mode Audit your policies and switch any in “report only” to “on.” If your logging is solid but enforcement lags, you’re collecting intel on your own exposure.

• Audit ROPC usage Huntress and Microsoft both recommend disabling the ROPC OAuth grant where possible. If your scripts rely on it, begin migrating them to app registrations with certificate-based authentication.

• Map your top attackers Tools like Microsoft Defender for Cloud Apps can surface unusual sign-in patterns: logins at odd hours, from unfamiliar geographies, or with known-bad user agents. Combine this with SIEM correlation to get ahead of the next wave.

Password spraying isn’t glamorous. It doesn’t make headlines like a zero-day or a supply chain breach. But it’s working—because the bar to stop it is sometimes just one checkbox away from disabled.

Final Take: Don’t Trust the Quiet

The worst attacks often start with silence. No sirens, no alerts that matter. Just a slow ramp-up of failed logins—10, then 50, then thousands—until the breach slips in where your last audit left a gap.

This campaign is a warning shot across the bow: MFA alone won’t save you. You need policies that match the attacker’s playbook, not just your hopes.

If your Conditional Access feels like it was written by someone who assumed everyone plays fair, it’s time to rewrite the rules. In a world of automated sprayers and legacy OAuth flows, and even threats like phantom squatting, assume someone is already counting your failed attempts—waiting for that one missed checkbox.

It’s not paranoia. It’s patience.