Azure CLI Under Sustained IPv6 Password Spray; 78 Tenants Breached
Automated spray campaign from a single ASN burned through 81 million auth attempts in two weeks, hitting az login endpoints from an unusual IPv6 range.
Key points
- A password spray campaign targeting Azure CLI compromised at least 78 accounts across more than 81 million authentication attempts, per Huntress telemetry.
- All traffic sourced from a single IPv6 allocation, 2a0a:d683::/32, controlled by LSHIY LLC operating as AS32167.
- The campaign ran June 12 to June 26 and remains unattributed to any tracked threat actor.
- Tenants that extended or carved out of Microsoft's mandatory MFA rollout are the most exposed.
- Durable defence requires MFA on every identity that can reach
az, plus Conditional Access rules that treat CLI auth as a distinct risk surface.
Why spray a developer interface?
Azure CLI (az login) is an administrator and developer surface. Successful authentication there typically reaches service principals, subscription-level roles, or automation credentials, not just a mailbox. That shifts the blast radius from data theft toward cloud tenant takeover, resource hijacking for cryptomining, or lateral movement into CI/CD pipelines. Volume alone does not explain the targeting. The operator picked the highest-value door.
Should you worry about the IPv6 angle?
Most commodity spray operations rotate through residential proxy networks or bulletproof hosting to blend into normal authentication noise. Concentrating 81 million attempts inside a single /32 IPv6 allocation is either operationally careless or a deliberate bet that defenders are not blocking on IPv6 CIDRs. The approach worked long enough to breach 78 accounts before detection. Huntress has not tied the traffic to a named cluster. Treat this as unattributed, likely financially motivated activity at low-to-medium confidence pending corroborating infrastructure data from other vendors.
Password spray against Entra ID, formerly Azure AD, is not new tradecraft. Overlapping tactics have appeared in campaigns tracked by other vendors under names including Midnight Blizzard. Nothing in the published Huntress data links this campaign to state-sponsored activity.
We covered a related Microsoft identity exposure on 19 June when device code phishing was shown to sidestep MFA entirely, a reminder that credential-based attacks on Azure surfaces are running in parallel across multiple methods right now.
What should defenders check now?
Sign-in logs in Entra ID filtered for Azure CLI as the client app, with failed authentication from IPv6 sources outside your known range. Conditional Access policies that actually cover CLI logins: many tenants scope CA to browser sessions and leave programmatic authentication exposed. Any service principal or user account without MFA enforcement. Password spray only works where a second factor is absent. Legacy authentication protocols still enabled on the tenant.
Microsoft has been tightening defaults, including the mandatory MFA rollout for Azure sign-ins that began phasing in during late 2024. Tenants that opted for extensions or carve-outs are the likely victim pool.
What comes next?
Blocking the LSHIY range at the network edge is a stopgap. Pivoting to a fresh ASN takes hours. Huntress is continuing to publish indicators, and the source IPv6 space will likely shift once the current allocation gets widely blocklisted. The operator has already demonstrated patience across a two-week window, so assume the campaign continues under new infrastructure.
The underlying condition that made this possible, programmatic authentication surfaces left outside MFA and Conditional Access scope, is a tenant configuration problem, not a Microsoft flaw. Fix the configuration first.
