Title
Microsoft 365 Token Theft: Why MFA Didn’t Stop This Attack
97 accounts. 79 organisations. Every one of them had multi-factor authentication switched on.
That's the finding from Huntress, which tracked a Microsoft 365 campaign running from July 14 to September 22, 2026. And no, this isn't a story about companies that claimed to have MFA and hadn't finished the rollout. The MFA worked. Users got the prompt. Users approved it. The attackers got in anyway.
They never broke MFA. No cracked TOTP seed, no cloned security key, no clever flaw in the login flow. They let the user authenticate perfectly, then stole what came out the other end.
What actually happened
The technique has a clunky name, adversary-in-the-middle, and a simple shape. The attacker stands up a login page that sits between your user and Microsoft. Your user types their password into it. The page passes it straight through to the real Microsoft login. Microsoft says "fine, now do MFA." Your user gets the push on their phone, sees nothing unusual about it because nothing is unusual about it, and approves.
Microsoft is satisfied and issues an access token. That token goes to the attacker's page, because the attacker's page is what Microsoft has been talking to.
From there the attacker replays it from their own machines. Huntress counted 497 successful Microsoft 365 sign-ins off the back of this, against more than 200,000 failed login attempts traced to a single address range. Other tokens arrived through device-code phishing and ordinary social engineering. The collection method varied. The thing collected did not.
No threat actor has been publicly named.
The token is the asset now
Most of us still carry a mental model from around 2015: the password is what attackers want, MFA is what stops them using it, job mostly done. That model is now actively misleading.
Think about a hotel. The front desk checks your ID, then hands you a keycard. The ID check was the hard part, and it happened once. After that, the card opens doors. Nobody at the elevator asks who you are, because the card is proof that the check already happened.
A session token is that keycard. MFA is the front desk. What this campaign shows is that if someone lifts the card out of your hand on the way to the elevator, the quality of the ID check stops mattering.
So "we have MFA" has quietly stopped being an answer to "are we protected against account takeover." MFA controls the act of authenticating. Token theft skips authentication and goes after the receipt. Worse, your detection probably keys on login events, and the adversary isn't logging in. They're continuing a session someone else started.
The three-hour problem
A stolen token expires. That's the good news, and the attackers knew it, which is why the interesting part is what they did in the hours right after getting in.
They made it permanent. Huntress counted 48 rogue Entra devices registered across the campaign, essentially fake computers enrolled into the victim's own tenant. In no fewer than 19 organizations, the attackers stripped out the existing MFA methods and registered their own, within three hours of first sign-in. In one case on July 21, a new authenticator app showing up as "iPhone 13" was active less than 51 minutes after the session was hijacked.
The order matters. The stolen token wasn't the goal; it was the tool used to acquire a legitimate, durable foothold. Once an attacker owns a registered device and a registered MFA method in your tenant, they never need to phish anyone again. They can walk in the front door as the user, indefinitely.
Then the mailbox work. The attackers created inbox rules with deliberately forgettable names like ".", "sss" and "iT," which deleted or hid mail containing words like payroll, deposit and bonus. That isn't espionage. That's invoice fraud, with the rules in place so nobody sees the colleague asking "are you sure you want to change your bank details?"
What Conditional Access needs to say
Huntress puts the fix in one sentence, and the wording is the point: Conditional Access should "require MFA (or block) for All Users, All Cloud Apps, and All Client App types, unconditionally."
The operative word is unconditionally, and most mid-market tenants fail on it through entirely reasonable accumulated history. A break-glass admin excluded from the policy. A service account excluded because it broke a nightly job in 2024. Contractors on a looser policy because onboarding them properly would have taken a sprint nobody had. Each was defensible the day it was made. Together they're a map, and the attacker only needs one way in.
So your exclusion list, not your policy, is your real attack surface. Read it out of context and ask of each entry whether you'd create it today. Confirm All Client App types really means all of them, since legacy auth is still the softest way into a well-configured tenant. And restrict the device-code workflow, which this campaign used as a token source.
Go check these today
None of this needs a budget conversation. It's an afternoon.
Audit registered Entra devices. Look for enrolled devices nobody can account for. This is the one that finds a live intruder, so start here.
Review MFA methods per account. Flag anything added recently, especially where an old method was removed and a new one added close together. That's the campaign's signature.
Hunt for inbox rules with meaningless names, rules that delete rather than file, or anything keyed on payroll, deposit, invoice or bank. Run it tenant-wide.
Check enterprise apps for unexpected consent grants. Another foothold that survives a password reset.
Read your Conditional Access exclusions as a standalone list. Be unkind about it.
Know how to revoke sessions before you need to.
That last one is what most often goes wrong under pressure. A password reset alone does nothing here, because the token is already out. You have to revoke the sessions and remove the attacker's registered device and MFA method, or you've changed a lock the intruder stopped using days ago.
The shift worth making
Keep your MFA. Turn it on everywhere you haven't. Nothing here argues against it, and a tenant without it is in a far worse place than any of these 79 organizations.
But the question your controls answer has to change. "Who is logging in?" was right for a decade. The question now is "what is holding a valid token, and should it be?"
That reframing makes the rest obvious. It's why device registration matters more than password policy, and why session revocation belongs in the playbook beside the password reset rather than in a footnote under it.
These companies weren't careless. They were answering last decade's question correctly.
