Modern Microsoft 365 authentication issues tokens — essentially digital passes — that allow users to stay signed in across sessions without re-entering credentials. These tokens are stored in the browser or application and presented automatically on each request. If an attacker steals a valid token, they can use it to impersonate the user without needing their password or passing MFA, because the authentication has already been completed.

Session hijacking via unusual IP change is one of the clearest signals that a token has been stolen and is being used from a different location. When the IP address associated with an active session changes dramatically — particularly to a different country or an anonymising service like Tor or a commercial VPN — it suggests the session is no longer being used by the original user.

This is one of the primary techniques used in Adversary-in-the-Middle (AiTM) phishing attacks, where a proxy intercepts the authentication flow and captures the token in real time.

• Attacker intercepts an AiTM phishing proxy session, capturing the authentication token in real time after the user completes MFA — no password or second factor required on the attacker’s device
• Stolen token used from a different country or anonymising infrastructure, granting full access to whatever Microsoft 365 services the user is authenticated to
• Inbox forwarding and mail-hiding rules created within the compromised session window, persisting after the token is eventually revoked
• Sensitive SharePoint documents accessed and shared externally during the session, with no MFA friction or additional challenge
• User account impersonated in Teams messages or emails, enabling social engineering of colleagues and business partners from a trusted, legitimate identity
• Session used to pivot — the compromised user’s existing OAuth consents or shared application access leveraged to reach adjacent services or accounts
• Attacker acts within minutes of token capture — the window between session hijack and persistence establishment is very short, making rapid detection critical
• Token replay may continue for hours or days if Continuous Access Evaluation (CAE) is not enabled, with no sign-in failures or alerts to indicate ongoing abuse

Some IP changes during an active session are legitimate:

• Users on mobile devices moving between Wi-Fi and cellular networks
• Users connecting through a corporate VPN that has multiple exit nodes or changes IP periodically
• Users travelling and connecting from different locations in the same session
• Users on split-tunnel VPN configurations where the IP visible to Microsoft may vary

The key differentiators for a suspicious IP change are: geographic implausibility (the IP change implies travel that couldn't have happened in the time elapsed), use of anonymising infrastructure (Tor, datacenter IP ranges, commercial proxy services), and sudden appearance in a country with no prior sign-in history for that user.

• In Entra ID sign-in logs, review the session in question — note the original IP/location and the new IP/location, and assess whether the change is geographically plausible
• Check whether the new IP belongs to a known VPN, Tor exit node, or commercial proxy (tools like IPInfo or Defender threat intelligence can help)
• Review whether the user has an active travel request, remote work arrangement, or is known to use a VPN
• Look at what actions were taken during the session, particularly after the IP change — email rule creation, file access, or admin actions are high-severity indicators
• Check whether the user received any phishing emails recently that may have contained an AiTM link
• Verify with the user directly (via phone or secondary communication channel — not email) whether the session activity is theirs

1. If the IP change cannot be explained by a known VPN or travel, revoke all active sessions for the account immediately via Entra ID (Users > select user > Revoke sessions)
2. Reset the user's password using a secure channel — do not rely on email reset if the mailbox may be compromised
3. Re-enrol or verify MFA for the account before allowing sign-in to resume
4. Review the user's mailbox for any rules created or modified during the suspicious session window — delete any unauthorised rules
5. Check SharePoint and OneDrive activity logs for file access or sharing that occurred during the session
6. If an AiTM phishing attack is suspected, search for similar phishing emails sent to other users in the organisation and block the relevant URLs/domains in Defender
7. Consider enabling Continuous Access Evaluation (CAE) for the organisation, which allows near-real-time session revocation when anomalies are detected

Overe Auto-Response: The Possible Session Hijack - Unusual IP Change alert can be configured in Overe to trigger automatic session revocation or account block when this activity is detected. Review your Auto-Response settings under Org Config > Auto-Response to ensure an appropriate automated action is in place for this high-severity indicator.

Microsoft: Continuous Access Evaluation

Microsoft: Defend against AiTM phishing attacks

Microsoft: Sign-in log activity details in Entra ID

After investigating a session hijack alert, review these related risk areas:

• Suspicious Inbox Rules — a compromised session is frequently used to create mail-hiding rules immediately
• Risky Inbox Forwarding Rules — attackers establish forwarding to maintain access after the session is revoked
• Phishing URL Clicked — AiTM session hijacks typically begin with a phishing link clicked by the user
• Mailbox Audit Bypass — if audit bypass is enabled, forensic coverage of actions taken during the compromised session may be incomplete
• CA MFA Bypass Paths — review whether Conditional Access policies could be strengthened to limit token replay attacks