81 Million Logins, One Skipped Checkbox: Inside the LSHIY ROPC Campaign (Pipeline Test)

Eight of the 64 breached organizations in the LSHIY campaign had no MFA policy at all. That's the unsurprising part. The genuinely uncomfortable statistic is the other 56 — businesses that had Conditional Access Policies enabled, checked the MFA box, and got compromised anyway, because the box they checked didn't cover the door the attacker actually walked through.

What actually happened

Between June 12 and June 26, 2026, Huntress tracked a password-and-token spray campaign against Microsoft 365 and Azure CLI sign-ins. The scale is the headline number: more than 81 million login attempts in a two-week window, traced mostly to an IPv6 range tied to a provider called LSHIY LLC. But volume isn't what makes this campaign worth a teardown — plenty of spray campaigns generate huge attempt counts and go nowhere. What matters is the compromise count behind that volume: 78 Microsoft accounts across 64 organizations, with a sharp escalation on June 22 when 30 identities across 23 businesses fell in a single day.

The attackers weren't guessing randomly. They were replaying username-password pairs pulled from old breach combo lists — credentials exposed years ago and never rotated — and testing them not through the normal browser sign-in page, but through Azure CLI, using an OAuth grant type called Resource Owner Password Credentials, or ROPC.

Why ROPC is the quiet part of this story

ROPC is old and, on paper, already on its way out — it's deprecated in OAuth 2.1. The flow lets an application send a raw username and password straight to a tenant's token endpoint and get back a valid access token, no browser redirect, no interactive prompt, no MFA challenge. It was built for a pre-mobile-app, pre-zero-trust era when that made sense. It should not still be a live door into most 2026 Microsoft 365 tenants. It still is, because Conditional Access policies enforce their checks at the authorization endpoint — the interactive sign-in path — and ROPC never goes near it.

That's the trick. Conditional Access isn't broken as a concept. It's scoped wrong in practice. Huntress found the same handful of misconfiguration patterns across the affected tenants: MFA enforced only for specific apps rather than "All Cloud Apps," MFA required only for admin groups, MFA triggered only from untrusted locations (so a login that happens to route through a trusted IP range sails through unchallenged), and policies quietly sitting in report-only mode — logging what they would have blocked, blocking nothing. Every one of those is a policy that looks correct in the admin console and does nothing against ROPC.

The gap between "we have MFA" and "MFA covers this"

I've reviewed enough tenant configurations to know this isn't a rare mistake — it's close to a default one. Most Conditional Access rollouts start narrow: MFA for admins first, then maybe finance, then "we'll expand coverage later." Later often doesn't come, or comes only for the interactive login surface everyone actually watches during rollout testing. Legacy and non-interactive auth flows — ROPC, and its cousins in device code and refresh token abuse — get left alone because nobody's user experience depends on them, which also means nobody's monitoring dashboard highlights them.

That's precisely the blind spot this campaign monetized. The fix Huntress and Microsoft both point to is real and worth doing immediately if you haven't: scope Conditional Access to All Users, All Cloud Apps, and All Client App types, and turn on the userStrongAuthClientAuthNRequired setting, which enforces strong auth at the client level and blocks ROPC outright regardless of app-level policy gaps. If Azure CLI isn't something most of your users need, restrict it to the accounts that do.

Where this fits the malware-free pattern

Notice what's absent from this whole campaign: no malware, no exploit, no zero-day. Just a stale password and a token endpoint that never asked for anything more. That's consistent with what we flagged in our breakdown of CrowdStrike's 2026 breakout-time data — the overwhelming majority of 2025's intrusions were malware-free, built entirely on valid or semi-valid credentials moving through trusted, under-monitored paths. ROPC is a textbook example of a "trusted path" that's actually a monitoring gap wearing a badge.

We've also written about how Kerberoasting abuses a legitimate Active Directory feature rather than a vulnerability, and how device-code phishing turns a legitimate OAuth flow into a token-theft vector. ROPC joins that list: not a bug, a feature nobody finished locking down.

This wasn't an isolated spike

The LSHIY campaign is a symptom, not the disease. Huntress reports that credential spray volume across its customer base has risen more than 155x over the past six months, with a current mean of roughly 1,964 failed login attempts per protected tenant, per month. That's not one aggressive actor — it's a baseline shift in how opportunistic credential abuse operates now. Target selection in this campaign, per Huntress, was driven almost entirely by password prevalence in existing combo lists rather than industry or company size, which is its own useful data point: nobody gets to sit this one out because they're "not an interesting target." If your users reused a password that's floated around in a breach dump anywhere in the last several years, you're in the target pool by default.

The daily compromise pattern also tells a story worth sitting with. Two to four accounts a day for over a week isn't loud enough to trip most anomaly-detection thresholds tuned for burst behavior — it looks like background noise until you're specifically looking for it. The June 22 spike to 30 accounts in a single day is the kind of event a SOC actually notices. Everything before that date was, from a detection standpoint, already a breach in progress that simply wasn't loud enough to page anyone. That's the same lesson as almost every malware-free intrusion: slow, credential-based abuse blends into normal telemetry precisely because it never does anything a signature or a volume threshold is built to catch.

A log-review checklist, not just a policy checklist

Fixing Conditional Access scope is necessary but not sufficient, because it only protects you going forward — it does nothing to tell you whether this specific campaign already touched your tenant during the window it was active. Pull Entra ID sign-in logs and look specifically for: non-interactive sign-ins tagged with the ROPC grant type; any successful authentication from 2a0a:d683::/32 or ASN 32167; successful sign-ins immediately preceded by a burst of failures from the same source, a classic spray fingerprint; and any Azure CLI authentication from an account that doesn't normally use Azure CLI at all. That last one is worth automating as a standing rule, not a one-time query — a finance or HR account authenticating via Azure CLI is a stronger anomaly signal than most behavioral baselines will ever produce on their own.

Where a honeytoken would have fired before Conditional Access even mattered

Here's the angle Conditional Access hardening alone doesn't solve: policy misconfiguration is a moving target. You close the ROPC gap this quarter, and six months from now a new app registration, a new legacy client, or a forgotten exception reopens a similar hole somewhere else in the tenant. Configuration review catches what you remember to review. It doesn't catch what you forgot existed.

This is exactly the kind of gap Mine2's honeytoken deployments are built to sit inside. Two placements would have mattered here:

• Canary credentials seeded into the same combo-list ecosystem attackers draw from. If a decoy username-password pair — one that maps to a fake but monitored Microsoft 365 identity — ends up in the same breach dumps and paste sites this campaign's password lists came from, any successful authentication against it, through any flow including ROPC, is a guaranteed true positive. The credential has no legitimate owner, so there's no baseline to tune and no false-positive rate to manage.
• A decoy service principal with a slightly-too-appealing name, sitting in Entra ID with permissions that look valuable and are never legitimately used. A ROPC-based spray campaign testing credential pairs against a tenant will eventually touch enumerable identities; a canary identity designed to be found produces the same one-shot, high-fidelity alert a real compromised account would generate — except a week before the real one gets found, not a week after.

Neither of those requires you to have perfectly scoped every Conditional Access policy in your tenant first. That's the point. Deception doesn't compete with getting your CAP configuration right — it's the backstop for the gap between "we think we covered this" and "we actually covered this," which the LSHIY campaign proved is a wider gap than most security teams assume.

What to check this week

If you run Microsoft 365 or Entra ID: pull sign-in logs and filter for non-interactive sign-ins and ROPC grant-type authentications, specifically around June 12–26, and specifically from AS32167 or the 2a0a:d683::/32 range. Confirm your Conditional Access policies are scoped to All Users, All Cloud Apps, and All Client App types — not a subset that felt sufficient at rollout time. Then ask the harder question: what other legacy or non-interactive auth path in your tenant has never been tested against your current policy set? That's the one worth planting a canary in front of, because policy review will eventually find the ones you remember. It won't find the ones you don't.

See how Mine2 deploys identity-layer deception across Microsoft 365, Active Directory, and cloud environments to catch credential abuse the moment it happens — not the audit cycle after.