Sixty-four organizations got breached this month despite having MFA enabled on every account that mattered. Not because MFA failed — because it was never actually being checked for the login path the attackers used. Between June 12 and June 26, 2026, Huntress tracked a password spray campaign that threw 81 million login attempts at Azure CLI and successfully compromised 78 accounts. The passwords weren't clever. The gap was.
The attack was boring on purpose
There's no zero-day here, and that's the point. The campaign, linked to infrastructure controlled by LSHIY LLC over an IPv6 range, replayed previously breached username-password pairs — credentials that leaked years ago and were never rotated — against Azure through OAuth's Resource Owner Password Credentials flow. ROPC is a legacy authentication method that exists mostly for backward compatibility with older tooling.
Volume did the work that sophistication usually does. Compromises started at two to four accounts a day, then spiked to 30 accounts across 23 businesses in a single day on June 22 — a clear sign the operators scaled up infrastructure or refined their target list mid-run. Targeting wasn't industry-specific either; researchers found the attackers were simply going after whichever passwords appeared most often in leaked credential lists. This was a numbers game, not a targeted operation.
Why MFA didn't stop it — and why that's not MFA's fault
Here's the part that should make you go check your own tenant right now. ROPC doesn't interact with Conditional Access Policies the same way modern browser-based sign-in flows do. A lot of organizations scope their MFA and Conditional Access enforcement to specific applications rather than "All Cloud Apps." If Azure CLI, PowerShell, or other CLI-based sign-ins aren't explicitly covered by that policy, those logins can bypass MFA enforcement entirely — in a tenant that would tell you, correctly, that MFA is turned on for every user.
That's the actual lesson: "MFA is enabled" and "MFA is enforced on every login path" are different claims, and most security reviews only verify the first one. This campaign is what happens when the second one is false and nobody noticed.
This isn't an isolated incident
Huntress has also flagged a 155x surge in credential spray attack volume across its customer base recently, with multiple campaigns running concurrently across different networks. Legacy authentication protocols keep showing up as the soft target because attackers have figured out that organizations assume MFA is a universal shield when it's actually a per-application setting that needs to be checked, not assumed.
What to check this week
Open your Conditional Access policies and confirm they're scoped to "All Cloud Apps," not a curated list. If Azure CLI or PowerShell sign-ins aren't explicitly inside that scope, they're in a blind spot right now, not hypothetically.
Disable ROPC at the tenant level unless you have a specific, documented dependency on it. Most organizations don't — it's legacy plumbing nobody remembers turning on.
Set up alerting on login volume, not just login failure. A single failed login is nothing. Tens of thousands of attempts in a short window against one tenant is a signal your SIEM should catch — specifically for CLI and legacy protocol endpoints, which don't get the same monitoring attention as the standard web sign-in page.
Rotate credentials for accounts that show up in breach-monitoring feeds, and treat developer and admin CLI tooling as a first-class identity surface with the same governance as any user-facing login. Security teams routinely harden the portal and leave the CLI alone because it "feels" lower-risk. This campaign is the data point that says otherwise.
If you haven't pulled up your Conditional Access policy scope and cross-checked it against every sign-in method your organization actually uses, that's the ten-minute task that matters more than almost anything else on your list today.