OFFENSIVE SECURITY | FIELD NOTE

By uMercs Research | October 26, 2026

Somewhere between July and September, an attacker logged into business mailboxes at 79 organizations, read them, rerouted payroll conversations, and quietly set up rules so the owners would not notice. They never had a single password. They never defeated a single MFA prompt either. They arrived after all of it was over.

Huntress tracked the campaign across ten weeks, July 14 to September 22, 2026: stolen Microsoft 365 sign-in sessions replayed at scale, at least 97 accounts taken over, and 497 successful sign-ins against more than 200,000 failed attempts. The researchers called it token spraying, because it works exactly like password spraying but with stolen sessions instead of guessed passwords. Most attempts failed. The attacker kept going anyway.

The uncomfortable part is not that MFA was beaten. It is that MFA was never the thing standing in the attacker's way. If your mental model of account security is a locked front door with a second lock, this campaign is the correction: modern sign-in works more like a hotel, and hotels do not check your ID at the room door.

The key card problem

When you sign in to Microsoft 365, the password and the MFA prompt happen once, at the front desk. Once you pass both, the platform hands your device a session token: a temporary pass that says this session already proved who it is. Every request after that shows the token, not the password. The door does not check your ID again. It checks whether you are holding a key card.

That design is reasonable and nearly universal. It is also the entire attack. Whoever holds a valid token gets in without the password and without an MFA prompt, because the token is issued after both checks already passed. An attacker does not need to break the front desk. They need to be standing behind you when the key card is handed over.

The main capture route in this campaign was an adversary-in-the-middle relay. The attacker hosts a lookalike sign-in page and proxies the real Microsoft login behind it. The victim types real credentials into what is genuinely the real sign-in flow, relayed through the attacker's server. The victim approves a real MFA prompt. Everything works exactly as Microsoft designed it. Then the session token comes back through the relay on its way to the victim's browser, and the attacker keeps a copy. MFA was not bypassed. It was completed, honestly and enthusiastically, and the receipt was stolen.

Huntress observed two other capture routes. Device-code phishing talks a victim into typing a code into Microsoft's legitimate device sign-in page, which authorizes a session on the attacker's device. And in some cases, plain social engineering steered users through one of the flows. Once captured, tokens were replayed in bulk, mostly from a single block of rented infrastructure: 193.26.115.0/24, six addresses belonging to 1337 Services GmbH, a hosting provider incorporated in Hamburg. Subtle, no.

The campaign, in numbers

Ten weeks. 79 organizations. At least 97 mailboxes. 497 successful sign-ins from replayed tokens, against a background of more than 200,000 failed attempts. The ratio says something honest about the attack: it is cheap, automated, and mostly unsuccessful, which is why it runs at volume.

The attacker moved between six addresses in that hosting range in four phases, with breaks of a week or two between them. Huntress noted that blocking any single address would have stopped one phase at most. The infrastructure is disposable by design.

Speed is the other signature. In a July 21 incident, the hijacked session appeared from a campaign address 12 minutes after the victim reached the MFA prompt. By September 22, the gap was four minutes. From September 11, the attacker ran an automated program that reused captured tokens, completing 303 successful sign-ins across 29 organizations in four days.

Four minutes from MFA prompt to attacker in the mailbox is faster than most organizations can page a human. Any response plan that starts with someone noticing something is wrong should be tested against that number.

Making the stay permanent

The first thing most teams do after a suspected account takeover is reset the password. In this campaign, that would have changed almost nothing. Huntress documented three kinds of persistence that outlive a reset.

First, rogue devices. The attacker registered at least 48 computers in victims' Microsoft Entra directories, each named DESKTOP- followed by eight hexadecimal characters. A registered device stays in the directory until someone explicitly deletes it, and a device registration can be used to request tokens that look more legitimate than a replayed session. The attacker effectively checked in at the front desk under your name and was issued their own key card.

Second, swapped MFA. In 19 organizations, the victim's existing MFA methods were deleted and a new one registered, typically within three hours of the first sign-in from a campaign address. In the July 21 case, an authenticator app labeled iPhone 13 was active on the account less than an hour after the session was hijacked. From that point the attacker can satisfy MFA for new sign-ins at will, and that access survives a password reset. Nobody audits the authenticator list; the password gets changed and everyone goes home.

Third, session continuity. The stolen sessions themselves were used within minutes of capture, and refresh behavior varies by configuration, but the rogue devices and replacement MFA methods are the durable artifacts. They are also the ones almost nobody looks for.

What the victims never saw

The attacker's mailbox work was quiet and surgical. Hidden inbox rules with names like a single period, sss, and iT deleted incoming mail or marked it read and moved it to folders like RSS Feeds and Conversation History. Mail disappeared from the inbox without a trace a normal user would ever notice.

One compromised mailbox tells the rest of the story. The attacker sent a payroll-related email to an external accountant, modified a rule to catch any message mentioning payroll, direct deposit, bank, or bonus, and five minutes later created a second rule that hid all incoming mail from that accountant. The victim kept a mailbox that looked completely normal while a payroll conversation continued without them.

That is the point of hiding mail rather than spamming from it: the goal is time. Payment diversion and wire fraud need a few quiet days. A mailbox the owner still trusts is worth far more than one that starts shouting.

What actually stops this

The most useful number in the whole report is buried in the middle: the campaign address was blocked 1,052 times, and every one of those blocks came from just four organizations whose Conditional Access policies refused the sign-ins. Four tenants out of 79 did almost all of the successful defending. Everyone else's MFA waved the attacker through, because MFA had already been completed when the token was minted.

There is a triage lesson in those blocks too. A sign-in rejected by Conditional Access with error AADSTS53003 means the credential or token was valid. The policy stopped that attempt; it did not stop the attack. If your monitoring files those events as noise, the attacker is knocking on a different door while you file paperwork.

Defense that holds up against token replay has four legs. Conditional Access that requires managed or compliant devices, and that covers every app and client type, including the non-interactive flows replay tools prefer. Restricting the device-code flow so a code cannot authorize a rogue session. Phishing-resistant MFA, meaning FIDO2 security keys and certificate-based methods, where the proof is bound to the legitimate sign-in page, so a relay that copies it gets a useless souvenir. And directory hygiene: audit registered devices for names nobody recognizes, audit MFA methods for phones nobody owns, and revoke sessions and refresh tokens after any suspicious sign-in rather than stopping at the password reset.

What offensive testing should validate

A meaningful test of this attack path does not check whether MFA is on. It checks what happens after MFA says yes. In a controlled tenant, capture a session through a relay you operate, then measure what the environment does with it.

Does Conditional Access actually refuse the replayed session, or only the interactive sign-in? Do the non-interactive token flows, the Office and broker clients the replay tools use, fall under the same policies as a browser login? Does a device registration with a DESKTOP- style name and no management record generate an alert, and does that alert reach a human inside the same shift?

Test the persistence questions too. If a session is revoked, does everything tied to it die, or does a rogue device keep minting tokens? If MFA methods are deleted and re-registered, does anyone see it? Can an inbox rule named with a single period in a finance mailbox survive a week? Every one of those questions has an answer in your tenant today, and most organizations have never asked.

Finally, test the detection story end to end. A blocked sign-in with error 53003, a mystery device in Entra, an authenticator nobody enrolled, mail moving to RSS Feeds: each is a small event. The measure of a defender is whether those small events connect to an eviction inside four minutes, or inside four weeks.

The takeaway

MFA is not wrong. It is one check, performed once, at the front desk. After that, access is a key card, and key cards get copied. The organizations that walked away clean from this campaign were not the ones with the strongest passwords or the most prompts. They were the four that decided the room door should also check who is holding the card.

Bind sessions to devices you manage. Restrict the flows that can mint new sessions. Audit what is registered in your directory, because the attacker's favorite persistence is the inventory nobody reviews. And when an account is compromised, treat a password reset as step one of cleanup, not the end of it. Of the artifacts this attacker left behind, the password is the only thing a reset actually touches.

Sources

Huntress, M365 Token Spray and Replay Campaign Compromises 97 Accounts at 79 Organizations, October 22, 2026: https://www.huntress.com/blog/token-replay-spray

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

WizardCyber, Valid Password, Stolen Session: Hunting The Microsoft 365 Token Spray-And-Replay Campaign, October 23, 2026: https://wizardcyber.com/m365-token-spray-replay-hunting/