81 Million Login Attempts Later: What the Microsoft 365 Password Spray Attack Reveals About Conditional Access Gaps
Between 12 and 26 June 2026, a threat actor made more than 81 million login attempts against Microsoft 365 accounts. By the time the campaign was identified, 78 accounts across 64 organisations had been compromised.
Cybersecurity firm Huntress traced the activity to an IPv6 range linked to LSHIY LLC and found the attackers weren’t exploiting a new vulnerability. They were using old, previously leaked username and password combinations that had never been rotated, then authenticating through a legacy OAuth mechanism that let them slip past multi-factor authentication in many of the organisations affected.
The detail that matters most for anyone running Microsoft 365 isn’t the scale of the attack. It’s that most of the compromised organisations already had MFA switched on.
The problem wasn’t the absence of a security control.
It was gaps in how that control had been configured, gaps that are extremely common and often invisible until something like this exposes them.
Quick summary
Huntress’s research shows that having MFA enabled isn’t the same as having it enforced everywhere an attacker might try to get in.
- The attackers used the ROPC (Resource Owner Password Credentials) OAuth flow via Azure CLI to authenticate directly, bypassing the interactive prompt where MFA normally applies
- Common misconfigurations included MFA scoped to specific apps rather than all cloud apps, MFA limited to admin accounts, MFA required only from untrusted locations, and MFA policies left in report-only mode
- Eight of the affected organisations had no MFA policy at all
- Huntress also reports a more than 155-fold increase in password-spraying activity over the past six months, with tenants averaging around 1,964 failed login attempts a month
The fix isn’t more security tools. It’s making sure the ones already in place actually apply where they need to.
What happened
Huntress observed the campaign directly targeting its customers over a two-week window. Daily compromises started small, typically two to four accounts a day, before spiking to 30 accounts across 23 organisations on 22 June. By the end of the campaign, the attackers had successfully compromised 78 accounts across 64 organisations, all traced back to the same IPv6 range.
What made the campaign notable wasn’t a sophisticated exploit. The attackers relied entirely on credential combinations already exposed in previous breaches, tested at scale against Microsoft 365 tenants until a working match was found, as reported by BleepingComputer. Huntress noted the targeting wasn’t specific to any industry or business size, it was based purely on which leaked passwords happened to still work.
How the attackers bypassed MFA
Once a valid username and password combination was found, the attackers authenticated using ROPC, a legacy OAuth flow that sends credentials directly to Microsoft’s token endpoint rather than through the normal interactive sign-in process.
That distinction matters. Conditional Access policies that enforce MFA typically do so at the interactive sign-in stage, where a user is prompted to approve a push notification or enter a code. ROPC doesn’t go through that stage at all. It exchanges a username and password for an access token directly, with no interactive prompt and no opportunity for MFA to trigger, even in tenants where MFA was technically switched on.
Microsoft has recommended against using ROPC for exactly this reason for some time, but the flow still works in any tenant where it hasn’t been explicitly restricted or blocked.
Why MFA didn’t stop it
In most of the affected organisations, MFA existed. It just wasn’t configured to cover every path an attacker might use. Huntress identified four recurring patterns:
- MFA applied to specific apps only. Policies covering admin portals or particular applications rather than being set to “All Cloud Apps,” leaving other sign-in paths, including Azure CLI, uncovered.
- MFA limited to admin accounts. Standard user accounts, which made up the bulk of the compromises, had no MFA requirement at all.
- MFA required only from untrusted locations. Policies that only trigger MFA for traffic from unfamiliar locations, which sophisticated attackers can work around.
- Policies left in report-only mode. Conditional Access policies that were configured correctly but never actually switched from monitoring to enforcement.
On top of these four patterns, eight of the affected organisations had no Conditional Access policy requiring MFA at all.
Common mistakes and pro tips
A few patterns come up repeatedly when Conditional Access policies are reviewed properly:
- Assuming that having MFA “on” somewhere in the tenant means it’s protecting everything
- Leaving legacy authentication protocols like ROPC available by default, when most organisations have no genuine need for them
- Treating report-only mode as a temporary testing step, then never circling back to switch it to enforced
- Reviewing Conditional Access policies once at setup and never revisiting them as the organisation and its Microsoft 365 usage evolves
A properly configured policy should apply to all users, all cloud apps, and all client app types, with legacy authentication protocols blocked outright unless there’s a specific, documented reason to keep them available.
What we’d recommend doing now
If you’re not certain exactly what your Conditional Access policies cover, that uncertainty is worth resolving before it becomes a problem rather than after. A proper review typically covers:
- Confirming MFA is enforced for all users and all cloud apps, not just admin accounts or specific applications
- Checking whether legacy authentication flows like ROPC are still available, and restricting or blocking them where they’re not genuinely needed
- Reviewing any policies currently sitting in report-only mode and deciding whether they should be enforced
- Testing policy behaviour using Microsoft’s Conditional Access “What If” tool to confirm policies work as intended rather than assuming they do
The bottom line on this attack
This campaign succeeded not because organisations were careless, but because Conditional Access configuration is genuinely easy to get subtly wrong, and those gaps tend to stay invisible until something like this puts them under pressure. MFA being switched on somewhere in a tenant provides very little reassurance if it doesn’t apply consistently across every user, application, and sign-in method.
Our Microsoft 365 Support service includes reviewing and tuning Conditional Access policies as part of ongoing tenant management, so gaps like these get caught before they’re exploited rather than after. If you’d like a clear picture of where your organisation currently stands, our speaking to one of our specialists is a good place to start.
Frequently Asked Questions
What is a password-spraying attack?
Password spraying involves testing a small number of commonly used or previously leaked passwords against a large number of accounts, rather than repeatedly guessing many passwords against one account. It’s designed to avoid triggering account lockout policies that watch for repeated failed attempts on a single user.
Does having MFA enabled protect against this kind of attack?
Not automatically. This campaign specifically succeeded in organisations where MFA existed but didn’t cover every sign-in path, including legacy authentication flows such as ROPC, which bypass the interactive prompt where MFA normally applies.
What is ROPC and why does it matter here?
ROPC (Resource Owner Password Credentials) is a legacy OAuth authentication flow that exchanges a username and password directly for an access token, without an interactive sign-in step. Because MFA is usually enforced at that interactive step, ROPC can bypass it entirely in tenants where the flow hasn’t been restricted.
How can I check if my organisation is affected?
Reviewing your Conditional Access policies to confirm they apply to all users, all cloud apps, and all client app types is the starting point, alongside checking whether legacy authentication protocols are still enabled. If you’re unsure how to interpret your current configuration, that’s exactly the kind of review our Support team can carry out for you.
Is this attack still ongoing?
Huntress observed this specific campaign between 12 and 26 June 2026, but noted a much broader, sustained increase in password-spraying activity across its customer base over the preceding six months. Treat this as a prompt to review configuration now rather than a one-off incident tied to a single date.