Microsoft 365 Session Token Theft: Why MFA Passes and the Attacker Still Gets In

Every few months a story goes around describing a phishing kit that "bypasses MFA," and the reaction inside IT teams is roughly the same: mild alarm, a check that MFA is still switched on, and then back to work. That reaction is understandable and it is the wrong one, because the attack does not bypass MFA at all. It lets MFA work perfectly. The user types the password, gets the prompt, approves it, and signs in — and the attacker walks away with the thing Microsoft handed over at the end of that process. This article explains what is actually taken, which control genuinely stops it, and — more usefully — the specific limits of the controls most organizations have already been sold.

What is actually stolen

When you sign in to Microsoft 365, the end of the sign-in is not the password and it is not the authenticator prompt. It is a token: a signed statement from Microsoft Entra ID saying this browser, on this device, has proved who it is. Your browser stores it and presents it on every subsequent request, which is why you are not asked to sign in again every time you open Outlook on the web.

An adversary-in-the-middle phishing kit is a reverse proxy. The victim clicks a link and lands on infrastructure the attacker controls, but what they see is the genuine Microsoft sign-in page, because the proxy is fetching it live from Microsoft and passing it through. Everything the victim types goes forward to Microsoft. Everything Microsoft sends back goes to the victim. The password is real, the MFA prompt is real, the approval is real, and the sign-in succeeds — on the attacker's machine as much as the victim's, because the proxy sits in the middle of the conversation and keeps a copy of the session cookie Microsoft issues at the end.

From that point the attacker replays the cookie and is inside the mailbox. They do not need the password again. They do not need the authenticator again. Changing the password later does not, by itself, disturb them. This is why "we have MFA" is simultaneously a true statement and an irrelevant one against this specific attack: MFA did its job, and the job was finished before the theft happened.

The one control that breaks the attack

Passkeys, Windows Hello for Business, FIDO2 security keys and certificate-based authentication are described as phishing-resistant, and the reason is mechanical rather than marketing. When one of these credentials is created, it is bound to the address of the site that created it. When the browser later asks it to sign in, the credential checks the address it is being asked to sign in to. A proxy on a lookalike domain is a different address, so the credential does not produce a signature at all. There is nothing for the proxy to relay, and no session is created — so there is no cookie to steal.

Note the shape of that: the attack does not get partway and then fail. It cannot start.

Here is where most organizations lose the benefit. Rolling out passkeys and telling people to register them does not close the gap, because the phishing page will simply offer the user a password and an authenticator prompt instead, and the user — who has both — will use them. The control only bites when a Conditional Access policy requires a phishing-resistant method, so the real Microsoft endpoint refuses to complete the sign-in with anything weaker. Microsoft ships this as a built-in authentication strength you select in the policy's grant control; you do not have to define it yourself.

This is also why the method matters and not just the presence of MFA. If your tenant is still enforcing multi-factor authentication the old way, per account rather than through policy, there is no place to require a strength at all — that distinction is covered in per-user MFA vs Security Defaults vs Conditional Access. And if a meaningful share of your users are still on text-message or voice-call codes, they are on the weakest end of the range at exactly the moment Microsoft is retiring it, which is its own piece of work: the SMS and voice MFA retirement.

The sequence that works in practice is unexciting and worth following exactly:

1. Find out who can actually move today. Microsoft publishes a workbook for this at aka.ms/PasswordlessWorkbook, which reports registration and usage across the tenant.
2. Create the policy in report-only mode and read the sign-in logs for a week. This tells you which apps and which people would have been blocked, before anyone is.
3. Enforce it by group, starting with administrators, then finance and the executive team, then everyone the workbook shows is ready.
4. Leave the rest on the old path, on purpose, with a written list and a date. An exception you have named is a plan; an exception you have not noticed is the way in.

What phishing-resistant sign-in does not do

It protects the moment of sign-in. It does not protect the token afterwards. If malware is already running on the laptop, it can read tokens out of the browser or the token cache regardless of how strong the original sign-in was. That is a different attack with a different answer, and it is the reason the following controls belong beside it rather than instead of it.

Require a compliant or hybrid joined device

This is the control that does the heavy lifting for the browser session, and it is usually the one that gets deferred because it needs device management to be in order first. A stolen cookie replayed from the attacker's own machine fails the device requirement, because that machine is not enrolled and cannot prove it is. Pair it with a policy that blocks device platforms you do not support: a policy that only applies to platforms you have listed can be sidestepped by an attacker whose traffic appears to come from one you have not.

Token Protection — read the scope before you buy it

Token Protection cryptographically ties a token to the device it was issued to, so a copy lifted onto another machine is useless. It is generally available for desktop and mobile applications on Windows, iOS and macOS, covering Exchange Online, SharePoint Online and Teams.

It does not cover browser sessions.

That single sentence is why we are calling it out here rather than listing it as the answer. The browser session is precisely what an adversary-in-the-middle proxy takes. Token Protection is a real and worthwhile control against malware stealing tokens off a managed endpoint, and it is not the control that answers this attack. If a proposal you are reading offers Token Protection as the fix for proxy phishing, that is a scope error worth raising before the work starts, not after.

Continuous access evaluation, and its honest arithmetic

Continuous access evaluation lets Microsoft 365 services react to a critical event — an account disabled, a password changed, sessions revoked, a high user risk detection — in close to real time instead of waiting for the token to expire. Microsoft's stated propagation for those events is up to about fifteen minutes.

The trade-off is rarely mentioned. CAE only shortens exposure when something fires an event. If nothing is detected, a CAE-capable session can run for up to 28 hours, and a shorter token lifetime you configured elsewhere is ignored for those sessions. In other words, CAE converts your exposure from "fixed and short" to "very short if you detect it, longer if you do not." That makes detection quality a condition of CAE being a net gain, not an optional extra alongside it.

If it has already happened: the order matters

The most common containment mistake is also the most intuitive one. Someone reports a suspicious sign-in, the help desk resets the password, everyone relaxes, and the attacker is still reading mail an hour later.

A password change ends sessions that depend on that password. A session cookie captured after a completed sign-in does not depend on it. Microsoft documents this directly in its guidance on refresh tokens and on revoking access in an emergency: a self-service reset or a user-initiated change does not end sessions that were not established with the password, and even an administrator reset from the admin center leaves that class of cookie alive. Sessions have to be revoked as a separate, explicit act.

Microsoft's own token theft playbook sets the order: disable the account, revoke sessions, disable the user's registered devices, then investigate. Two steps in it get missed constantly and both matter more than they sound:

• Delete authentication methods the attacker added, before re-enabling the account. Registering a new authenticator or an alternate email is the standard way to keep access after the cookie dies. If you re-enable the account without clearing those, you have handed the account back with the attacker's key still in it.
• On hybrid accounts, reset the on-premises password twice. Microsoft's stated reason is to limit pass-the-hash exposure where on-premises password replication lags.

Then go looking for the things that outlive the session: inbox rules that move or delete mail, new forwarding addresses, consented applications, and anything that changed on the mailbox during the window.

The gaps nobody puts in the proposal

Every control above has documented edges. A plan that does not name them is not finished, and these are the ones that decide whether the work holds:

• Break-glass accounts are excluded from all of it. Microsoft's own policy templates instruct you to exclude emergency access accounts, so the tenant does not lock itself out on a misconfiguration. That is correct advice, and it means those accounts are the undefended path. They need hardware keys held physically, long random credentials, and a high-priority alert on any sign-in — because nothing else is guarding them.
• Conditional Access does not cover every role type. Policies apply to built-in directory roles. Custom roles and roles scoped to an administrative unit are not covered the same way, and calls made by service principals are not caught by a policy scoped to users. A related point worth checking at the same time: a stolen session belonging to someone holding a standing administrator role is a much larger event than one belonging to a user, which is the argument for eligible rather than permanent role assignments.
• Third-party MFA blocks the strongest control. External authentication methods are not compatible with authentication strengths. A tenant using an outside MFA provider cannot select the phishing-resistant strength and falls back to a plain "require MFA" grant, which is what the proxy defeats. This is a question to ask in the first conversation, not during implementation.
• Not every device can take a phishing-resistant credential. Microsoft's readiness guidance rules out Windows 8.1 and earlier and Windows Server, iOS 16 and earlier, Android 13 and earlier, and macOS 12 and earlier, with virtual desktops and Linux needing their own approach. Shared and kiosk devices are a separate case again. Budget security keys for those populations rather than promising complete coverage.
• Everyone needs a second registered method. Microsoft recommends at least two, and the reason is operational: if a single key is lost and there is no second method, the recovery path becomes a help desk call, and a help desk that can restore access over the phone is a social-engineering target.

About the numbers in the news

This subject comes with alarming statistics attached, and they deserve handling with some care — partly because accuracy is the point, and partly because an IT director who checks one figure and finds it overstated will discount everything beside it.

The figures circulating in August 2026 about a kit called Mirage2FA — thousands of targeted accounts across dozens of countries, with a majority of victims in the United States — trace to a single source: telemetry published by the sandbox vendor ANY.RUN. That research is real and the arithmetic is internally consistent. Two qualifications travel with it and usually get dropped. First, ANY.RUN describes the counts as potential impact rather than independently confirmed compromises. Second, the underlying sample is files and links that researchers and customers chose to submit to a malware sandbox, so it has no denominator: it supports "this was seen a lot" and it does not support a rate, a share, or a claim about how common the kit is relative to anything else.

Two further points of context. The kit was documented publicly by other researchers in June 2026, so August coverage describing it as newly discovered is late rather than breaking. And the technique itself — proxy phishing that harvests session cookies — has been documented since 2022 and predates that. The reason to act is not that something new appeared this month. It is that the technique has been available and cheap for years, and the control that answers it is a policy setting most tenants have not switched on.

One practical warning that follows from the same research: do not let this turn into an exercise in blocking published indicators. The loader path in that campaign is a rotating pattern rather than a fixed address, and the hosting moves. Blocking a specific URL or IP produces a ticket you can close and almost no protection. The identity controls work no matter which kit is used next.

What to check this month

In rough order of how much protection you get per hour spent:

1. Does any Conditional Access policy require a phishing-resistant method, or do your policies only require MFA? If it is the second, that is the gap this article is about.
2. Are administrators covered by that policy today, and are they using it — not merely registered for it?
3. Do you require a compliant or hybrid joined device for access to Microsoft 365, and do you block device platforms you do not manage?
4. Does your help desk know that a password reset is not containment, and does the runbook say to revoke sessions and clear attacker-added authentication methods before re-enabling an account?
5. Are your break-glass accounts on hardware keys, and does a sign-in with one raise an alert somebody actually receives?
6. Is device code flow blocked where you do not need it? That is a separate route to the same outcome, and it is the subject of how device code phishing actually works — worth reading if your answer here is "we have never checked", because blocking it is free and does not need a premium license.
7. Are the detections wired up — the sign-in risk detections in Entra ID Protection, and the stolen-cookie and proxy-phishing alerts in Defender — and does an alert reach a person rather than a mailbox nobody opens?

Most of these are configuration rather than purchase. Conditional Access and Token Protection need Entra ID P1, which is included in Microsoft 365 Business Premium, E3 and E5. Risk-based policies and the identity risk detections need P2. Device compliance needs Intune. The coordinated response to proxy phishing needs the Defender products deployed together. It is worth being clear-eyed about that split before designing around risk-based policies in a tenant that does not license them.

The one-sentence version

If your tenant requires multi-factor authentication but does not require a phishing-resistant method, and you have never revoked a session as a deliberate step, then the attack described here works against you today, and the first fix is a policy change rather than a product.

---

Sources

• Microsoft Learn — Token Protection in Microsoft Entra Conditional Access (supported applications and platforms; browser scope)
• Microsoft Learn — Protecting tokens in Microsoft Entra ID (device compliance, risk-based policy, device code flow, network enforcement)
• Microsoft Learn — Continuous access evaluation (critical events, propagation time, session lifetime)
• Microsoft Learn — Refresh tokens in the Microsoft identity platform, and Revoke user access in an emergency (what a password change does and does not end)
• Microsoft Learn — Token theft playbook (containment order, clearing attacker-registered authentication methods, hybrid password reset guidance)
• Microsoft Learn — Passkeys (FIDO2) in Microsoft Entra ID, and Overview of Conditional Access authentication strengths
• Microsoft Learn — Plan a phishing-resistant passwordless authentication deployment (operating system readiness, shared devices, second method)
• Microsoft Learn — Require phishing-resistant MFA for administrator roles, and How to require device compliance (break-glass exclusions, role type limits, external method incompatibility)
• Microsoft Security Blog — multi-stage phishing campaign leading to adversary-in-the-middle token compromise, 4 May 2026; and From cookie theft to BEC, 12 July 2022
• ANY.RUN — Mirage2FA campaign telemetry, 18 August 2026 (source of the circulated figures; the vendor describes them as potential impact rather than confirmed compromises). Earlier independent analysis of the same kit: Fortra, June 2026
• CISA — Implementing Phishing-Resistant MFA

Microsoft, Microsoft 365, Microsoft Entra ID, Microsoft Intune, Microsoft Defender, Exchange Online, SharePoint Online and Microsoft Teams are trademarks of the Microsoft group of companies. AZ Innovations is an independent IT services provider and is not affiliated with or endorsed by Microsoft.