Identity attacks

Token theft in Microsoft 365: how stolen sessions skip MFA

MFA is on and the account still gets taken over. Token theft is why: the attacker steals the session after MFA, not the password. How it works, a worked example, and the steps that stop it.

A client calls. Their finance manager’s mailbox has been sending invoices nobody wrote. You check the account: strong password, MFA switched on, every sign-in approved. So how did the attacker get in?

Often the answer is token theft. The attacker never beat MFA. They waited until the real person passed it, then took the thing Microsoft 365 hands out afterwards: the session token. Here’s what that is, how it gets stolen, what it looks like in the logs, and what actually stops it.

What is token theft?

When you sign in to Microsoft 365, you prove who you are once: password, then MFA. Microsoft then gives your browser or app a token, a small piece of data that says “this person already signed in.” Every email you open after that is let through because of the token, not because you typed your password again.

That’s what makes daily work bearable. It’s also the weak spot. Whoever holds the token is treated as you, until it expires or is revoked. If an attacker copies it to their own machine, Microsoft sees a valid, already-approved session. No password prompt, no MFA prompt.

Token theft is a form of session hijacking. The full definition is in our glossary under token theft.

How attackers steal Microsoft 365 tokens

There are three common routes.

  1. A fake login page in the middle. The person clicks a link and lands on a page that relays everything to the real Microsoft sign-in. They type their password, approve MFA, and the fake page copies the token on the way back. This is AiTM phishing. Microsoft’s Digital Defense Report 2024 reported a 146% rise in AiTM phishing attacks over the year before.
  2. Malware on the laptop. Info-stealing malware reads the browser’s saved cookies and tokens and sends them off. The person never sees a fake page at all.
  3. A token left where it shouldn’t be. Tokens and app secrets end up in scripts, shared files or logs, and someone finds them.

In every case the result is the same: a session that already passed MFA, now running from someone else’s machine.

A worked example

This example is illustrative. Names and times are made up.

  • Tuesday 9:12 – Dana, an accounts manager at a 40-person firm, gets an email that looks like a shared invoice. She clicks, signs in on what looks like the normal Microsoft page and approves the MFA prompt on her phone. She lands in her real inbox and thinks nothing of it.
  • 9:14 – The same session shows up from a server in another country. It’s Dana’s token, replayed. Microsoft logs it as a normal, MFA-satisfied session.
  • 9:20 – The attacker adds an inbox rule that moves any mail containing “invoice” or “payment” to a folder Dana never opens.
  • Thursday – A supplier’s real invoice arrives. The attacker replies from Dana’s account with “new bank details.”
  • Next week – The supplier calls about a missing payment. That’s the first time anyone notices.

Resetting Dana’s password on Tuesday afternoon would not have been enough on its own. The stolen token would have kept working until it was revoked.

Why MFA doesn’t stop token theft

MFA protects the moment of sign-in. Token theft happens after that moment. By the time the attacker has the token, MFA has already done its job, for the real person.

That doesn’t make MFA useless. It still blocks plain password attacks, and it’s the base everything else builds on. But “MFA is on” is not the same as “accounts can’t be taken over.” The gap is everything that happens after sign-in.

How to stop token theft: a checklist

Make the token harder to steal

  • Move admins and finance staff to phishing-resistant MFA (passkeys or FIDO2 security keys). CISA calls FIDO/WebAuthn the only widely available phishing-resistant authentication. It refuses to sign in on a fake site, so the AiTM relay fails.
  • Only allow sign-in from managed devices for the people who handle money and admin rights, using Conditional Access.
  • Keep laptops clean. Info-stealers are the other main route. Patch browsers and watch the endpoint.

Make a stolen token less useful

  • Shorten session lifetimes for high-risk roles and apps, so a stolen token expires sooner.
  • Look at Microsoft’s token protection settings in Conditional Access, which tie a token to the device it was issued to. Check which apps and devices support it in your tenant before relying on it.

Notice when it happens

  • Watch for the same session from two places. A session that starts on a laptop in Ohio and carries on from a server abroad minutes later is the classic sign. See impossible travel.
  • Alert on new inbox rules, especially ones that forward mail or move it out of sight.
  • Alert on new MFA methods or devices added to an account.

Respond properly

  • Revoke every session, not just the password. Then reset the password and sign-in methods.
  • Remove what the attacker added: inbox rules, forwarding, MFA methods, app consents.
  • Check who else got mail from the account while it was taken over.

How Centeye Gatewatch handles stolen sessions

Centeye Gatewatch watches every sign-in across Microsoft 365 and Google Workspace and spots stolen sessions replayed from someone else’s machine. With Ironwatch on the laptop, it checks the session against the device it should be coming from.

When it finds one, Gatewatch ends every session, resets the password and sign-in methods, and removes what the attacker added, such as forwarding rules. It also spots MFA prompt floods, the other common way past MFA (see MFA fatigue attacks). Another way attackers get a token without stealing a password is device code phishing. If an account has already been taken over, work through our first-hour checklist for a compromised Microsoft 365 account.

For MSPs, that means one view of stolen-session alerts across every client tenant, instead of reading sign-in logs one tenant at a time.

FAQ

What is token theft in Microsoft 365?

It’s when an attacker copies the session token Microsoft 365 gives a user after they sign in. With that token, the attacker is treated as the user without needing the password or MFA.

Can token theft bypass MFA?

Yes. The token is issued after MFA succeeds, so replaying it skips the MFA step entirely. Phishing-resistant MFA makes the token much harder to steal in the first place.

Is token theft the same as session hijacking?

Token theft is the most common way session hijacking happens today. Session hijacking is the broader term for taking over a session someone else already started.

Does resetting the password stop token theft?

Not on its own. Revoke all sessions as well, then remove any rules, MFA methods or apps the attacker added.

How do I know if a token was stolen?

Look for the same user’s session coming from two different places or devices close together, new inbox rules, and new MFA methods. A tool that watches sign-ins across tenants makes this far easier than reading logs by hand.

New to these terms? Our security glossary has plain-English definitions. Want to see stolen-session detection on your own Microsoft 365 or Google Workspace? Start a free trial.


AiTM figure from the Microsoft Digital Defense Report 2024. Phishing-resistant MFA guidance per CISA. Token protection per Microsoft Learn. The worked example is illustrative.

See one attack, end to end.

A 30-minute intro call on sample data, or a free trial on your own tenant.