Your Company Has MFA. This Week We Learned That May Not Mean Much.

Over two weeks in June, a single attacker fired more than 81 million login attempts at Microsoft 365 environments and broke into at least 78 accounts across 64 organizations. Here is the detail that should get your attention in the boardroom: many of the organizations that got breached had multi-factor authentication in place.

They had bought the control. They had deployed the control. They could tell their auditors, their insurers, and their boards that MFA was “done.” And the attacker walked past it anyway.

What actually happened

The campaign, documented by the security firm Huntress, was not sophisticated. The attacker took username and password combinations exposed in old breaches — credentials that were never rotated — and replayed them at scale through Microsoft's Azure command-line interface, a tool administrators use to manage cloud resources.

The trick was the door they chose. Instead of the normal sign-in page, the attacker used a legacy login method called ROPC, an outdated flow that Microsoft itself recommends against using. That flow sends the password straight to the server with no interactive MFA prompt. If a company's access policies weren't configured to cover it, MFA simply never fired.

Huntress found the same configuration gaps again and again in the companies that got hit. MFA was enforced only for certain applications instead of all of them, so the command-line route wasn't covered. Or it was enforced only for administrators. Or only for logins from “untrusted” locations. In some cases the policy was set to report-only mode — meaning it logged what it would have blocked, and blocked nothing. And eight of the impacted businesses had no MFA policy at all.

This was not an isolated event. Huntress reported a more than 155-fold increase in password-spraying attacks across its customer base, with protected organizations now averaging roughly 1,964 failed login attempts per tenant every month. Whoever is behind this particular campaign remains unknown. It doesn't matter. The playbook is cheap, automated, and available to anyone.

The gap between “we have it” and “it works”

I wrote in Cyber Risk Is Business Risk that compliance tells you a control exists; security tells you the control works. This incident is that distinction made flesh.

Every one of these breached organizations could have answered “yes” to the question “Do you have MFA?” That yes would have satisfied most audit checklists, most cyber insurance questionnaires, and most board briefings. And it was worthless the moment an attacker chose a login path the policy didn't cover.

This is why the Three Questions matter. Not “do we have MFA,” but: What are we protecting? What would it cost us if we lost it? And how do we know our defenses actually work? The third question is the one boards skip, because the answer requires evidence, not attestation. A control that has never been tested against the way attackers actually behave is a hope, not a control.

There's a budget lesson here too, and it cuts in an unusual direction. The fix for this problem costs almost nothing. No new platform, no seven-figure procurement. It's configuration work: extending an existing policy to cover all applications, all users, and all login methods, and turning off legacy flows nobody should be using. The organizations that got breached didn't lack budget. They lacked verification. When your CISO asks for resources, the right follow-up isn't only “what does it cost?” — it's “how will we prove it's working a year from now?”

What to ask your CISO this week

The beauty of this incident, from a board perspective, is that it converts directly into questions any director can ask without a technical background:

“Does our MFA policy cover every application, every user, and every login method — or only some of them?” The breached organizations had MFA for the front door while a side door stood open. A partial yes is a no.

“Are any of our access policies running in report-only mode?” Report-only means the control is watching, not acting. There may be good reasons during a rollout. There is no good reason indefinitely.

“Have we disabled legacy login methods that bypass MFA?” The attackers used a flow that Microsoft has told customers to avoid. Ask whether it's blocked in your environment, and if not, why.

“When did we last test this against a real attack technique, and what did the test find?” Not a compliance audit — an actual exercise that tries to get in the way this attacker did.

If the answers come back crisp and evidenced, you have a security program. If they come back as reassurance, you have a checklist.

The uncomfortable truth

Eighty-one million login attempts sounds like an extraordinary assault. It isn't. It's Tuesday. The credentials came from old breaches, the tooling is automated, and the technique exploits nothing more exotic than the gap between what organizations believe they've deployed and what they've actually verified.

The organizations that survived this campaign weren't luckier or richer. Their policies covered all the doors, not just the one facing the street. That's not a technology difference. It's a governance difference — and governance is the board's job.