PotSolutions › Modern Workplace › Session Token Theft

Zero Trust & Security

Session Token Theft: The Attack Path That Skips MFA

Multi-factor authentication is checked once, at sign-in. The session token issued afterwards is what every app actually trusts from that point on — and it’s what attackers go after next.

8 min read Updated July 2026

When a user signs into Microsoft Teams, Outlook, or any modern web app, they authenticate once and the app issues a session token so they aren’t asked to re-verify on every click. That token — not the password, not the MFA prompt — is what the app actually checks from then on. It’s convenient, and it’s also the reason session hijacking works even against organisations that have done MFA correctly.

Steal that token, and an attacker inherits the session exactly as it stood the moment it was issued — fully authenticated, MFA already satisfied, no further prompts required. There are two distinct ways this actually happens in practice, and they call for different mitigations.

Two Paths In

Cookie Theft vs. Interception

Cookie / File-Based Theft

Malware or an attacker with local access copies session cookies or token files directly off a compromised device. No network interception needed — the token is simply sitting on disk.

  • Requires some form of access to the device itself
  • Common vector: info-stealer malware run on an unmanaged endpoint
  • Phish-resistant MFA (FIDO keys, Windows Hello) doesn’t stop this — the token is stolen after MFA already succeeded

Adversary-in-the-Middle Interception

A proxy server sits between the user and Microsoft’s real sign-in page during a live login, capturing the session token — including the completed MFA challenge — the instant it’s issued.

  • No device access required, only a convincing phishing page
  • Tooling like Evilginx and Mamba 2FA automate this at scale
  • Detected and blocked differently — see our CSS phishing protection deep dive

Microsoft Teams’ classic desktop client used to store its session token in a predictable, user-accessible location under %AppData%\Microsoft\Teams, which made cookie-based theft almost trivially easy for anything already running on the device. The current Teams client no longer stores tokens there — a real improvement — but the underlying risk hasn’t gone away. Browsers and other apps still hold equivalent tokens, and any device without proper endpoint protection is still a viable target.

Why a Password Reset Doesn’t Help

This is the detail that catches people out: a session token’s validity is largely independent of the account password. Once issued, it remains usable until it either expires naturally or is explicitly revoked. Changing the password after a breach is discovered — the instinctive first response — often does nothing to the token an attacker already holds. If nobody revokes active sessions specifically, the attacker can keep using Teams, Outlook, or SharePoint as the legitimate user for as long as that token stays valid.

Standard MFA is checked once. After that initial challenge, the app trusts the session token for its full lifetime — which is exactly the assumption both cookie theft and AITM interception exploit.

The Fix

What Actually Closes This Gap

Continuous Access Evaluation + Device Compliance

This is the mitigation that matters most against cookie theft. A stolen token replayed from an attacker’s own machine is a token being used from a device that was never enrolled and never verified. Conditional Access, backed by Continuous Access Evaluation, re-checks device compliance and session risk in near real time rather than trusting the token blindly for its full lifetime — and a request from an unmanaged device gets refused, even with a technically valid token in hand. We cover the mechanics of this in detail in Device Compliance: Why Zero Trust Starts at the Endpoint.

Token Protection & Device-Bound Sessions

Token protection policies in Conditional Access, together with the hardware-bound Primary Refresh Token on Windows, cryptographically tie a session to the specific device that requested it. Copying the token file elsewhere produces something that simply doesn’t validate on a different machine — the theft succeeds, but the stolen artefact is worthless. Sign-in frequency and session-expiry controls in Conditional Access add a second layer, shrinking the window a stolen token stays usable even where full token binding isn’t yet in place everywhere.

Catching Interception at the Login Page

Token protection and device compliance mitigate the damage after a token exists. For AITM specifically, it’s better to catch the interception before a legitimate token is ever handed to the attacker’s proxy in the first place. Our own agentless CSS phishing protection validates each sign-in session against Entra ID’s real login flow in real time, showing users a clear visual confirmation on a genuine sign-in and a red warning the moment a proxy is detected sitting in the middle.

Monitoring as the Backstop

No single control catches everything. Session and sign-in monitoring — impossible-travel alerts, unfamiliar device fingerprints, unusual application access patterns — exists specifically to catch what slipped past the controls above. It won’t prevent the initial theft, but it materially shortens how long a stolen session stays useful before someone notices.

Continuous Access Evaluation Conditional Access Token Protection Primary Refresh Token Session Monitoring Defender for Endpoint

None of This Works in Isolation

Device compliance, Conditional Access, token protection, and login-time validation only add up to real protection when they’re deployed together and kept consistent as a tenant grows — not layered on ad hoc after an incident. We deploy this as one coherent baseline through Config365, rather than a pile of settings someone configured once and never revisited.

Related Reading

Device Compliance: Why Zero Trust Starts at the Endpoint The control that makes a stolen token unusable on an unmanaged device Agentless CSS Phishing Protection Catching AITM interception at the Microsoft sign-in page itself Modern Workplace & Enterprise Security The full Zero Trust baseline this control is part of

Get Started

Could a Stolen Session Token Still Get Someone In?

We’ll review your Conditional Access, token protection, and session controls, and close the gaps that let a stolen token keep working after MFA has already passed.

Start a Project View M365 Security Overview
Theme