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

Cybersecurity researchers at Huntress have documented a large-scale, ongoing password spray campaign targeting Microsoft's Azure command-line interface (CLI), as reported by The Hacker News on July 1, 2026. The attack compromised at least 78 Microsoft accounts through more than 81 million automated login attempts.

What Happened

Between June 12 and June 26, 2026, attackers launched a sustained automated password spray campaign against Azure CLI authentication endpoints. The activity originated from an IPv6 address range (2a0a:d683::/32) controlled by internet infrastructure provider LSHIY LLC (AS32167). Password spray attacks differ from brute-force attacks in an important way: instead of hammering a single account with many passwords, the attacker tries a small number of common passwords across a very large number of accounts. This approach helps evade lockout policies that trigger after repeated failed attempts on the same account.

Huntress attributed the attack to a specific autonomous system and flagged the volume and automation as notable. At least 78 accounts were confirmed compromised during the two-week window. The use of IPv6 infrastructure is worth noting because many legacy security monitoring tools and IP reputation services have less coverage of IPv6 ranges, which can make detection harder.

Why This Matters to Small Teams

Small teams and solo developers often rely heavily on cloud CLI tools like Azure CLI to manage infrastructure, deploy applications, and automate pipelines. These tools typically authenticate using Azure Active Directory credentials, which means the same account targeted in a password spray may also have access to production databases, storage buckets, and CI/CD secrets. A single compromised account can cascade into a full infrastructure breach.

Password spray attacks are specifically effective against organizations that do not enforce multi-factor authentication (MFA). Many indie developers and startups set up cloud accounts quickly and defer security hardening. Default configurations often leave accounts protected only by a password, which is exactly the condition these attackers exploit. The scale here, over 81 million attempts in two weeks, shows that this is not a targeted operation. It is opportunistic, automated, and casting a wide net.

Another risk for small teams is credential reuse. If a developer uses the same password across their Microsoft account, their Azure CLI service principals, or their personal email, a successful spray against one surface can unlock others. Small teams also tend to have fewer people watching authentication logs, so a compromised account may go undetected for days or weeks.

How to Stay Protected

1. Enable MFA on all Azure and Microsoft accounts immediately. This is the single most effective control against password spray. Even if an attacker guesses a correct password, they cannot complete the login without the second factor.
2. Audit your Azure service principals and app registrations. Remove any credentials that are unused or overly permissive. Service principals used in CI/CD pipelines should follow the principle of least privilege.
3. Review Azure sign-in logs for unusual activity. Look for authentication attempts from unfamiliar IP ranges, especially IPv6 addresses, or from geographies where your team does not operate. Azure Active Directory provides sign-in logs under the monitoring section.
4. Use Conditional Access policies if your Azure plan supports them. Require compliant devices or block sign-ins from high-risk locations. Even basic named-location policies add friction for automated spray tools.
5. Avoid reusing passwords across cloud accounts and developer tools. Use a password manager to generate and store unique credentials for every service. Pay particular attention to accounts that have CLI or API access.
6. Monitor for alerts from Microsoft Defender for Cloud or your SIEM. If you do not have centralized log monitoring, consider setting up basic Azure Monitor alerts for failed sign-in thresholds on privileged accounts.

How UNPWNED Helps

UNPWNED scans public-facing web infrastructure for security misconfigurations, exposed headers, TLS issues, and other hygiene gaps that increase your attack surface. While UNPWNED does not directly monitor Azure Active Directory sign-in events or authentication logs, the scanner helps you identify exposed admin panels, weak transport security, and missing security headers that could give attackers additional footholds if an account credential is ever compromised. Keeping your web layer hardened reduces what an attacker can do even after gaining initial access.

---

This post was drafted with AI assistance based on authoritative security sources, then published under editorial review.