Session Hijack via Unusual IP Change

Why this risk matters

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.

What happens if this is abused

With a stolen session token, an attacker has full access to whatever Microsoft 365 services the user is authenticated to — typically Exchange Online, SharePoint, Teams, and any connected applications. Crucially, this access doesn't require the user's password and bypasses MFA entirely because authentication already occurred.

Common attacker actions after session hijack include: reading and exfiltrating emails, setting inbox forwarding or hiding rules, accessing sensitive SharePoint documents, impersonating the user in Teams or email, and using the session to pivot to other accounts or services the user has access to.

Because the attacker is using a valid session token rather than credentials, many detection mechanisms that rely on failed logins or MFA challenges don't trigger. The session may appear legitimate until the IP anomaly is flagged.

When this is expected or acceptable

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.

Checks to perform before taking action

  • 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

Safe remediation steps

  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.

Related risks and follow-on checks

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
TBD CTA