What Microsoft's Eviltoken-Style Session-Token Attacks Mean for Exchange Online and Entra ID Admins

Eviltoken-style session-token attacks bypass MFA. A stolen refresh token, primary refresh token (PRT), or browser session cookie gets replayed from attacker-controlled infrastructure, and Conditional Access approves the request because the token itself is the proof of authentication. There is no password to enter, no MFA prompt to defeat, and no geographic anomaly for traditional Conditional Access rules to catch if the attacker is using a residential proxy near the user's home. The defenses that work are tenant configuration choices that treat the session as the attack surface, not the credential.

If you operate a Microsoft 365 tenant and an attacker steals one of your user's sessions, the controls that matter are Entra ID token protection (GA November 2024), Authentication Strengths, sign-in frequency, Continuous Access Evaluation for Exchange Online and SharePoint, and Risky Sign-In revocation. Password reset, Conditional Access location, and legacy protocol blocking look relevant but do not block token replay by themselves. The rest of this article covers the attack mechanics, the right controls, the runbook that survives a partially token-restricted session, and where DMARC aggregate reports catch the next pivot if the attacker decides to impersonate your domain.

Why a stolen session bypasses MFA in the first place

A session token that Microsoft issued to a user is the proof of authentication. When the token is presented to Exchange Online, SharePoint, or Graph, the service trusts it. Conditional Access checks whether the session is still valid but does not decide "this is really Alice." MFA proves identity at sign-in. After the user has proved it, the token is what they carry around. Eviltoken-style attacks steal that token and present it from attacker infrastructure, whether a refresh token reused in a different browser, a PRT lifted from a compromised endpoint, or a browser cookie copied into a remote profile. Replay is not a sign-in event in the usual sense, so the password, the authenticator app, the FIDO key, and the MFA challenge are all out of the loop. This is the structural difference between token theft and credential theft: a stolen password is defeated by MFA, a stolen session is not, because the session is what MFA would have produced.

Where the session-token surface area lives in Microsoft 365

The token attack surface has three layers, all sharing the same Entra ID token, so a single compromise opens all three.

Layer one is Entra ID itself: refresh tokens, primary refresh tokens, browser session cookies. These are issued at sign-in, refreshed on schedule, and live in cookies, browser storage, the Microsoft Authentication Broker on Windows, and the SSO extensions that bridge the tokens into native apps.

Layer two is Exchange Online, the part admins feel most directly during an incident. Outlook on the Web, the new Outlook, native Outlook for Microsoft 365, and the mobile mail clients all consume the Entra ID token to authenticate to mailbox data. A token compromise gets read access to mail, can send mail on behalf of the user, can create inbox rules, can grant Send-As rights to another account, and can move messages without the legitimate user seeing them.

Layer three is everything else the Entra ID token touches: SharePoint, OneDrive, Teams, Defender XDR, the Azure portal, every file the user can reach, every Teams chat the user is in, any Graph-only automation account that shares the tenant. A stolen token is tenant-wide reach until the token expires or is revoked. Most replay windows are hours; some go days if a PRT was lifted. The window does not need to be long to start the spinoff.

Which M365 controls actually block replay (and which only slow it)

The simplest way to think about the tenant's configuration is three buckets: actually blocks replay, slows the attacker, irrelevant to tokens.

Actually blocks replay:

• Entra ID token protection. GA since November 2024. Binds refresh tokens and PRT to the device they were issued on. A replay from a different device fails at refresh time. The control has to be enabled for the user, the app, and a sign-in frequency that triggers re-authentication when the binding metadata is missing.
• Authentication Strengths. Reject older browser session cookies that lack current policy bindings. A policy of phishing-resistant MFA prevents the cookie from being a viable long-lived token.
• Sign-in frequency. Forces re-authentication before the existing refresh token is good for another cycle. A stolen token has a useful window measured in hours, not days.
• Continuous Access Evaluation (CAE) for Exchange Online and SharePoint. When risk signals trip, CAE revokes the active session in near-real-time. CAE only fires for the workloads that participate in it (Exchange Online, SharePoint, OneDrive, Teams at the time of writing).
• Risky Sign-In and Risky User policies. Force sign-out after detection. Reactive, not preventive, but they terminate an in-flight session if the risk engine catches the replay.

Slows the attacker:

• Conditional Access location policies. The attacker relays through the user's region or uses a residential proxy. Detection is plausible but evasion is cheap.
• Device compliance. Useful only when the attacker is using a personal device. Does nothing if the attacker has compromised a compliant device or is using Graph from a server.
• Conditional Access MFA prompts. The token already passed MFA. The prompt does not appear during replay.

Irrelevant to tokens:

• Password rotation. No password is involved. The legitimate user is still using their old password; the attacker is using the session.
• Legacy protocol block. Graph is not legacy. Blocking basic auth does not stop token-based Graph access.
• Account lockout. Lockout is for sign-in attempts. Tokens are not sign-in attempts.

If you have time to harden one thing, enable token protection for the affected users, set a four-hour sign-in frequency, and confirm CAE is enabled for Exchange Online. Those three together close most of the practical replay window.

The token-revocation runbook that survives a partial-token session

When a token compromise is suspected or confirmed, the runbook is short and the order matters.

1. Revoke the user's Entra ID sessions from the Microsoft Entra admin center (Users > user > Sessions > revoke), or via the Microsoft Graph endpoint POST /users/{id}/revokeSignInSessions. The legacy PowerShell equivalent is Revoke-AzureADUserAllRefreshToken and still works on older tenants.
2. Invalidate refresh tokens specifically if the Graph endpoint returned ambiguous results; the admin UI is the source of truth.
3. Audit and remove inbox rules the attacker created, especially forwarders to external addresses, rules that move messages to RSS Feeds or conversation history folders, and rules that mark-as-read to suppress evidence. Removing the rule spinoff is the most consequential single cleanup because the rule is what turns a brief stolen session into a longer-term exfiltration path.
4. Audit mailbox permissions for new Send-As, Send-on-behalf-of, or Full Access grants issued during the attack window.
5. Audit Microsoft 365 Groups and SharePoint for new external sharings during the same window. The token reaches everything.
6. Preserve the audit logs first before anything destructive. MailItemsAccessed, SubmitMessage, and InboxRule operations only survive if exported before the attacker deletes them.

If the attacker's session is still alive at step 1, the attacker can see the revocation take effect. Plan around that.

Where the email-side evidence lives after a token theft

Sign-in logs are the first checkpoint. Filter on the affected user, on refresh token correlation IDs, on anonymous IP, on atypical travel, and on persistent browser session flags. Modern Entra ID sign-in logs surface the token type (refresh, PRT, browser session) explicitly.

The Unified Audit log is where the mailbox-side evidence lives. MailItemsAccessed events with Bind and SubmitMessage actions show reads and sends. InboxRule operations show spinoff-rule creation. SearchMail activities show mailbox-content access, especially if the attacker used eDiscovery to enumerate the mailbox. External mail-forwarding-rule creation is the key spinoff signal. When the Exchange Online extended audit pipeline is enabled, MailItemsAccessed events include sensitivity labels and folder paths, which lets the investigation recover the actual scope of mailbox access rather than only confirming access happened. Export these events before revocation closes the audit pipeline. Revocation does not erase prior logs, but it does close the window during which the attacker could erase them.

The post-compromise pivot that DMARC aggregate reports can see

A stolen Entra ID session is invisible to DMARC aggregate reports by design. Mail sent from the customer's own infrastructure using a stolen session is correctly authenticated: SPF passes for the customer's sending IPs, DKIM signs with the customer's keys, From-header alignment holds. The reports do not flag it.

What the reports do see is the next pivot. When an attacker who has been operating inside the mailbox decides to step outside it, they typically move to impersonating the customer from external infrastructure. Lookalike-domain vendor fraud, a spoofed executive reply to a finance request, a fake customer-service reply to a vendor inquiry, a CFO-impersonation email to accounting, all of those flow through sending infrastructure the customer does not own. At that point DMARC aggregate reports from the receiving inbox show new unauthorized sources, new DKIM failures, or new From-mismatch traffic claiming to be the customer's domain. DMARC aggregate reports do not catch the token theft. They catch the spinoff.

DMARCFlow turns that signal into a feed the admin can scan in two minutes per day. The relevant control to detect a stolen session lives in Microsoft 365, not in DMARC reporting. The relevant control to detect the spinoff from a stolen session lives in DMARC aggregate report monitoring, and DMARCFlow is one practical layer for it. Together: tenant configuration prevents and contains the session compromise, and DMARCFlow surfaces the next step before end users do.

FAQ

Does Conditional Access block session-token theft?
No. Conditional Access evaluates whether the request comes from a user with a valid session and the right state. It does not detect that the session is being replayed from an attacker-controlled device. Conditional Access slows token theft through device compliance and location policies but does not stop it. Pair Conditional Access with token protection, sign-in frequency, Authentication Strengths, and Continuous Access Evaluation for Exchange Online and SharePoint.

How do I revoke a stolen Entra ID refresh token?
Use the Microsoft Entra admin center (Users > user > Sessions > Revoke), the Graph endpoint POST /users/{id}/revokeSignInSessions, or the legacy PowerShell Revoke-AzureADUserAllRefreshToken. Revocation invalidates refresh tokens, primary refresh tokens, and active browser sessions. Access tokens already issued to Graph or Exchange Online within the same minute window expire on their own; revocation does not chase them.

Does token protection stop replay from a stolen browser cookie?
Token protection binds refresh tokens and primary refresh tokens to the device they were issued on. A replayed token on a device without the matching bound credential fails at refresh-token exchange, not at the original sign-in. Token protection does not bind browser session cookies directly. For browser sessions, pair token protection with sign-in frequency, Authentication Strengths that require phishing-resistant MFA on session issuance, and revocation when a risk signal trips.

Where can I see if a stolen token was used to read mail?
The MailItemsAccessed audit event in the Unified Audit log. Bind actions are reads; SubmitMessage actions are sends. Filter on the affected user for the attack window, export before revocation closes the audit pipeline, and cross-reference event IP and client info against the user's known device fingerprints in Entra ID sign-in logs. Extended audit events include sensitivity labels and folder paths when enabled.

What is the difference between revoking sessions and resetting a password?
Session revocation invalidates refresh tokens and active browser sessions, forcing re-authentication. It does not invalidate the password. Password reset invalidates the password plus the sessions. For a suspected token compromise, session revocation is sufficient and faster because the user does not need to set a new password. For a confirmed credential compromise, password reset, session revocation, MFA-factor reset, and revocation of multifactor authentication methods form the full containment.

Do DMARC aggregate reports catch a stolen Exchange Online session?
No. Mail sent from the customer's own infrastructure using a stolen session is correctly authenticated and does not show in the reports as unauthorized. DMARC aggregate reports become useful in the spinoff scenario when an attacker pivots from a stolen session to impersonating the customer from outside the tenant. DMARCFlow is one practical layer that surfaces that spinoff within the daily report cycle.