Token protection and token theft in Microsoft 365

In recent years, token theft has become one of the dominant attack patterns against Microsoft 365 tenants. Attackers don't need the user's password if they can steal the session tokens issued after the user has already signed in — and tokens can be stolen from compromised devices, intercepted on insecure networks, or extracted via phishing kits running adversary-in-the-middle proxies.

How token theft works

The classic pattern:

1. Attacker sends a phishing email with a link to a fake Microsoft sign-in page hosted on attacker infrastructure.
2. Victim clicks, the page proxies their input through to the real Microsoft sign-in — capturing both the credentials and the session token Microsoft issues.
3. Attacker now has a valid session token that doesn't require knowing the password or completing MFA again — the MFA has already been completed by the victim.
4. Attacker imports the token into their own browser session and accesses the user's mailbox, files, Teams.

MFA alone doesn't stop this — the attacker has the post-MFA token. Tools like Evilginx and Tycoon automate adversary-in-the-middle phishing at scale.

What Microsoft 365 offers to defend

Several Microsoft features layer together for defence:

Token Protection (formerly token binding)

A Conditional Access capability (currently in public preview / GA progressively for various workloads) that binds tokens to the specific device they were issued for. A stolen token replayed from a different device fails because the token's cryptographic binding doesn't match.

When fully rolled out, this is the most direct mitigation — tokens become non-portable.

Continuous Access Evaluation (CAE)

When risk signals indicate a compromise — anomalous sign-in location, identity protection alert — CAE revokes active tokens in near real time, cutting short an attacker's session even if they grabbed the token.

Phishing-resistant authentication

FIDO2 keys, passkeys, and Windows Hello for Business are phishing-resistant: the cryptographic challenge-response can't be relayed through an adversary-in-the-middle proxy. If the user has phishing-resistant authentication required, the AitM attack fails at the sign-in step.

Microsoft Defender XDR detection

Defender XDR has detections specifically for token replay anomalies — same token used from very different geographic locations, sudden token use from an unusual user agent. Triggers an alert and (with Identity Protection) can revoke the session.

Identity Protection user risk

A user with confirmed compromised credentials is forced to reset password and reauthenticate, invalidating active tokens.

Conditional Access for risky sessions

Sessions evaluated as high-risk get either blocked or forced to re-authenticate, even mid-session.

What a robust defence looks like

For a Microsoft 365 tenant in 2026:

• Phishing-resistant MFA (FIDO2 / passkeys / Windows Hello) for all privileged users and increasingly all users.
• Conditional Access policies requiring compliant device for sensitive workloads.
• Token Protection enabled where available.
• CAE enabled.
• Defender XDR monitoring with token-replay detection.
• Identity Protection with risky-user policies.
• User awareness training — even phishing-resistant tenants benefit from users being suspicious of unexpected sign-in prompts.

What still leaks

• Cookie theft from compromised devices — if an attacker has malware on the user's device, they can copy tokens / cookies directly without an AitM proxy. The mitigation is device-side: Defender for Endpoint, ASR rules, tamper protection.
• OAuth consent attacks — attackers convince users to grant a malicious app Graph permissions. Mitigation: app consent policies restricting user consent to risky scopes.

Token theft has changed the cost-benefit of investing in phishing-resistant authentication. For tenants that haven't pushed FIDO2 / passkeys broadly yet, this is the year.