Your MFA is on, and it did not apply
If someone asked whether your business has multi-factor authentication switched on, you would probably say yes. It is the control everyone has heard of, the one the insurance form asks about, and for most small businesses it is genuinely in place.
The uncomfortable question is a different one: does it apply to every way in. For a group of businesses this summer, the answer turned out to be no, and they found out the hard way.
What happened
Huntress documented a password spraying campaign against Microsoft accounts that compromised 78 user accounts across 64 organisations in a fortnight in June, out of more than 81 million login attempts.
Password spraying is the patient version of guessing. Rather than hammering one account with thousands of passwords, which triggers a lockout, the attacker takes one likely password and tries it against every account they can name, then waits, then tries the next. In this case they were not really guessing at all. They were replaying username and password pairs from old breaches that had never been changed.
The interesting part is how those logins succeeded against businesses that had multi-factor authentication configured.
The door that never asks for a second factor
The attackers signed in through something called the Resource Owner Password Credentials grant, usually shortened to ROPC. It is a legacy way for an application to sign in by sending a username and password straight to Microsoft, with no interactive prompt. It exists for old software that predates modern sign-in, and it cannot show a second-factor challenge, because there is nobody sitting in front of it to answer one.
So a valid password submitted this way becomes a working session without ever meeting your MFA.
Huntress found four distinct ways the victims' protections failed to cover it, and they are worth reading as a checklist, because none of them is exotic:
- Some organisations had no MFA at all. Eight of them.
- Some applied MFA only to certain applications, and this sign-in route was not among them.
- Some applied MFA only to certain groups, commonly administrators. The compromised users were not in those groups.
- Some required MFA only from untrusted locations, and the attacker's traffic carried a United States geolocation that counted as trusted.
- Two had the policy in report-only mode, which logs what would have happened and enforces nothing.
That last one deserves a pause. Report-only is a legitimate testing setting, meant to be temporary. It looks identical to a working policy on a summary screen. Somebody switched it on to check the impact, and it stayed.
The attackers appear to have been validating credentials rather than using them, most likely to resell. Huntress saw no follow-on activity after the successful logins, which is small comfort: the buyer is the one who acts.
Why this reaches an ordinary business
Nothing here required a vulnerability. No software was unpatched, no clever exploit was involved. The attack used a supported feature, old passwords, and gaps between a policy and the reality it was meant to describe.
That makes it a governance problem rather than a technical one, and it is the sort that grows quietly. Policies are written once, for the applications and people that existed that year. New applications appear. People change roles and leave the group the policy covered. A setting goes into report-only for a fortnight's testing and never comes out. Nobody is being careless, and the gap opens anyway.
It also explains a frustrating pattern: the business that answers "yes, we have MFA" on an insurance proposal form or a client questionnaire, honestly, and is still compromised through a password.
What to check this month
Four questions, and your IT provider should be able to answer all of them. If they cannot, that is itself the finding.
Does our MFA policy cover all users and all applications, or a subset? "All users, all cloud apps" is the answer you want. Anything narrower needs a reason you can state.
Is any policy in report-only mode? Check rather than assume. This is the one that looks fine from a distance.
Do we allow legacy sign-in routes that cannot present a second factor? In Microsoft 365 the relevant control is blocking legacy authentication, and modern tenants can also restrict this specific grant. The question for your provider is direct: is legacy authentication blocked, and if not, which application still needs it.
Do we treat location as trust? A rule that skips MFA from "trusted" places assumes an attacker cannot appear to be in one. In this campaign, they could.
Then do the unglamorous thing underneath all of it. These accounts fell to passwords that had leaked previously and were never changed. Every reused password from an old breach is a working key until someone rotates it, and no policy fixes that on its own.
How Steelwise can help
Checking whether the protections you believe are in place actually cover every route into your systems, and getting a plain answer out of your IT provider, is a short piece of work. Get in touch.
Further reading
- NCSC: multi-factor authentication for online services
- NCSC: device security guidance
- ICO: personal data breaches