How the LSHIY Password-Spraying Attack Abuses OAuth’s ROPC Grant

What it is

Huntress's Tradecraft Tuesday recap of the LSHIY password-spraying campaign against Microsoft Azure/Entra ID, which abuses the deprecated OAuth ROPC (Resource Owner Password Credentials) grant. Huntress reports a 155x increase in credential-spraying attacks in H1 2026, much of it attributable to this single campaign — which specifically targets Azure CLI as the client application.

How it works

ROPC lets a caller submit a username/password directly to a tenant's /token endpoint and receive a user-delegated token, minting it without ever triggering MFA or Conditional Access. Spike's framing: "Even though we call it an authorization method, it's technically an impersonation method." The actor rotates source IPs after each attempt via BYOIP and vast IPv6 space to evade Smart Lockout.

Preconditions / Affected

Any Entra tenant where ROPC is reachable and Conditional Access is not scoped to cover the accounts that can use it. Of 23 impacted orgs Huntress analyzed, all but eight had MFA; of those 15, roughly one third had MFA scoped to specific users, leaving groups (e.g., owners hit via ROPC) excluded. The takeaway the page stresses: MFA presence is not enough — CAP scope is the failure point, and some victims had an explicit block policy that still didn't catch this vector.

Threat-hunting specifics (net-new)

Details beyond the catalog summary, useful for blocking/hunting:

• Original source: LSHIY LLC IPv6 range 2a0a:d683::/32 (terminated early July after Huntress contact; LSHIY confirmed it was a BYOIP customer).
• Post-takedown: FranTech (AS53667), ranges 2605:6400::/32 and 2605:6404::/32, plus IPv4 via Tor exit nodes — at significantly lower volume.
• Community reports of similar traffic from German ISP 3xK Tech.
• Huntress observed no post-compromise activity after successful logins; hypothesis is the actor is validating credential lists for resale on the dark web — a "whack-a-mole" pattern as the actor hops between interchangeable BYOIP/peering providers.

What to do

The page's concrete guidance is limited: scope Conditional Access Policies to actually enforce over every account (including privileged/owner accounts reachable via ROPC) rather than assuming MFA coverage. It does not provide commands or a step to disable the ROPC grant.

Caveats

This is a webinar recap, not a technical advisory — no queries, KQL, or configuration commands are given. Geolocating the IPv6 sources is described as unreliable ("a hot mess"). The resale/validation motive is an explicitly stated hypothesis, not confirmed.