Azure CLI Password Spray: When Your MFA Does Not Fire

Your administrators run the Azure command line every day. They script a new storage account, pull a sign-in report, restart a service, check a Microsoft Entra policy. It is fast, it is how modern cloud work gets done, and it is exactly the doorway a large credential attack has been walking through this summer.

Security firm Huntress is tracking an ongoing, automated password-spray campaign aimed squarely at the Microsoft Azure command-line interface. The unsettling part is not the raw volume, though the volume is enormous. It is that many of the organizations that got compromised already had multi-factor authentication turned on. Their MFA simply never fired.

For banks, credit unions, and mortgage companies, that is the whole story in one sentence: having MFA is not the same as having MFA that covers the way an attacker actually signs in. This article walks through what happened, why the MFA stayed silent, and the specific settings your team should verify in Microsoft 365 this week.

What Happened: 81 Million Login Attempts Against Azure CLI

Between June 12 and June 26, 2026, Huntress observed more than 81 million login attempts hammering the Azure CLI across its monitored customers. Over that two-week window, the campaign compromised at least 78 Microsoft accounts across 64 organizations. Huntress attributes the traffic to a single autonomous system, AS32167, operated by an infrastructure provider called LSHIY, with the observed sign-ins arriving from an IPv6 address range.

Password spraying is an old technique with a simple logic. Instead of guessing many passwords against one account, which trips lockout defenses, the attacker tries one common or previously-stolen password against thousands of accounts, then moves to the next password. In this campaign, the attacker was not guessing at random. It was replaying username and password pairs exposed in earlier breaches that the account owners never rotated. Old passwords that still work are the fuel, and there is a lot of that fuel in circulation.

This is not a one-off spike. Huntress reports that the volume of credential-spray attacks across its customer base has climbed more than 155 times over the prior six months, with a current average of roughly 1,964 failed sign-in attempts per month per protected tenant. Spray at industrial scale is now the baseline, not the exception, and financial institutions sit near the top of any attacker's target list because the payoff is money, borrower data, and access to core systems.

The organizations that got hit were not careless. Many had multi-factor authentication in place. The attacker simply used a sign-in path their MFA policy did not cover.

How a replayed password reaches a Microsoft 365 account through the Azure CLI legacy sign-in flow, with no interactive MFA prompt along the way.

Why the MFA Did Not Fire

Here is the mechanism, because the mechanism is the lesson. The Azure CLI still supports an older sign-in method called Resource Owner Password Credentials, usually shortened to ROPC. In a ROPC sign-in, the client hands a raw username and password straight to the token endpoint and asks for a token in return. There is no browser, no redirect, and no interactive step where Microsoft Entra ID can stop and ask for a second factor.

That is the crack the campaign drove through. A Conditional Access policy that requires MFA generally enforces it at the interactive authorization step. ROPC skips that step. So a token can be issued off a valid username and password with no second-factor challenge, unless the tenant also blocks legacy authentication and scopes Conditional Access to every client app type. The organizations that got hit had not done both, and that is a scoping gap, not an unfixable hole in Microsoft 365.

Huntress found the gaps in familiar places. Some organizations required MFA only for specific applications, such as the admin portals, and never extended the policy to all cloud apps. Some required MFA only for certain groups, such as administrators, leaving standard users exposed. Some required MFA only from untrusted locations, and the attacker's traffic was geolocated inside the United States, so the location condition never triggered. And some had the right policy sitting in report-only mode, watching but never enforcing.

Every one of those is a scoping decision that looked reasonable on the day it was made and quietly left a door open. If you have not audited your Conditional Access design against every sign-in path recently, this campaign is a strong reason to do it now. Our guide to Conditional Access policies for financial institutions covers the baseline design, and the companion piece on the June 2026 Entra Conditional Access enforcement change explains a related shift in how all-resources policies now handle exclusions.

How to Close the Gap in Microsoft 365

The good news is that the fix set is well understood and it is built into the Microsoft 365 platform your institution already licenses. According to Microsoft, more than 99 percent of password-spray attacks and more than 97 percent of credential-stuffing attacks use legacy authentication protocols, and these attacks would stop with basic authentication disabled or blocked. That single control does most of the work.

Three settings, applied together, close the door this campaign is walking through.

In Microsoft terms, that means three named building blocks. First, block legacy authentication, which Microsoft offers both as a Conditional Access policy and, for smaller tenants, through Security Defaults. Second, require multi-factor authentication for Azure management, a Microsoft-managed policy that covers the Windows Azure Service Management API. That single API groups the Azure portal, the Microsoft Entra admin center, Azure PowerShell, and the Azure CLI, so one policy protects all four. Third, run a baseline MFA policy that targets all users and all resources with no resource exclusions, so nothing quietly falls outside the net.

Two of those are worth pairing with tenant-level identity hygiene. Turn on sign-in risk and user risk policies in Microsoft Entra ID Protection so a burst of failed sign-ins from a single network raises a flag automatically. And force a password reset on any account whose credentials may have appeared in a prior breach, because this campaign runs entirely on old passwords that were never changed. For a deeper look at moving beyond simple app-based codes, our article on phishing-resistant MFA for financial institutions covers where the strongest factors fit.

What to Verify This Week

You do not need a project plan to check the things that mattered in this campaign. A single afternoon in the Microsoft Entra admin center covers most of it. Walk this list against your own tenant.

If you find a successful sign-in from an address or network you do not recognize during that review, treat the account as compromised until proven otherwise. Reset the password, revoke active sessions and tokens, and check for mailbox rules or app registrations the attacker may have added to keep a foothold. The techniques overlap heavily with other identity attacks, including the device-code method we broke down in our piece on Microsoft 365 device-code phishing, and the same layered defenses apply.

That is simple to say and harder to keep true across every policy, every tenant change, and every new sign-in surface. Here is how the same problem looks from the seat of a partner who does this at scale.

The six Microsoft 365 controls that close the gap this campaign exploited, all built into Microsoft Entra ID.

What Examiners Expect

Regulators moved past checkbox MFA years ago. For banks and credit unions, the FFIEC guidance titled "Authentication and Access to Financial Institution Services and Systems," issued in August 2021, sets the expectation that authentication controls are layered and effective for access to systems and customer data. It is supervisory guidance rather than a single rule with a fine attached, but examiners lean on it, and "we had MFA turned on" is not a passing answer when the MFA never covered the path an attacker used.

For independent mortgage companies and other non-bank financial institutions, the FTC Safeguards Rule points the same direction. It calls for multi-factor authentication for anyone accessing customer information, unless the institution's qualified individual approves an equivalent or stronger control in writing. Either way, the message to your examiner is the same one this campaign delivered to 64 organizations: the control has to actually fire.

The practical takeaway for a governance conversation is simple. Document that your MFA covers all users, all resources, and all client app types, that legacy authentication is blocked, and that you monitor sign-in risk. That documentation is far easier to produce when a single partner manages the tenant and can show the policy set on request. Our rundown of the Conditional Access rules every financial institution needs is a useful starting checklist for that file.

How ABT Closes This Gap

ABT is a Tier 1 Microsoft Cloud Solution Provider dedicated to financial services. We manage the Microsoft 365 tenants of more than 750 banks, credit unions, and mortgage companies, which means Conditional Access design is not a one-time project we hand off. It is something we own, audit, and tighten as the threat landscape shifts, exactly as it shifted with this campaign.

Two parts of the ABT operating model speak directly to what happened here. First, we harden the managed tenant so the gaps that let this spray through are closed by default: legacy authentication blocked, MFA required across all users and resources including Azure management, and identity risk policies enforced rather than left in report-only. Second, Guardian MxDR gives your institution a twenty-four-hour managed detection and response team that watches Microsoft 365 sign-in activity, spots a spray in progress, hunts for any sign-in that succeeded, and responds before a compromised account becomes a compromised institution.

The campaign proved that turning MFA on is not the finish line. Keeping it correctly scoped, and watching for what still slips through, is the work. That is the work we do every day.

Frequently Asked Questions