Password spraying surges 155× in 2026 by slipping through MFA blind spots
Huntress measured a 155× increase in password spraying attacks in the first half of 2026, driven by an LSHIY campaign that generated 81 million login attempts in two weeks through the ROPC flow. Security teams must disable ROPC and extend MFA to every authentication flow, with no exceptions.
August 19, 2026. Huntress publishes a finding that reframes identity risk: a 155× increase in password spraying attacks in the first half of 2026. Mid-June 2026, a single campaign generated 81 million login attempts in two weeks and 78 account compromises. Brute force is an old reflex — but the spring behind this surge is new: attackers are no longer cracking passwords, they are walking around MFA.
This is not a password-strength problem. It is a configuration problem: organizations that believe they have turned on MFA, while their most critical authentication flows were left exposed.
A campaign aimed at the Azure CLI
The biggest contributor to the surge is a campaign tied to hosting provider LSHIY LLC. It targeted the Azure CLI, the command-line tool administrators use to manage Azure and Entra ID resources. The traffic originated from an IPv6 range controlled by that provider.
The mechanics are textbook, but scaled to industrial proportions. Attackers harvest valid usernames from LinkedIn, company sites, breach dumps, and phishing. They assemble a short password list — breached passwords, company-name variants, seasonal terms. Then they spray one password against every account on the list, staying under lockout thresholds, before moving to the next password.
The raw result: more than 81 million attempts in two weeks, concentrated in mid-June. What made each attempt more profitable is that the campaign reused username-and-password pairs stolen in earlier breaches and never rotated. Each success is worth more than a blind guess.
ROPC, the authentication flow MFA never sees
The technical heart of the story is ROPC (Resource Owner Password Credentials), a legacy OAuth grant deprecated in OAuth 2.1. ROPC was built to help applications migrate from direct authentication to OAuth. Its flaw: it supports neither MFA nor SSO.
In practice, ROPC sends the username and password straight to the /token endpoint, with no interactive MFA prompt. For an attacker, a reused password that still works becomes a live session, with no second factor in the way.
That is where the trap closes on defenders. Many of the compromised businesses had deployed MFA through a Conditional Access policy — but that MFA did not cover the ROPC flow the attacker used. The policy protected the web interface, not the token endpoint.
Andrew “Spike” Brandt, Principal Threat Intelligence Incident Commander at Huntress, distills the trap in one line: “Even though we call it an authorization method, it’s technically an impersonation method.”
Another telling detail: Huntress saw no post-compromise activity after the successful LSHIY logins. Rich Mozeleski, Staff Product Manager, suspects the attacker was validating credentials for resale on the dark web. Credential theft has become a product of its own.
BYOIP turns blocking into whack-a-mole
The campaign also exposed the limits of IP-based blocking. LSHIY used its BYOIP (bring your own IP) offering, a legitimate service that lets a customer route traffic through the provider with its own IP ranges. Attackers use that flexibility to swap ranges and providers at will.
The observed sequence is telling. The campaign started from the IPv6 range 2a0a:d683::/32. After LSHIY shut down the initial activity, attempts shifted to FranTech IPv6 ranges, then to 3xK Tech over IPv4. IPv6 hands attackers a nearly unlimited pool of addresses, which makes blocking a small set of IPs pointless.
The lesson is blunt: the attacker switches providers faster than the defender blocks. Infrastructure blocking remains useful, but it cannot be the primary defense.
The blind spots of MFA
The most instructive part is Huntress’s sample: 23 businesses hit by the LSHIY campaign. Eight had no MFA at all. Of the remaining 15, MFA did not apply to the attacker’s sign-in attempts — either because the policy was limited to certain apps or user groups, relied on trusted locations, or was still in report-only mode.
A Conditional Access policy can appear to require MFA while still leaving out specific users, applications, or sign-in methods. That is the gap the campaign exploits, without targeting any particular industry: it goes after organizations whose identity controls leave a seam open.
The difficulty is real: fine-tuning Conditional Access without locking out legitimate users is a balancing act, and that difficulty is part of why this keeps working for attackers.
The practical takeaway is that MFA is not a binary state. It is a scope: which users, which apps, and which sign-in methods are covered, and whether the policy is enforced or merely observed. The LSHIY campaign did not defeat MFA — it found the flows MFA was never told to guard. Huntress’s sample is small, but the pattern is not: eight organizations with no MFA, fifteen with MFA that did not apply. Roughly one in three unprotected, the rest partially protected — that ratio is the real headline. Close the scope gap and the surge loses most of its fuel.
Detect the spray and ROPC use
The LSHIY campaign leaves clear traces in the logs. Two signals are enough to spot it:
- successful sign-ins without MFA in Entra ID sign-in logs, from unfamiliar IP ranges — a successful spray stands out by the validity of the credentials, not by volume;
- ROPC requests, identifiable by the
grant_type=passwordproperty or the client app in sign-in logs, often tied to the Azure CLI or legacy clients.
To grasp ROPC’s danger, read the flow: a POST to /token with grant_type=password, the username and password in the clear. No redirect, no MFA prompt, no token negotiation — the endpoint answers directly with an access token. This is exactly the mechanism OAuth 2.1 removed, but it remains available until it is explicitly disabled on the tenant.
Huntress’s guidance inverts the intuition: do not prioritize the most heavily sprayed tenants, which are often the least compromised. Prioritize by credential validity — the only signal that separates a failed guess from an access actually obtained.
One more practical note: because the spray reuses breached credentials, enabling passwordless sign-in (passkeys or FIDO2) removes the raw material entirely — with no password to guess, there is nothing left to spray. It is the only mitigation that survives the attacker’s next provider switch.
Verdict
Password spraying is not a password problem — it is an authentication-perimeter problem. The 155× surge did not come from a new exploit technique; it came from a configuration gap: organizations whose MFA never covered the ROPC flow, and attackers agile enough to change IPs at will.
The fixes come down to four decisions, all actionable with no budget:
- Disable ROPC — or the applications that rely on it — across the tenant;
- Require MFA for all users, all cloud apps, and all client app types, with no exclusions, blocking methods that cannot satisfy an MFA requirement;
- Restrict the Azure CLI to the administrators who actually need it;
- Do not prioritize response by spray volume — the most heavily sprayed tenants are often the least compromised; prioritize by credential validity instead.
Mozeleski closes with: “Appropriately configured and managed conditional access is a superpower.” The corollary is just as clear — a misconfigured MFA is an absent MFA. If your Conditional Access policy contains an exclusion, a report-only mode, or a forgotten application, that is exactly where the next campaign will walk through.
References
- Huntress, “Twist the Nozzle on Password Spraying: A Tradecraft Tuesday Recap”, August 18, 2026.
- Huntress, “LSHIY Password Spray Attack”, 2026.
- BleepingComputer, “Password spraying attacks surge 155x as hackers exploit MFA gaps”, August 19, 2026.