What 81 Million Failed Logins Actually Buy an Attacker
Identity & Detection Engineering

What 81 Million Failed Logins Actually Buy an Attacker

July 2026 Cybersecurity Research Notes ~6 min read

Between June 12 and June 26, 2026, a single threat actor threw more than 81 million login attempts at Microsoft 365 tenants. The campaign didn't rely on a zero-day, a leaked exploit, or custom malware. It relied on old breached passwords, a legacy authentication protocol, and gaps in Conditional Access policies that most defenders assumed were already closed.

Managed detection firm Huntress observed the activity directly against its customer base and confirmed the outcome: 78 Microsoft accounts compromised across 64 organizations. Do the arithmetic and the attacker's hit rate sits under 0.0002%. On paper that looks like a campaign that mostly failed. In practice, it's a reminder that at internet scale, a vanishingly small success rate is still a very good return on investment.

81M+login attempts over 2 weeks
78accounts compromised
64organizations affected
155xincrease in spraying volume observed by Huntress

How the attack actually worked

The mechanics matter more than the headline number. The attacker wasn't guessing passwords at random — they were testing username and password combinations pulled from prior breach dumps against live Microsoft 365 tenants, using Microsoft's own Azure command-line interface (Azure CLI) as the login client. Azure CLI is a legitimate administrative tool used every day to manage virtual machines, deploy applications, and automate cloud operations, which makes its traffic pattern easy to overlook in a sea of normal admin activity.

The part that made this campaign effective rather than just noisy is the authentication flow the attacker chose: ROPC, the Resource Owner Password Credentials OAuth grant. ROPC sends a username and password directly to the token endpoint in a single request. It was designed for legacy, non-interactive scenarios, and critically, it does not support modern authentication flows like interactive MFA prompts or single sign-on. If a valid credential pair is found, ROPC can hand back a token without ever surfacing an MFA challenge — not because MFA was bypassed technically, but because the flow itself was never wired to enforce it in many tenant configurations.

"ROPC sends the password straight to the /token endpoint with no interactive MFA prompt." — Huntress

The Conditional Access gaps that made this work

Huntress's investigation found that most affected organizations actually had MFA deployed. The problem wasn't absence of MFA — it was scope. Four specific misconfiguration patterns showed up repeatedly across impacted tenants:

  • Scoped to specific applications, not "All Cloud Apps." A Conditional Access policy that only covers certain sanctioned apps leaves any other authentication surface — including Azure CLI's OAuth flow — outside its enforcement.
  • Enforced only for privileged groups. Policies that require MFA for admins but not standard users assume the standard user account isn't worth compromising. It is — it's a foothold.
  • "Untrusted locations only" triggers. Attackers routing traffic through infrastructure that resolves as a trusted or familiar location sidestep this condition entirely.
  • Report-only mode left enabled. A policy in report-only mode logs what would have happened. It enforces nothing. Some organizations appear to have left pilot policies in this state long after they should have gone live.

In some of the organizations Huntress examined, there was no Conditional Access MFA policy in place at all. The campaign's source traffic was traced to an IPv6 range registered to LSHIY LLC (AS32167); Huntress reported the activity through the provider's abuse channel and, as of publication, had not received a response.

Why the economics still favor the attacker

It's tempting to read a 0.0002% success rate and conclude the campaign was a failure. That framing misses how spraying at this scale actually pays off. The marginal cost of an additional login attempt against a token endpoint is close to zero — proxy infrastructure and breached credential lists are commodity resources in 2026's threat landscape. Against that cost structure, even a hit rate this low nets dozens of working accounts across dozens of organizations. And a single compromised account in a Microsoft 365 tenant is rarely the end goal — it's a foothold for mailbox access, lateral movement, business email compromise, or staging further intrusion.

Huntress's broader telemetry reinforces that this isn't an isolated spike: password-spraying volume against its customer base is up more than 155-fold, with tenants now averaging nearly 2,000 failed login attempts per month. This has become background radiation, not an anomaly — which changes what "normal" needs to mean in your detection baseline.

What this means for detection and identity architecture

For security leaders and engineering teams, the lesson isn't "deploy MFA" — most of the affected organizations already had. The lesson is that MFA enforcement has to be evaluated by flow, not just by policy existence. A few concrete steps follow directly from this campaign:

  1. Audit Conditional Access scope against "All Cloud Apps," not a curated list. Any exclusion is a potential bypass path, and legacy protocols like ROPC are exactly where gaps hide.
  2. Block or tightly restrict legacy authentication flows. If ROPC isn't required for a specific, known automation use case, disable it. Where it is required, scope it to specific service principals and monitor it explicitly.
  3. Move report-only policies to enforced deliberately, on a deadline. Pilot mode should have an expiration date, not an indefinite lifespan.
  4. Instrument detection for Azure CLI-origin authentication anomalies — unusual volume, unfamiliar source ranges, or credential-stuffing patterns against the token endpoint specifically, since this traffic can otherwise blend into legitimate administrative activity.
  5. Prioritize phishing-resistant authentication (FIDO2 security keys, platform passkeys) over SMS or push-based MFA where feasible — these are immune to credential-replay style flows in a way that push notifications are not.
The takeaway: identity is the perimeter now, and a perimeter is only as strong as its least-enforced authentication path. A campaign built entirely from old breached passwords and a legacy OAuth flow compromised 78 accounts across 64 organizations that mostly believed they were protected. The gap wasn't a missing control — it was an incompletely enforced one.

Sources

Identity Security Microsoft 365 Detection Engineering Conditional Access Cloud Security

Working through a Conditional Access audit or hardening identity flows for a Microsoft 365 or Azure environment? I build and review security tooling and cloud architecture for teams that want this fixed correctly the first time — reach out if that's useful.