Password Spraying Surges 155x, Exploiting Legacy Auth Flows in Microsoft Azure
A new report from **Huntress** reveals a staggering 155x increase in password spraying attacks during the first half of 2026. A significant contributor is a campaign targeting **Microsoft Azure CLI**, leveraging reused credentials and a deprecated OAuth grant to bypass even multi-factor authentication (MFA). This surge highlights critical gaps in current security postures and conditional access policies.

Cybersecurity firm **Huntress** has identified a dramatic 155x increase in password spraying attacks within the first six months of 2026. While password spraying isn't a new technique, the scale and methods behind this latest spike are particularly concerning.
A key driver of this surge is a sustained campaign targeting **Microsoft**'s **Azure CLI**, the command-line interface used by administrators to manage **Azure** and **Entra** resources. The malicious traffic primarily originated from an **IPv6** range controlled by internet hosting provider **LSHIY LLC**.
Over a mere two-week period in mid-June, **Huntress** observed more than 81 million login attempts and 78 successful account compromises linked to this campaign.

## The Authentication Flow That Time Forgot
Password spraying typically involves several stages:
1. **Reconnaissance:** Attackers gather valid usernames from public sources like **LinkedIn**, company websites, or data breach dumps.
2. **Password List Creation:** A short list of common passwords, previously breached credentials, or company-specific terms is assembled.
3. **Spray Across Accounts:** Attackers attempt one password against many accounts, carefully adhering to lockout thresholds to avoid detection.
4. **Gain Foothold:** Successful access leads to lateral movement, Business Email Compromise (BEC), data exfiltration, or further credential theft.
The **LSHIY** campaign distinguished itself by combining the broad reach of password spraying with the reuse of valid, unrotated username-and-password pairs from past breaches. This made each successful attempt particularly valuable.
Crucially, the attackers exploited the **Resource Owner Password Credentials (ROPC)** OAuth grant. **ROPC**, deprecated in **OAuth 2.1**, was designed to assist applications transitioning from direct authentication. However, it lacks support for modern authentication flows like MFA or SSO, sending usernames and passwords directly to the `/token` endpoint without an interactive MFA prompt. This vulnerability allowed attackers to leverage reused credentials into active sessions.
Many of the compromised organizations had implemented multi-factor authentication (MFA) via a Conditional Access Policy (CAP). However, the MFA was often not configured to cover this specific legacy flow that the attackers exploited.
**Andrew βSpikeβ Brandt**, Principal Threat Intelligence Incident Commander at **Huntress**, noted, βEven though we call it an authorization method, itβs technically an impersonation method.β
Interestingly, **Huntress** observed no post-compromise activity immediately following the successful logins tied to the **LSHIY** campaign. **Rich Mozeleski**, Staff Product Manager at **Huntress**, speculates that the attacker might have been validating credentials for resale on the dark web.
**LSHIY** subsequently terminated the attacks from the original IP range, confirming that the attacker had utilized its bring-your-own-IP (BYOIP) offering.
## The Rise of IPv6 BYOIP
BYOIP is a legitimate service allowing customers to route traffic through an ISP using their own IP ranges. For attackers, this flexibility enables them to switch IP ranges and providers rapidly, complicating detection and blocking efforts and helping them evade IP-based detection and account-lockout controls.
The initial **LSHIY** campaign attacks originated from the **IPv6** range `2a0a:d683::/32`. The vast address space offered by **IPv6** provides attackers with an enormous pool of addresses, making traditional IP blocking less effective for defenders.
After **LSHIY** ceased the original activity, spray attempts shifted to **FranTech**-hosted **IPv6** ranges, with subsequent activity appearing from **3xK Tech** using **IPv4**. This ease of switching providers creates a persistent βwhack-a-moleβ problem for defenders trying to block malicious infrastructure.
## Scope is the Soft Spot
The **LSHIY** campaign did not target a specific industry. Instead, it exploited organizations with gaps in their password controls or multi-factor authentication (MFA) policies.
**Huntress** analyzed 23 affected businesses. Eight had no MFA in place. Of the remaining 15, MFA did not apply to the attackerβs sign-in attempts because policies were either limited to certain applications or user groups, relied on trusted locations, or remained in report-only mode.

These findings underscore that even with MFA implemented, organizations must meticulously review the scope and enforcement of their Conditional Access policies. A policy might appear to require MFA but still contain exclusions for specific users, applications, or sign-in methods, creating exploitable vulnerabilities.
Fine-tuning conditional access without inadvertently locking out legitimate users is a complex challenge, and this difficulty is precisely what attackers continue to leverage.
## Shut Off the Tap
To mitigate these types of attacks, **Huntress** recommends several key strategies:
* **Enforce Strong Password Hygiene:** Consider adopting passwordless options where feasible.
* **Disable ROPC:** Remove **ROPC** (or applications that rely on it) from your system.
* **Restrict Azure CLI Access:** Limit **Azure CLI** access to only non-admin users who explicitly require it.
* **Prioritize by Credential Validity:** Instead of focusing solely on spray volume, prioritize incident response based on the validity of compromised credentials, as heavily sprayed tenants are often less compromised.
* **Require Universal MFA:** Mandate MFA for all users, all cloud applications, and all client application types, without exclusions. Block authentication methods that cannot satisfy MFA requirements, including the legacy **ROPC** grant.
* **Utilize Strong Conditional Access Settings:** Employ robust settings like `userStrongAuthClientAuthNRequired` to enforce strong authentication at the client level and block **ROPC**.
As **Mozeleski** aptly put it, βAppropriately configured and managed conditional access is a superpower.β
Attackers can switch providers and IP ranges faster than defenders can block them. The most effective defense is to ensure that a password alone cannot grant access. This involves maintaining strong passwords, restricting **Azure CLI** access to essential personnel, and applying comprehensive Conditional Access policies across all users, cloud applications, and client application types.
## Tradecraft Tuesday: No Products. No Pitches. Just Hacks.
Tradecraft Tuesday offers cybersecurity professionals in-depth analysis of emerging threat actors, attack vectors, and mitigation strategies. Weekly sessions provide technical walkthroughs, comprehensive breakdowns of malware trends, and up-to-date Indicators of Compromise (IOCs).
Participants benefit from:
* Detailed briefings on new threat campaigns and ransomware variants.
* Evidence-driven defense methodologies and remediation techniques.
* Direct interaction with **Huntress** analysts for incident response insights.
* Access to actionable threat intelligence and detection guidance.
[Register for Tradecraft Tuesday β](https://www.huntress.com/community-series/tradecraft-tuesday?utm_source=bleepingcomputer&utm_medium=article&utm_campaign=cy26-08-camp-brand-global-broad-all-x-x-f_proof&hnt=ns5oa1n4i3gx)
Advance your defensive posture with real-time intelligence and technical education specifically designed for those responsible for safeguarding their organizationβs environment.
*Sponsored and written by **Huntress Labs***.