A massive automated password-spray campaign against Microsoft‘s Azure command-line interface has racked up more than 81 million login attempts in just two weeks.
Huntress researchers traced the attack to an IPv6 range controlled by internet infrastructure provider LSHIY LLC (AS32167).
Between June 12 and June 26, 2026, the threat actor compromised at least 78 Microsoft accounts across 64 organizations, with a sharp surge in effectiveness observed last week.
LSHIY Password Spray Campaign
The campaign began as a steady trickle, with two to four account compromises daily between June 12 and 21, before spiking dramatically on June 22 when 30 identities across 23 businesses were compromised in a single day.
This wave fits a broader pattern, as Huntress has observed a 155-fold increase in credential spray attack volume across its customer base over the past six months, with attacks intensifying sharply in late May through early June.
The attackers’ core tradecraft involved replaying previously breached, unrotated credentials via the OAuth 2.0 Resource Owner Password Credentials (ROPC) flow, a deprecated grant type that sends a username and password directly to a tenant’s /token endpoint without triggering an interactive MFA prompt.
This matters because many victim organizations had implemented MFA through Conditional Access Policies (CAPs), yet those policies were never configured to cover this specific legacy authentication path.
Some login activity also showed inconsistent geolocation data, with certain IPs resolving to China and others mislabeled as originating from Nebraska, complicating defenders’ detection.
Analysis of the June 22 spike found that 15 of the 23 impacted businesses had MFA enforced via CAP, yet it still failed to block the attackers due to configuration gaps.
In some cases, MFA was scoped to specific apps, such as Microsoft Admin Portals, rather than “All Cloud Apps,” leaving Azure CLI sign-ins uncovered, while other organizations applied policies only to select user groups, such as admins, thereby excluding the compromised accounts entirely.
Several businesses required MFA only from untrusted locations, a condition the attacker’s mislabeled IPs managed to evade, and two organizations had policies set to report-only mode, meaning MFA was technically implemented but never enforced. Notably, eight impacted businesses had no MFA policy at all.
The attack traffic originated from the IPv6 range 2a0a:d683::/32, registered to LSHIY LLC, an infrastructure provider with business addresses in Hong Kong, Wuhan, and a shared office space in New York that obscures the company’s true ownership.
LSHIY operates two autonomous systems, AS32167 and AS955, both reportedly originating from China according to third-party telemetry. Huntress reported the activity through LSHIY’s abuse channel but had not received a response as of publication.
Security teams should treat the Azure CLI and ROPC as high-risk surfaces that require precise CAP configuration, rather than assuming that MFA alone provides adequate protection.
Organizations should enforce MFA or blocking for All Users, All Cloud Apps, and All Client App types without exceptions, and enable the userStrongAuthClientAuthNRequired setting to enforce strong client-level authentication and block ROPC flows outright.
Restricting Azure CLI application access to non-admin users, disabling legacy authentication protocols, and regularly testing CAP behavior with Microsoft’s “What If” policy simulator all help close these gaps.
Incident response should also be prioritized based on credential validity rather than raw spray volume, since the most heavily targeted tenants are often the least likely to actually be compromised.
Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.
