AiTM Phishing Exposed (1/2): How Session Hijacking Works
AiTM phishing doesn't bypass MFA. It waits for MFA to succeed, then takes what comes next. This is how the attack works and why standard MFA provides no protection against it.
A user on your tenant authenticated this morning. MFA completed. Sign-in passed. By the time they opened Outlook, someone else was already reading their inbox.
In April 2026, attackers ran a coordinated campaign targeting Microsoft 365 users across 26 countries. Not because MFA failed. Not because users clicked something they should have recognised. The attackers waited for MFA to succeed, then took what came next.
I have seen this play out in tenant investigations. The sign-in log shows a clean authentication. MFA completed. Conditional Access passed. There is nothing unusual in the record, because the authentication was genuine. The compromise happened in the seconds between the server issuing a session token and the browser receiving it. By then, the damage was done.
Key Takeaways
- AiTM phishing steals the session token after authentication completes. MFA provides no protection against this
- Only phishing-resistant MFA (FIDO2 hardware keys, passkeys) blocks the attack entirely
- Continuous Access Evaluation (CAE) and token protection are the two controls most organisations have never enabled but should
Who was targeted?
The April 2026 campaign was not random. Healthcare and life sciences accounted for 19% of targets, financial services for 18%, professional services and technology for 11% each, according to the Microsoft Security Blog.
The sector distribution reflects attacker prioritisation, not a geographic or technical limitation. Healthcare and financial services hold high-value regulated data. Organisations in both sectors have strong incentives to avoid publicising breaches, which gives attackers more time to operate before detection.
What I find consistently when working with professional services firms: email is treated as low-risk data. It is not. A compromised inbox in a law firm, accounting practice, or consulting company contains client contracts, financial data, and credentials shared by email. Healthcare organisations know they are targets. Professional services organisations often do not, and their inboxes contain exactly the kind of active supplier and client relationships that make conversation takeover profitable.
How does the attack actually work?
The attack starts with an email. Not a poorly written phishing attempt with suspicious formatting, but a well-structured HR communication referencing a code of conduct review or a disciplinary notice. The subject line creates urgency. The PDF attachment looks routine.
The lure quality in these campaigns has shifted significantly. Cofense’s 2026 annual report found that 18% of all malicious emails in 2025 were AI-generated conversational attacks, with the pace of attacks more than doubling from one every 42 seconds in 2024 to one every 19 seconds in 2025. The grammar is correct. The context is plausible. The urgency feels real. Defence has to shift toward controls that work regardless of whether the user recognised the email.
When the victim opens the PDF, they find a link. Clicking it leads through multiple CAPTCHA pages. This filters out automated security scanners, which will not interact with CAPTCHAs, while looking like standard bot protection to the victim.
After the CAPTCHA, the victim lands on a login page that appears identical to Microsoft’s. It is not. The page is a proxy-rendered replica hosted on the attacker’s domain. The attacker’s server sits in the middle, forwarding all traffic between the victim and Microsoft in real time.
The victim enters their password. Microsoft prompts MFA. The victim approves it. Authentication completes successfully. Everything worked exactly as designed.
Then the proxy captures the session cookie.
As Microsoft issues the session cookie confirming authentication, it passes through the attacker’s proxy. The proxy captures a copy and forwards the cookie to the victim’s browser. The victim’s session continues to work normally. They notice nothing. The attacker loads that same cookie in their own browser. Microsoft sees a valid authenticated session. No password required. No MFA prompt appears.
What the attacker captured is not just a credential that expires in an hour. The session cookie maps to a refresh token that remains valid until explicitly revoked, with a default inactivity window of 90 days. The attacker does not need to keep the proxy running after the initial capture. They use the refresh token to silently generate new access tokens for as long as the refresh token stays active. That window closes only when someone in your organisation notices and revokes it.
Within minutes, the attacker creates inbox rules to delete security alerts and Microsoft notifications. Then the actual work begins.
The attacker opens the inbox and reads. Not just to copy data out, but to understand what is in motion. Active threads with suppliers about pending payments. Ongoing negotiations with clients. An invoice chain that has been going back and forth for two weeks. They look for anything with financial context and a relationship that already has trust built into it.
Then they reply. From the compromised account. Within the existing thread. With details only someone who had read the conversation would know.
The contact on the other end has no reason to pause. The email comes from the right address. It references the right invoice number. The tone matches. Thread hijacking is not a rare tactic. It is the standard playbook after a mailbox is taken.
The most common outcome: a message arrives in an active payment thread with updated bank details. Accounts payable processes it. The money leaves. The real vendor follows up weeks later asking why the invoice has not been paid.
Why didn’t MFA stop it?
MFA stopped exactly what it was designed to stop: an attacker trying to log in with a stolen password. It does not protect what happens after a successful login.
When you complete MFA, Microsoft issues a session cookie and stores it in your browser. That cookie functions like a physical key card. Once issued, it works independently. You do not need to re-authenticate every time you open a page or switch between apps. The AiTM proxy sits between you and Microsoft during authentication, so the session cookie passes through the attacker’s server before reaching your browser. The attacker captures a copy. They do not need to pass through the entrance you used. They have a duplicate key card, and it works for as long as the underlying refresh token remains active.
The failure point is not MFA. It is the assumption that authentication is the last line of defence. MFA is a gate at the entrance. The session cookie is the badge you carry inside. If someone copies the badge, the gate is irrelevant. The response has to be about revoking the badge quickly, not making the gate harder to pass.
MFA confirmed who authenticated. The session cookie confirmed nothing about who used it afterwards. That distinction is what AiTM exploits.
What does this look like in a real tenant?
The sign-in log shows a successful authentication. MFA completed. Conditional Access passed. Nothing looks wrong, because the authentication itself was genuine.
What appears later: a sign-in from an unfamiliar IP or country, using the session that was established correctly. By default, no alert fires. The sign-in does not look anomalous unless you have Continuous Access Evaluation configured to monitor the session’s ongoing validity, or token protection bound to the device that authenticated.
Entra ID Protection’s sign-in risk detection is not reliable for real-time AiTM detection. The initial authentication is genuine: the correct user, the correct MFA, the correct device. Risk signals may appear later when the stolen token is replayed from an attacker-controlled IP, but even then confidence is often low. By the time risk is flagged, the attacker has had minutes to hours of uncontested access.
The inbox rules are what most tenants notice first. Rules created to delete security alerts, Microsoft 365 notifications, or messages from specific senders. By the time someone finds those rules, conversation takeover has often already started.
What I find when I audit tenants after a compromise: CAE is not enabled, token protection is not configured, and there is no monitoring for inbox rules created outside business hours. The attack succeeded not because the controls do not exist, but because they were never turned on.
The infrastructure behind these attacks is increasingly commoditised. Open-source toolkits like Evilginx2 and EvilProxy provide ready-built AiTM proxy infrastructure pre-configured for Microsoft 365, available to anyone who can run a command line. In May 2026, the FBI issued a warning about Kali365, a phishing-as-a-service platform distributed via Telegram that goes further, adding AI-generated lures, automated campaign templates, and built-in OAuth token capture targeting Outlook, Teams, and OneDrive. The volume will increase. The lure quality will not drop.
What do you do about it?
Phishing-resistant MFA (FIDO2 or passkeys) is the only control that prevents the attack entirely, because the credential is bound to the legitimate domain and will not authenticate through a proxy. Continuous Access Evaluation and token protection in Conditional Access address what happens after a token is stolen: they shorten the window in which it remains usable and can bind it to the device that authenticated. Inbox rule monitoring is where most tenants can realistically catch an active compromise before significant data leaves.
Part two covers the configuration of each control, the detection queries that catch token replay in Sentinel, and how to run incident response when a session token has been compromised.
Frequently Asked Questions
Does MFA protect against AiTM phishing?
Standard MFA (push notifications, TOTP codes) does not. Microsoft’s analysis of the April 2026 campaign confirmed that every targeted account had MFA enabled. Only phishing-resistant MFA (FIDO2 hardware keys or passkeys) prevents the attack, because the credential is bound to the legitimate domain and will not authenticate through a proxy.
What is a session token and why does it matter?
After authentication completes, Microsoft issues a session cookie and a refresh token. The session cookie gives access to apps without re-authenticating. The refresh token is what makes the stolen credential dangerous: it remains valid until explicitly revoked, with a default inactivity window of 90 days. Access tokens expire in 60 to 90 minutes, but the refresh token silently generates new ones. An attacker who captures the session cookie after an AiTM attack does not need to maintain a proxy connection. They use the refresh token to obtain fresh access tokens indefinitely. That is why revoking sessions is only effective if refresh tokens are also revoked.
Is Continuous Access Evaluation available on my licence?
Critical event evaluation is available in all Entra ID tenants at no additional cost. Events that trigger it include account disabled, password reset, MFA enabled for user, and administrator token revocation. High user risk also triggers CAE, but generating that signal requires Entra ID Protection, which is a P2 feature. Full CAE with Conditional Access policy enforcement requires Entra ID P1, which is included in Microsoft 365 Business Premium, E3, and E5. Configure it in the Entra admin centre under Protection > Conditional Access, then open or create a policy and set the session control to Customize continuous access evaluation.
How quickly should I act if I find a suspicious inbox rule?
Act immediately. Revoke the user’s sessions first, then investigate. Do not investigate first and revoke later. The order matters. By the time you find the rule, the attacker may already be inside active email threads.
Why do attackers reply from within existing threads rather than starting new emails?
Trust. A reply within an existing thread inherits all the context of the conversation: the right names, the right subject line, the right history. The recipient has already established a relationship with the sender. A new email from the same address would still raise less suspicion than a cold outreach, but a reply in a thread the recipient initiated themselves raises almost none. That is why thread hijacking is consistently one of the most common techniques in business email compromise.