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.”
Microsoft Patches CVSS 10.0 Azure AI Foundry Vulnerability Allowing Privilege Escalation
AWS is unable to restore access to Bahrain, one UAE cloud data zone after war damage
Cisco Warns of Critical ISE 0-Day Flaw and Hackers Allegedly Selling Fortinet FortiGate 1-Day Flaw
Anthropic prepares “Claude Money” to analyze bank account and financial data
GhostCode Phishing Kit Evades Microsoft 365 MFA to Hijack Accounts in 78 Seconds
CISA Warns of Cisco Secure Email Gateway 0-Day Flaw Actively Exploited in Attacks
VPN flaw exposed 246,000 personnel records in japan
Hackers deploy Casbaneiro Trojan that activates on bank websites
German police read Signal, Telegram, WhatsApp messages without breaking encryption
Urgent Patch! cPanel, GitLab Flaws Expose Users to RCE, File and Credential Theft
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.
