In customer tenants I keep running into the same uncomfortable fact: token theft in Microsoft 365 is very much alive, even where MFA policies are strong. Many people treat multi-factor authentication as a silver bullet. But adversary-in-the-middle (AiTM) phishing and infostealer malware can steal session cookies or refresh tokens after the user has authenticated legitimately. With those in hand, an attacker can take over the session and skip MFA entirely. Over the last few months I've seen several tenants chase alerts about odd sign-in patterns that, once we dug in, came down to stolen session tokens.

Attackers steal tokens after MFA in two main ways

AiTM phishing puts itself between the user and the real login page. It captures the password, the MFA prompt and the session token that comes back. Infostealer malware takes a different route and pulls browser and app tokens straight off a compromised device, ready for the attacker to reuse. Both methods get around classic protections like MFA or network restrictions, because the stolen token is technically valid until it expires or gets revoked. That makes detection hard. Without decent anomaly detection (unfamiliar sign-in properties or anomalous tokens, for example), Entra ID treats these sessions as legitimate. Microsoft's documentation on Identity Protection risks and its playbook for responding to token theft are useful references for what to watch for.

Here is a typical AiTM token theft scenario as a simple flowchart:

flowchart TD
    User["User logs in"] --> AiTM["Phishing site relays login"]
    AiTM --> MFA["MFA entered"]
    MFA --> EntraID["Entra ID authenticates"]
    EntraID --> AiTM
    AiTM --> Token["Token is stolen"]
    Token --> Attacker["Attacker reuses session"]

Figure: Typical adversary-in-the-middle token theft workflow.

Conditional Access, token protection and device signals limit token replay

In practice, Conditional Access (CA) is still the most effective tool we have here, provided we use it to require device-based signals for critical apps. If access has to come from a compliant or Entra hybrid joined device, an attacker can't simply replay a stolen token from some random machine. I also tend to recommend sign-in frequency controls for high-risk apps. They force users to reauthenticate more often, which shortens the time a stolen token stays useful. Continuous access evaluation (CAE) goes a step further. As I described in my post on CAE and strict location enforcement, it lets Entra ID revoke sessions immediately for certain risks or location changes.

A newer option is token protection for sign-in sessions. As of January 2025 it's still in public preview and only works for modern Windows desktop apps (Microsoft's documentation), but it looks promising. The issued token is cryptographically bound to the device, so a stolen copy can't be replayed somewhere else. Browser and mobile sessions aren't covered yet. For desktop scenarios like Exchange Online and SharePoint file access, though, it's a real improvement (you'll need Entra ID P1/P2, depending on the policy).

Identity Protection flags risky sessions that point to token theft

I strongly recommend Microsoft Entra ID Protection (requires Entra ID P2), because it surfaces anomalies such as "anomalous token" and "unfamiliar sign-in properties". These detections often show sessions coming from new locations or devices, and that's exactly what most token theft attacks look like. Build a habit of checking the Entra ID → Protection → Risk detections dashboard for new suspicious sign-ins.

Practical tip: After a token theft incident, always look at the inbox rules in Exchange Online for signs of malicious forwarding or deletion. In many cases I've worked on, attackers created rules to cover their tracks, so don't skip this when you investigate a compromised account.

Incident response starts with revoking sessions and checking methods

If you suspect token theft or Identity Protection raises risk detections, act fast. First revoke all active sign-in sessions for the user in the Microsoft Entra admin center → Users → select user → Revoke sessions. If you have the right permissions (UserAuthenticationMethod.ReadWrite.All in Microsoft Graph PowerShell), you can script this as well:

# Prerequisites: Microsoft Graph PowerShell, UserAuthenticationMethod.ReadWrite.All
Revoke-MgUserSignInSession -UserId <UPN or object ID>

Then reset the user's password, confirm that every MFA method is correct, and check for suspicious inbox rules in Exchange Online ("Mailflow → Rules" and the user-level inbox rules in the Exchange admin center). That way the attacker actually loses access and you don't overlook a hidden backdoor.

Detection and device-based CA are what actually fix the problem

Token theft after MFA has become a standard attacker technique. It's no longer rare, and when it succeeds the impact is always high. MFA remains essential, but your defenses have gaps if you don't also have device-based CA policies, regular reviews in Entra ID Protection and a quick incident response process. Piloting token protection makes sense. So does making sure your team can revoke sessions and communicate with users quickly. With some practice and the right tools, you can make token theft attacks a lot less attractive. If you want more detail on AiTM attacks in Microsoft 365, have a look at my earlier post on AiTM phishing and token theft in Microsoft 365.