81 Million Login Attempts in Two Weeks: The Microsoft 365 Legacy-Auth Hole That Bypasses Your MFA (2026 Hardening Playbook)

Between 12 and 26 June 2026, Huntress researchers documented an automated password-spray campaign against Microsoft Azure CLI authentication that generated more than 81 million login attempts and compromised at least 78 accounts across 64 organisations. Per the same reporting, attackers bypassed MFA in many environments by authenticating through the Resource Owner Password Credentials (ROPC) OAuth flow — a legacy path that several tenants' Conditional Access policies failed to cover. The MFA most mid-market companies bought is not the MFA their tenants actually enforce. The six-point Microsoft 365 identity hardening playbook is inside.

CALL IT DEV — Software, AI and dedicated tech teams — Casablanca | Madrid | Dubai

81 Million Login Attempts in Two Weeks: The Microsoft 365 Legacy-Auth Hole That Bypasses Your MFA (2026 Hardening Playbook)

What Huntress reported about the June 2026 Azure CLI password-spray campaign

Between **12 June 2026 and 26 June 2026**, **Huntress** researchers documented an automated password-spray campaign against Microsoft cloud identities that used the **Azure CLI** authentication path as its front door. Per the Huntress write-up published in early July 2026, the campaign generated **more than 81 million login attempts** during that fortnight and **compromised at least 78 accounts across 64 organisations**. The scale is not what makes the incident operationally interesting. The mechanism is.

Two properties of the campaign matter for anyone running a Microsoft 365 tenant in 2026:

Huntress traced the campaign traffic to infrastructure hosted by **LSHIY LLC**, and the campaign only stopped when that provider terminated the attackers\' accounts. The takedown is the point where Huntress\'s telemetry ends. The exposed control gap in the affected tenants is the point where the buyer\'s work begins.

Nothing in this article is invented. Every claim is attributed to Huntress, to Microsoft documentation on OAuth flows and Conditional Access, or to widely-published guidance on M365 identity hardening.

Why this is a different failure mode from infostealer session hijacking

An infostealer campaign like the one described in our earlier analysis of [session-token theft and MFA bypass](/en/blog/infostealer-session-hijacking-mfa-bypass-identity-security-2026) steals authenticated session cookies from a compromised endpoint **after** the user has already signed in and completed MFA. The attacker replays the cookie against the service and inherits the session without ever presenting a password or a second factor.

The June 2026 Azure CLI campaign is the opposite shape. There is no endpoint compromise. There is no cookie theft. There is no session replay. The attacker walks up to the **front door** — the interactive authentication endpoint — with a known-valid password from a previous breach, requests a token via a **legacy OAuth flow that the tenant configured MFA on but never actually applied to that flow**, and is issued a valid access token. The MFA layer never runs, not because it was defeated, but because on the ROPC code path it was never invoked in the first place.

That distinction matters for the response. Session-token theft is fixed by hardening the endpoint (EDR, browser telemetry, device compliance) and by shortening token lifetimes and binding tokens to devices. Password spray plus ROPC bypass is fixed by **closing the legacy-auth code paths** at the tenant level so the second factor is enforced everywhere no matter which OAuth flow the client requests, and by **rotating credentials that appeared in past breaches** so the spray target list is empty.

Buyers who read only the infostealer coverage will harden endpoints and still leave the front door open. Buyers who read only the password-spray coverage will close legacy auth and still be exposed to token theft on the endpoints they never hardened. Both problems are real and both need dedicated controls.

The six-point Microsoft 365 identity hardening playbook

The six controls below are the operational response to the pattern Huntress documented. Every control is standard Microsoft-published guidance; the value is in operating them as a coherent set rather than picking two and treating the rest as optional.

1. Inventory and block legacy authentication tenant-wide

Legacy authentication protocols in the M365 context include the ROPC OAuth flow, the OAuth device-code flow when used unnecessarily, basic authentication against IMAP, POP3 and SMTP AUTH, and the older Exchange ActiveSync flows that predate modern authentication. Per Microsoft\'s own documentation, these paths pre-date modern conditional access controls and are the historically documented mechanism by which MFA is not enforced even when the tenant believes it is.

The correct posture in 2026 is a **tenant-wide block of legacy authentication** enforced through a Conditional Access policy that targets **all users** and **all cloud applications**, with the report-only mode used first to surface any legitimate application that is still using a legacy path so it can be migrated or retired. Basic authentication for Exchange Online has been end-of-life for interactive user protocols since Microsoft\'s 2022–2023 deprecation programme; SMTP AUTH remains available but should be scoped to named service accounts only, not enabled tenant-wide.

Every account, every mailbox, every service principal that still authenticates via a legacy path is an exposed component in the exact code path Huntress documented being abused.

2. Audit Conditional Access for coverage gaps

The Huntress finding that "several organisations\' Conditional Access policies failed to cover" the ROPC flow is a specific instance of the general Conditional Access gap pattern. A tenant that has a Conditional Access policy titled "Require MFA for all users" is not the same as a tenant that actually requires MFA on every sign-in. The gaps are typically:

The audit is not conceptually hard. It is a systematic review of every Conditional Access policy, every exclusion, and every client-app selector, against the assumption that any exclusion is an active attack path until proven otherwise. Break-glass accounts are the only legitimate exclusion, and they should be monitored on every sign-in.

3. Rotate credentials exposed in past breaches, and enable breached-password detection

The Huntress campaign worked because the sprayed credentials were valid. They were valid because they had leaked in earlier third-party breaches and never been rotated on the M365 side. Microsoft Entra ID (formerly Azure AD) Password Protection provides a **breached-password detection** capability that rejects passwords appearing in Microsoft\'s known-breach corpus, and Azure Identity Protection surfaces per-user leaked-credential risk signals derived from external breach ingestion.

The operational discipline is threefold: enable breached-password detection tenant-wide with the global banned-password list; force a password reset for any user surfaced by Identity Protection as having a leaked credential, without waiting for the next scheduled rotation; and set an expectation with the workforce that a leaked password anywhere is a leaked password everywhere and requires an immediate change on the corporate account.

4. Phishing-resistant MFA for privileged accounts

Not all MFA is equivalent. SMS-based codes and voice-call codes are vulnerable to SIM-swap and interception. Push notifications are vulnerable to fatigue attacks. Time-based one-time passwords are vulnerable to real-time phishing via adversary-in-the-middle kits.

The phishing-resistant category — FIDO2 security keys, Windows Hello for Business, and platform authenticators bound to the device — is the baseline that Microsoft recommends for **all privileged accounts** in 2026. Every Global Administrator, every Privileged Role Administrator, every Exchange Administrator, every account with a role that could pivot into a Global Administrator, should be on phishing-resistant MFA. Regular users benefit as well; the priority order is by blast radius.

5. Monitor failed-login telemetry for spray patterns

Password spray attacks have a characteristic signal: a very high ratio of failed sign-ins per successful sign-in, distributed across many usernames and many source IP addresses, with each username seeing only a small number of attempts to stay below per-account lockout thresholds. Microsoft Entra ID sign-in logs, Entra ID Protection risk detections, and the Unified Audit Log surface the raw telemetry.

The operational value is in **continuous baselining**: what is the normal failed-sign-in-per-hour rate for this tenant, on which endpoints, from which countries. Deviations from that baseline — a spike in failures against the ROPC endpoint specifically, or a spike in failures against a specific service principal, or a distributed pattern across many usernames — are the signal Huntress\'s telemetry saw at internet scale and that a well-instrumented tenant can see for itself at its own scale.

6. 24/7 managed detection so an alert at 03:00 gets a human response

The Huntress campaign generated telemetry continuously across a fourteen-day window. Any organisation whose SOC operates business-hours only would have seen the failed-sign-in spike on Monday morning after eleven hours of unattended attack traffic. Any organisation whose alerts land in a shared inbox with no rotation coverage would have seen the compromise notification when someone got to the inbox.

Managed detection and response — a 24/7 rotation that receives the alert, triages it, and responds within a defined SLA — is the operational answer to attack traffic that does not respect a nine-to-five schedule. The value is not detection technology; the value is the human being who picks up the pager at 03:00 and executes the response runbook.

Where Call IT Dev fits

Call IT Dev operates managed security operations and 24/7 SOC monitoring from Casablanca and Rabat, with delivery cover from Madrid and Dubai. The delivery footprint gives European buyers **follow-the-sun coverage** with a **CET-aligned primary shift** and an English- and French-primary analyst bench that extends to Spanish and Arabic on demand. The identity-hygiene practice — legacy-auth inventory, Conditional Access audit, breached-password rotation, phishing-resistant MFA rollout, sign-in telemetry baselining — is delivered as an operational discipline rather than a one-off assessment.

The commercial construct that makes the six-point playbook affordable for mid-market buyers is the nearshore Morocco cost basis, which our [why-Morocco](/en/why-morocco) page describes in detail. Dedicated engineering pods, technical-support teams and cybersecurity analysts are staffed from the same national talent pipeline anchored by named private-sector investors and by public digital-strategy commitments. The same platform delivers our broader [cybersecurity](/en/services/cybersecurity), [technical-support](/en/services/technical-support) and [cloud-infrastructure](/en/services/cloud-infrastructure) practices.

Further reading

${CTA_M365}

الأسئلة الشائعة

What is a password spray attack?

A password spray attack is an automated authentication attack in which the attacker tries a small number of commonly-used or previously-breached passwords against a very large list of usernames, staying below per-account lockout thresholds so no single account triggers a defensive response. The Huntress report from early July 2026 documented a password-spray campaign against Microsoft Azure CLI authentication that generated more than 81 million login attempts between 12 and 26 June 2026 and compromised at least 78 accounts across 64 organisations using previously breached but never-rotated credentials.

What is ROPC and why does it bypass MFA?

ROPC stands for Resource Owner Password Credentials, a legacy OAuth 2.0 authentication flow in which the client collects the username and password directly and exchanges them for an access token. Per the Huntress reporting, in the June 2026 campaign attackers used the ROPC flow against Microsoft cloud identities and bypassed MFA in many environments because the affected tenants' Conditional Access policies did not cover the ROPC code path. The MFA was configured; it was structurally not invoked on that flow. Microsoft's guidance is to block legacy authentication tenant-wide through Conditional Access.

How do I know if legacy auth is enabled in my Microsoft 365 tenant?

Microsoft Entra ID sign-in logs surface every authentication event with the client-app type and the authentication protocol used. Filter the sign-in logs on legacy authentication client-app categories (Exchange ActiveSync, IMAP, POP, SMTP AUTH, other clients using basic authentication) and on the OAuth flow used to identify ROPC and device-code flow traffic. A Conditional Access policy scoped to block legacy authentication should first be deployed in report-only mode to surface any legitimate application still using a legacy path so it can be migrated or retired before enforcement.

What should Conditional Access cover?

A defensible Conditional Access posture in 2026 covers all users, all cloud applications, and all client-app types, with break-glass accounts as the only legitimate exclusion. The audit surfaces the gaps: excluded user groups created for a short-term reason and never re-included, excluded applications creating uncovered code paths, location or device conditions that leave a "trusted" path uncovered, and client-app conditions that silently skip legacy clients. The Huntress finding that "several organisations' Conditional Access policies failed to cover" the ROPC flow is a specific instance of the client-app gap pattern.

How fast should exposed credentials be rotated?

Any credential surfaced by Microsoft Entra ID Protection as a leaked-credential risk should be rotated on discovery, without waiting for the next scheduled rotation. The Huntress campaign worked because previously breached credentials had never been rotated on the M365 side. Enabling Entra ID Password Protection breached-password detection tenant-wide rejects passwords appearing in Microsoft's known-breach corpus at the point of change, which addresses the class rather than the instance. The workforce expectation is that a leaked password anywhere is a leaked password everywhere and requires an immediate change on the corporate account.

When does managed detection and response make sense for an SMB?

Managed detection and response makes operational sense at the point where the volume or timing of security alerts exceeds what an internal team can triage inside the response window the threat model requires. The Huntress campaign generated telemetry continuously across a fourteen-day window; a business-hours-only SOC would have accumulated eleven hours of unattended attack traffic every night and every weekend. For most SMBs the arithmetic falls on the side of an external 24/7 rotation from the point at which the internal team is smaller than three or four analysts, because sustainable follow-the-sun coverage requires more staff than most SMBs will fund internally.

CALL IT DEV — Software, AI and dedicated tech teams — Casablanca | Madrid | Dubai — contact@callitdev.com — +212-537-373777