The 155x spray spike is a scope problem: MFA that never covered Azure CLI

Huntress reports a 155x increase in password spraying attacks in the first half of 2026 ^[1], and one of the largest single contributors was a campaign aimed at Microsoft's Azure CLI, the command-line tool admins use to manage Azure and Entra resources ^[2]. The number worth acting on is not 155x; it is 15, the count of victim organisations that had multi-factor authentication in place and lost accounts anyway ^[9][10].

Huntress analysed 23 affected businesses ^[9]. Eight had no MFA at all ^[9]. In the remaining 15, MFA existed and was enforced through a Conditional Access Policy, but it did not apply to the sign-in attempts the attacker actually made, because the policies were limited in scope ^[7][10]. That is roughly two thirds of the sample where the control was purchased, deployed, and presumably reported as done, and was not in the path ^[17].

The path was Resource Owner Password Credentials, a legacy OAuth grant deprecated in OAuth 2.1 and originally introduced so applications could migrate off direct password handling ^[5]. ROPC supports neither MFA nor SSO. It sends the username and password to the /token endpoint and issues a session with no interactive prompt ^[6]. Andrew "Spike" Brandt, principal threat intelligence incident commander at Huntress, put it plainly: "Even though we call it an authorization method, it's technically an impersonation method." ^[8]

The volumes: in mid-June alone, Huntress observed more than 81 million related login attempts and 78 account compromises in a two-week window ^[16]. That is roughly one compromise per million attempts ^[20], which reads as terrible odds until you notice the attempts cost nothing and the credentials were not guesses. The campaign paired spraying scale with valid username and password pairs from earlier breaches that had never been rotated ^[4]. Huntress says the campaign does not appear to target a particular industry, and instead finds organisations whose password controls or MFA policies leave gaps ^[14].

Infrastructure blocking will not carry the weight here. The traffic came from an IPv6 range, 2a0a:d683::/32, controlled by hosting provider LSHIY LLC ^[3]. LSHIY later terminated the activity from that range and confirmed the attacker had been using its bring-your-own-IP service, which lets customers route traffic through the provider using address space they own ^[11][12]. The spray attempts then moved to FranTech-hosted IPv6 ranges, and later to 3xK Tech over IPv4 ^[13]. IPv6 alone hands the attacker an address pool large enough that blocklists of a few IPs are decoration ^[15].

Huntress saw no post-compromise activity following the successful logins ^[18]. Rich Mozeleski, a staff product manager at Huntress, suspects the operator was validating credentials for resale on the dark web ^[19]. Treat that as a single-sourced hypothesis, and treat the 78 accounts as live inventory somebody else may buy.

What to watch: whether your Conditional Access policies are scoped by client app and grant type rather than by user and location, and whether ROPC token requests appear in your sign-in logs at all. Watch for the same credential set reappearing from a third or fourth provider, since swapping BYOIP arrangements is the cheap part of this operation ^[13][12]. An awareness campaign does not close a flow that never prompts the user.