Microsoft 365 Session Token Theft: Why MFA Is Not the Whole Story

Multifactor authentication (MFA) is one of the most important protections for a Microsoft 365 account. It makes a stolen password much less useful on its own. But MFA is not the end of the sign-in process. After a person signs in, Microsoft Entra ID and the application being used issue tokens or session cookies that help keep the person signed in. In some phishing attacks, criminals try to steal that already authenticated session. This is known as Microsoft 365 session token theft.

In this guide

What is a Microsoft 365 session token?

When a user signs in, the identity service and the application work together to establish access. Depending on the app and sign-in flow, browsers may hold cookies and Microsoft Entra may issue tokens that support single sign-on or request access to a service.

That is why a person can sometimes return to Outlook or another Microsoft 365 app without typing a password and approving MFA every time. Existing session state, sign-in frequency settings and app behavior can allow access to continue for a period of time.

The phrase “session token” is often used broadly. An Entra refresh token, an access token and an application’s own browser session cookie are not interchangeable, and they do not all have the same lifetime or revocation path. Microsoft’s guidance on emergency access revocation explains that some browser-based applications issue their own session tokens, which the application itself must revoke.

How can AiTM phishing capture an authenticated session?

An adversary-in-the-middle (AiTM) phishing site sits between a person and a legitimate sign-in service. Rather than only collecting a password on a fake page, the site can relay parts of the real sign-in flow in real time.

A typical sequence may look like this:

• A user follows a link to a convincing sign-in page.
• The page relays the user’s details and authentication steps to the genuine service.
• The user completes their password and MFA steps.
• The phishing service may capture the resulting session cookie or token.
• The attacker may then try to replay that session before it expires or is revoked.

Microsoft has documented AiTM campaigns that captured session cookies and used session replay to access accounts and support business email compromise. That does not mean every phishing page can steal every type of token: the outcome depends on the attack, client, app and protections in place. It does show why a user can approve MFA and still need a careful response to a suspected compromise. See Microsoft’s analysis of cookie theft and business email compromise and a later multi-stage AiTM campaign.

What could an attacker access?

If a session is successfully reused, the attacker’s access is constrained by the affected user’s permissions, the session and application, and the controls that still apply. Depending on those factors, activity could include:

• Reading or searching the user’s email.
• Accessing files the user can reach in OneDrive or SharePoint.
• Reviewing business conversations or shared information in other connected services.
• Sending messages from the compromised mailbox.
• Creating inbox rules or changing forwarding settings to hide or redirect messages.
• Using mailbox access to target suppliers or colleagues with fraudulent payment requests.

These are possible outcomes, not automatic results of every stolen session. An investigation should establish what the account could reach and what activity actually occurred.

Why a password reset may not finish the response

Resetting a compromised password is an important step. However, it should not be treated as proof that every active session, application cookie or persistence method has been removed.

In its 2026 report on the Tycoon2FA phishing platform, Microsoft said some attackers could retain access after a password reset unless active sessions and tokens were explicitly revoked. Microsoft has also described a separate AiTM and business email compromise campaign where response needed to go beyond a password reset, including revoking session cookies and checking for changes to MFA methods. These are specific incident findings, but they illustrate why the response should cover both credentials and sessions.

There is another practical detail: Microsoft Entra can revoke its own sign-in sessions and tokens, but an application may issue its own session cookie. Microsoft notes that Entra cannot directly revoke an application-issued session token. The IT team may need to use that application’s own sign-out or revocation process as well.

What should happen after suspected session theft?

The response depends on the evidence and the affected services, but an IT provider should have a documented way to investigate the account and contain access. Actions may include:

• Resetting credentials and revoking the user’s active Entra sessions and tokens.
• Signing the user out of affected applications or revoking application sessions where supported.
• Reviewing sign-in logs, risk alerts, devices and authentication methods for unfamiliar activity.
• Checking mailbox rules, forwarding, delegates, OAuth app consent and recent permission changes.
• Reviewing activity in Exchange, SharePoint, OneDrive and other services the user could access.
• Checking the user’s computer for malware or other signs of compromise.
• Preserving relevant evidence and confirming whether messages or data were accessed or sent.
• Restoring only the legitimate account settings, then monitoring for repeat sign-ins or changes.

The goal is to confirm what happened, remove unauthorized access, and check whether the attacker changed anything that could provide another way back in. A ticket closed after a password reset may leave important questions unanswered.

How can a business reduce Microsoft 365 session token theft risk?

No single setting prevents every form of account compromise. Microsoft recommends a defense-in-depth approach. The controls below should be selected for the organization’s licensing, devices, users and business requirements.

Use phishing-resistant authentication where practical

Passkeys, FIDO2 security keys and Windows Hello for Business are examples of phishing-resistant sign-in methods. They can reduce exposure to credential relay attacks because the sign-in is tied to the legitimate site or device in ways that ordinary passwords and one-time codes are not.

MFA still matters, especially for accounts that cannot yet use phishing-resistant methods. Ask which authentication methods are allowed, who is covered, and whether privileged accounts receive stronger protection.

Review Conditional Access and device requirements

Conditional Access can apply sign-in requirements based on factors such as user, device compliance, application and sign-in risk. Requiring approved or managed devices for sensitive access can limit what an attacker can do from an unfamiliar endpoint.

Sign-in frequency and persistent browser-session settings may also be relevant. They should be configured to balance risk and usability; asking users to sign in more often by itself does not replace phishing-resistant authentication, device protections or an incident-response process. Review the current Microsoft Conditional Access session controls and check that the tenant’s licences support the controls being considered.

Check whether Token Protection is supported

Microsoft Entra Token Protection can bind supported sign-in session tokens to the device where they were issued, which is intended to reduce replay from another device. Availability varies by platform and application; it is not a universal switch for every browser or Microsoft 365 client. Confirm the current Token Protection support and prerequisites before planning a policy.

Protect the devices that hold active sessions

Keep business devices managed, updated and protected with endpoint security. Limit unnecessary local administrator access, review browser and application controls, and investigate devices that stop reporting. If malware can operate on a user’s device, identity controls alone may not address the whole problem.

This is also why patching should be verified. Our guide to MSP patch compliance explains what to ask for when updates fail, devices go offline or the report does not show exceptions.

Make monitoring and response ownership clear

Detection and response depend on licensing, enabled features, retained logs and someone reviewing the alerts. Agree who checks suspicious sign-ins, who can revoke sessions, how after-hours incidents are escalated, and which applications need separate session revocation.

Questions to ask your IT provider

You do not need to become a Microsoft security engineer to ask for clear answers. Consider asking:

• Which phishing-resistant sign-in methods can we use with our current licences and devices?
• Are Conditional Access policies covering all employees, guests and administrators who need them?
• Are unmanaged or noncompliant devices restricted from sensitive data?
• How do we identify unusual sign-ins or suspected token replay, and who reviews the alerts?
• If an account is compromised, how do you revoke Entra sessions and app-issued sessions?
• What do you check beyond a password reset, including mailbox rules, MFA methods and OAuth apps?
• When were the incident steps last reviewed or tested?

An effective answer should describe the current configuration and response owner, not just name products the business owns.

Get an independent Microsoft 365 security review

Allegiance IT Advisory helps businesses independently review Microsoft 365 identity, email and device controls. A focused Microsoft 365 Security Review can examine the agreed evidence, explain gaps in plain language and recommend practical next steps. It can also be included as a module in our Independent IT Review.

The review is designed to work alongside your IT provider. It does not assume the provider is doing a poor job, and it does not require you to replace them. The aim is to understand which controls are configured, who owns them, and what should happen if an account or session is suspected of being compromised.

If your business relies on Microsoft 365 and you want an independent perspective on identity and session security, book a 20-minute call to discuss whether a review fits your needs.