Microsoft 365 Token-Replay Attacks Compromise 97 Accounts at 79 Organizations

Posted

If you sign in to Microsoft 365 at work, your password is no longer the only thing standing between your inbox and an intruder. Attackers are stealing the digital proof of login that your device receives after you have already cleared the extra security check, then replaying it from their own machines.

Attackers compromised 97 Microsoft 365 accounts across 79 organizations this way, The Hacker News reported on October 26, 2026. The underlying research comes from Huntress, published October 22, 2026, which tracked the campaign over ten weeks, from July 14 to September 22, 2026.

The scale is worth sitting with: more than 200,000 failed login attempts produced 497 successful sign-ins across the affected organizations. None of it depended on guessed passwords. A booby-trapped sign-in page sat between the victim and the real Microsoft login and passed everything through honestly, including the multi-factor authentication prompt, the extra step such as a code sent to your phone. What it kept was the session token, the digital key Microsoft issues to confirm that this person has proven who they are. Because that key is only handed out after the extra step, whoever holds it never has to clear that step again. Huntress calls the abuse token spraying: the same pattern as password spraying, but with stolen keys instead of guessed passwords.

The tokens came from more than one place, including fake sign-in pages, device-code phishing tricks and plain social engineering during a legitimate login. The replay traffic traced back to a single block of rented internet addresses tied to a German hosting company, 1337 Services GmbH.

Once inside, the attackers made sure they could stay. They registered at least 48 rogue devices, fake computers added to the victims’ Microsoft directories, which keep working as a way to request fresh keys until someone deletes them. In 19 organizations, the existing authentication methods were wiped and replaced with the attacker’s own within three hours of the first sign-in. In one case, a new authenticator labeled “iPhone 13” was active less than 51 minutes after the session was hijacked.

They also planted hidden inbox rules with names as short as “.”, “s” and “d”, set to delete or bury messages mentioning payroll, deposits or bonuses. In one mailbox a rule swallowed every incoming message, and the account was then used to send spam to hundreds of outside addresses before Microsoft’s own risk scoring flagged it. In at least one incident, the hijacked mailbox sent a payroll-related email to an outside contact.

Here is the part that should worry anyone who has ever fixed a breach by changing a password: a password reset alone does not evict the attacker. The rogue devices and the swapped authentication methods survive it. Huntress recommends revoking sessions and resetting the password together, then auditing registered devices, reviewing authentication methods, and checking inbox rules and unexpected business applications for anything unrecognized.

This is a different problem from the Microsoft 365 compromise Forkast covered on October 18, where attackers abused ConnectWise and SkyKick vendor credentials to reach tenants directly. That incident turned on stolen vendor access; this one turns on stolen session tokens, with no vendor access required.

Huntress’s other main recommendation is Conditional Access, Microsoft 365 rules that decide who can sign in, from which device and under what conditions. Its advice is blunt: require the extra authentication step, or block access entirely, for all users, all cloud apps and all client app types, without exceptions, and restrict the device-code flow attackers also abuse.

Trust & Security