InfoSecBulletin Cybersecurity for mankind
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. According to Huntress, the activity comes from an IPv6 address range (2a0a:d683::/32) managed by the internet 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.”
14,000 Dahua cameras compromised: TP-Link flaws enable RCE
Microsoft Reveals Project Zenith Windows PCs Able to Run 30B+ AI Models Locally
Google issues warning of new Chrome zero-day flaw exploited
CrowdStrike’s ‘FalconFlank’ zero-day allows SYSTEM privileges
727,000 data exposes: French hospital fined €500,000
153 Million Driver’s License Surfaced on Dark Web: FBI Starts Investigation
Google Unveils Gemini 3.8 Flash Cyber to Identify and Auto-Patch Security Flaws
SonicWall SMA1000 SSRF Hits 10, Exploiting CVE-2026-83548Â
Gartner
70% of SOCs Will Pilot AI Agents: Only 15% Will See Results
CVE-2026-62911
Nearly 22,000 Microsoft Exchange Servers are vulnerable to attack
The password spray attack is important because of its large scale and the fact that many targeted organizations had Conditional Access rules in place. This attack used an old method called Resource Owner Password Credentials (ROPC) to get around these protections.
ROPC is an old OAuth 2.0 method where a user gives their username and password to an app. The app then sends this info to an authorization server to get an access token. It was removed in OAuth 2.1.
Microsoft advises customers not to use ROPC because it does not work 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 caused a few successful logins each day from June 12 to 21, 2026, with about two to four accounts hacked daily. The only day with more was June 19, when 12 user accounts were breached. On June 22, the pattern changed, affecting 30 accounts from 23 businesses.
A total of 78 user accounts were hacked in 64 organizations during the campaign. Most of the password spraying came from LSHIY LLC. Some of the IP addresses are in the U.S., and a few are in 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 seems to use old username/password pairs that were hacked before but were never changed. The ROPC method allowed attackers to focus on businesses that had MFA set up, but it was not properly applied 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, organizations should make sure all users, all cloud apps, and all client app types require MFA when using CAP, limit the Azure CLI application for non-admin users, and focus on checking the validity of credentials.
