Microsoft 365 token theft: why MFA is not enough against AiTM attacks

MFA can succeed while the session is still compromised

MFA is highly effective against a stolen password used on its own. It does not, however, guarantee that the browser shown to the user is talking directly to Microsoft. In an adversary-in-the-middle attack—usually shortened to AiTM—a malicious site acts as a proxy between the victim and the real Microsoft 365 sign-in page.

The user enters a password and approves MFA against Microsoft's legitimate infrastructure. The service then issues an authenticated session. The malicious proxy captures the session artifact passing through it and can replay it. From Microsoft 365's perspective, MFA was genuinely satisfied; the attacker is not guessing it, but reusing the result of the sign-in.

The right message is therefore not 'MFA is useless.' It remains essential, but traditional MFA must be completed with phishing-resistant authentication, managed devices, hardware-bound tokens, risk signals and a revocation process that has actually been tested.

• Microsoft — Token theft response playbook ↗
• Microsoft — Protecting tokens in Microsoft Entra ↗

What an AiTM proxy actually intercepts

A token is not the password. It is an audience-, permission- and time-limited artifact used by a client or application after authentication. A Microsoft 365 session can involve several artifacts: an Entra sign-in cookie, an application session cookie, an access token, a refresh token and, on a joined Windows device, a Primary Refresh Token (PRT).

The captured type determines scope and response. An access token provides access to a resource until expiry or rejection. A refresh token can request new access tokens. An application cookie can remain valid according to that application's rules even after an Entra action. Microsoft notes that Entra cannot directly revoke a cookie created and controlled by a third-party application.

• Microsoft — Revoke user access in an emergency ↗
• Microsoft — Understanding the Primary Refresh Token ↗

Traditional MFA and phishing-resistant MFA are not equivalent

A push notification, TOTP code, SMS or voice call confirms that a second factor was presented. In an AiTM flow, the malicious site can relay that step to Microsoft in real time and capture the resulting session. Number matching reduces blind approvals, but it does not cryptographically bind authentication to the real domain being visited.

FIDO2 passkeys, security keys and Windows Hello for Business use a key associated with the service domain. The authenticator does not produce a valid response for a fraudulent domain. Microsoft also includes certificate-based authentication configured as multifactor in its built-in Phishing-resistant MFA strength.

That resistance protects the sign-in ceremony. It does not stop malware on an already signed-in endpoint from attempting to extract a token or operate the local session. Phishing-resistant identity must therefore be paired with device health and replay protection.

• Microsoft — Conditional Access authentication strengths ↗
• Related guide — Deploy passkeys with Microsoft Entra ID →

The seven controls that materially change risk

None of these controls covers browsers, native clients, personal devices and third-party applications by itself. Priority depends on the population: start with administrators, finance, HR, publicly visible people and accounts with access to large volumes of email or files.

• Require a phishing-resistant authentication strength for administrators and sensitive applications.
• Allow sensitive data only from compliant or Microsoft Entra hybrid joined devices where the use case permits it.
• Roll out Token Protection for supported platforms, applications and resources.
• Deploy Microsoft Defender for Endpoint, network protection, cloud protection and tamper protection.
• Use Entra ID Protection risk policies and export sign-in, risk and audit logs to a SIEM.
• Keep Continuous Access Evaluation and understand which applications do not yet reevaluate critical events.
• Test response: account block, revocation, endpoint isolation, persistence search and controlled recovery.

Enforce the right authentication strength with Conditional Access

Create a Conditional Access policy for administrative roles and target All resources. Under Grant, choose Require authentication strength, then Phishing-resistant MFA. Exclude only planned and tested emergency accounts. Microsoft recommends starting in Report-only and examining sign-ins before setting the policy to On.

Do not block registration before users have a compatible method. First issue passkeys, FIDO2 keys, Windows Hello for Business or suitable certificates, using Temporary Access Pass for bootstrap. Then extend the strength to sensitive applications and other ready groups.

For a particularly sensitive action, such as activating a PIM role or opening a confidential SharePoint site, use an authentication context to request strong authentication at the point of action. This protects the action that matters without creating prompts everywhere.

• Microsoft — Require phishing-resistant MFA for administrators ↗
• Microsoft — Plan phishing-resistant passwordless deployment ↗

A compliant-device requirement stops a stolen session from becoming a workstation

A policy requiring a device marked compliant adds evidence that the endpoint is known, encrypted, patched and controlled according to your Intune rules. It prevents many tokens replayed from an unknown machine from reaching protected resources. For administrators, combining a compliant device with phishing-resistant authentication is much stronger than simply adding more MFA prompts.

Compliance helps only when its criteria are meaningful. Integrate Microsoft Defender for Endpoint machine risk, encryption, firewall state and a minimum OS version. A registered but unmanaged device should not be treated as equivalent to a compliant one.

Guests, BYOD, mobile devices and emergency scenarios need separate paths. Use app protection policies, session restrictions or limited web access instead of a permanent exception that bypasses the entire policy.

• Microsoft — Require device compliance with Conditional Access ↗
• Microsoft — Conditional Access and Intune compliance ↗

Token Protection binds the session to the device—with limits

Token Protection is a Conditional Access session control that requires cryptographically device-bound sign-in tokens. An exported artifact then cannot be used from another supported machine. The feature requires Microsoft Entra ID P1 and should be validated in Report-only before enforcement.

Native application support is generally available on Windows, iOS/iPadOS and macOS, but matrices differ. On Windows, Microsoft lists Outlook, Teams, OneDrive, Word, Excel, PowerPoint, Windows App and selected PowerShell modules; supported resources include Exchange Online, SharePoint Online, Teams, Azure Virtual Desktop and Windows 365.

Do not assume that every browser and SaaS application is covered. Web support remains limited to selected preview scenarios accessing Azure Resource Manager. Perpetual clients, old versions, certain device registration types and extensions can be blocked. Measure Token Protection - Sign In Session and tokenProtectionStatusDetails in sign-in logs before enforcement.

• Microsoft — Token Protection overview ↗
• Microsoft — Token Protection deployment guide for Windows ↗

CAE speeds revocation; shortening every session is not the answer

Continuous Access Evaluation lets Exchange Online, SharePoint Online, Teams and supported clients react to critical events before normal token expiry: account disablement, password reset, explicit revocation or high user risk. Microsoft targets near-real-time response, with propagation latency of up to roughly 15 minutes for some events.

CAE does not cover every client and resource combination. An application maintaining its own cookie can also preserve the session under its own policy. The response plan must therefore include revocation in affected applications, not merely Revoke sessions in Entra.

Forcing MFA every hour everywhere increases fatigue and trains people to respond to prompts. Microsoft warns that excessive reauthentication can make users more vulnerable to fraudulent sign-in screens. Reserve Sign-in frequency for applications, risks and devices that justify it; prefer SSO on managed devices, CAE and interactive reauthentication for sensitive actions.

• Microsoft — Continuous Access Evaluation ↗
• Microsoft — MFA prompts and session lifetime ↗

Detect replay through identity risk and logs

Entra ID Protection exposes signals including Anomalous token, Attacker in the Middle, unfamiliar sign-in properties, malicious IP and attempted PRT access. A successful non-interactive event from a new ASN, empty device or unexpected country deserves more attention than a single failed interactive sign-in.

Microsoft states that some token-theft detections containing an existing MFA claim are no longer automatically closed. Risk details instead expose time, IP, client, request ID and correlation ID for investigation. A user-risk policy therefore needs to be configured: owning the license and occasionally viewing the dashboard does not contain an attack.

Export SigninLogs, AADUserRiskEvents, RiskyUsers and AuditLogs to Log Analytics or your SIEM. Retain Microsoft Purview Audit, Exchange, SharePoint, OneDrive, Teams and Defender XDR activity as well. A successful session from a new IP becomes much clearer when followed by an inbox rule, OAuth consent or mass download.

• Microsoft — Entra ID Protection risk detections ↗
• Microsoft — Handling token theft-related detections ↗

Two KQL hunts to start an investigation

The first query groups a session observed across multiple networks, countries or devices. This is not proof: a VPN, mobile network, Global Secure Access or Internet egress change can create the same pattern. Use it to produce a shortlist, then compare request ID, correlation ID, application, device, timeline and business activity.

The second hunt focuses on successful non-interactive sign-ins already marked risky. Adapt thresholds and exclusions to your environment, but never exclude a network or provider merely because it appears often; document the reason and monitor changes.

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "0" and isnotempty(SessionId)
| extend DeviceId = tostring(DeviceDetail.deviceId),
         Country = tostring(LocationDetails.countryOrRegion)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
            IPs=make_set(IPAddress, 10), ASNs=make_set(AutonomousSystemNumber, 10),
            Countries=make_set(Country, 10), Devices=make_set(DeviceId, 10),
            Apps=make_set(AppDisplayName, 10)
  by UserPrincipalName, SessionId
| where array_length(IPs) > 1
  and (array_length(ASNs) > 1 or array_length(Countries) > 1 or array_length(Devices) > 1)
| order by LastSeen desc

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == "0" and IsInteractive == false
| where IsRisky == true or RiskLevelAggregated in ("medium", "high")
| extend DeviceId = tostring(DeviceDetail.deviceId),
         Browser = tostring(DeviceDetail.browser),
         Country = tostring(LocationDetails.countryOrRegion)
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
          AutonomousSystemNumber, Country, DeviceId, Browser, SessionId,
          RiskLevelAggregated, RiskEventTypes_V2, ConditionalAccessStatus,
          CorrelationId, OriginalRequestId
| order by TimeGenerated desc

• Microsoft — SigninLogs schema ↗
• Related guide — Defender Advanced Hunting KQL queries →

Audit existing policies before creating more

Start by exporting Conditional Access policies with a read-only account. Look for excluded users, uncovered applications, permissive OR grant controls, disabled policies and old session settings. Then compare Report-only results in the sign-in logs.

A well-named policy is not evidence. Verify its targets, state and combined effect with other policies. The What If tool helps simulate a user, app, platform and IP address, but a real pilot remains necessary for Token Protection, compliance and legacy clients.

Connect-MgGraph -Scopes 'Policy.Read.All'

$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | Select-Object DisplayName,State,CreatedDateTime,ModifiedDateTime,`
  Conditions,GrantControls,SessionControls |
  Export-Clixml '.\Conditional-Access-Policies.xml'

$policies | Group-Object State | Select-Object Name,Count
Disconnect-MgGraph

• Microsoft — Analyze impact in Report-only mode ↗
• Microsoft — Get-MgIdentityConditionalAccessPolicy ↗

Harden the endpoint and the path leading to the fake page

Identity controls act late if the user already reached the fraudulent domain. Defender for Office 365 protects email and collaboration with anti-phishing policies and Safe Links. Defender for Endpoint Network Protection extends SmartScreen reputation to supported browsers and application HTTP(S) connections, which can block a malicious domain before the password is entered.

On endpoints, enable real-time and cloud protection, Network Protection, Tamper Protection, EDR and relevant ASR rules through an Audit, Warn and Block progression. Endpoint protection is essential for theft that does not use AiTM: a malicious browser extension, cookie theft, profile access or attempted PRT extraction.

Train users to report an unexpected sign-in page instead of counting MFA prompts. A fake site can display the real logo and real MFA. Better signals are the domain address, a sign-in launched from an unexpected document or QR code, and a request to authenticate when the normal session is already open.

• Microsoft — Network Protection in Defender for Endpoint ↗
• Microsoft — Defender for Office 365 protection ↗
• Related guide — Deploy ASR rules progressively →

Respond to token theft without stopping at the password

First preserve volatile evidence: timestamps, IPs, SessionId, request ID, correlation ID, client, device and alerts. If activity cannot be confirmed quickly, treat it as compromised. Block new sign-ins, revoke sessions and isolate the associated endpoint. For a hybrid identity, disable the account in Active Directory too and account for synchronization delay.

Revoke-MgUserSignInSession revokes Entra refresh tokens. CAE-capable applications can react quickly, but access tokens and application cookies follow their own rules. Open the consoles for critical applications and invalidate their sessions where that capability exists.

Reset the password from a clean administrative workstation, inspect registered MFA methods and passkeys, and require re-registration if the attacker added one. Do not restore the account until the entry point is understood and the endpoint is clean; otherwise the new credential may be captured immediately.

Connect-MgGraph -Scopes 'User.ReadWrite.All','Directory.ReadWrite.All'

$user = Get-MgUser -UserId 'user@contoso.com'
Update-MgUser -UserId $user.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $user.Id

# Inventory methods; remove only after validation.
Get-MgUserAuthenticationMethod -UserId $user.Id |
  Select-Object Id,AdditionalProperties

Disconnect-MgGraph

• Microsoft — Emergency revocation procedure ↗

Find Microsoft 365 persistence before restoring access

An attacker with a session often seeks durable access: an inbox rule that deletes or forwards messages, SMTP forwarding, delegation, a consented OAuth app, a new authentication method, a registered device or a privileged role. Revoking the session without removing these changes leaves a way back in.

Review activity from the first suspicious signal, not just after the alert. Look for unusual reads and downloads in Exchange, SharePoint, OneDrive and Teams, then identify affected recipients or data. If fraudulent mail left the account, use Explorer or Advanced Hunting to find recipients and purge messages when your licensing supports it.

• Visible and hidden inbox rules, mailbox forwarding and redirect addresses.
• Unexpected FullAccess, SendAs and SendOnBehalf delegation.
• User and admin OAuth consent, Graph permissions and newly added applications.
• MFA methods, passkeys, Temporary Access Pass, registered devices and password changes.
• Role additions, PIM activations, Conditional Access changes and exclusions.
• Mass downloads, searches, external shares and access to sensitive email.

Connect-ExchangeOnline

Get-InboxRule -Mailbox user@contoso.com -IncludeHidden |
  Select-Object Name,Enabled,Priority,ForwardTo,RedirectTo,DeleteMessage

Get-Mailbox user@contoso.com |
  Select-Object ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

Get-MailboxPermission user@contoso.com |
  Where-Object { -not $_.IsInherited -and -not $_.Deny }

Get-RecipientPermission user@contoso.com |
  Where-Object { -not $_.IsInherited }

Disconnect-ExchangeOnline -Confirm:$false

• Microsoft — Respond to a compromised email account ↗
• Microsoft — Investigate app consent ↗

Roll out in waves and measure more than prompt count

A good rollout reduces replayable sessions without turning the workday into a stream of MFA prompts. Measure phishing-resistant method registration, compliant-device sign-ins, Token Protection Bound status, exceptions, untreated risk and actual containment time during an exercise.

Start with accounts that create the largest blast radius. Then add users handling payments, personal data or shared mailboxes before expanding. Every wave needs a recovery scenario and a tested emergency account outside the normal path.

The expected outcome: prevent, contain and explain

MFA remains a fundamental barrier, but a successful approval does not prove that the session stays in the user's hands. A modern architecture protects sign-in with passkeys, protects access with device state, protects the token against replay and still assumes that an incident will eventually need containment.

A useful Microsoft 365 assessment must therefore review authentication methods, Conditional Access, devices, sessions, risk, OAuth applications and investigative readiness together. That end-to-end view turns a list of policies into operational protection.

• Privileged and sensitive accounts use phishing-resistant authentication.
• Critical data requires a compliant device where the usage model permits it.
• Token Protection is enforced on compatible clients and its limits are documented.
• Risk policies trigger action; logs are exported and retained.
• CAE remains enabled and applications controlling their own sessions are inventoried.
• Email, browser and endpoint protections reduce access to fake sites and local extraction.
• The SOC can connect a session to its IP, client, device and subsequent Microsoft 365 activity.
• The incident plan covers sessions, MFA methods, OAuth consent, inbox rules and devices.
• An exercise confirms containment time and clean user recovery.

• Service — Microsoft 365 security assessment →
• Related guide — Secure Copilot agents and MCP servers →