Password Spraying Surged 155x — Because MFA Never Fired

In the first half of 2026, Huntress recorded a 155-fold increase in password-spraying attacks across its customer base. The spike was not a return to noisy brute force. It was a quieter reuse of old passwords against a login path that never asked for a second factor.

A large share of that traffic came from a campaign against Microsoft’s Azure CLI. In a two-week window in mid-June, Huntress counted more than 81 million login attempts and 78 compromised accounts across 64 organizations. Many of those organizations believed MFA was already on. For the sign-in method the attacker used, it never fired.

This article explains what spraying is, how the LSHIY campaign abused a deprecated OAuth grant, why Conditional Access looked complete while remaining incomplete, and what to change so a password alone cannot open the door.

Spraying Is Not Brute Force

A brute-force attack hammers one account with many password guesses. That pattern trips lockouts, rate limits, and “impossible travel” alerts. Password spraying inverts the order: the attacker picks one likely password, then tries it across a long list of usernames, waits, and moves to the next password.

• Brute force: many guesses against one account. Fast, loud, easy to lock out.
• Password spraying: one guess against many accounts. Slow enough to stay under lockout thresholds.
• Credential stuffing: known email-and-password pairs from earlier breaches, replayed on other sites.

This Campaign Mixed Spray Scale With Stolen Pairs

The LSHIY campaign sat between those last two categories. Huntress reported that targeting followed password prevalence on compromised combo lists, not industry or company size. Attackers reused username-and-password pairs that had already leaked and had never been rotated. That is why uniqueness still matters even when MFA exists on paper: a reused password that still works is a live session waiting to happen.

A typical spray still starts with reconnaissance — valid usernames from LinkedIn, company sites, breach dumps, or phishing — then a short list of common or seasonal passwords. This operator did not need clever guesses. The passwords were already known. The advantage was volume, infrastructure that was hard to block, and a sign-in flow that skipped the MFA page.

The Auth Flow That Time Forgot

Azure CLI, the command-line tool used to manage Azure and Microsoft Entra resources, still accepts a legacy OAuth grant called Resource Owner Password Credentials (ROPC). Microsoft’s own documentation warns that ROPC is incompatible with multifactor authentication. OAuth 2.1 deprecated the grant entirely.

In a normal browser sign-in, the user is sent to an authorization page. That is where Conditional Access can demand MFA, check device health, or refuse a risky location. ROPC never visits that page. The client sends a username and password straight to the tenant’s token endpoint. If the password is still valid, the endpoint can mint a user-delegated token with no interactive prompt.

Huntress principal threat intelligence lead Andrew “Spike” Brandt put it bluntly: even though we call ROPC an authorization method, “it’s technically an impersonation method.” For an attacker holding a reused password, that is the whole prize — a session, not a guess.

MFA Was Configured. The Policy Was Not.

This is the part that should unsettle anyone who treats an MFA checkbox as the finish line. On the June 22 spike, Huntress looked at 23 affected businesses. Eight had no MFA policy at all. The other 15 had MFA enforced through Conditional Access — and still lost accounts — because the policy did not cover the attacker’s path.

• MFA applied only to specific apps, such as Microsoft admin portals, so Azure CLI was left out.
• MFA applied only to certain groups, often “admins only,” while the compromised users sat outside that scope.
• MFA was required only from untrusted locations. Inconsistent IPv6 geolocation let attacker addresses appear trusted.
• MFA remained in report-only mode: configured, monitored, never enforced.

A Later Count Made the Gap Clearer

In a follow-up, Huntress wrote that 55 of the 78 compromised accounts already had Conditional Access policies requiring MFA. One organization even named a policy “Block Azure CLI.” The policy did not, in fact, block Azure CLI. MFA did not fail as a technology. It failed as a scope.

Huntress saw no post-compromise activity after the successful LSHIY logins. Staff product manager Rich Mozeleski suspects the operator was validating credentials for resale rather than living in the tenants. That is cold comfort. A confirmed password that bypasses MFA is still a product on a dark-web list, and the next buyer may not stop at validation.

Blocking IPs Became Whack-a-Mole

The first wave came from IPv6 range 2a0a:d683::/32, announced by hosting provider LSHIY LLC (AS32167). The attacker used LSHIY’s bring-your-own-IP (BYOIP) service — a legitimate peering product that lets a customer route traffic through ranges they already own. After Huntress and others reported the abuse, LSHIY suspended that user in early July.

The spray did not stop. Activity shifted to FranTech-hosted IPv6 ranges, then to 3xK Tech using IPv4, rotating through thousands of addresses and keeping per-IP volume low. Huntress later saw about 1.5 million attempted logins a day again. IPv6 gives attackers an enormous address pool. Provider hopping gives them a new pool whenever one is shut down.

Defenders who wait to block the current ASN will always be a step behind. The durable control is making a password insufficient, not maintaining a denylist of yesterday’s infrastructure.

What Organizations Should Change

Fine-tuning Conditional Access without locking out real users is hard. That difficulty is part of why this keeps working. Huntress’s guidance is still the shortest path out:

• Require MFA — or block the sign-in — for all users, all cloud apps, and all client app types, with no silent exclusions.
• Use a strong client setting such as userStrongAuthClientAuthNRequired so ROPC cannot succeed even when the password is correct.
• Disable ROPC and other legacy grants that cannot satisfy MFA. Microsoft already tells developers to migrate away.
• Restrict the Azure CLI application to people who actually need it. Most staff do not.
• Prioritize response by credential validity, not spray volume. The noisiest tenants are often the least compromised.
• Treat password hygiene as unfinished MFA: unique secrets, rotation after any leak, and passkeys or other passwordless options for high-value accounts.
• Write the rules down. Our 2026 strong-password guide helps turn “we have MFA” into a standard covering reuse, rotation, and fallback methods.

What Individuals Should Do

You do not need an Entra tenant to be in this blast radius. The same combo lists that fed Azure CLI sprays are tried against personal email, shopping, and social accounts every day. Spraying and stuffing both feed on reuse.

• Use a unique password for every account. Generate one with our password generator, then store it in a manager.
• Run a breach test on anything you have reused. The LSHIY passwords were old; they still worked because nobody rotated them.
• Turn on MFA everywhere, then prefer passkeys or a security key for email, your password manager, banking, and work. Traditional MFA still helps against stuffing — but as our AitM article explains, SMS and TOTP are not the end of the story.
• If you use Azure CLI or any other legacy client, ask IT whether ROPC is still allowed for your account. A password you never type into a browser can still be replayed by a tool.