The side door around MFA: lessons from 81 million break-in attempts

Between June 12 and June 26, security firm Huntress watched a single attacker make more than 81 million login attempts against Microsoft 365 accounts. Seventy-eight accounts fell, across 64 organizations.

Here's the detail worth your three minutes: most of the breached businesses had multi-factor authentication — MFA, the code or tap-to-approve on your phone — turned on. The attacker didn't defeat anyone's second factor. They walked around it.

How you walk around MFA

Two things had to line up.

First, the passwords. The attacker wasn't guessing. They were replaying username-and-password pairs stolen in old data breaches, betting some had never been changed. This is called password spraying, and it's automated and cheap — 81 million attempts in two weeks is a machine's work. Huntress reports these attacks have grown more than 155-fold across its customers in six months, with the average business tenant now seeing roughly 1,964 failed login attempts a month.

Second, the login route. Microsoft 365 still supports an outdated sign-in method (a leftover called ROPC, built for older software) that hands the password over directly and never triggers an MFA prompt. No code, no tap. If your security rules don't explicitly cover that route, a valid stolen password sails through and MFA never fires.

The four gaps that let them in

In Microsoft 365, the rules that decide when a login gets an MFA challenge live in a feature called Conditional Access. When Huntress analyzed the campaign's worst day — June 22, with 23 businesses hit — 15 of those businesses had MFA policies in place. The policies just had holes:

• MFA covered some apps, not all. Some policies protected only the Microsoft admin portals. The route this attacker used wasn't on the list, so it was never challenged.
• MFA covered some people, not all. Some policies applied only to administrators. The accounts that fell belonged to regular staff outside the policy.
• "Trusted locations" exceptions. Some policies skip MFA for logins that appear to come from a familiar place. The attacker's addresses were mislabeled as U.S.-based, so they qualified.
• Report-only mode. Two businesses had the policy built but set to "report-only" — a burglar alarm installed and never switched on.

Eight more of the breached organizations had no MFA policy at all.

None of this means MFA doesn't work. It means "we turned on MFA" and "every login gets challenged" are two different sentences, and attackers are now systematically probing the space between them.

What to do this week

This is a 15-minute conversation, not a project.

1. Ask your IT provider one question, word for word: "Does our MFA policy apply to all users and all cloud apps, with no trusted-location exceptions — and is it enforced, not report-only?" Anyone managing your Microsoft 365 can answer in minutes. If the answer has a "mostly" in it, you've found your gap.
2. Ask them to block legacy sign-in methods. "Block legacy authentication" is the setting to request by name. It closes the side door this attacker used, and almost no small business still needs what it breaks.
3. Retire old passwords. This campaign only worked against passwords already stolen in past breaches and never changed. Any work password that's years old or reused on other sites should go — a password manager makes that a one-hour chore instead of a recurring risk.

One piece of good news: after Huntress reported the activity, the hosting provider cut the attacker off on July 2 and this wave stopped. The next one will come from somewhere else — the gaps are what matter, not this particular burglar.

Misconfigured MFA is exactly the kind of problem that's invisible until someone tests for it. If you'd rather check than assume, Tenant Strike runs a read-only scan that grades your Microsoft 365 setup A–F — including whether MFA actually covers every user and app — and shows the exact fix. Nothing to install, about five minutes to a report.