This article was written with the help of AI. We used an AI assistant to draft it, then checked the figures against the original Huntress research and the steps against Microsoft's documentation. Sources are linked throughout.
A Microsoft 365 token replay attack campaign documented by Huntress on October 22, 2026 shows why MFA on its own is no longer the finish line. In its report, Huntress says it responded to related incidents at 79 organizations between July 14 and September 22, 2026, seeing at least 497 successful sign-ins and more than 200,000 failed attempts. The Hacker News put the total at 97 compromised accounts.
The attackers did not crack anyone's MFA. They captured what a successful sign-in produces, the session token, and reused it from their own machines.
How the Attack Works
Huntress found the tokens came from three places: fake sign-in pages that relay to the real Microsoft page (adversary-in-the-middle), device-code phishing, and social engineering during a real login. The relay version goes like this:
- An employee clicks a link to what looks like the Microsoft sign-in page.
- They enter their password and approve the MFA prompt. The fake page passes both to Microsoft in real time.
- Microsoft signs them in and issues a session token. The fake page keeps a copy.
- The attacker presents that token from another computer and is treated as already signed in.
As Huntress puts it, the token is "minted after MFA," so whoever holds it does not need to pass MFA again.
Once in, the attackers in this campaign dug in. Huntress reports at least 48 fake computers joined to victims' Entra directories, MFA methods wiped and replaced in 19 organizations, and inbox rules set up to hide mail, including rules keyed on payroll and banking words.
Why a Password Reset Is Not Enough
The attacker does not need the password while the token works. Huntress says a reset alone leaves the attacker's devices and MFA methods in place. And Microsoft's emergency access guide explains that even after you revoke sessions, an app keeps working until its current access token expires, one hour by default.
Email authentication does not help here either. SPF, DKIM and DMARC protect your domain from being spoofed in email. They do nothing about a stolen sign-in session. Keep them; just do not read a clean DMARC report as a clean mailbox.
What to Check in Your Tenant
1. Sign-in logs
In the Microsoft Entra admin center, open the sign-in logs and look for successful sign-ins from hosting companies, unfamiliar countries or unfamiliar devices, especially right after someone reports clicking a link. Huntress recommends hunting for sign-ins from hosting infrastructure with odd browser or app identifiers. One odd location is not proof on its own; people travel and use VPNs. Look at the combination.
2. Registered devices
List the devices registered to each suspect user. In this campaign the fake ones were named "DESKTOP-" followed by eight letters and numbers and were registered from hosting IP addresses. Remove anything the user does not recognize.
3. MFA methods
Open the user's authentication methods and remove any phone, app or key they did not set up. Huntress specifically warns about methods re-registered shortly after being cleared.
4. Inbox rules and app consents
Look for rules with very short or punctuation-only names, rules that move mail to RSS or Conversation History folders, and rules that trigger on payroll or banking terms. Check for new enterprise applications the user consented to.
5. Contain the account
Microsoft's emergency steps: in the Entra admin center, go to Entra ID > Users > All users, select the user, turn off Account enabled if you see active misuse, and select Revoke sessions. Then reset the password and clean up devices and MFA methods. Export the sign-in and audit records before you change much, so you have a timeline for your insurer or anyone else who asks later.
Before revoking sessions widely, make sure an emergency admin account can still sign in. Locking out your only administrator turns a security problem into an outage.
Make the Next One Harder
- Conditional Access for every user and app. Huntress's main point: "Token replay attacks can be prevented with properly implemented Conditional Access Policies." Require MFA, or block access, for all users, cloud apps and client types, and require a compliant or registered device where your business can support it. Start in report-only mode.
- Block device-code sign-ins with a Conditional Access authentication-flows policy unless you have a specific need for them.
- Phishing-resistant MFA for admins and anyone handling money: passkeys, Windows Hello for Business or security keys. These are tied to the real Microsoft address and do not work through a relay page.
- Limit user consent to apps so a phished user cannot approve a malicious app.
- Token Protection, a Conditional Access control that only accepts sign-in tokens bound to the device they were issued to. Microsoft's documentation shows it is enforced for desktop and mobile apps reaching Exchange Online, SharePoint Online and Teams on registered Windows devices and MDM-managed Apple devices, but browser support is limited to a preview for a few Azure apps. It will not stop a stolen browser session in Outlook on the web today, so treat it as one layer, not the fix.
Most of these controls need Conditional Access, which comes with Microsoft 365 Business Premium. Our Microsoft 365 security baseline lists the settings we turn on first.
Sources
- Huntress: M365 Token Spray and Replay Campaign Compromises Business Email Accounts (October 22, 2026)
- The Hacker News: Microsoft 365 token replay attacks (October 26, 2026)
- Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
- Microsoft Learn: Token Protection in Conditional Access
Common questions
Does a token replay attack mean MFA is useless?
No. The attacker does not break MFA. The victim completes MFA on a fake page that passes everything to Microsoft, and the attacker keeps the session token Microsoft hands back. Phishing-resistant methods such as passkeys and security keys are built to refuse that kind of relayed sign-in.
Is resetting the password enough?
No. Huntress says a password reset alone leaves the attacker's devices and MFA methods in place. Revoke the user's sessions, reset the password, and then remove any devices and MFA methods the user does not recognize.
Does revoking sessions cut the attacker off immediately?
Not always. Microsoft says revoking stops new tokens from being issued, but an app keeps working until its current access token expires, which is one hour by default. Apps that support continuous access evaluation can end sooner.
Does DMARC protect us from this?
No. SPF, DKIM and DMARC check whether email claiming to be from your domain was sent by you. They do nothing about a stolen sign-in session. Keep them, but do not treat a clean DMARC report as proof a mailbox is safe.
