Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
A laptop login screen with a translucent duplicate session key drifting toward a shadowed server rack

Microsoft 365 Token Replay Bypassed MFA at 79 Firms

by

Microsoft 365 Token Replay Bypassed MFA at 79 Firms

In brief

  • Attackers replayed stolen Microsoft 365 session tokens at 79 organizations, logging in 497 times without a password. How token spraying works, and what stops it.
  • Between July 14 and September 22, 2026, Huntress recorded 497 successful Microsoft 365 sign-ins from replayed tokens, against more than 200,000 failed attempts traced to a single hosting block.
  • The attackers never needed a password and never broke MFA: victims completed MFA themselves, through a relay page, and the attacker kept the session token Microsoft issued afterwards.
  • Once inside, the attackers registered at least 48 rogue Entra devices, replaced victims’ MFA methods, and hid their activity with inbox rules — which is why a password reset alone does not end this attack.

Last verified: October 29, 2026.

What happened

Between July 14 and September 22, 2026, the security firm Huntress detected a campaign that compromised Microsoft 365 accounts at 79 organizations. Huntress published its findings on October 22, 2026, and the story was picked up independently by The Hacker News and other security press in the days that followed.

The numbers describe Huntress’s own customer base, not every Microsoft 365 tenant in the world, and that distinction matters. Across those 79 organizations, Huntress recorded 497 successful Microsoft 365 sign-in events from replayed tokens, set against more than 200,000 failed login attempts traced to the same infrastructure: the 193.26.115.0/24 address block belonging to German hosting provider 1337 Services GmbH. The campaign ultimately compromised 97 accounts and registered at least 48 rogue devices in Microsoft Entra ID. A count of 497 sign-in events is not the same as 497 separate compromised accounts; the same account can produce several successful sign-ins, and the 97-account figure is the better measure of how far the attackers got.

Neither Huntress nor Microsoft has publicly named the actor behind the campaign. Microsoft’s Entra ID Protection telemetry independently flagged several of the replay addresses as linked to nation-state actors or cybercrime groups, but that is as far as attribution has gone. The hosting provider, for its part, is a legitimate IP hosting business; the finding concerns servers used by the attackers, not evidence that the provider participated in the operation.

MFA worked. The session didn’t.

The most misleading way to describe this campaign is to say the attackers “bypassed MFA.” In the usual sense, they did not. They let MFA succeed, then stole what success produced.

The attack starts with an adversary-in-the-middle relay: a fake sign-in page that sits between the victim and Microsoft’s real authentication service. The victim types in their credentials and completes their MFA challenge, exactly as they normally would. The relay passes everything through to Microsoft, so from the victim’s side nothing looks wrong. But the relay keeps the “proof of login” token Microsoft issues once authentication completes. Because that token is minted after MFA, whoever holds it does not need to pass MFA again. The attacker replays it from their own machines, sometimes within minutes of capture, and Microsoft sees a sign-in that already carries MFA’s blessing.

Huntress calls the scale-up “token spraying”: the same pattern as password spraying, but with stolen tokens instead of guessed passwords. Tokens were replayed at volume across many organizations, which is why more than 200,000 failed attempts sit alongside the 497 successes. Most stolen tokens did not work — they had expired, been revoked, or belonged to accounts the attacker could not use — but at that volume, the ones that worked were enough.

Tokens did not all come from the relay pages. Huntress says the campaign also used device-code phishing and social engineering during legitimate login processes. Device-code phishing tricks a victim into entering a code on a real Microsoft page, which authorizes a device the attacker controls. The mechanism differs, but the prize is the same: a session that already passed authentication.

What the attackers did once they were in

Getting in was only the first step. Once inside a mailbox, the attackers moved quickly to make their access survive the obvious response.

First, they registered their own devices in Entra ID — at least 48 across the campaign — giving them a persistent foothold that does not depend on any single stolen token. Second, they replaced victims’ MFA methods, often within hours, so that future sign-ins could be satisfied by an authenticator app the attacker controlled. Third, they created inbox rules to hide their activity, diverting or deleting messages that might alert the victim — the classic staging for business email compromise, where a hijacked mailbox is used to send convincing messages to colleagues, customers, or finance contacts. In at least one incident, Huntress reports, a hijacked mailbox sent a payroll message to an outside contact.

That sequence is the reason this campaign matters beyond its own victim count. A stolen session is temporary; a registered device and a replaced MFA method are not. Anyone responding to a suspected token theft who only resets the password has addressed the least durable part of the intrusion.

Why a password reset alone fails

This is the point most coverage buries, and it is the point that decides whether a victim actually recovers.

Resetting a password does not revoke a session token that is already issued, does not remove a device the attacker registered in Entra, does not restore the MFA methods the attacker replaced, and does not delete the inbox rules the attacker created. Each of those survives a password change on its own. A victim who resets their password and stops there may still have an attacker device sitting in their tenant, an attacker authenticator app ready to satisfy the next MFA prompt, and a rule quietly hiding the evidence.

The correct cleanup order, as Huntress’s response guidance and independent write-ups agree, is: revoke the account’s sessions and reset the password together; remove any rogue Entra devices; remove MFA methods the victim does not recognize and re-register legitimate ones; delete unfamiliar inbox rules; and review unfamiliar app consents and delegated access. Only after that cleanup should the account be treated as recovered. For administrators, the same review extends to managed service provider accounts, where one technician identity can reach many customer tenants — a single compromised MSP identity multiplies the blast radius of exactly this kind of attack.

What actually stops a stolen session

For individual users, the defenses are unglamorous and mostly about not handing the token over in the first place. Treat any sign-in page reached from an email link with suspicion, and navigate to Microsoft 365 directly instead. Be wary of device-code prompts you did not initiate: a code you are asked to enter on a Microsoft page, for a sign-in you did not start, is a device-code phishing attempt until proven otherwise. And if your organization offers phishing-resistant MFA — passkeys or hardware security keys — use it: these methods bind the authentication to the legitimate site, so a relay page cannot capture a reusable proof of login in the same way.

For administrators, Huntress’s findings point to Conditional Access as the control that matters most. A policy that ties mail access to a managed or compliant device, or that requires re-authentication from unfamiliar locations and hosting networks, makes a token replayed from a rented server block far harder to use. Microsoft’s Token Protection feature, which binds tokens to a device for the applications it covers, is designed for exactly this threat, and administrators should pilot it in report-only mode before enforcing it. Blocking the device-code flow where it is not needed, and requiring MFA to register new devices, close two of the doors this campaign walked through. None of these controls is a single fix; together, they turn a stolen token from an open door into a credential that only works on the victim’s own machine.

Monitoring completes the picture. Sign-in logs should be searched for the pattern this campaign leaves behind: successful sign-ins from hosting-provider address ranges, OAuth token requests from unusual user agents, new device registrations, MFA method changes, and inbox-rule creation in quick succession. Any one of those events can have an innocent explanation. Several together, on the same account, within hours, is the signature of this attack.

What to watch next

Three questions remain open, and each is worth watching rather than assuming. First, attribution: neither Huntress nor Microsoft has named the actor, and the campaign’s infrastructure — a rented hosting block — is the kind of thing that can be re-rented. Second, scope: the 79 organizations are the ones Huntress could see; the technique itself works against any Microsoft 365 tenant whose Conditional Access does not cover it, so other victims may surface in other vendors’ reporting. Third, response: Microsoft has not, as of this writing, announced a tenant-wide change in response to this campaign, so the defenses above remain administrator-configured rather than default-on. If that changes, or if a named actor emerges, this article will be updated.

The broader lesson is one that applies well beyond Microsoft 365. Multi-factor authentication is a strong control, but it authenticates a moment, not a session. Everything that happens after that moment — the token, the device registration, the MFA method itself — is part of the security boundary too. The attackers in this campaign understood that boundary better than many of their victims did. They did not defeat MFA. They waited for it to finish, and took what it left behind.

Related reading

Sources

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment