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.”
Bypassing firewalls, AI Agents Accessed Indian ‘ Data Without Permission: CERT-In
MITRE ATT&CK v20 Unveils 9 New Attack Techniques On AI Exploits, MFA Bypass, and CAPTCHA Evasion
Hackers Exploit Fortinet Flaws to Deploy Stealthy PEERSTITCH Malware on FortiGate Firewalls
Hacker stole Meta GitHub repos; Stole Source Code
Urgent patch! Zoom,NVIDIA and IBM Patch 41 Security flaws
Microsoft patches record braking 1411 flaws; 2 zero days
Anthropic unveils “OSS Scanner” Free AI Vulnerability Scanner for Open-Source Projects
Rise on RCE Exploits Targeting Hikvision Camera Flaw
FortiBleed Attack Compromised 80,000+ Devices, SonicWall Patches 4 SMA1000 Flaws CVSS 10
Critical Atlassian & IBM Flaws Expose Files and Enable Remote Code Execution
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.
