LSHIY: Large-Scale Password Spraying Abusing ROPC and IPv6

Posted on by — No Comments ↓

LSHIY: Large-Scale Password Spraying Abusing ROPC and IPv6

1. Basic Information

  • Article Title: How the LSHIY Password-Spraying Attack Abuses OAuth’s ROPC Grant
  • Publisher: Huntress
  • Publish Date: 2026-08-19
  • Severity: High
  • Original Source: Huntress
  • Related Sources: BleepingComputer
  • Related Entities: LSHIY campaign, Microsoft Azure CLI, Entra ID, OAuth ROPC, Conditional Access, IPv6 BYOIP

2. Executive Summary

Attackers tried a small number of reused passwords against many accounts. They got tokens from the old ROPC flow, which does not use MFA. This compromised organizations even if they had MFA enabled, because the policy had coverage gaps.

3. Attack Flow

  1. The attacker collects valid usernames and password guesses from public info and data leaks.
  2. The attacker tries one password against many accounts slowly to avoid account lockouts.
  3. The attacker sends usernames and passwords directly to the tenant’s /token endpoint using ROPC for Azure CLI.
  4. If the combination is correct, the attacker gets a user-delegated token without interactive MFA.
  5. The attacker uses BYOIP (Bring Your Own IP) and a large IPv6 space to change sources and weaken IP-based detection.
  6. Over two weeks, the system saw over 81 million attempts and 78 compromised accounts.
  7. No actions were observed after success. This suggests credential validation or resale, but it is not confirmed.

4. Attacker Infrastructure and Location

  • The attacker connects to Entra’s token endpoint from external infrastructure such as LSHIY LLC, FranTech, 3xK Tech, and Tor.
  • The authentication happens completely in the cloud. No malware needs to run on the victim device.

5. Visibility for Victims and Administrators

  • Users do not see MFA prompts, so they rarely notice successful logins.
  • Administrators see a small number of successes hidden among many failures, using Azure CLI/ROPC from wide IPv6 sources.
  • Attacks succeed if MFA policies have exclusions for certain users, apps, or client types, or if they are in report-only mode.

6. Success and Failure Conditions

Success Conditions

  • Users have valid, reused passwords.
  • ROPC or apps that use ROPC are allowed.
  • Conditional Access does not cover all users, all cloud apps, and all client types.
  • Success detection relies only on total trial volume.

Failure Conditions

  • Disable ROPC and block authentication flows that cannot satisfy MFA.
  • Limit Azure CLI users to the minimum necessary and use passwordless authentication.
  • Detect based on credential validity and successful authentication rather than source IPs.

7. What Happens on Success

  • The system issues a user-delegated token to the attacker. A cloud session starts using only a password.
  • Usually, this leads to email compromise, lateral movement, and data theft. However, this campaign showed no post-authentication actions.

8. Observable Logs

Email

  • No post-success email actions were confirmed. Check Exchange audits for suspicious searches, forwarding, and sending.

Proxy / SWG / DNS

  • Because traffic does not go through victim devices, internal proxies likely will not show authentication attempts.

Endpoint / EDR

  • Initial compromise does not need device execution. SOCs must distinguish this from legitimate user Azure CLI usage.

Identity / IdP

  • Azure CLI, ROPC, password grant, non-interactive sign-ins, and many failures with a few successes at /token.
  • Attempts from ranges like 2a0a:d683::/32, 2605:6400::/32, and 2605:6404::/32.
  • Reasons why MFA requirements were not met, and Conditional Access report-only or exclusion settings.

SaaS / Cloud

  • M365/Azure operations using successful tokens, impossible travel for the same user, and access to multiple resources in a short time.

Network

  • IdP logs are the primary evidence, rather than perimeter logs. Aggregation by IPv6 prefix is necessary.

9. Attack Success Determination

  • Attack Attempted (Success Unconfirmed): Only ROPC failures are visible.
  • User Action Confirmed: No user action is required.
  • Initial Execution Confirmed: Not applicable for initial device execution in this chain.
  • Malware Execution or Auth Success Confirmed: ROPC success and token issuance are confirmed.
  • Data Theft or Session Compromise Confirmed: SaaS access using a successful token is confirmed.
  • Follow-on Compromise Confirmed: Email rules, data retrieval, permission changes, and lateral movement are confirmed. Not observed in this campaign.

10. Investigation Playbook

Trigger

  • Abnormal Azure CLI/ROPC attempts, spraying from IPv6 prefixes, and successful non-interactive authentication.

Initial Checks

  1. Identify successful users and issued tokens before counting failures.
  2. Check why Conditional Access did not apply.
  3. Check if the same credentials were used in other tenants or apps.

Device

  • Check the Azure CLI execution history on legitimate user devices to separate it from external authentication.

Auth and Cloud

  • Revoke tokens, change passwords, cancel sessions, and audit email, OneDrive, and Azure operations.

Subsequent Operations

  • Check for email forwarding, OAuth consent, app registrations, data retrieval, and permission changes.

Containment

  • Block ROPC and non-compliant clients, limit Azure CLI usage, and remove Conditional Access exclusions.

Determination Categories

  • Spray Attempted / Credential Validated / Token Issued / Cloud Session Used / Follow-on Activity Confirmed

11. Defense and Detection Ideas

Single Events

  • Prioritize ROPC success, Azure CLI authentication without MFA, and authentications allowed by report-only policies.

Time-Series Correlation

  • Correlate many failures -> success for the same user -> token issued -> SaaS access.

Threat Hunting Perspective

  • Aggregate IPv6 addresses by /32 or similar prefixes to track the same app ID, user, and auth flow even if the source changes.

Log Gaps

  • Non-interactive sign-ins, Conditional Access evaluation reasons, client apps, and token destination records are often missing.

Priority Actions

  1. Disable ROPC.
  2. Enforce MFA or block access for all users, all apps, and all clients.
  3. Restrict Azure CLI usage.
  4. Implement passwordless auth and ban leaked passwords.
  5. Prioritize successful authentications in SOC alerts.

12. Facts / Inference / Hypothesis

Facts

  • Huntress observed over 81 million attempts and 78 compromised accounts over two weeks.
  • Out of 23 companies, 8 did not use MFA. The remaining 15 had gaps in their MFA coverage.
  • No additional operations were observed after the attacks.

Inference

  • Because IPv6/BYOIP makes IP blocks short-lived, correlating auth flows, apps, and success results is critical.
  • Organizations must verify that MFA applies to all paths, including ROPC, rather than just checking if MFA is turned on.

Hypothesis

  • The lack of post-authentication actions matches the goal of credential validation and resale, but this is not confirmed.

13. MITRE ATT&CK Mapping

  • T1110.003 Password Spraying (High): Trying a few passwords against many accounts.
  • T1078 Valid Accounts (High): ROPC authentication using valid credentials.
  • T1528 Steal Application Access Token (Medium): Not a theft, but unauthorized issuance. It is similar because the attacker gets a token.
  • T1090 Proxy (Medium): Using BYOIP, Tor, and multiple providers to switch sources.
  • T1539 Steal Web Session Cookie (Low): Cookie theft is not confirmed. This is a supplementary mapping for token use.

14. Unknowns and Additional Investigation

  • Who is the attacker? What is the geographic distribution of target tenants? What are the scopes and lifespans of the obtained tokens? Were there truly no post-authentication actions?

15. Impact on SOCs

This issue directly affects global organizations and SOCs that use M365/Entra and Azure CLI. SOCs should look not only at the high volume of failures, but also at low-frequency successes, reasons for missing MFA, ROPC usage, and IPv6 prefixes. Having a policy on paper does not mean defense is working.

16. Summary by Role

For SOCs

Prioritize tracking ROPC successes and cloud operations after token issuance, rather than just counting failure volumes.

For Administrators

Stop ROPC and apply Conditional Access to all users, all apps, and all client types.

For Users

Avoid password reuse. There are paths where attackers can compromise accounts using only leaked passwords, even without MFA prompts.

Leave a Reply