Password spraying attempts rose 155x in the first half of 2026, according to Huntress — a surge driven not by new brute-force tools but by attackers exploiting legacy authentication paths that bypassed multi-factor protections.
How the LSHIY campaign operated at scale
Huntress traced a major share of the surge to a campaign targeting Microsoft's Azure CLI. The activity, originating from an IPv6 range controlled by internet hosting provider LSHIY LLC, produced more than 81 million related login attempts in mid‑June and 78 account compromises in a two‑week window. Huntress observed the campaign over several months and noted the attacker reused valid username/password pairs from earlier breaches — credentials that many organizations had not rotated.
The campaign followed classic password‑spraying tradecraft: reconnaissance to assemble valid usernames, a short list of likely passwords, spraying a single password across many accounts, and then pivoting if access was obtained. Huntress found little post‑compromise activity tied to the logins; Rich Mozeleski, Staff Product Manager at Huntress, suspects the attacker may have been validating credentials for resale on the dark web.
ROPC: a legacy grant that lets attackers sidestep MFA
The attack chain depended on abuse of Resource Owner Password Credentials (ROPC), a legacy OAuth grant deprecated in OAuth 2.1. ROPC sends username and password directly to the /token endpoint and does not support modern interactive flows such as MFA or single sign‑on. That absence made ROPC attractive: a reused password that still worked could immediately yield an active session without an MFA prompt.
Andrew “Spike” Brandt, Principal Threat Intelligence Incident Commander at Huntress, described the risk plainly: “Even though we call it an authorization method, it’s technically an impersonation method.” Huntress found that many affected organizations had deployed multi‑factor authentication via Conditional Access Policies (CAPs), but those CAPs did not cover the ROPC flow the attacker used — leaving a critical bypass in place.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildIPv6, BYOIP, and the challenges of blocking infrastructure
The campaign illustrates how infrastructure flexibility helps attackers. Initial activity came from IPv6 range 2a0a:d683::/32; LSHIY later terminated the traffic and confirmed the attacker had used its bring‑your‑own‑IP (BYOIP) offering. After that shutdown, spray attempts shifted to FranTech‑hosted IPv6 ranges and then to 3xK Tech using IPv4.
Huntress called out BYOIP as a legitimate service that also enables attackers to move rapidly between IP ranges and providers, complicating IP‑based blocking. IPv6’s vast address pool further reduces the efficacy of blocking a small set of addresses, producing a “whack‑a‑mole” detection problem for defenders.
Scope is the soft spot: how Conditional Access misconfiguration mattered
Huntress analyzed 23 affected businesses and found variable defenses: eight had no MFA at all; of the remaining 15, MFA did not apply to the sign‑in attempts because policies were scoped to certain apps or user groups, relied on trusted locations, or remained in report‑only mode. In short, a policy can appear to require MFA while leaving out specific users, applications, or sign‑in methods.
Huntress emphasized that fine‑tuning Conditional Access without locking out legitimate users is difficult — and that difficulty is a recurring exploitable weakness. As Mozeleski put it, “Appropriately configured and managed conditional access is a superpower.”
Mitigations Huntress recommends for defenders
- Enforce password hygiene and consider moving toward passwordless options.
- Disable ROPC (or remove apps that rely on it) to close the direct username/password token path.
- Restrict Azure CLI access for non‑administrative users.
- Prioritize incident response by credential validity rather than spray volume — heavily sprayed tenants are not always the most compromised.
- Require MFA for all users, all cloud apps, and all client app types with no exclusions; block auth methods that cannot satisfy MFA, including the legacy ROPC grant.
- Use a strong Conditional Access setting such as userStrongAuthClientAuthNRequired to enforce strong authentication at the client level and block ROPC.
What this means for technologists, affected enterprises, and end users
Technologists and security teams should audit Conditional Access policy scope, search for any apps still permitting ROPC, and enforce client‑level strong authentication so password reuse cannot generate a session. They should also restrict Azure CLI access to those who truly need it.
Affected enterprises and procurement leaders need to factor BYOIP and provider switching into threat models: LSHIY confirmed BYOIP use in the campaign, and the attacker moved between providers (FranTech, 3xK Tech) when blocked, demonstrating how quickly infrastructure can change.
End users should expect tighter controls — organizations must keep passwords strong and rotate credentials from past breaches because reused, unrotated pairs remain highly valuable to attackers that can bypass MFA via legacy flows.
Attackers found and exploited a specific gap: legacy OAuth behavior that bypasses interactive MFA and Conditional Access scoping that failed to cover that behavior. The remedy is equally specific — make sure a password alone cannot open the door: keep passwords strong, limit Azure CLI access to people who need it, and apply Conditional Access across all users, cloud apps, and client app types.
