Between June 12 and June 26, an automated attacker made more than 81 million login attempts against Microsoft 365 accounts monitored by the security firm Huntress. The traffic came from IPv6 address space registered to an infrastructure provider called LSHIY LLC, and the target was not the Microsoft 365 web login page but the Azure command line interface. By the time the campaign was documented, it had compromised at least 78 accounts across 64 organizations, with daily compromises spiking from two or three a day to 30 accounts in a single day on June 22.
What makes this campaign worth paying attention to is not the volume. Credential stuffing at scale is not new. It is the mechanism that let so many of those 78 accounts fall despite having multi-factor authentication turned on.
The Flow That Conditional Access Forgot
The attackers authenticated using a legacy OAuth mechanism called Resource Owner Password Credentials, or ROPC. ROPC lets an application exchange a username and password directly for an access token at Microsoft’s /token endpoint, without ever routing the user through an interactive sign-in page. That design predates modern authentication and it was never built to support MFA prompts, security keys, or single sign-on redirects. If a valid username and password pair reaches that endpoint, ROPC hands back a token. There is no prompt to intercept, because there is no interactive session to prompt.
Huntress found that many of the compromised organizations had Conditional Access policies requiring MFA already in place. The policies simply were not written to cover this authentication flow. A Conditional Access policy that requires MFA for browser sign-ins but does not explicitly block or restrict legacy protocols leaves ROPC as an open side door, and attackers who already know this walk straight through it. Microsoft’s own guidance recommends disabling legacy authentication and, for any policy meant to be comprehensive, applying it to all users, all cloud apps, and all client app types rather than scoping it narrowly.
The passwords themselves came from breach combo lists. Huntress noted that targeting was not selective by industry or company size, it was selective by password prevalence. If a credential pair from an old breach still worked, LSHIY’s infrastructure eventually tried it.
Why This Matters More Than a Typical Credential Stuffing Story
A compromised Microsoft 365 account is not just a mailbox an attacker can read. It is a fully authenticated sending identity. Mail sent from that account passes SPF because it originates from Microsoft’s own infrastructure. It passes DKIM because Microsoft signs it with the tenant’s real key. It passes DMARC because both of those checks pass and they align with the visible From address. None of the three protocols that most domain owners rely on to stop spoofing were designed to ask whether the person typing at the keyboard is actually authorized to be there. They were designed to confirm the message came from where it claims to come from, and after a successful ROPC token grant, it genuinely did.
That is the gap this campaign exploits at scale. Once an account is compromised through password spray, everything downstream, BEC messages to finance teams, invoice fraud sent to real vendors, internal phishing that uses a colleague’s actual signature, arrives with a clean authentication result. Every dollar figure in every fraud report that traces back to a hijacked mailbox, including the billions the FBI’s IC3 report attributed to BEC last year, starts with an authentication event exactly like this one succeeding.
Closing the Actual Door
The fix for this specific campaign is not a DMARC change. It is auditing Conditional Access configurations to confirm ROPC and other legacy authentication flows are blocked outright, not merely deprioritized behind an MFA prompt that ROPC never has to answer. Microsoft’s userStrongAuthClientAuthNRequired setting enforces strong authentication at the client level in a way that stops ROPC before a token is ever issued. Rotating passwords that appear in breach data, before an attacker gets there first, closes the other half of the gap.
None of that replaces DMARC. It complements it. DMARC enforcement stops someone from sending mail that merely claims to be from your domain without ever touching your infrastructure. It cannot see, and was never meant to see, a message sent by someone who is technically inside your tenant because a password from a 2019 breach still worked and a Conditional Access policy had a gap nobody had tested. Continuous monitoring of your DMARC aggregate and forensic reports is one of the few places that unusual sending behavior from an account that is legitimately yours starts to become visible, even if the protocol itself cannot block it.
The Takeaway
81 million login attempts is a number large enough to sound abstract. 78 successful compromises, each one a fully authenticated Microsoft 365 identity now available to send mail that will pass every check your recipients’ filters run, is not abstract at all. If your organization has not tested whether its Conditional Access policies actually block ROPC and other legacy flows, this campaign is the reason to check this week, not the next time you get around to it.
Authentication protocols can only verify what they were designed to check. When an account is compromised, not spoofed, visibility into your outbound mail is what catches it. Sign up for free to Excello Mail and monitor your domain’s DMARC reports continuously, so a compromised account does not get a free pass just because the password was real.