Stop Microsoft 365 Token Theft and AiTM Phishing

The uncomfortable truth about Microsoft 365 account takeover in 2026 is that multi-factor authentication is no longer enough on its own. Adversary-in-the-middle (AiTM) phishing kits sit between you and the real login page, let you complete MFA, then steal the resulting session token and replay it to take over your account. Microsoft observed campaigns hitting tens of thousands of users across thousands of organizations this spring. Here is how the attack works and the controls that actually stop it.

Key takeaways

• AiTM phishing uses a reverse-proxy page that relays your login to the real Microsoft service in real time, capturing the session cookie after you complete MFA.
• With the stolen token, attackers bypass MFA entirely and access mailboxes and Microsoft 365 services as you, often pivoting to internal phishing and business email compromise.
• Phishing-as-a-service kits like the FBI-flagged Kali365 have industrialized these attacks, lowering the skill barrier.
• The strongest defenses are phishing-resistant MFA, Conditional Access token protection, and device compliance requirements.
• Microsoft Defender's attack-disruption can detect and automatically contain AiTM attacks early if configured.

How AiTM token theft works

Traditional phishing steals your password. AiTM phishing steals your session. The attacker stands up a malicious page that acts as a reverse proxy between you and the genuine Microsoft login. When you enter your credentials and complete MFA through that proxy, the attacker silently captures the authentication tokens and session cookies the service hands back.

Those cookies represent an already-authenticated session. The attacker imports them into their own browser and is logged in as you, no password or MFA prompt required. Unlike old-school credential harvesting, AiTM intercepts authentication traffic in real time, which is exactly why ordinary, non-phishing-resistant MFA does not stop it.

The lure that gets you to the proxy page has grown more convincing too. Microsoft's spring 2026 reporting traced multi-stage campaigns that opened with a believable "code of conduct" or HR-style email, routed victims through legitimate-looking redirects to evade URL scanners, and only then landed them on the AiTM proxy. Phishing-as-a-service kits like the FBI-flagged Kali365 package all of this, the proxy, the token capture, the evasion, so that low-skill operators can run campaigns that used to require real expertise. That industrialization is why these attacks now hit thousands of organizations at once rather than one target at a time.

> man in the middl

Why this is so dangerous

Once attackers hold your session token, they can read and send mail, set up forwarding rules, launch internal phishing from your trusted account, and escalate to business email compromise that defrauds colleagues, partners, or customers. Because the activity originates from a legitimate, authenticated session, it can be hard to distinguish from normal use.

The key reason this works is that most MFA methods verify the login but do nothing to protect the token afterward. Here is which methods actually stop AiTM and which only feel safe:

MFA / control	Stops password theft	Stops AiTM token theft	Notes
SMS code	Partly	No	Phishable and relayable
Authenticator push (approve)	Yes	No	Token still stolen after approval
Number-matching push	Yes	No	Better against fatigue, not AiTM
FIDO2 security key / passkey	Yes	Yes	Origin-bound; will not relay
Conditional Access token protection	n/a	Yes	Binds token to the device
Compliant-device requirement	n/a	Yes	Blocks sign-in from attacker machines

How to protect your organization

1. Deploy phishing-resistant MFA. Move users to FIDO2 security keys or passkeys. Because these bind authentication to the real site's origin, the reverse-proxy page cannot relay them, breaking the attack at the front door.

2. Enable Conditional Access token protection. Configure token protection so that sign-in session tokens are cryptographically bound to the device, making a stolen cookie unusable on the attacker's machine.

3. Require compliant or hybrid-joined devices. Conditional Access policies that demand a managed, compliant device block sign-ins from attacker-controlled machines even with a valid token.

4. Turn on attack disruption. Ensure Microsoft Defender's automatic attack-disruption is enabled so AiTM patterns can be detected early and mitigating controls applied to endpoints and identities automatically.

5. Train and simulate. Run phishing simulations and user-awareness training, and tune Exchange Online Protection and Defender for Office 365 to their recommended baselines to cut down on the lures reaching inboxes.

The shift from password to session security

The big mental shift for 2026 is recognizing that the session token, not just the password, is now the prize. Defenses have to protect authentication and the artifacts it produces. Phishing-resistant MFA addresses the front end, while token protection and device compliance address the back end where the cookie lives.

This connects directly to the broader infostealer and session-theft problem. Cookies are stolen not only through AiTM phishing but through malware, as covered in our guide to infostealer cookie and session theft. The same logic underpins our recommendation to adopt phishing-resistant MFA with security keys and to defend against AI-enhanced phishing, which makes these lures more convincing than ever.

What to do tonight

If you administer a Microsoft 365 tenant, close the highest-value gaps first:

• Roll out phishing-resistant MFA (FIDO2 keys or passkeys) to admins and high-risk users immediately, then expand. This breaks AiTM at the front door.
• Enable Conditional Access token protection so session tokens are cryptographically bound to the device and a stolen cookie is useless elsewhere.
• Require compliant or hybrid-joined devices in Conditional Access to block sign-ins from attacker-controlled machines even with a valid token.
• Turn on Microsoft Defender automatic attack disruption so AiTM patterns are detected and contained early.
• Audit for the signs of compromise now: new inbox forwarding or auto-delete rules, impossible-travel sign-ins, and sessions from unfamiliar devices. Revoke sessions and reset credentials on anything suspicious.
• Pilot token protection and device policies before broad rollout so you do not lock out legitimate users on unmanaged devices or older client apps.

Frequently asked questions

Does MFA still matter if it can be bypassed?

Yes, very much. MFA still stops password-only attacks, which are vastly more common. The point is that ordinary MFA is no longer sufficient against AiTM, so you should upgrade to phishing-resistant methods rather than abandoning MFA.

What makes phishing-resistant MFA different?

FIDO2 keys and passkeys use cryptography bound to the legitimate site's origin. A reverse-proxy phishing page has a different origin, so the authentication simply will not complete through it. There is no token for the attacker to steal.

How do I detect a token-theft compromise?

Look for sign-ins from unusual locations or impossible-travel patterns, new inbox forwarding rules, mass mail sent from an account, and sessions that do not match the user's normal devices. Microsoft's token-theft playbook details the investigation steps.

Can token protection break legitimate workflows?

Token protection and device-compliance policies need testing before broad rollout, since they can affect users on unmanaged devices or certain client apps. Pilot with a group, review sign-in logs, and expand gradually to avoid locking out legitimate access.

We were hit. What is the immediate response?

Revoke the user's sessions and refresh tokens, reset the password, and re-register MFA from a known-good device. Then hunt for what the attacker did: new inbox forwarding or auto-delete rules, mailbox delegation changes, OAuth app consents, and any internal phishing sent from the account. Microsoft's token-theft playbook walks through the full containment and investigation steps; move fast, because a stolen token is often used within minutes.

Are personal Microsoft accounts at risk too, or just business tenants?

The technique works against any web login that issues session cookies, so personal accounts can be targeted, but the strongest defenses (Conditional Access token protection, device-compliance policies) are Entra ID features aimed at organizations. For a personal account, the realistic protection is a passkey or FIDO2 key plus vigilance about the lures, since you do not have tenant-level Conditional Access to fall back on.