Skip to main content
Password Spraying Just Got 155x WorseAuthentication Methods
4 min readFor Bank Information Security Officers

Password Spraying Just Got 155x Worse

Huntress documented a 155x surge in password spraying attacks during the first half of 2026. This spike wasn't just due to brute-force attempts. Attackers combined credential reuse with a deprecated OAuth flow that bypasses Multi-Factor Authentication (MFA) entirely.

The most damaging campaign targeted Microsoft's Azure CLI through Resource Owner Password Credentials (ROPC), a legacy authentication method that OAuth 2.1 has officially deprecated. ROPC sends usernames and passwords directly to the token endpoint without triggering interactive MFA prompts. For attackers with valid credentials from previous breaches, this flow turns stale passwords into active sessions.

In mid-June, Huntress observed over 81 million login attempts and 78 account compromises in a two-week window. The traffic originated from IPv6 range 2a0a:d683::/32, controlled by hosting provider LSHIY LLC through its bring-your-own-IP (BYOIP) service.

What the Numbers Show

Huntress analyzed 23 affected organizations and found systematic gaps in authentication controls:

Eight organizations had no MFA configured. These environments relied solely on password strength to prevent unauthorized access.

Fifteen organizations had implemented MFA, but their Conditional Access Policies left exploitable gaps. Policies were scoped to specific applications, user groups, or trusted network locations. Others were in report-only mode, logging violations without blocking them.

No post-compromise activity was detected after successful logins. Rich Mozeleski, Staff Product Manager at Huntress, suspects the attacker validated credentials for resale rather than immediate exploitation.

The campaign didn't target a specific industry. It exploited organizations where authentication policy scope created openings.

Why ROPC Still Matters

ROPC was designed as a migration bridge for applications moving from direct authentication to OAuth without immediate refactoring. It's been deprecated because it bypasses the interactive flows that enable MFA, single sign-on, and phishing-resistant authentication.

Yet ROPC remains available in many Azure environments because disabling it can break legacy applications. Andrew "Spike" Brandt, Principal Threat Intelligence Incident Commander at Huntress, describes it accurately: "Even though we call it an authorization method, it's technically an impersonation method."

When an attacker submits a valid username and password through ROPC, the system issues a token without checking whether MFA should apply. Your Conditional Access Policy might require MFA for interactive logins, but if it doesn't explicitly block ROPC, the policy doesn't protect that flow.

IPv6 and BYOIP Complicate Blocking

The LSHIY campaign originated from an IPv6 range, then shifted to FranTech-hosted IPv6 addresses after LSHIY terminated the original activity. Subsequent attempts appeared from 3xK Tech using IPv4.

IPv6 provides attackers with an enormous address pool, making IP-based blocking impractical. BYOIP lets customers route traffic through a provider using IP ranges they control, which means attackers can switch providers faster than you can update block lists.

This infrastructure flexibility turns IP blocking into a reactive measure that consumes time without stopping the underlying threat.

What Your Team Should Do

Audit your Conditional Access Policy scope immediately. Don't assume that enabling MFA for "all users" covers every authentication path. Review:

  • Which client application types your policies apply to
  • Whether legacy authentication protocols are explicitly blocked
  • If any user groups or service accounts are excluded
  • Whether policies are in report-only mode or actively enforcing

Disable ROPC unless you have a documented business requirement. If you can't disable it organization-wide, restrict it to specific service accounts and monitor those accounts continuously. Block ROPC for all interactive user accounts.

Restrict Azure CLI access to administrators who need it. Non-admin users rarely require command-line access to Azure resources. Removing unnecessary access reduces your attack surface.

Enforce MFA across all users, all cloud applications, and all client application types with no exclusions. Use Conditional Access settings like userStrongAuthClientAuthNRequired to enforce strong authentication at the client level. This setting blocks authentication methods that can't satisfy MFA requirements, including ROPC.

Don't prioritize incident response by spray volume. The organizations receiving the highest number of login attempts weren't necessarily the most compromised. Prioritize by credential validity, focus on accounts where attackers successfully authenticated, not where they guessed the most.

Implement continuous password monitoring against breach databases. Attackers in this campaign reused credentials from previous breaches that were never rotated. If a user's password appears in a breach dump, force a reset immediately.

Consider passwordless authentication for high-privilege accounts. FIDO2 security keys and Windows Hello for Business eliminate password-based attacks entirely. Start with administrators and expand from there.

Why This Keeps Working

Fine-tuning Conditional Access without locking out legitimate users is difficult. You need to understand every authentication flow your applications use, identify which legacy protocols remain active, and test policy changes without disrupting production access.

That complexity is exactly why attackers target authentication policy gaps. They're betting that your MFA implementation covers the obvious interactive flows but misses the deprecated methods that still work.

As Mozeleski observed: "Appropriately configured and managed conditional access is a superpower." The inverse is also true, misconfigured Conditional Access creates blind spots that attackers exploit systematically.

Attackers will continue switching providers and IP ranges faster than you can block them. The effective defense isn't blocking infrastructure. It's ensuring that a password alone cannot grant access, regardless of which authentication flow an attacker attempts to use.

OAuth 2.1 FIDO2

You Might Also Like