Microsoft 365 Token Spraying Attack Explained: How Stolen Sessions Bypass MFA at 79 Organisations (World Tech)

Microsoft 365 token spraying attack explained — cloud server infrastructure

Illustrative image: server racks in a data centre. Image: Wikimedia Commons. This is not a Microsoft product image — token spraying targets cloud sign-in sessions, not a physical device, so no official product photo applies.

TL;DR: Microsoft 365 token spraying attack explained in one line: attackers let victims complete a real Microsoft sign-in — including multi-factor authentication — stole the session token issued afterwards, and replayed it from their own machines, compromising 97 accounts at 79 organisations without ever guessing a password.

📌 KEY HIGHLIGHTS

Disclosed 22 October 2026 by Huntress: a ten-week campaign, observed 14 July to 22 September 2026, across 79 organisations in Huntress's customer base.
The scale: more than 200,000 login attempts, 497 successful sign-ins, 97 accounts ultimately compromised, and at least 48 rogue devices registered in Microsoft Entra ID.
Why MFA did not stop it: the stolen token is issued only after MFA succeeds, so whoever holds it never has to pass MFA again.
The persistence trick: in 19 organisations, victims' MFA methods were wiped and replaced within three hours of the first campaign sign-in.
The fix that fails: a password reset alone does not revoke the stolen session, the rogue devices, or the attacker's MFA methods.

Microsoft 365 token spraying attack explained: what happened?

Most account takeovers start with a guessed or leaked password. This one did not. Researchers at Huntress, a managed security company, described a campaign in which attackers placed a fake sign-in page between the victim and Microsoft's real login system — an adversary-in-the-middle relay. The page passed everything through honestly, including the multi-factor authentication prompt, so the victim saw nothing wrong. What the attackers kept was the prize handed out at the end of a successful sign-in: the session token, Microsoft's digital proof that this person has already proven who they are.

Because that token is minted after MFA, replaying it skips MFA entirely. Huntress calls the technique "token spraying": the same volume-and-automation idea as password spraying, but with stolen tokens instead of guessed passwords. The replay traffic traced back to the 193.26.115.0/24 address range, rented infrastructure linked to German hosting provider 1337 Services GmbH — hosting context, not proof that the provider ran the campaign, and no threat actor has been named.

Honest dating matters here. This is not a brand-new attack discovered on 28 October: Huntress published its findings on 22 October 2026, The Hacker News and others reported them on 26 October, and the story recirculated in security roundups on 28 October. The campaign window itself closed on 22 September. The reason it still matters today is that the technique works against any Microsoft 365 tenant configured the way most are — MFA on, and little else.

How the attack works, step by step

Stage	What the attacker does	What the victim sees
1. Lure	Fake Microsoft sign-in page, device-code phishing, or social engineering during a real login	A normal-looking Microsoft login prompt
2. Relay	Adversary-in-the-middle page forwards credentials and MFA codes to real Microsoft infrastructure	Login succeeds, MFA passes — nothing looks wrong
3. Steal	Capture the session token issued after MFA	Nothing — the session continues normally
4. Replay	Replay the token from attacker machines, sometimes within minutes, at scale	A successful sign-in in Microsoft's logs, with no failed password attempt
5. Persist	Register rogue Entra devices, replace MFA methods, hide inbox rules	Mail quietly diverted; payroll and banking threads targeted

Microsoft 365 token spraying attack explained — code on a computer monitor

Illustrative image: code on a computer monitor. Image: Wikimedia Commons / Unsplash. The attack needs no malware on the victim's machine — it abuses the legitimate sign-in flow itself.

What the attackers did once inside

Getting in was only the start. Huntress found at least 48 rogue devices registered in victims' Entra ID directories, often named like DESKTOP- followed by eight hexadecimal characters. In 19 organisations, the victim's existing MFA methods were removed and a new method registered within three hours of the first campaign sign-in — in one case on 21 July 2026, an authenticator app labelled "iPhone 13" was activated less than 51 minutes after the session was hijacked. That is the point of persistence: even if the stolen session expires or is revoked, the attacker's own authenticator can pass future MFA challenges.

Then came concealment. Attackers created hidden inbox rules with one- or two-character or punctuation-only names — ".", "sss", "ss", "iT" — moving mail to obscure folders such as RSS Feeds or Conversation History, with rules keyed on payroll and banking terms. In one case, a compromised mailbox sent a payroll-related email to an outside contact: the classic staging for business email compromise, where the payoff is a fraudulent payment instruction from a trusted inbox.

One number needs care. The 497 figure is successful sign-in events, not compromised accounts — the account count is 97, across 79 organisations, all within Huntress's customer environments. It is not a count of every Microsoft 365 tenant worldwide, and the true total is unknown.

Why it matters for World Tech readers — including in India

Indian businesses run heavily on Microsoft 365, and the default setup — MFA switched on, little else — is precisely the configuration this campaign defeats. MFA is not broken, and it is not useless: it still stops password guessing cold. But MFA answers the question "did this person prove who they are?", and a stolen post-MFA token answers that question with someone else's proof. Treating MFA as a guarantee, rather than one layer, is the misunderstanding this campaign exploits.

The defensive lesson is also the most counter-intuitive one in the whole story. Conditional Access policies that require MFA for all users, all cloud apps and all client app types — with no exceptions — actually changed outcomes: in one phase, 1,052 sign-ins from a campaign address were blocked where such policies existed, while 232 sign-ins from the same address succeeded across 28 organisations without them. And a Conditional Access block should not be read as a win on its own: Huntress notes the block happens after authentication succeeds, so the credential behind it was valid and deserves investigation.

Should you care?

✅ Verdict: If you use Microsoft 365 at work, yes — check your sessions, not just your password. For individuals, the practical steps are free: never approve an unexpected MFA prompt, be suspicious of sign-in pages reached from email links, and report odd sign-ins immediately. For admins, the work is in the tenant: Conditional Access without exceptions, restricted device-code flow, and session revocation done properly. A password reset that leaves the attacker's devices and MFA methods in place is a false sense of security.

What to do if you suspect a replayed session

Huntress's response order matters, and the order is the message: revoke sessions AND reset the password together — a reset alone leaves the current access token valid until it expires, roughly 90 minutes by Huntress's estimate. Then audit Entra devices and remove any you do not recognise, check for MFA methods cleared and re-registered within minutes, and review inbox rules for very short or punctuation-only names and rules targeting payroll or banking terms. Finally, check for new enterprise applications granted access to the tenant, and hunt sign-in logs for OAuth2:Token and Cmsi:Cmsi requests from hosting providers using the Office or Authentication Broker client. For prevention, restrict device-code flow with Conditional Access authentication-flow policies, stop standard users consenting to new enterprise applications, and pilot Token Protection, which stops a stolen token working on another device for the apps it covers.

For the wider token-theft picture, read our Gheist GitHub stolen tokens explainer, where stolen tokens were used to siphon repository secrets, and our PHP2Shell CISA KEV explainer on the week's other actively exploited flaw. For a cloud-breach contrast, see our GMO Onamae Desktop Cloud breach explainer.

FAQs

What is token spraying in Microsoft 365? Token spraying is Huntress's name for replaying many stolen Microsoft 365 session tokens at scale across organisations, in the same volume pattern as password spraying — except nothing is guessed. The tokens are stolen after victims complete a real sign-in, then replayed from attacker machines until some are accepted.

How does token spraying bypass MFA? It does not break MFA; it walks around it. The session token is issued only after the victim passes MFA, so whoever holds the token never has to pass MFA again. The fake sign-in page relays the victim's real MFA approval to Microsoft and keeps the resulting token.

How many accounts were compromised in the Huntress campaign? 97 accounts at 79 organisations, from 497 successful sign-in events out of more than 200,000 login attempts between 14 July and 22 September 2026. Those numbers cover Huntress's customer environments, not all Microsoft 365 tenants.

Does changing your password stop token replay? No, not on its own. A password reset leaves the stolen session token valid until expiry (about 90 minutes), and leaves any rogue devices and replacement MFA methods the attacker registered fully in place. Revoke sessions and reset the password together, then remove the devices and methods.

How can organisations protect against token spraying? Enforce Conditional Access requiring MFA (or blocking access) for all users, all cloud apps and all client app types with no exceptions; restrict device-code flow; block standard-user consent to new enterprise applications; and monitor Entra sign-in logs for token requests from hosting infrastructure. Piloting Token Protection adds a further barrier for covered apps.

Takeaway: MFA still matters — but it proves a login, not every later use of that login. When the proof itself is stolen, only session revocation, device and MFA audits, and exception-free Conditional Access close the door.

Follow World Tech on TechByCountry for tomorrow's 6 PM update.

📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.

TechByCountry — Daily Tech News, Country by Country

Search This Blog