81 Million Azure Login Attacks Expose Holes in Microsoft Cloud Defenses
A massive password‑spray campaign hit more than 81 million Azure CLI login attempts between June 12 and 26, compromising at least 78 Microsoft accounts by exploiting old passwords and a deprecated OAuth flow. The incident shows how legacy features and partial MFA coverage can still put corporate and government cloud tenants at risk, even when they think they are locked down.
One of the world’s most widely used cloud platforms has just been reminded that its weakest points are often the features it left behind but never fully shut off. Between June 12 and 26, a coordinated password‑spray campaign targeted more than 81 million Azure CLI login attempts, ultimately compromising at least 78 Microsoft accounts by leaning on previously breached passwords and a legacy authentication flow.
Security researchers who analyzed the campaign found that attackers systematically tried old credential pairs against Azure’s command‑line interface, exploiting the deprecated Resource Owner Password Credentials (ROPC) OAuth flow. That flow, long discouraged in favor of more secure methods, allowed attackers to bypass some of the protections organizations thought they had in place. Even where multi‑factor authentication (MFA) was enabled, the way Azure CLI sign‑ins were handled left gaps that the attackers were able to use.
For system administrators and security teams, the numbers are sobering. Password‑spray attacks, which attempt a small number of common or previously leaked passwords across many accounts, are designed to slip under the radar of traditional lockout policies. In this case, the attackers combined that technique with a focus on a less‑monitored interface—the CLI used by developers and automated scripts—rather than the more heavily scrutinized web portals.
The immediate victims were the at least 78 accounts confirmed as compromised, belonging to organizations that have not yet all been publicly identified. But the operational stakes are broader. Azure accounts often sit at the center of an enterprise’s identity and access management web; a single breached account can open doors to code repositories, data storage, and administrative functions across multiple services. For companies in regulated sectors such as finance, healthcare or critical infrastructure, a successful intrusion at that level can mean not only data theft but also potential manipulation of systems that control real‑world operations.
Strategically, the incident exposes a persistent problem in cloud security: providers and customers alike tend to focus on the newest features and recommended best practices, while attackers look for the old doors that have been left half open. Deprecating an OAuth flow in documentation does not automatically remove it from every tenant configuration, and organizations with complex, layered deployments can struggle to identify where legacy methods are still in use.
The campaign also lands in a political context where governments are increasingly concerned about their reliance on a small number of U.S. cloud providers. For public‑sector agencies running workloads on Azure, the idea that attackers can still exploit outdated authentication flows, even in environments where MFA is widely deployed, raises fresh questions about oversight, auditing, and how quickly providers should be required to fully disable risky features.
A simple but hard lesson stands out: cloud security is not only about adding new locks; it is about making sure the old ones are removed or cannot be picked. Every legacy authentication path left open is an invitation for password‑spray operators to keep trying.
What happens next will hinge on how rapidly Microsoft and its customers respond. Key signals will include whether Microsoft forces the shutdown of ROPC and similar legacy flows across all tenants, how many more compromised accounts are eventually disclosed, and whether regulators in the U.S. and Europe push for tighter rules on deprecating risky authentication methods. Enterprises will be racing to audit their own Azure sign‑in patterns—and to close any remaining gaps—before the next campaign tests the system again.
Sources
- OSINT