You Have MFA Enabled. Have You Tested Whether It Actually Stops an Attacker?
Multifactor authentication is one of the most effective defenses against account compromise — a stolen password shouldn’t be enough to get into Microsoft 365. But there’s a real difference between having MFA configured and knowing it protects every way an attacker might try to log in. A recent campaign against Microsoft Entra ID is a clean example of that gap, and it’s worth fifteen minutes to check whether it applies to you.
They weren’t breaking MFA. They were going around it.
The attackers weren’t cracking codes or exploiting Microsoft Authenticator. They found an authentication path that Conditional Access simply didn’t cover.
The campaign targeted Azure CLI logins using an older OAuth method called Resource Owner Password Credentials, or ROPC. ROPC lets an application hand a username and password straight to Microsoft’s authentication service in exchange for an access token — no browser, no interactive login prompt, and no way to insert an MFA challenge into the process. Microsoft has said for years that ROPC is incompatible with MFA and recommends organizations move away from it entirely.
That’s the mechanical problem. The practical one is what it revealed: a lot of organizations had an MFA policy that looked complete on paper and had a hole in it they didn’t know about.
“MFA enabled” and “MFA enforced everywhere” are not the same statement
An administrator can open Entra ID, see a Conditional Access policy requiring MFA, and reasonably conclude the account is protected. But a Conditional Access policy is really a long list of conditions — which users it covers, which apps and cloud resources it applies to, whether certain locations or countries are treated as trusted, whether service accounts are excluded, and whether the policy is actually enforcing or still sitting in report-only mode.
Huntress found real organizations where every one of those boxes looked checked for normal browser logins, but the same policy didn’t apply to Azure CLI’s ROPC flow. In one slice of the campaign, 15 of 23 affected businesses already had MFA enforced through Conditional Access — it just didn’t reach the path the attackers used. From the organization’s side, MFA was on. From the attacker’s side, the password alone was still enough.
Why the scale here matters
Password spraying isn’t new. What’s changed is the volume an automated attack can push through. In this campaign, Huntress observed the attackers rotating traffic through roughly 12,800 different IP addresses while keeping the request count from any single address low — a “low and slow” pattern designed specifically to dodge simple rate-limiting and IP-blocking defenses. When infrastructure gets shut down, the attackers just move to a new provider and keep going.
None of this requires a high success rate to be worthwhile. Attackers already have enormous supplies of previously breached usernames and passwords from data leaks, infostealer logs, phishing, and reused credentials elsewhere. An old credential from a breach is worth little on its own — a credential that’s been freshly confirmed to still work against a live Microsoft 365 tenant is worth quite a bit more. Automated spraying is how that confirmation happens at scale.
Where configuration reviews fall short
A lot of security assessments stop at the question “is MFA enabled?” That’s a fair starting point, but it’s a configuration question, not a security question. The one that actually matters is: can someone with a valid password get past this control anyway?
That distinction is a big part of why penetration testing exists. A configuration review will tell you MFA is required. An adversarial test can show you that browser login requires MFA, Azure CLI login requires MFA — and a third, less obvious OAuth path issues a token on password alone. That third result is the one that tells you something about your actual exposure.
Identity infrastructure deserves the same scrutiny as your network
Penetration testing still gets thought of mostly in terms of firewalls, servers, and web applications. But for most organizations today, Microsoft Entra ID is the front door to email, file storage, collaboration tools, Azure resources, and often broader administrative access. That means the authentication layer itself belongs in scope — not assumed to work because a policy exists.
In practice, this is a narrow, controlled test: using a client-provided test account and its known password, we check whether that account can obtain a usable Microsoft cloud token through anything other than the expected, MFA-protected path. There’s no need to run millions of guesses — one authorized account answers the question directly. The result you want is simple: valid username, valid password, no MFA, no access. If the result instead is a usable token, that’s a real gap worth knowing about before an attacker finds it first.
What to check in your own environment
If you run Microsoft 365 or Entra ID, it’s worth a look at your Conditional Access setup with a few specific questions in mind:
Does MFA (or an equivalent strong authentication requirement) apply to all the users it’s supposed to, not just a subset?
Are all relevant cloud apps and resources covered, or only certain ones like admin portals?
Do user, group, or location exclusions create a gap nobody intended?
Are your policies actually enforcing, or is anything still sitting in report-only mode?
Can Azure CLI access be restricted to only the people who actually need it?
Do any legacy applications or workflows still depend on ROPC?
Do your sign-in logs show unexpected Azure CLI activity or password-only authentications?
Don’t just configure the control. Validate it.
The broader lesson here isn’t specific to Microsoft 365. Security controls usually fail not because the technology is bad, but because there’s a path around it that nobody tested. MFA remains one of the best defenses an organization can deploy. The question worth asking isn’t “do we have MFA” — it’s “have we confirmed there’s no authentication path where MFA doesn’t apply?”
That’s the kind of question a penetration test is built to answer. At Mile High Cyber, our testing is built around what an attacker can actually exploit — authentication paths, identity controls, segmentation, and access, not just a list of what looks vulnerable on paper. The best time to find a gap in your MFA strategy is before someone with a stolen password finds it for you.
If you’d like a second opinion on whether this applies to your environment, talk to a founder directly — no sales process, no obligation.
Terry Bradley, CISSP, is the President and Founder of Mile High Cyber, with over 30 years of experience in cybersecurity. A CISSP since 2008, he specializes in penetration testing, vulnerability management, and virtual CISO services, helping small and mid-sized organizations identify, remediate, and verify their most critical security risks.
Sources
Huntress: “No (Bad) CAP: Inside an Ongoing LSHIY Password Spray Attack” — huntress.com/blog/lshiy-password-spray-attack
BleepingComputer: “Password spraying attacks surge 155x as hackers exploit MFA gaps” — bleepingcomputer.com/news/security/password-spraying-attacks-surge-155x-as-hackers-exploit-mfa-gaps
Microsoft Learn: OAuth 2.0 Resource Owner Password Credentials (ROPC) — learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc