
Huntress researchers have been tracking a massive automated password spray campaign against Microsoft Azure CLI environments since June 12, 2026.
A password spray attack is when attackers try a small number of common passwords across many accounts instead of many passwords on one account. This helps avoid lockouts while exploiting weak or reused passwords. It is often used in large-scale account takeover attempts.
In fourteen days, the attackers made over 81 million login attempts against Huntress customer accounts and successfully broke into 78 Microsoft accounts across 64 organizations. Last week the pace accelerated sharply: on June 22 alone, 30 user accounts across 23 businesses were compromised in a single day.

The traffic originates almost entirely from the IPv6 range 2a0a:d683::/32, controlled by LSHIY LLC, an internet infrastructure provider registered to AS32167.
“LSHIY operates to distinct ASNs: in addition to AS32167 (which was registered June 14, 2021), it also operates AS955 (registered June 22, 2022). Third parties report that the IPv6 ranges associated with both of these autonomous systems originate in China. Upon further investigation into this IPv6 range of interest, Huntress found specific IPv6 addresses in that range that were recent, including one from a maintainer created on June 11, 2026.” reads the report published by Huntress.
LSHIY lists business addresses at two factory buildings in Hong Kong and Wuhan, and one at a shared office rental space in New York. Huntress reported the activity through the company’s abuse channel, but it received no reply.
The attacker’s method is straightforward and effective. They replay old username and password combinations from breach data against the OAuth ROPC flow, the Resource Owner Password Credentials grant type, which sends credentials directly to the /token endpoint with no interactive MFA prompt.
“In the campaign, threat actors replayed validated credentials via the OAuth ROPC (Resource Owner Password Credentials) flow. ROPC is an OAuth 2.0 grant type that has been deprecated in OAuth 2.1. This auth flow takes a username/password at the /token endpoint for a tenant and mints a new user-delegated token once provided with the correct credentials.” continues the report. “This matters because many of the compromised businesses had implemented multi-factor authentication (MFA) via a Conditional Access Policy (CAP), but the MFA was not configured to cover this specific flow that attackers used. “
No MFA challenge fires because ROPC doesn’t support modern authentication flows, making it an effective bypass for organizations that haven’t specifically blocked it.
Here’s the part that should make every Microsoft 365 admin uncomfortable. Of the 23 businesses hit on June 22, 15 had MFA enforced via Conditional Access Policy. It didn’t help them.
“When analyzing the June 22 spike in attacks that impacted 23 businesses, we found that 15 of those companies had MFA implemented and enforced via CAP.” states the report.”However, while these organizations thought they were protected by MFA, the MFA did not fire for various reasons during this campaign.”
Some had MFA scoped to specific apps like Microsoft Admin Portals rather than all cloud apps. Others enforced MFA only for admin accounts, not regular users. Several triggered MFA only from untrusted locations, and the attacker’s IP addresses — inconsistently geolocated between China and Nebraska depending on the tool, slipped through the trusted location check. Two organizations had MFA in report-only mode, meaning it was set up but never enforced. Eight impacted businesses had no MFA policy at all.
The volume of this type of attack is not new but it’s growing fast. In the past six months, Huntress has seen credential spray attacks increase by over 155 times across its customer base, with a current mean of roughly 1,964 failed attempts per month per protected tenant. The targeting appears purely opportunistic, driven by which credentials appear most frequently in compromised password lists rather than by business sector or size.

The fix is not complicated but requires precision. Conditional Access Policies need to cover all users, all cloud apps, and all client app types without exceptions, partial coverage is what this campaign exploits. Enabling the userStrongAuthClientAuthNRequired setting enforces strong authentication at the client level and blocks ROPC flows outright. Restricting Azure CLI access for non-admin users removes another attack surface. And on the detection side, Huntress notes that triggering response based on spray volume alone points defenders at the most-sprayed and least-compromised tenants; prioritizing by credential validity is more effective.
“One glaring error here is that legacy protocols like ROPC can bypass some poorly-configured CAPs entirely since they don’t go through the authorization endpoint where policies are enforced. However, some of the other issues outlined above – such as misconfigured trusted locations or user groups – can also lead to gaps.” concludes the report.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, password spray campaign)