Password Spraying Surged 155x by Skipping the MFA Prompt

Nobody clicked anything. There was no phishing page, no proxied login screen, no malware and no stolen session cookie. Somebody sat on a large block of IPv6 addresses, posted usernames and passwords at Microsoft's token endpoint several million times a day, and walked out with valid access tokens for the accounts where the password happened to be right. The interactive sign in screen, where multifactor authentication actually lives, was never loaded.

Key Takeaways

• Huntress recorded a 155 times increase in credential spraying across its customer base during the first half of 2026.
• Between 12 June and 26 June 2026, a single actor made more than 81 million login attempts and compromised 78 user accounts across 64 organizations.
• LSHIY LLC (AS32167) controlled the IPv6 range 2a0a:d683::/32 the campaign sprayed from; when that block went away the actor moved to FranTech (AS53667) and to Tor exit nodes.
• ROPC, the OAuth Resource Owner Password Credentials grant, posts a username and password straight to the /token endpoint, and Microsoft states that the flow "is incompatible with multifactor authentication (MFA)".
• Of the 23 businesses compromised on 22 June alone, 8 had no MFA at all and 15 had MFA that did not cover the client app, the user group or the sign in location involved.

What Is ROPC and Why Does It Skip the MFA Prompt?

ROPC is an OAuth grant type in which the application handles the user's password directly and trades it for a token in a single HTTP request, with no browser and therefore no place to show a second factor. Microsoft's own documentation opens with a warning: "Microsoft recommends you do not use the ROPC flow; it's incompatible with multifactor authentication (MFA)."

The request is genuinely that small. A client ID, a scope, a username, a password and grant_type=password, sent as a form post to login.microsoftonline.com. What comes back is a bearer access token, an ID token and, if the scope asked for offline_access, a refresh token. That last item is the part defenders underrate: a refresh token converts one correct password guess into ongoing access that survives long after the spray traffic stops.

Andrew "Spike" Brandt, Huntress's Principal Threat Intelligence Incident Commander, put the framing bluntly in the company's Tradecraft Tuesday recap: "Even though we call it an authorization method, it's technically an impersonation method." The grant was written for legacy apps that could not open a browser. In 2026 the thing invoking it was Azure CLI, driven by somebody who was not an administrator anywhere.

How Big Was the June Campaign, and Who Ran It?

Between 12 June and 26 June 2026 the actor generated over 81 million login attempts against Huntress customer accounts and compromised 78 of them across 64 organizations. Huntress traced the traffic to the IPv6 range 2a0a:d683::/32, controlled by an internet hosting provider named LSHIY LLC (AS32167) with addresses registered in Hong Kong, Wuhan and New York. After that range was taken down the spraying resumed from FranTech (AS53667) across 2605:6400::/32 and 2605:6404::/32, plus IPv4 addresses belonging to Tor exit nodes. Huntress also recorded spraying from 3xK Tech GmbH (AS200373).

Do the division and the campaign looks almost comically inefficient: roughly one compromised account per million login attempts. That ratio is the whole point. Spraying at IPv6 scale costs the attacker close to nothing, and a hit rate of 0.0001 percent still clears 78 real mailboxes in a fortnight. Huntress makes the corresponding warning to defenders explicit, advising against triaging by spray volume because it "points at the most-sprayed, least-compromised tenants". Volume is noise. Credential validity is the signal.

The single worst day was 22 June, when 30 identities across 23 businesses fell in one push. That 23 organization cohort is the one Huntress dissected, and it is where the interesting part is, because most of them had MFA.

Why Did MFA Fail for 15 of the 23 Organizations?

Because their Conditional Access policies had conditions, and ROPC arrived through a gap in them. Eight of the 23 businesses had no MFA at all, which needs no explanation. The other 15 had MFA implemented and enforced through Conditional Access, and were compromised anyway: their policies were scoped to particular applications, particular user groups or particular sign in locations, and the request that mattered fell outside the scope. Roughly a third of the 15 had MFA applied only to selected users, leaving the group that owned the sprayed account uncovered.

Here is the timing detail nobody has flagged. Microsoft's mandatory MFA rollout put Azure CLI (app ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46) into Phase 2 enforcement starting 1 October 2025, but tenants were allowed to postpone Phase 2 until 1 July 2026. This campaign ran in the final fortnight of that postponement window. Worse, the same document notes that Phase 2 applies to requests sent to https://management.azure.com/ and that "Generally, Microsoft Graph APIs aren't in scope for Azure MFA enforcement". An attacker who wanted mail data rather than resource management was never inside the scope of that enforcement in the first place.

So the honest reading is not that MFA was bypassed. It is that a policy which is true for 99 percent of sign ins is a policy with a documented exception, and password spraying is an industrial process for finding exceptions.

What This Means for Your Inbox

A compromised Entra identity is a compromised mailbox, and that is normally the point. The endgame of this class of intrusion is business email compromise: read the thread, learn the vendors, learn who signs off on payments, then send one message from a real address that nobody has any reason to doubt. There is no malicious attachment for a gateway to catch, because there is nothing malicious in the message except the sender's intent.

This is the third distinct route past MFA into a corporate inbox that has needed writing up recently, and none of them involved breaking cryptography. Attackers hijacked live Outlook sessions with adversary in the middle proxies, they logged in with Gmail app passwords that skip the second factor by design, and now they post credentials at a token endpoint that was never wired to prompt. Every one of these is the identity provider working exactly as specified.

The reason it keeps working is that the raw material is cheap. Password spraying needs a list of real corporate addresses, and those are for sale in bulk: a forum seller recently advertised 3.64 million employee records pulled from corporate Azure tenants, complete with job titles and reporting lines. Directory data feeds the spray, the spray produces a token, the token produces a wire transfer.

How Do You Close the ROPC Gap?

The fix is unglamorous and mostly consists of deleting the conditions from your Conditional Access policies. Huntress's guidance is to require MFA, or block outright, for All Users, All Cloud Apps and All Client App types, unconditionally. Five concrete steps, in the order worth doing them:

• Hunt first, then fix. Search your Entra sign in logs across the last 30 days for an authentication protocol of ropc, and for the user agent string BAV2ROPC, both of which Elastic's detection rule keys on. Every hit should map to a known, intended automation. Anything else is an incident.
• Remove the scoping. Rewrite the tenant MFA policy to cover all users, all cloud apps and all client app types with no application exclusions, no trusted location allowance and no group carve outs. Each exclusion is a documented address for an attacker to spray.
• Restrict Azure CLI for non admin users. Most staff have no business holding a token for app ID 04b07795-8ddb-461a-bbee-02f9e1bf7b46. Scope the application to the people who actually run infrastructure.
• Turn on the client level control. Huntress names userStrongAuthClientAuthNRequired, describing it as a setting that "enforces strong authentication at the client authentication level and blocks ROPC flows, forcing this type of attack to fail".
• Move service accounts off passwords entirely. Microsoft's recommendation is to migrate user identities used for automation to workload identities, managed identities or certificate credentials, which have no password to spray at all.

For individual users the lever is smaller but real: a passkey or FIDO2 security key on the account means the account has no password to guess. NIST SP 800-63B has been steering authentication toward exactly this for years, and ROPC is a clean illustration of why.

Looking Ahead

The infrastructure moved twice during a two week campaign, from LSHIY to FranTech to Tor, which tells you blocking address ranges is a delaying tactic rather than a fix. What does not move is the ROPC grant itself, which Microsoft has deprecated in its libraries, warned against in its docs and still accepts at the token endpoint because somebody, somewhere, has a script that depends on it.

A 155 times increase in six months is not a new technique being discovered. It is an old one becoming obviously worth the electricity. Every tenant that keeps a legacy flow open for one integration keeps it open for everyone, and 81 million attempts is what checking looks like.