Skip to content
Azure CLI Password Spray Hits at Least 78 Microsoft Accounts in 81M+ Attempts

Azure CLI Password Spray Hits at Least 78 Microsoft Accounts in 81M+ Attempts

Ravie LakshmananJul 01, 2026Password Security / Cloud Security

Cybersecurity researchers have warned of a “massive, ongoing, automated password spray attack” aimed at Microsoft’s Azure command-line interface (CLI), compromising dozens of accounts in the process.

The activity, per Huntress, originates from an IPv6 address range (2a0a:d683::/32) controlled by internet infrastructure provider LSHIY LLC (AS32167).

“Between June 12 and June 26, the threat actor behind it made more than 81 million login attempts and successfully compromised at least 78 Microsoft accounts across 64 organizations,” the company said in a statement. “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.”

What makes the password spray attack noteworthy is not only the scale, but also the fact that many of the compromised organizations had Conditional Access policies enabled. Specifically, the campaign has been found to leverage a deprecated OAuth flow called Resource Owner Password Credentials (ROPC) to bypass Conditional Access Policy (CAP) protections.

ROPC is a legacy OAuth 2.0 grant type where a user directly provides their username and password to a client application, which then sends these credentials to an authorization server to exchange them for an access token. It was deprecated in OAuth 2.1.

In its documentation, Microsoft recommends customers against using the ROPC, arguing it’s incompatible with multi-factor authentication (MFA).

“In most scenarios, more secure alternatives are available and recommended,” the tech giant says. “This flow requires a very high degree of trust in the application, and carries risks that aren’t present in other flows. You should only use this flow when more secure flows aren’t viable.”

The credential and token spray attacks are said to have resulted in a handful of successful logins per day between June 12 and 21, 2026, averaging two to four accounts being compromised daily, with the exception of June 19, when 12 user accounts (aka identities) were compromised. The steady cadence changed on June 22, with 30 identities across 23 businesses impacted.

In all, 78 user accounts were compromised across 64 organizations as part of the campaign. The vast majority of the password spraying activity emanated from LSHIY LLC. Some of the IP addresses resolve to the U.S., while a few others resolve to China.

“These attacks are part of a large wave of credential spray attacks across a few different ASNs,” Huntress said, adding it has witnessed the volume of credential spray attacks surge by over 155 times across its 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.”

The activity appears to specifically weaponize old username/password combinations that were previously breached but had never been rotated. The use of the ROPC vector meant that the attackers were able to target enterprises that had implemented MFA, but it wasn’t enforced or configured to account for Azure CLI ROPC logins. 

This included scenarios where MFA wasn’t triggered –

  • Enforcing MFA only for specific apps, as opposed to “All Cloud Apps,” thereby failing to cover Azure CLI logins used by the threat actors
  • Enforcing MFA only for specific user groups, such as Admins
  • Enforcing MFA only when requests originate from non-trusted locations

“It’s worth noting that eight businesses impacted by the campaign had no MFA policy at all,” Huntress said. “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.”

To counter this line of attack, organizations are advised to require MFA for All Users, All Cloud Apps, and All Client App types when enabling CAP, restrict the Azure CLI application for non-admin users, and prioritize response by credential validity.

“This attack reveals cracks in CAPs that haven’t been appropriately configured,” Huntress researchers concluded. “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.”

Source link