MFA Was On. They Got In Anyway: How Stolen Microsoft 365 Sessions Work

You did the right thing. You turned on multifactor authentication (MFA) for everyone in Microsoft 365. Your staff grumbled for a week, then got used to tapping "Approve" on their phones.

So how does an attacker end up reading your bookkeeper's email anyway?

Security firm Huntress just published research on a campaign that did exactly that. Between July 14 and September 22, 2026, Huntress responded to related incidents at 79 organizations. It counted at least 497 successful sign-ins, along with more than 200,000 failed attempts. In Huntress's words, "The Microsoft accounts were compromised without the attacker ever needing a password."

MFA still matters a great deal. Attackers have simply learned to go around it, and if you run Microsoft 365 for a business, school, or church here in Arkansas, it helps to understand how.

First, What's a "Session Token"?

When you sign in to Microsoft 365 and finish the MFA prompt, Microsoft gives your browser or app a token, a kind of digital wristband. For a while after that, the token is your proof that you already signed in, so you aren't asked for your password and MFA every time you open an email.

Huntress calls it the "proof of login." Because the token is created after MFA is finished, whoever holds it doesn't have to pass MFA again. Someone who steals your wristband can walk right in.

How the Attack Happens, Step by Step

This is the sequence Huntress documented.

Step 1: The victim signs in through a fake page that passes everything along. This is called an adversary-in-the-middle (AiTM) attack. The victim clicks a link and lands on a page that sits between them and Microsoft. It shows the real Microsoft sign-in page and the real MFA prompt. The victim enters their password, approves MFA, and gets signed in like any other day, while the relay keeps a copy of the token. (Huntress didn't say what the lure emails looked like, so we can't show you an example.)

Huntress also saw two other ways of getting tokens:

  • Device-code phishing. The victim is talked into typing a short code on Microsoft's real sign-in page. That approves the attacker's session instead of their own.

  • Social engineering during a normal sign-in, where someone is talked through approving access they shouldn't.

Step 2: The token gets used within minutes. The attacker replays the stolen token from rented servers. In one July case, the hijacked session showed up 12 minutes after the victim reached the MFA prompt. On September 22, the gap was four minutes.

Step 3: The attacker sets up a way back in. A stolen token eventually expires, so the attacker works fast to stay:

  • In 19 organizations, the victim's MFA methods were wiped and a new one registered within three hours of the first sign-in. In one case, an authenticator app labeled "iPhone 13" was added less than an hour after the session was hijacked.

  • The attacker registered at least 48 fake computers in victims' Microsoft directories, named "DESKTOP-" plus eight characters.

Huntress points out that this kind of access survives a password reset unless someone finds and removes the attacker's authenticator and devices.

Step 4: The attacker hides and goes after money. Huntress found inbox rules with forgettable names like "sss" and "." that deleted mail or moved it into folders nobody checks, such as RSS Feeds and Conversation History. In one case, a rule grabbed any message mentioning payroll, direct deposit, bank, or bonus. Five minutes later, a second rule hid every reply from the company's outside CPA. The attacker then used the mailbox to send a payroll-related email to that CPA.

Picture that in your business office: the person who handles payroll keeps working all week with no idea their replies are disappearing.

What Stopped It

On September 11, the attacker switched to a new server and started replaying tokens in bulk. Over four days, that server got into 29 organizations. It was also blocked 1,052 times, and every one of those blocks came from just four organizations.

Those four had Conditional Access policies in place. Conditional Access is the set of rules in Microsoft 365 that decides who can sign in, from where, and how. Huntress's advice is to require MFA (or block access) for all users, all cloud apps, and all client app types, with no exceptions.

So in the same week, against the same attacker, four organizations kept the door shut because of how their Conditional Access was set up.

What You Can Do This Week

Hand this list to your IT person or provider:

  • Review your Conditional Access policies. Make sure MFA is required for everyone and every app, with no gaps for older email clients or "temporary" exceptions that became permanent.

  • Block device-code sign-in if you don't use it. Microsoft recommends getting "as close as possible to a unilateral block" on this sign-in method and allowing it only where it's truly needed.

  • Stop staff from approving new apps on their own. Huntress recommends turning off user consent so new apps have to be requested and reviewed.

  • Plan your move to phishing-resistant MFA. CISA calls phishing-resistant MFA, such as FIDO security keys and passkeys, the "gold standard." Ask your provider what it would take to move staff over, starting with anyone who handles money or student data.

  • Put a phone call in front of every payment change. A changed bank account or direct deposit request gets a callback to a number you already have, plus a second person's sign-off.

If You Think an Account Was Taken Over

Changing the password isn't enough. Huntress's containment steps:

  1. Revoke the user's sessions and reset the password. Huntress notes a reset alone leaves the current access token working until it expires, roughly 90 minutes.

  2. Check the account's MFA methods and remove any authenticator the user doesn't recognize.

  3. Check registered devices for computers nobody recognizes, especially odd "DESKTOP-" names.

  4. Review inbox rules for short or punctuation-only names and rules that send mail to RSS Feeds, RSS Subscriptions, or Conversation History.

  5. Look for newly added apps that were granted access to your tenant.

One more tip from Huntress for your IT team: if Conditional Access blocked a sign-in, treat it as proof the attacker had a working password or token. The policy did its job, but that account still needs attention.

Would Your Organization Catch It?

  • If someone added a new authenticator app to your bookkeeper's account at 2 a.m., who would find out, and when?

  • Does anyone check for new devices in your Microsoft 365 directory?

  • Would you notice an inbox rule named "sss"?

  • Is your Conditional Access set up for every user and every app, or just some?

  • If an account were taken over today, does your team know that a password reset alone won't kick the attacker out?

If any of those are hard to answer, you're in good company. Most of the organizations we talk to have never looked.

How Red Garrison Can Help

At Red Garrison, we think like attackers, and an attacker would much rather borrow your session than fight your MFA.

  • Microsoft 365 Security Assessment. We review your Conditional Access, MFA methods, device-code and app-consent settings, and mailbox rules, then give you a plain-English list of what to fix first.

  • Huntress-powered ITDR for Microsoft 365 and Google Workspace. Around-the-clock monitoring of sign-ins, MFA changes, rogue devices, and inbox rules, with people who respond when something looks wrong. (Here's why we think ITDR matters for schools.)

  • Incident Assist. If you suspect an account was taken over, we'll help you revoke access, remove what the attacker left behind, and figure out what they saw.

  • Red Garrison Bootcamp. Training that shows your staff what fake sign-in pages and device-code tricks look like.

Whether you run a small business, a school district, or a church office, the goal is the same: a stolen token should get the attacker nowhere.

Let's Check Your Microsoft 365 Before Someone Else Does

Book your free assessment with Red Garrison this week. We'll look at how your Microsoft 365 sign-ins are protected, check for the warning signs from this campaign, and tell you honestly what we'd lock down first. If something already feels off, start with Incident Assist today.

We think like attackers. We work like partners.

Sources

  1. Huntress, "M365 Token Spray and Replay Campaign Compromises Business Email Accounts" (Oct. 22, 2026): https://www.huntress.com/blog/token-replay-spray

  2. Help Net Security, "Microsoft 365 accounts compromised at 79 organizations, no passwords needed" (Oct. 23, 2026): https://www.helpnetsecurity.com/2026/10/23/microsoft-365-accounts-stolen-sessions/

  3. The Hacker News, "Microsoft 365 Token-Replay Attacks Compromise 97 Accounts at 79 Organizations" (Oct. 2026): https://thehackernews.com/2026/10/microsoft-365-token-replay-attacks.html

  4. Microsoft Learn, "Block authentication flows with Conditional Access policy" (device code flow guidance): https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows

  5. Microsoft Learn, "Revoke user access in an emergency in Microsoft Entra ID": https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access

  6. Microsoft Learn, "Configure how users consent to applications": https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent

  7. CISA, "Implementing Phishing-Resistant MFA" (fact sheet, Oct. 2022): https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf

Next
Next

PHP2Shell: The PHP Flaw That Could Hand Over Your Website