Your MFA Isn't Enough: How a Deprecated Flow Lets Attackers Walk Into Microsoft 365
You have MFA enabled. You assume a baseline of security for your **Microsoft 365 accounts**. Then the headlines appear: "81 million login attempts, dozens of accounts compromised." This is a recurring frustration for IT professionals: the constant defense against password sprays, and the realization that standard MFA configurations are no longer sufficient. This isn't a zero-day exploit; it's attackers leveraging a known, deprecated authentication flow that many organizations, perhaps due to the complexity of their environments, overlook.
The LSHIY Activity: Incident Overview
Between June 12 and June 21, 2026, cybersecurity firm Huntress observed a significant password spray campaign targeting Microsoft 365 environments. This activity aligns directly with **MITRE ATT&CK technique T1110.003 (Password Spraying)**, a common tactic for initial access. Over 81 million login attempts were recorded. This was an opportunistic sweep, utilizing old username/password combinations sourced from previously breached credential lists.
Attackers successfully compromised accounts. Huntress confirmed at least 78 user accounts across 64 organizations were breached during this period. A notable spike occurred around June 22, with 30 user accounts across 23 businesses impacted in a single day. This represents a substantial increase from the typical 2-4 accounts compromised daily during the observation window.
These attempts largely originated from an IPv6 range (2a0a:d683::/32) linked to LSHIY LLC, an internet infrastructure provider. LSHIY operates Autonomous System AS32167, with registered addresses in Hong Kong, Wuhan (China), and New York. While some third-party geolocation data might indicate U.S. IPs, the underlying infrastructure often resolves to China. Huntress reported this activity to LSHIY's abuse desk, but as of the post date, no response had been received.
The Deprecated Flow That Lets Them In
The attack chain is straightforward: Attackers acquire old credentials from a combo list. They target the Microsoft 365 login, but not through a standard browser prompt. Instead, they use the OAuth ROPC (Resource Owner Password Credentials) flow, specifically via the Azure CLI. This flow, deprecated in OAuth 2.1 for valid security reasons, permits direct submission of the username and password to the /token endpoint.
Crucially, the ROPC flow can issue a user-delegated token without needing an interactive MFA prompt. This is the core vulnerability. Even if MFA is enabled for users logging into Outlook Web Access or other interactive services, Conditional Access Policies (CAPs) may not be configured to explicitly block or enforce MFA for all cloud apps and all client app types, particularly legacy ones like ROPC. This misconfiguration creates a critical bypass, directly enabling **MITRE ATT&CK technique T1556.006 (Azure AD Conditional Access Policy Bypass)**.
In such cases, MFA simply does not trigger. The password spray hits the ROPC endpoint, valid old credentials succeed, and a token is issued without any MFA challenge or warning.
Huntress pinpointed several common MFA configuration weaknesses that allowed this bypass, demonstrating how attackers exploit gaps in policy enforcement to achieve **T1556.006 (Azure AD Conditional Access Policy Bypass)**:
- MFA for specific apps only: Many organizations enforced MFA for administrative portals or specific applications, but not for "All Cloud Apps." This leaves gaps, such as the Azure CLI, exposed for **Microsoft 365 accounts**.
- MFA for specific user groups: If MFA was only enabled for, for example, "Admins Only," any compromised standard user account outside that group remained vulnerable.
- MFA from non-trusted locations: Attackers can evade this if their IP addresses are mislabeled or routed through seemingly trusted geographies, as was observed with some LSHIY IPs resolving to the U.S.
- "Report-only" mode: Some businesses had MFA policies implemented but left them in "report-only" mode, meaning they were never actually enforced. This renders the policy inert.
- No MFA at all: Eight of the compromised businesses had no MFA policy in place.
The Practical Impact: Why This Matters
The immediate consequences are significant: 78 compromised accounts across 64 organizations. For each of these accounts, an attacker gains a valid token, granting access to the user's Microsoft 365 resources. This includes email, SharePoint, OneDrive, and Teams. Such access can lead to data exfiltration, business email compromise, or further lateral movement within the environment.
This broader trend points to a rapidly growing threat. Huntress reported a >155x increase in credential spray attacks targeting **Microsoft 365 accounts** across its customer base in the past six months, with a significant surge in late May and early June. This is not an isolated event; it represents an ongoing, growing risk. Attackers are employing broad-spectrum attacks, understanding that even with widespread MFA adoption, misconfigurations or overlooked legacy flows create accessible entry points.
What You Need to Change, Now
This incident underscores a critical point: "MFA is enabled" is insufficient. Verification of how and where it is enforced is essential. To begin, a thorough audit of your Conditional Access Policies (CAPs) for **Microsoft 365 accounts** is paramount. Ensure these policies demand MFA—or, ideally, block access entirely—for "All Users," "All Cloud Apps," and "All Client App types" unconditionally. Any configuration gaps, such as enforcing MFA only for specific applications, will inevitably leave critical vectors exposed for attackers to exploit.
Beyond this, explicitly blocking ROPC flows is a non-negotiable step. Microsoft provides a specific Conditional Access setting for **Microsoft 365 accounts**, userStrongAuthClientAuthNRequired, precisely for this purpose. Implementing this setting enforces strong authentication at the client level, effectively neutralizing the ROPC flow as an MFA bypass mechanism.
Furthermore, consider the principle of least privilege: restrict or block access to the Azure CLI application for non-administrative users managing **Microsoft 365 accounts**. Most standard users have no operational need for this tool, and limiting its availability significantly reduces a potential attack surface. In terms of incident response, shift focus from the sheer volume of failed attempts—81 million is impractical to chase—to credential validity. Prioritize investigation into successful logins, especially those that appear to bypass expected MFA prompts or involve token issuance events that do not align with interactive user authentication patterns.
Finally, a critical review of any Conditional Access Policies currently in "report-only" mode is essential. This mode is designed for testing and validation, not for active security enforcement. Policies left in "report-only" status provide no actual protection and must be moved into enforcement to secure your environment effectively.
Attackers are leveraging old credentials and a deprecated flow to bypass what many consider a fundamental security control for **Microsoft 365 accounts**. The solution is not necessarily more complex technology, but rather precise configuration and a deeper understanding of how existing controls function. The evidence is compelling; these security gaps demand immediate attention for all **Microsoft 365 accounts**.
