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.”
Japan banking crisis
Outage causes disruption at 128 japan banks: preventing ATM transaction
Daily Cyber security update for 06.11. 2026
Cyber attack causes French bank Credit Mutuel Arkea €100 million missing
OpenAI AI Pipeline Discovers 948 Linux Kernel Privilege Escalation Flaws in 30 Hours
Bangladeshi Researcher Rasel Earns First Apple CVE Recognition for Model I/O Flaw
WinRAR, WordPress RCE flaw & Zyxel GS1900 Zero-Day exploited in the wild
Daily Cyber security update for 04.11. 2026
Daily Cyber security update for 03.11. 2026
Using ARTEX AI, Hacker to attack 200 Organizations Across 14 Countries
Amadeus cyber incident impacted “Cathay Pacific, Qantas, Japan, Malaysia, Korean & Asiana” Airlines
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.
