AiTM Phishing Exposed (2/2): Stop Session Hijacking

The session token is already captured. What happens next depends entirely on what you configured before the attack started.

Part 1 of this series covered how AiTM attacks work, why standard MFA provides no protection, and what a compromised tenant looks like from the sign-in logs. This article covers the response: the controls that prevent the attack, shorten the damage window, or surface an active compromise before significant data leaves.

Key Takeaways

Phishing-resistant MFA (FIDO2 or passkeys) is the only control that stops AiTM before a token is captured. The credential is bound to the legitimate domain and will not authenticate through a proxy.

Continuous Access Evaluation revokes stolen sessions near real time instead of waiting up to 90 minutes for the access token to expire naturally.

Token protection in Conditional Access binds access tokens to the device that authenticated. A stolen token is unusable on attacker infrastructure.

Requiring a compliant device in Conditional Access adds a compliance check that a replayed token from attacker infrastructure cannot satisfy.

Inbox rules created outside business hours are the most consistent early indicator of an active compromise. Most tenants have no automated detection for them.

What is the only control that stops AiTM before a token is captured?

Phishing-resistant MFA stops the attack before the proxy has anything to steal. The protection is not in the strength of the credential: it is in how the credential is bound. FIDO2 hardware keys and passkeys use public key cryptography tied to the legitimate origin: login.microsoftonline.com. When the AiTM proxy serves a different domain, the authenticator checks that domain against the registered relying party ID and refuses to sign. Authentication fails at that step. No session token is issued. The proxy captures nothing.

Standard push notifications and TOTP codes do not have this property. The proxy forwards the MFA challenge to the victim and the response back to Microsoft. The user sees a normal prompt. MFA completes. The proxy captures what follows.

The practical gap I see in most tenants: FIDO2 is enabled as an authentication method but not enforced. Security keys are registered in the tenant. Conditional Access still accepts push notifications as a satisfying MFA claim. The security key sits in a drawer while the user authenticates with the method AiTM is designed to bypass.

Two deployment paths exist. FIDO2 hardware keys (YubiKey, Feitian, and others) are portable and work across any browser on any machine. Passkeys stored in the Microsoft Authenticator app are device-bound, stored in the phone’s secure enclave, and require biometrics or PIN to use. Hardware keys offer wider portability. Authenticator passkeys are easier to deploy at scale without purchasing hardware. Both count as phishing-resistant MFA in Entra ID.

Configuring authentication strength in Conditional Access:

In the Entra admin centre, go to Protection > Authentication methods > Authentication strengths. The built-in Phishing-resistant MFA strength covers FIDO2 keys and passkeys and requires no custom configuration.
Open or create a Conditional Access policy. Under Grant, select Require authentication strength and choose Phishing-resistant MFA. This rejects push notifications and TOTP codes as insufficient.

For enterprises standardising on a specific hardware key, authentication strengths support AAGUID-based restrictions: you can limit the policy to keys from a specific manufacturer. Configure this under Authentication strengths > Advanced options.

Start enforcement with privileged accounts and users who handle payments, supplier relationships, or client negotiations. Those are the accounts AiTM campaigns target first.

How does CAE limit the damage once a session token is stolen?

Without Continuous Access Evaluation, a stolen access token remains valid until it expires. The default lifetime is 60 to 90 minutes. If you revoke a compromised session with CAE configured, Exchange Online, SharePoint, and Teams receive that revocation near real time. Microsoft states up to 15 minutes of latency is possible due to event propagation, but in practice it is far shorter than the 90-minute window you face without CAE. Without CAE, the revocation does nothing to the existing token. The attacker continues with the captured session for up to 90 minutes after you acted.

CAE responds to five critical events: account deleted or disabled, password changed or reset, MFA enabled for the user, administrator token revocation, and high user risk detected by Entra ID Protection. When any of these occur, CAE-capable applications enforce the change immediately rather than waiting for token expiry.

What I find consistently in post-compromise audits: CAE was never configured. The option exists in every Entra ID tenant at no additional cost, but the default state is not enforced. Administrators revoke sessions and believe the attacker is locked out. They are not. The captured session token is still valid and generating new access tokens. That 90-minute gap is enough time to complete a thread hijacking and redirect a supplier payment.

To configure CAE, open a Conditional Access policy in the Entra admin centre. Under Session, select Customize continuous access evaluation and set it to Strictly Enforced. This requires real-time reauthentication when a critical event occurs and blocks access from clients that cannot respect CAE signals. Critical event evaluation is included in all Entra ID tenants at no cost. Full CAE with Conditional Access policy enforcement requires Entra ID P1, included in Microsoft 365 Business Premium and E3. Microsoft 365 E5 includes Entra ID P2, which covers all P1 capabilities. The Microsoft documentation on Continuous Access Evaluation covers supported applications and client requirements.

What does token protection add to Conditional Access?

Token protection closes the portability gap that CAE does not address. When it is active, the access token issued after authentication is cryptographically bound to the specific device that completed the sign-in. An attacker who captures that token on a different machine cannot satisfy the proof of possession the token requires. The token is useless outside the device it was issued to.

One boundary to understand before deploying: token protection covers native applications only. Outlook desktop, Teams desktop, and OneDrive client are in scope. Browser sessions are not. AiTM attacks that steal browser session cookies fall outside what token protection can stop. The protection matters most in environments where post-compromise lateral movement happens through native app access rather than browser-based sessions.

CAE and token protection address different parts of the same problem. CAE shortens the window between revocation and effect. Token protection makes a captured token non-transferable from the moment it is issued. Used together, they reduce a 90-minute unchecked access window to near zero for supported native applications.

Configure it in a Conditional Access policy under Session: select Require token protection for sign-in sessions. Token protection is generally available on Windows and in preview on iOS and macOS. It has production support for Exchange Online, SharePoint, and Teams. Not all clients support it yet. Run the policy in report-only mode first, then pilot before enforcing. The Microsoft documentation on token protection covers supported clients and known limitations.

What other Conditional Access controls reduce the risk?

Three additional LIMIT-layer controls are worth configuring alongside CAE and token protection. None of them prevent the initial token capture, but each one reduces the attacker’s window or makes the stolen token harder to use.

Require compliant device. A compliant device grant requires that the device accessing corporate resources is enrolled in Intune and meets your compliance policy. A stolen session token replayed from attacker infrastructure fails this check because the attacker’s machine is not enrolled. This does not apply to all users (BYOD scenarios require a different approach), but for managed devices it adds a meaningful barrier.

Sign-in frequency. Under Session in a Conditional Access policy, set sign-in frequency to 1 to 4 hours for high-risk users. This forces reauthentication more frequently and shortens the window in which a stolen token can be used before the next auth check.

Persistent browser session: Never persistent. Also under Session, set Persistent browser session to Never persistent for unmanaged devices. This prevents browser sessions from surviving past the browser being closed, which reduces the useful lifetime of any captured session cookie.

These three controls are not replacements for CAE and token protection. They are additional layers that raise the cost and complexity of using a stolen token.

How do you detect an active compromise before the damage spreads?

Inbox rules are the most reliable early indicator of an AiTM compromise. Attackers create them within minutes of gaining access, typically targeting security alerts and Microsoft 365 notifications. By the time you find those rules, the attacker has had uncontested access. They are still the fastest signal available, and most tenants have no automated detection watching for them. Run this query in Microsoft Sentinel or Log Analytics to surface inbox rule creation events. Results are grouped per user so you see the full set of actions and destinations in one row:

OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| extend RuleParams = todynamic(Parameters)
| mv-expand RuleParams
| where RuleParams.Name in ("ForwardTo", "RedirectTo", "ForwardAsAttachmentTo", "DeleteMessage")
| extend ParamName = tostring(RuleParams.Name)
| extend ParamValue = tostring(RuleParams.Value)
| summarize
    Actions = make_set(ParamName),
    Destinations = make_set(ParamValue),
    FirstSeen = min(TimeGenerated)
  by UserId, Operation
| order by FirstSeen desc

For token replay detection, look for non-interactive sign-ins where the same user session originates from multiple countries within a short window:

AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| where UserPrincipalName has "@"
| summarize
    IPCount = dcount(IPAddress),
    IPs = make_set(IPAddress),
    Countries = make_set(tostring(LocationDetails.countryOrRegion)),
    Resources = make_set(ResourceDisplayName)
  by UserPrincipalName, bin(TimeGenerated, 1h)
| where IPCount > 2
| where array_length(Countries) > 1
| project TimeGenerated, UserPrincipalName, IPCount, Countries, Resources, IPs
| order by IPCount desc

Set both as scheduled analytics rules in Sentinel. The time between token capture and active threat is too short to rely on ad-hoc queries.

What is the right response when a session token is compromised?

Most incident response guides say investigate first, then act. For a compromised session token, that order is wrong. While you investigate, the attacker is inside active email threads. I have seen organisations spend two hours documenting a compromise while the attacker was redirecting a payment. Revoke first.

Step 1: Revoke all refresh tokens immediately. In the Entra admin centre, open the user profile and select Revoke sessions. With CAE configured, active sessions in supported apps terminate within seconds.

Step 2: Disable the account temporarily. This catches sessions in clients that are not CAE-capable and would otherwise remain active until token expiry.

Step 3: Check for and delete inbox rules. Run the Sentinel query above or review the mailbox rules directly. Document which rules existed and when they were created. That timestamp tells you when the attacker first had access.

Step 4: Check for OAuth consent grants. Attackers sometimes use the compromised session to consent to third-party OAuth applications that maintain persistent access after you revoke the session. In the Entra admin centre, check Enterprise applications > User consent for grants added during the compromise window.

Step 5: Audit file access and forwarding rules. Review which SharePoint and OneDrive files were accessed. Check whether mail forwarding was configured at the mailbox level, separate from inbox rules.

Step 6: Reset the password. Do this after step 1, not instead of it. A password reset alone does not revoke existing refresh tokens. If you reset the password first and skip the revocation, the attacker’s session may remain valid.

Step 7: Verify MFA methods before re-enabling the account. Confirm no attacker-added authentication methods are registered before the user authenticates again.

Frequently Asked Questions

What is the difference between a FIDO2 hardware key and a passkey in Microsoft Authenticator?

Both count as phishing-resistant MFA in Entra ID. A FIDO2 hardware key is a physical device (YubiKey, Feitian) that stores the credential in tamper-resistant hardware and works across any machine and browser. A passkey in Microsoft Authenticator stores the credential in the phone’s secure enclave and is tied to that device. Hardware keys are more portable. Authenticator passkeys are easier to deploy at scale without purchasing hardware.

Does FIDO2 work for all Microsoft 365 applications?

Browser-based FIDO2 is the most widely supported path and works for all Microsoft 365 web apps. Native desktop applications (Outlook, Teams) support FIDO2 on Windows through the authentication broker, either Windows Hello for Business or Microsoft Authenticator. This requires Windows 11 version 22H2 or later. Mobile apps support passkeys on iOS 17 and Android 14 and later. For tenants beginning the migration to phishing-resistant MFA, browser-based enforcement is the most practical starting point.

How quickly does a stolen token become unusable after I revoke a session with CAE enabled?

For Exchange Online, SharePoint, and Teams, revocation reaches CAE-capable clients near real time. Microsoft states up to 15 minutes of latency is possible due to event propagation time. Clients that do not support CAE, including legacy authentication paths and third-party applications that have not implemented the CAE client SDK, continue to use the token until it expires. Disabling legacy authentication is a prerequisite for CAE to be fully effective across your tenant.

Why does a password reset not revoke a stolen refresh token?

A password reset invalidates the password credential. It does not revoke refresh tokens issued before the reset. An attacker who captured a refresh token before the reset can continue generating new access tokens after the password changes. Revoking sessions in the Entra admin centre explicitly invalidates the refresh tokens. Both actions are needed. The session revocation must come first.

Can token protection break existing workflows?

Yes. Token protection is in preview and some clients cannot satisfy the proof of possession requirement. Enforcing it on affected users produces access failures. Before enforcing, run the policy in report-only mode to identify which sign-ins would fail. Pilot with a small group first. The Microsoft documentation on token protection lists supported clients — link in the token protection section above. Expand enforcement as coverage grows.

Start with FIDO2 enforcement on privileged accounts. That is where AiTM campaigns focus first, and phishing-resistant MFA is the only control that stops the attack before a token is captured.