Between June 12 and June 26, someone pointed a firehose at Microsoft 365.

Cybersecurity firm Huntress documented a password spray campaign that generated 81 million login attempts across their customer base in two weeks. The attackers used previously breached username/password combinations and tried to authenticate through Microsoft’s Azure command-line interface. 78 accounts were compromised across 64 organizations.

The uncomfortable part: many of those organizations had MFA enabled.

How MFA got bypassed without being “hacked”

The attackers didn’t crack MFA. They walked around it.

They authenticated using ROPC (Resource Owner Password Credentials), a legacy OAuth flow that sends passwords directly to a token endpoint with no interactive MFA prompt. If your Conditional Access policies don’t explicitly cover this flow, the attacker gets a valid token using nothing but a stolen password. (This is a different bypass than device code phishing, but the result is the same: MFA never fires.)

ROPC exists for backward compatibility with older applications that can’t handle modern authentication. Most organizations don’t need it. Few have explicitly blocked it.

The misconfigurations that got people compromised

Huntress broke down what went wrong in the 64 organizations that were hit:

MFA applied only to specific apps, not “All Cloud Apps.” If your policy protects Outlook and SharePoint but doesn’t cover Azure CLI or other endpoints, there’s a gap.
MFA enforced only for admins. Standard user accounts were wide open.
MFA required only from untrusted locations. Residential proxies and VPN exit nodes make the attacker’s traffic look like it’s coming from a “trusted” range. MFA never triggers.
Policies stuck in report-only mode. Your tenant logs what would have been blocked, but doesn’t actually block anything. Some organizations set this up for testing and never flipped the switch.
No MFA policy at all.

Any one of these is enough. The attackers only need one path that works.

The volume isn’t a fluke

Huntress reported a 155x increase in password spraying activity per tenant. Organizations are averaging nearly 2,000 failed login attempts per month now. That’s sustained, automated probing at a scale that wasn’t happening a year ago.

The campaign traffic originated from an IPv6 range owned by an entity called LSHIY LLC (AS32167). Huntress reported the activity through the company’s abuse portal and got no response.

Someone acquires breached credentials in bulk, points automated tooling at thousands of tenants, and waits for the ones with gaps. It’s cheap to run and only needs a small success rate to be profitable. As we noted in our breakdown of credential-based attacks, most intrusions now start with a login, not an exploit. This campaign is that trend at industrial scale.

Questions to ask your IT provider

You don’t need to configure this yourself. But you do need to know whether it’s been done. Here’s what to ask at your next IT review:

“Does our MFA policy cover all applications, or just some of them?” If the answer is “specific apps” or “just email and SharePoint,” there are gaps. The policy needs to cover everything, including tools your staff may never interact with directly.

“Have we blocked legacy authentication protocols?” The specific protocol exploited here (ROPC) exists for backward compatibility with old software. If nobody’s explicitly turned it off, it’s probably still available.

“Is MFA required for every user, or just admins?” This campaign went after standard user accounts, not administrators. If MFA only applies to people with admin roles, most of your staff is unprotected.

“Are any of our security policies still in test mode?” Microsoft’s system lets you create policies in “report-only” mode for testing. Some organizations set them up that way and never flip the switch to enforce them. They look like they’re working, but they’re not blocking anything.

“Do we exempt any locations from MFA?” Some configurations skip MFA when traffic comes from a “trusted” network. Attackers use residential proxies to make their traffic look like it’s coming from trusted locations.

If your IT provider can’t answer these questions clearly, or if the answer to any of them is “I’m not sure,” that’s worth a deeper conversation.

MFA is a policy, not a toggle

There’s a gap between “we have MFA” and “MFA covers every authentication path an attacker could use.” This campaign lived in that gap. It didn’t exploit a bug in Microsoft’s code. It exploited configuration choices that looked reasonable in isolation but left a door open.

Huntress found 64 organizations with that door open in two weeks. They weren’t looking for all of them, just the ones in their own customer base. The actual number is much larger.

If your firm hasn’t had someone walk through your security policies recently, this is a good reason to get that on the calendar.

Artech Solutions helps law firms and professional services firms in the Des Moines metro configure Microsoft 365 security policies correctly the first time, including Conditional Access, MFA coverage, and legacy protocol blocking. If you’re not sure whether your tenant has the gaps described above, let’s find out together.