81 million attempts, 78 accounts: ROPC is where "we have MFA" stops being true

A password-spraying campaign tracked as LSHIY ran more than 81 million authentication attempts over two weeks against Microsoft Entra ID tenants and came away with 78 compromised accounts, according to a Huntress writeup dated 19 August 2026 and summarised on dev.to ^[1][3]. The attempts went straight to the tenant /token endpoint using OAuth's resource owner password credentials grant against the Azure CLI client, which returns a user-delegated token without an interactive MFA prompt ^[4].

That is the whole story, and it is worth being precise about it. The organisations that lost accounts had MFA enabled ^[2]. What they did not have was MFA that applied everywhere: Huntress lists the preconditions as valid reused passwords, ROPC or ROPC-using apps permitted, and Conditional Access that does not cover all users, all cloud apps, and all client types ^[11]. Exclusions for particular users, apps or client types, or a policy still sitting in report-only mode, are enough ^[10]. A second factor you have deployed but not enforced on a legacy grant flow is a second factor the attacker never meets.

The arithmetic explains why this went unnoticed. Averaged over fourteen days, 81 million attempts is roughly 5.8 million a day ^[19], and 78 successes works out to about one per 1.04 million tries ^[18]. The operator sprayed one password across many accounts slowly enough to stay under lockout thresholds ^[16], so what an administrator sees is a handful of successes buried in an enormous pile of failures ^[17]. Source-based filtering was deliberately degraded: the campaign used bring-your-own-IP and a large IPv6 space to rotate origins ^[5], with attempts observed from 2a0a:d683::/32, 2605:6400::/32 and 2605:6404::/32 ^[6] and from infrastructure including LSHIY LLC, FranTech, 3xK Tech and Tor ^[7].

There is nothing to find on the endpoint. Authentication happens entirely in the cloud, no code runs on the victim device, and because the traffic never crosses the victim's network, internal proxies are unlikely to show the attempts at all ^[8]. The user gets no MFA prompt, so a successful login is not something they are likely to report ^[9]. Huntress says identity provider logs are the primary evidence here rather than perimeter logs, and that aggregation by IPv6 prefix is necessary to see the shape of it ^[14].

The remediation list is short and unglamorous: disable ROPC and block authentication flows that cannot satisfy MFA, cut the Azure CLI user population to the minimum and move it to passwordless, and detect on credential validity and successful authentication rather than on source IPs ^[13]. Investigators are told to identify the successful users and issued tokens before counting failures, establish why Conditional Access did not apply, check whether the same credentials work in other tenants or apps, compare against Azure CLI history on legitimate devices, then revoke tokens, reset passwords, kill sessions and audit mail, OneDrive and Azure operations ^[15].

What to watch is the second half of the campaign that has not happened yet. No post-authentication activity was observed, which Huntress reads as credential validation or resale, unconfirmed ^[12]. Spraying of this type normally precedes mailbox compromise, lateral movement and data theft ^[20]; if those 78 sessions are inventory rather than an endpoint, the buyers arrive later. Exchange audit logs for unusual searches, forwarding rules and sends are the place that shows up first ^[21].