MFA Token Theft: New Risks & Responses

Summary

Session token theft is now the dominant way attackers bypass MFA in Microsoft 365, accounting for around 80% of MFA-bypass breaches. Adversary-in-the-Middle phishing proxies the real login page, then copies the session token issued once the user passes MFA. Because that token is a bearer credential, it can be replayed from anywhere. MSPs cannot efficiently review these signals manually across dozens of tenants, but inforcer TDR detects these attacks and identifies the conditional access gaps that allowed them.

MFA Token Theft: New Risks & Responses

Session token theft is not a new threat. But it is a growing risk for businesses running Microsoft 365 environments, and one that MSPs serving these customers must be prepared to address.

New technology has allowed threat actors to increase both the volume and sophistication of attacks designed to steal session tokens. When these attacks are successful, the attacker can bypass MFA entirely and gather information from inside the tenant for weeks or months before initiating a breach.

Read on to learn how token theft works, how it has evolved in recent years, and what MSPs can do to protect their business customers.

The origins & evolution of session token theft

Microsoft 365 has issued session tokens for as long as Multi-Factor Authentication has existed, because they prevent users from needing to re-authenticate every time they open a file. But these tokens can be stolen, and doing so is currently easier than ever.

Here’s a quick breakdown of how session token theft originated, and why it’s a popular tactic for attackers:

• Before MFA, security used to rely entirely on usernames and passwords. It was simple, but it was also vulnerable. An attacker could simply phish credentials and use them to access sensitive information.
• MFA changed things by requiring the user to pass a secondary verification check before issuing a session token. This token is basically a temporary ID that gets stored in the user’s browser so they can navigate between different apps without having to manually reenter their credentials each time.
• Since threat actors could no longer access a tenant with stolen usernames and passwords alone, they responded by refocusing their attacks on the session tokens themselves.

Microsoft's 2025 Digital Defense Report attributes around 80% of MFA-bypass breaches to session token theft. And the way these attacks work means they can succeed even against well-managed tenants.

How session token theft works: Adversary-in-the-Middle phishing explained

Adversary-in-the-Middle phishing is the dominant method attackers use to steal session tokens. This technique is designed to intercept the live credential issued after MFA completes, and normally includes the following steps:

1. The lure. The target receives a convincing email or message with a link. It mimics a service they use every day, usually Microsoft 365, Google Workspace, or an HR portal, and it manufactures urgency so the recipient acts before they think.

2. The proxy. Clicking the link does not lead to the real site, but it does not lead to an easily-identifiable fake version either. Instead, it brings the user to a reverse-proxy server that the attacker controls. That server pulls the genuine, live login page from the real service and renders it in the victim's browser. Everything on screen is authentic, because it is authentic. It is simply being relayed.

3. The relay. The victim enters their username and password. The proxy passes them to the real service, which responds with an MFA challenge such as a code, app prompt, or push notification. The proxy passes that challenge straight back to the victim, who approves it on their device without seeing anything suspicious.

4. The interception. The real service verifies the MFA response and issues a valid session token. That token travels back through the attacker's server on its way to the victim's browser. The proxy copies it in transit.

5. The replay. A session token is a bearer credential, meaning whoever holds it is treated as the authenticated user. The attacker imports the stolen token into their own browser and gains access to the account.

This kind of attack requires no password and no further interaction with the victim. The user completed every step correctly. MFA functioned exactly as designed. The session was compromised anyway.

Why session Token theft is now easier than ever

Initially, it was reasonably difficult for a threat actor to successfully conduct an attack of this kind. Creating a convincing lure required the threat actor to write clean copy in language the target would find believable, build a page that looked right, and set up infrastructure to proxy the traffic. AI has unfortunately removed most of that cost.

Phishing-as-a-service kits now exist that handle proxying on the attacker’s behalf, and generative tooling can produce polished, plausible lures at volume. The technical bar to run a campaign that defeats MFA is now low enough that skill is barely a factor.

However there are still ways to identify a likely AitM attack, and spotting them quickly is essential for protecting the data threat actors are attempting to reach.

Related: How Microsoft Became the #1 Attack Surface for MSPs

Possible signs of session token theft

A hijacked session often leaves traces, and they are easy to identify once you know what to look for:

• Session IP change. A session that begins on one IP address and continues from a different one, with no re-authentication in between, is the clearest indicator of a replayed token.
• Impossible travel. Sign-ins from two geographies separated by more distance than the time to travel between them reasonably allows.
• Sign-in anomalies. Unfamiliar device or browser fingerprints, unusual sign-in times, hosting-provider or VPN IP ranges, or authentication patterns that do not match the user's history.

Individually, these signs may not always be enough to definitively point towards an attack. Users frequently travel, work from cafés, and switch devices. What matters more is correlation: the specific combination of a legitimate MFA success followed by session activity that no longer matches the person who passed it.

Unfortunately, this is exactly the kind of context that many security products are unable to provide. And manual detection is not a reliable strategy for MSPs tasked with protecting dozens of tenant environments.

Why manual threat detection is inadequate for MSPs

In theory, an analyst could catch session token theft by manually reviewing sign-in logs. But in practice, the amount of work required to detect such attacks on an ongoing basis makes it less than feasible for MSPs.

The person responsible would need to open the sign-in logs for each managed tenant and review every single authentication event. Then they would need to identify and investigate anything that appeared out of the ordinary, checking it against the IP’s reputation, the user’s normal patterns, their location, and other factors. And this work would never end, because tokens can be stolen at any time and used within minutes. It would be a full-time role, even for a single tenant.

But MSPs are typically responsible for protecting dozens or hundreds of tenants, each with its own baseline of normal behavior, its own travelling users, and its own log volume. This makes manual detection an all but impossible strategy for MSPs guarding their customers against token theft.

Effectively protecting tenants before and after token theft

If manual review is not viable, the alternative is tooling. But successfully protecting a tenant against token theft involves two separate areas of focus: before and after an incident occurs.

Security teams often describe these jobs using the terms “left of boom” and “right of boom”. The "boom" is the moment of compromise, so left of boom covers everything that happens before it: hardening configurations, enforcing policy, closing gaps, and reducing the number of ways in. Right of boom covers everything after: detecting the intrusion, containing it, removing the attacker, and fixing whatever let them through.

Tenant management is a left of boom service. An MSP offering this kind of support is responsible for ensuring that every tenant is configured correctly and stays that way. They apply security baselines, update policies, and remediate drift. This work genuinely reduces attack surface, and it remains essential.

But session token theft is fundamentally a phishing problem, and phishing succeeds on user error. A well-configured tenant does not stop someone clicking a link and approving a prompt they believe is legitimate. The user's judgement is the failure point, and no amount of tenant hygiene can prevent it.

That means some attacks will still succeed regardless of how well the environment is managed. This is exactly why MSPs need a right of boom solution alongside their management tooling—and ideally one that complements their existing left of boom platform.

Addressing token theft via inforcer TDR

inforcer TDR is the right of boom software our team developed to complement our multi-tenant management platform, which is rebranding to 365 Manager. It enables MSPs to continuously monitor every managed tenant for potential signs of a breach, then correlates these signals using deep Microsoft telemetry and separates the ones that likely represent an attack from isolated events.

This provides context that most other threat detection solutions are unable to supply, allowing MSPs to spend more time responding to real threats and less time dealing with false positive alerts triggered by ordinary user actions. It also shrinks the detection window, allowing MSPs to identify attacks much faster than manual review allows.

But detection is only half of what TDR does. Whenever it flags an incident, it also identifies the gap in the tenant environment that allowed the attack to succeed and streamlines the remediation process. This means every incident resolved can be used to harden the tenant against future attacks.

Here’s an example:

• A stolen token is replayed from an unmanaged device in another country
• inforcer TDR alerts the MSP that conditional access was not configured
• Since conditional access is what prevents tokens from being used by devices outside the business, there was nothing preventing that token being used from anywhere in the world
• The MSP can now configure conditional access properly—or make the case that their customer needs to purchase a Microsoft 365 license that includes Entra ID P1 and conditional access if they don’t have one already

Related: Scalable Entra ID policy management for MSPs serving multiple tenants

Using threat detection to drive licensing conversations

This is where right of boom solutions like inforcer TDR deliver value beyond immediate security outcomes.

Moving customers up to Business Premium can be a challenge for MSPs. Customers do not always see the value in purchasing a more expensive license than the one they already have, and abstract arguments about attack surface rarely move that discussion very far.

inforcer TDR gives MSPs something more concrete to work with by:

• Showing the customer a real attack in their own environment
• Naming the specific control that would have blocked it
• Pointing to the license that enables that control.

This changes the nature of the conversation, because the customer is now looking at the fix for something that already happened to them, with a clear line drawn between the incident and the gap that allowed it.

For MSPs, this can turn a security product into a growth lever. inforcer TDR detects and contains the attack, then hands you the evidence you need to close the upgrade that prevents the next one.

Learn More: The Ultimate Guide to M365 Business Premium: A Must-Have for MSPs

Is your security offering evolving faster than session token theft?

Session token theft will likely only become easier and more common as the tools and techniques required to perform this kind of attack become even more accessible. And the human error it depends on is not something any configuration can eliminate.

The only practical response to these attacks is for MSPs to cover both sides of the boom: manage tenants properly so there are fewer ways in, and run detection that catches the attacks that get through anyway. Pairing 365 Manager with inforcer TDR covers both, and gives you a repeatable way to demonstrate to customers why the licensing they need is worth paying for.

Frequently Asked Questions