Attackers are no longer stealing passwords — they are stealing session tokens. AiTM phishing bypasses multi-factor authentication while your employee sees a perfectly normal Microsoft login screen. How the attack works, which campaigns are active in 2026, and how Token Protection in Conditional Access stops it.
Multi-factor authentication has been the standard security advice for years: enable MFA and your accounts are protected. That is still true for a large portion of attacks — but not for AiTM phishing. AiTM stands for adversary-in-the-middle: an attack method in which the attacker positions themselves between your employee and the real Microsoft login page, relays the entire authentication exchange in real time, and intercepts the session token that is issued afterwards. Your user sees a valid login screen, enters their code, and believes everything is fine. Meanwhile the attacker has full access to the account.
Microsoft recorded a 146 percent rise in AiTM attacks over the past year. In April 2026, a large-scale campaign was discovered that hit more than 35,000 users at over 13,000 organisations across 26 countries. The attack ran through fake emails about a 'code of conduct review' from the internal compliance department. Attachments led via multiple redirects to a fake Microsoft login page that looked identical to the real one. Anyone who signed in unknowingly handed their session token to the attacker.
In a regular phishing attack, the attacker steals your password. With MFA enabled, that password alone is not enough — the attacker also needs the verification code. AiTM solves this by proxying the entire login flow live. Your employee types their password on the fake page. That page forwards the password to the real Microsoft server. The real server requests an MFA code. The fake page asks your employee for that code too. As soon as your employee enters the code, the fake page forwards it to Microsoft. Microsoft issues a session token. The fake page intercepts that token. Your employee receives an error message or is redirected to a harmless page. The attacker has the token and uses it immediately — from a different location, on a different device — for full access to the mailbox, SharePoint, and Teams.
Verification codes via SMS, an authenticator app, or email offer no protection against this method. The attack also leaves little visible trace: the employee legitimately signed in, on their own device, and entered their real MFA code. Only the destination of the session token differs.
AiTM attacks are no longer the preserve of sophisticated state actors. Phishing-as-a-service platforms such as Tycoon2FA, developed by threat actor Storm-1747, make the attack method accessible to any criminal with a limited budget. The platform offers an admin dashboard that lets attackers set up ready-made phishing campaigns targeting Microsoft 365, Outlook, and similar services. CAPTCHA screens block automated analysis. Proxy services mask the traffic origin. Every month, tens of millions of phishing messages are sent via Tycoon2FA to more than 500,000 organisations worldwide — from healthcare to finance to mid-sized businesses.
The most dangerous aspect is that stolen session tokens remain valid even after a victim changes their password. As long as the token has not been explicitly revoked, the attacker has access. Some tokens are valid for days to weeks, depending on the tenant configuration.
When you sign in to Microsoft 365, the system issues a set of tokens. The Primary Refresh Token is a long-lived token stored on your device that allows the system to issue new access tokens without requiring you to sign in again. An attacker who obtains such a token effectively has a valid pass to your digital workplace — without knowing your password, without having your device, and without completing your MFA. Tokens are also portable: they are not bound by default to the device on which they were created. A token issued on your laptop can be used by an attacker on their own server on the other side of the world.
Token Protection is a session control within Conditional Access that binds tokens to the specific device on which the sign-in took place. A bound token no longer works on a different device. The attacker can intercept the token, but cannot do anything with it.
You activate Token Protection via the Entra portal, under Conditional Access, as a new policy. The configuration runs in three steps. First, create a new Conditional Access policy and set the target resource to: Office 365 Exchange Online, Office 365 SharePoint Online, and Microsoft Teams Services — these are the services that support Token Protection. Second, under Session, set the option 'Require token protection for sign-in sessions.' Third, initially scope the policy to Windows devices that are Entra joined, hybrid joined, or Entra registered. Support for macOS and iOS is available in preview.
The feature requires Microsoft Entra ID P2 licences. For organisations already running Microsoft 365 Business Premium or E5, P2 is included and no additional licence needs to be purchased.
An additional protection layer is Continuous Access Evaluation, or CAE. By default, Microsoft 365 has no way to immediately terminate an active session once something suspicious is detected — tokens remain valid until they expire, even if the account is already compromised. CAE solves this by having Entra and services such as Exchange Online and SharePoint communicate in real time about session validity.
With CAE active, the service responds immediately to signals such as a password change, a blocked account, a manual token revocation via the admin console, or a location change that violates a Conditional Access rule. The session is terminated without waiting for the token to expire. This reduces the window an attacker with a stolen token has from hours or days to minutes. CAE is active by default for most Microsoft 365 services, but verify in the Entra portal that evaluation is enabled for your tenant.
Token Protection stops token-replay attacks after a token has been stolen. It does not prevent the sign-in process itself from being proxied via an AiTM attack. For that, phishing-resistant authentication is needed: methods that are cryptographically bound to the domain of the real service. Passkeys, FIDO2 security keys, and Windows Hello for Business all operate on this principle. A fake page gets nothing, because the key refuses to authenticate against any domain other than the original. Your employee simply cannot be deceived via an AiTM proxy when phishing-resistant MFA is in place.
The combination of phishing-resistant MFA and Token Protection closes two attack paths simultaneously. The attack fails at the attempt, and even if an attacker somehow obtains a token, that token will not work on a different device.
First, activate Token Protection via Conditional Access for Exchange Online, SharePoint, and Teams. Start in report-only mode to see which sign-ins are affected before enforcing the policy. Second, verify that Continuous Access Evaluation is active in your Entra portal and configure a Conditional Access policy that restricts sign-ins from unmanaged devices or unknown locations. Third, ensure Defender for Office 365 is configured with Safe Links and Safe Attachments active, and enable Zero-hour Auto Purge for messages classified as suspicious after delivery. Fourth, establish a procedure for immediately revoking sessions and tokens as soon as a suspicious sign-in pattern is detected. Review Entra Sign-in Logs weekly for impossible travel and sign-ins from unknown countries.
AiTM phishing is not a theoretical risk. The campaigns are active, the kits are inexpensive, and the targets are organisations of all sizes and sectors. The technical protection exists and can be deployed with an existing Microsoft 365 Business Premium licence. It is a matter of configuration, not budget. Want help setting up Token Protection, reviewing your Conditional Access policies, or strengthening your detection capability? Contact Zarioh for a concrete assessment of your current security posture.
Zarioh Digital Solutions
IT specialists from Utrecht, the Netherlands. We help businesses with Microsoft 365, AI agents, hosting and telephony — and share what we learn in practice. Follow us on LinkedIn
Security
Security
Security
