Microsoft 365 Token-Replay Attacks Compromised 97 Accounts at 79 Organizations — Huntress Traced 200,000 Sign-In Attempts to One Hosting Range and 48 Rogue Entra Devices
Microsoft 365 Token-Replay Attacks Compromised 97 Accounts at 79 Organizations — Huntress Traced 200,000 Sign-In Attempts to One Hosting Range and 48 Rogue Entra Devices
Huntress researchers have documented a Microsoft 365 campaign that skipped password guessing entirely: an adversary-in-the-middle (AitM) relay captured sign-in sessions, and the attackers replayed the stolen tokens to walk into mailboxes. Between July 14 and September 22, 2026, the team detected 497 successful Microsoft 365 sign-in events across victim organizations from more than 200,000 login attempts — failures traced back to the 193.26.115[.]0/24 range — ultimately compromising 97 accounts at 79 organizations and registering 48 rogue Entra devices.
The mechanics are the part that matters for defenders. The campaign's AitM login page sits between the victim and legitimate Microsoft infrastructure, capturing entered credentials and MFA codes and relaying them to the real sign-in in real time. The prize is the access token Microsoft issues once sign-in completes: replayed from attacker infrastructure within minutes, it never has to bypass MFA a second time. Huntress codenamed the pattern "token spraying" — many stolen tokens replayed at scale across organizations, the way password spraying sprays passwords. "Rather than guessing passwords, the attacker replayed sign-in tokens stolen from victims," wrote researchers Andrea Hatcher, Susannah Matt, Matt Poto, and Andrew Schwartz. Tokens came from AitM relays behind fake sign-in pages, device-code phishing, and social engineering during legitimate logins.
Persistence followed a repeatable script. The attackers registered their own authenticator apps to keep completing MFA after stolen sessions expired: in 19 organizations, the victim's existing MFA methods were removed and a new method registered within three hours of the first sign-in — in one July 21 case, an app named "iPhone 13" was active less than 51 minutes after the session was hijacked. The 48 rogue devices served the same purpose: a registered machine gives an attacker a more durable way to request tokens than a stolen session, and it stays in the directory until someone deletes it. Then came the cleanup rules — hidden inbox rules with names like ".,", "sss", "iT", and "s" that deleted mail referencing payroll, deposit, and bonus or moved it into RSS Feeds and Conversation History. One mailbox marked every incoming message read and deleted, then sent outbound spam to hundreds of external recipients before Microsoft Entra ID Protection finally rated the account high risk.
The infrastructure story connects to a known corner of the criminal hosting market. The campaign was first observed from 193.26.115[.]221 — a Romanian IP that VirusTotal associates with the AsyncRAT remote access trojan — tied to German hosting provider 1337 Services GmbH. GreyNoise currently lists 29 addresses for the provider, ten flagged malicious and five suspicious, and the entity is linked to StarkRDP and rdp[.]sh, virtual-server rental platforms whose domains were seized in the January 2025 "Operation Talent" takedown and which are operating again, one rebranded as exy[.]sh.
What Should You Do?
- Act on suspected token compromise immediately — revoke active sessions and reset the password, then check what the attacker registered: new MFA methods, authenticator apps added within hours of unusual sign-ins, and unknown devices in the Entra directory.
- Audit Entra devices — a rogue device registration survives the session it was created for. Inventory registered devices, and treat any machine nobody can physically account for as an attacker foothold.
- Check mailboxes for hidden rules and outbound anomalies — rules named with punctuation strings, mail moved to obscure folders, and unexpected bulk outbound traffic are the operational fingerprints of this campaign.
- Close the workflow, not just the login — restrict the device-code flow with Conditional Access, and as Huntress recommends, require MFA (or block) for All Users, All Cloud Apps, and All Client App types, unconditionally.
The WAF Angle
A replayed token is a valid request from a valid identity with no attack payload in it — the exact class of traffic signature-based defenses sleep through. What catches it is behavioral: sign-in rate anomalies, impossible geography, a token used minutes after issuance from infrastructure that failed 200,000 other attempts. The pattern rhymes with the PeopleSoft session-hijacking campaign this site covered in September, where stolen authorized sessions turned a legitimate application into an exfiltration engine, and it is the account-level twin of the ConnectWise attack Microsoft attributed to Storm-0940: there the attacker abused application identities, here they steal user ones. The defense lesson is the same in both — put identity analytics and Conditional Access in front of the tenant, because the perimeter that matters is the token, not the packet.
