Acknowledgments: Special thanks to Dave Kleinatland, Matt Kiely, Jamin Becker, Bryan Masters, Justin Allen, and Arnelle French for their contributions to this investigation.
TL;DR: Huntress is observing a massive, ongoing, automated password spray attack against Microsoft's Azure command-line interface (CLI), originating from an IPv6 address range controlled by internet infrastructure provider LSHIY LLC, AS32167. Between June 12 through June 26, the threat actor made more than 81 million login attempts against Huntress customer accounts and successfully compromised at least 78 Microsoft accounts. Last week, the number and effectiveness of the compromises surged, continuing a concerning trend in the rapid expansion of these types of attacks. Notably, many of these organizations had Conditional Access policies, but the way they were configured didn't cover the techniques used by the threat actors in this campaign.
Background
Over the past several weeks, we have been tracking a wave of credential and token spray attacks against Microsoft 365 environments. This activity was also reported by the wider community, as seen on various Reddit threads.
Despite millions of failed login attempts, confirmed compromises from this wave have remained low, averaging a handful per day. Figure 1 below provides a screenshot of a specific timeframe for the compromises tied to this campaign (notably, the campaign began earlier than this screenshot). Between June 12 through 21, we saw a steady trickle of compromises, typically between two and four accounts being compromised daily (with the exception of 12 user accounts on June 19).
Then on June 22, we saw a significant spike in attacks, with 30 user accounts (which we label as "identities") across 23 businesses impacted.
Overall, between June 12 through June 26, we saw 78 user accounts being compromised across 64 organizations. Over this 14-day window, we've seen over 81 million login attempts. The majority of this tracked activity was originated from AS32167, an autonomous system that's linked back to internet infrastructure/hosting provider LSHIY LLC.
These attacks are part of a large wave of credential spray attacks across a few different ASNs. In the past six months, Huntress has observed the volume of credential spray attacks increase by over 155 times across our customer base. Attacks surged in particular in late May through early June, with a current mean value of about 1,964 failed attacks per month per Huntress-protected tenant. These numbers skew heavily towards certain targeted businesses. The median count currently sits at 804 per month. The targeting of these attacks seems to be based entirely on password prevalence on compromised password combo lists, and is not specific to business type or industry.
Attacker tradecraft
The threat actor appeared to be using old username/passwords combinations where the credentials were previously breached but had never been rotated.
While some of the IPs in this wave of attacks resolved to the U.S., some resolved to China. This is due to inconsistencies in third-party geolocation telemetry; while one third-party tool geolocated most of the IPs to China, another geolocated other IPs to Nebraska.
As such, some of the incidents were detected because the logins came from anomalous IPs. As Figure 2 shows, on an organization impacted on June 25, the SOC saw a number of events that were linked to this campaign that stemmed from China.
Attackers validating credentials via the ROPC flow
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.
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.
ROPC is considered problematic for several reasons, but one of those reasons is that it doesn't offer support for modern auth flows like MFA or SSO. That means, as we saw in this campaign, ROPC sends the password straight to the /token endpoint with no interactive MFA prompt.
MFA configuration holes
Because threat actors were using this attack vector, they were able to hit businesses that had implemented MFA, but that didn't properly configure it to cover Azure CLI ROPC sign ins.
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. However, while these organizations thought they were protected by MFA, the MFA did not fire for various reasons during this campaign (seen in Figure 3):
In some cases MFA was enforced for specific apps instead of "All Cloud Apps." For example, some organizations enforced MFA for Microsoft Admin Portals, which did not cover the Azure CLI logins used by the threat actor.
Other organizations enabled MFA only for specific user groups (like Admins Only). The compromised users were not in the scope of these specific user groups.
Several businesses had MFA set up so that it was only required from non-trusted locations, which the attacker's U.S.-geo-mislabeled IP address was able to evade.
In two cases MFA was left in-report only, meaning it was implemented but never enforced.
It's worth noting that eight businesses impacted by the campaign had no MFA policy at all. While threat actors in this campaign were able to get in despite MFA being set up, the takeaway should not be that MFA doesn't work at all; instead, organizations should ensure that their MFA policies are properly configured to address the authorization flow used across these incidents.
LSHIY: the attack's IPv6 range
The attacks came from the IPv6 address range of 2a0a:d683::/32, which has no corresponding value in the IPv4 addressing system. The range belongs to LSHIY LLC, an internet infrastructure provider that has business addresses registered at two different factory buildings in Hong Kong and Wuhan, China, and one at the TKO Suites at 42 Broadway, 12th floor, New York, NY 10004. TKO Suites is a shared office rental space for no business in particular, so whoever is at that office is keeping the true ownership of that company private.
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.
Huntress has reported the activity to the company via its abuse reporting mechanism, but we have not received a reply as of the time this post went live. We will update the post when we receive a reply from a company representative.
Mitigation guidance
This attack reveals cracks in CAPs that haven't been appropriately configured. CAPs evaluate sign-in clues like user, location, devices, and app type, to decide whether to require MFA before issuing a token. However, as we can see in this campaign, there are still potential weaknesses in how CAPs are deployed that can allow threat actors to slip through. 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.
Here are some other recommendations that can help protect against this type of attack:
Businesses setting up CAPs should require MFA (or block) for All Users, All Cloud Apps, and All Client App types, unconditionally. A strong Conditional Access setting (
userStrongAuthClientAuthNRequired) enforces strong authentication at the client authentication level and blocks ROPC flows, forcing this type of attack to failRestrict the Azure CLI application for non-admin users
Do not trigger response based on spray volume, as it points at the most-sprayed, least-compromised tenants; prioritize by credential validity instead
