Microsoft 365 Token Replay: Why MFA Didn't Stop It
By Yonatan Hoorizadeh — CISSP, CISM, CRISC, AAISM
Published By: Purple Shield Security
Published: October 26, 2026
Last updated: October 26, 2026
A ten-week token replay campaign took over Microsoft 365 email accounts at 79 organizations without ever needing a password. Attackers stole the session token Microsoft issues after multi-factor authentication (MFA) succeeds, then reused it from rented servers. MFA worked as designed. The missing control was Conditional Access, plus fast removal of attacker persistence.
What happened in the Microsoft 365 token replay campaign?
Between July 14 and September 22, 2026, the security firm Huntress tracked an attacker who replayed stolen Microsoft 365 sign-in tokens to take over business email accounts. Huntress responded to related incidents at 79 organizations, logging 497 successful sign-ins against more than 200,000 failed attempts. The Hacker News, reporting on the research, counted 97 compromised accounts.
The replay traffic came from a block of IP addresses belonging to 1337 Services GmbH, a hosting provider incorporated in Hamburg, Germany. Microsoft Entra ID Protection, the identity risk engine built into Microsoft's cloud directory, independently flagged several of those addresses as linked to known threat activity.
Huntress researchers summarized the core problem plainly: "The Microsoft accounts were compromised without the attacker ever needing a password." The victims completed their own MFA prompts. The attacker simply collected what those prompts produced.
Speed was a defining feature of the campaign. According to Huntress, a hijacked session appeared on attacker infrastructure 12 minutes after the victim reached the MFA prompt in a July 21 incident, and only four minutes after in a September 22 incident. The operator also rotated through six IP addresses across four phases, so blocking any single address stopped one phase at most.
How does a token replay attack get around MFA?
A token replay attack gets around MFA by stealing what MFA produces instead of the password MFA protects. After a user signs in and approves the MFA prompt, Microsoft issues a session token that proves the login already happened. Anyone holding that token can present it from their own machine and is treated as the signed-in user, with no second MFA prompt.
In this campaign, most tokens came from adversary-in-the-middle (AiTM) phishing. An AiTM relay is a fake sign-in page that sits between the victim and Microsoft, passing the real login screen and real MFA prompt through to the user while keeping a copy of the token Microsoft returns. Nothing looks wrong to the victim because every screen they see is genuine.
Huntress also observed device-code phishing. Device-code phishing tricks a user into typing a short code on Microsoft's legitimate device login page, which unknowingly approves a session the attacker started on their own device. Some tokens were also gathered through social engineering during an ordinary login.
Huntress calls the bulk reuse of these stolen tokens "token spraying." Token spraying follows the same pattern as password spraying, where an attacker tries one guess against many accounts, except the attacker is replaying already-valid sessions across many organizations at once.
What did the attacker do after getting into Microsoft 365?
Once inside a Microsoft 365 account, the attacker focused on keeping access after the stolen token expired and on setting up business email compromise (BEC), the fraud pattern where a trusted mailbox is used to redirect payments. Huntress documented rogue device registrations, swapped MFA methods, and hidden inbox rules across the affected organizations.
Rogue devices. Huntress found at least 48 fake computers registered in victims' Microsoft Entra ID directories, each named DESKTOP- followed by eight hexadecimal characters. A registered device gives the attacker a more durable way to request new tokens, and it stays in the directory until an administrator deletes it.
Swapped MFA methods. In 19 organizations, the victim's existing MFA methods were wiped and a new authenticator registered within three hours of the first sign-in from campaign infrastructure, according to Huntress. An attacker-controlled authenticator survives a password reset unless someone audits the account and removes it.
Hidden inbox rules. The attacker created mailbox rules with forgettable names such as a single period or "sss" that deleted mail or moved it into rarely opened folders like RSS Feeds and Conversation History. In one Huntress case, a rule caught any message mentioning payroll, direct deposit, bank, or bonus, and a second rule hid all mail from the company's outside accountant while the attacker sent that accountant a payroll-related email from the real employee's mailbox.
Why should a CFO or business owner care about token replay?
Token replay matters to finance and ownership because the end goal is money movement and data access, not a technical foothold. A hijacked Microsoft 365 mailbox lets an attacker request payroll changes, reroute vendor payments, and read sensitive client correspondence while hidden rules stop the real employee from noticing anything.
The payroll case Huntress described is the classic BEC setup. The attacker does not need to fool the accountant with a spoofed domain, because the request comes from the genuine employee's genuine mailbox. Any warning reply from the accountant is filtered away before the employee sees it.
There is also a cyber insurance angle that most coverage of this story skips. Insurance applications routinely ask whether MFA is enforced on email, and most mid-market firms answer yes. If a funds-transfer loss follows a takeover where MFA was enabled but session controls were not, expect the claim conversation to turn to what controls were actually in place. Leadership should know today how their policy treats social engineering and funds-transfer fraud, including any sublimits.
For regulated firms, a mailbox takeover can also become a reportable event. Healthcare, legal, and financial services inboxes routinely hold protected health information, privileged communications, or customer financial data. Under the HIPAA Breach Notification Rule, unauthorized access to protected health information is presumed to be a breach unless a documented risk assessment shows a low probability of compromise, so a quiet email takeover can trigger a formal notification decision.
What does Conditional Access do that MFA alone cannot?
Conditional Access is Microsoft Entra ID's policy engine that decides whether a sign-in is allowed based on who is signing in, from where, from what device, and to which app. MFA verifies a person once at login. Conditional Access can refuse a session that presents valid credentials from the wrong context, which is exactly the gap token replay exploits.
The campaign produced a rare natural experiment. During a four-day burst beginning September 11, a single replay address completed 303 successful sign-ins across 29 organizations, according to Huntress. The same address logged 1,052 blocked sign-ins, and every one of those blocks came from just four organizations whose Conditional Access policies refused the attempts.
Huntress recommends that organizations require MFA, or block access, for all users, all cloud apps, and all client app types, without exceptions. The exceptions are where token replay lives: legacy client types left open for an old scanner, a service account excluded during a migration, or a policy scoped to "selected apps" that never got expanded.
This is where cloud security services earn their fee. For most mid-market firms, the fix is not another product. It is configuring identity controls the organization already pays for inside its Microsoft 365 licensing, then testing that those controls actually refuse a replayed session.
How would a vCISO triage a suspected token replay in the first 72 hours?
A virtual Chief Information Security Officer (vCISO) treats a suspected token replay as two parallel incidents: an identity compromise that IT must contain, and a potential fraud event that finance and legal must manage. The common mistake is resetting the password, closing the ticket, and never asking what the attacker did with the mailbox.
Hours 0 to 4: contain the identity
Revoke all active sessions for the user in Microsoft Entra ID and reset the password. Huntress notes that a password reset alone does not invalidate an access token that has already been issued, which can stay usable for roughly 90 minutes unless sessions are revoked. Contain first, investigate second.
Hours 4 to 24: hunt for persistence
Check the account's registered devices, MFA methods, inbox rules, mail forwarding, delegates, and any enterprise applications granted access. Each of these can outlive the stolen token. When a cloud security consultant reviews a Microsoft 365 tenant after an incident like this, the first question is rarely whether MFA was on. It is which policy should have refused the sign-in, and why it did not.
Hours 24 to 72: manage the business exposure
Pull the mailbox's sent items and look for payment, payroll, or banking requests. Call finance and confirm any recent payment-detail changes through a known phone number, not by replying to email. Notify external partners who may have received fraudulent requests, loop in counsel to assess notification obligations, and check your cyber policy for notice deadlines.
A simple decision rule by size. If your organization has fewer than about 100 employees and no dedicated security leader, the realistic gap is not detection tooling. It is that nobody owns the Conditional Access design or the post-compromise runbook. That ownership gap is what vCISO services and fractional CISO services are built to close, ideally before the incident rather than during it.
At Purple Shield Security, this 72-hour sequence is part of the incident response runbook we build with clients, so the first call after a suspicious sign-in follows a plan instead of improvisation.
What should a business do this week about Microsoft 365 token replay?
A business should spend this week closing the gaps that let replayed tokens succeed and confirming that no attacker persistence already exists. Most of these steps are configuration changes in Microsoft Entra ID and Exchange Online, not new purchases, and a capable administrator can complete the review in a few days.
Close Conditional Access gaps. Confirm a policy requires MFA or blocks access for all users, all cloud apps, and all client app types, and document every exclusion with an owner and an expiry date.
Restrict device-code flow. Use the Conditional Access authentication flows setting to block it, then allow it only for the specific accounts or devices that need it.
Move high-risk accounts to phishing-resistant MFA. Passkeys and FIDO2 security keys are bound to Microsoft's real sign-in domain, so an AiTM relay page cannot complete the login. Start with finance, payroll, executives, and administrators.
Audit Entra ID devices. Look for devices named DESKTOP- plus eight hexadecimal characters, especially those registered from hosting provider IP addresses. Confirm with the user before deleting, since the pattern is rare but not unique to this campaign.
Audit MFA method changes. Flag accounts where MFA methods were cleared and re-registered within minutes, and remove any authenticator the user does not recognize.
Hunt suspicious inbox rules. Search for rules with one to three character or punctuation-only names, rules that move mail to RSS Feeds, RSS Subscriptions, or Conversation History, and rules keyed on payroll or banking terms.
Disable user consent to new applications. Require administrator approval before any employee grants a third-party app access to company data.
Put payment verification in writing. Make out-of-band phone verification mandatory for any change to payroll, vendor banking, or wire instructions, regardless of how legitimate the email looks.
Update the incident response runbook. Make "revoke sessions, then remove devices, MFA methods, and inbox rules" the standard response to any suspicious sign-in, not just a password reset.
Frequently asked questions
Does a password reset kick out an attacker who stole my Microsoft 365 token?
Not by itself. Huntress notes that an already-issued access token can remain valid for roughly 90 minutes unless sessions are explicitly revoked in Microsoft Entra ID. A password reset also leaves attacker-registered devices and authenticator apps in place, so you need to revoke sessions and remove both before treating the account as clean.
How can I tell if my Microsoft 365 tenant was hit by this campaign?
Huntress published indicators of compromise, including replay traffic from the 193.26.115.0/24 range, sign-ins using a bare "node" user agent through the Microsoft Office client, and Entra devices named DESKTOP- plus eight hex characters. Also review sign-in logs for Conditional Access block code AADSTS53003, because that block only fires after a valid credential is presented.
Will phishing-resistant MFA stop token replay attacks?
Phishing-resistant MFA such as passkeys or FIDO2 keys stops the AiTM relay method, because the key will not authenticate to a lookalike domain. It does not fully address device-code phishing or malware that steals tokens directly from a laptop. Pair it with Conditional Access policies, a block on device-code flow, and endpoint protection.
Is a hijacked business mailbox a reportable data breach?
It depends on what the mailbox contained and which laws apply to you. For HIPAA-covered entities and business associates, unauthorized access to protected health information is presumed to be a breach unless a documented four-factor risk assessment shows a low probability of compromise. Firms holding customer financial or personal data should also review state breach notification laws and contract obligations with counsel.
Token replay is a reminder that MFA is a checkpoint at the front door, not a guard on every room. If you want an independent review of your Microsoft 365 Conditional Access design, your identity incident runbook, or your exposure to business email compromise, Purple Shield Security can help. Our vCISO team works with mid-market and regulated organizations to put the right controls in place before an attacker tests them.
