Microsoft 365 Token-Replay Campaign Compromised 97 Accounts at 79 Organizations

Security firm Huntress has disclosed a Microsoft 365 attack campaign that compromised 97 accounts across 79 organizations between July and September 2026 by stealing authentication tokens rather than guessing passwords. The technique, which Huntress calls "token spraying," let attackers bypass multi-factor authentication entirely once they captured a valid sign-in session.

The disclosure, reported October 26 by The Hacker News, details a campaign that researchers Andrea Hatcher, Susannah Matt, Matt Poto, and Andrew Schwartz tracked from July 14 to September 22, 2026. Over that period, the attackers attempted more than 200,000 logins from a single IP range, succeeded 497 times, and ultimately took control of 97 accounts.

How Adversary-in-the-Middle Phishing Works

Rather than attempting to steal a password directly, the attackers used an adversary-in-the-middle (AitM) login page that sits between the victim and the genuine Microsoft sign-in page. The fake page relays the victim's credentials and MFA code to Microsoft in real time, so from the victim's perspective the login appears to succeed normally. But the attacker's proxy also captures the resulting access token — effectively a "proof of login" — and can replay that token from an entirely different device within minutes, no password or MFA code required a second time.

This matters because most organizations' MFA defenses are designed to stop an attacker from authenticating as the victim, not to detect an attacker presenting a token that was legitimately issued moments earlier. A stolen session token looks, to Microsoft's systems, identical to the real user's own continued session.

What Happened After Access Was Gained

Once inside an account, the attackers moved quickly to lock out the legitimate owner's ability to respond. In at least 19 of the 79 affected organizations, attackers removed the victim's existing MFA methods and registered their own authenticator app within three hours of the initial token theft — in one case, in under 51 minutes. They also registered 48 rogue devices directly in the victim organizations' Entra ID (formerly Azure AD) directories, giving them a persistent, legitimate-looking way to request new tokens going forward.

Inside compromised mailboxes, the attackers created hidden inbox rules — often named with single characters like "s" or "d" to avoid drawing attention during a cursory review — that automatically deleted, hid, or filed away any email containing keywords related to payroll, direct deposit, or bonuses. At least one compromised mailbox was then used to send spam to hundreds of external recipients before Microsoft's Entra ID Protection flagged the account as high-risk and intervened.

Infrastructure Points to Known Criminal Hosting

The earliest activity in the campaign traced to the IP address 193.26.115.221, which security researchers have separately linked to the AsyncRAT remote access trojan. That IP belongs to a hosting provider called 1337 Services GmbH, which Huntress connects to StarkRDP and rdp.sh — remote desktop rental services that were the target of a January 2025 law enforcement operation. StarkRDP has since rebranded as exy.sh, suggesting the underlying infrastructure survived the earlier enforcement action under a new name.

What Organizations Should Do

Because this is account and token abuse rather than a software vulnerability, there is no patch to install. Huntress recommends organizations audit their Entra ID directories for unrecognized devices, review which MFA methods are registered on executive and finance-team accounts, and check mailboxes for unfamiliar inbox rules — particularly single-letter rule names. Organizations should also restrict Microsoft's device-code sign-in flow through Conditional Access policies, since device-code phishing was one of the vectors used to harvest tokens in this campaign, and consider requiring MFA unconditionally across all users, cloud apps, and client application types rather than relying on risk-based triggers that an already-stolen token can evade.