M365 Token Spray and Replay - Tokens Captured After MFA → Replayed From One Rented /24 → Rogue Entra Devices → MFA Methods Wiped and Replaced → Hidden Inbox Rules Around Payroll Mail
Huntress published this account on October 22, 2026. Between July 14 and September 22 it tracked an operator who replayed stolen Microsoft 365 sign-in sessions from rented hosts in one address block, 193.26.115.0/24 at 1337 Services GmbH, and it responded to related incidents at 79 organizations. Because each session was minted after the victim passed MFA, replaying it needed no second factor. Inside, the operator registered rogue Entra devices, wiped victims' MFA methods and registered its own, and created inbox rules with one-to-three-character or punctuation names that hid mail, in one case mail about payroll. One compromised mailbox sent a payroll-related email to an outside CPA. Three caveats belong next to the headline. Huntress's text counts organizations and sign-in events. The 97 compromised accounts in The Hacker News's headline come from a "by the numbers" graphic in Huntress's report, and the text never repeats that figure or says how the accounts were counted. Huntress says the tokens came from several sources, including adversary-in-the-middle relays and device-code phishing, and gives no breakdown of how many tokens came from each. And it reports no confirmed financial loss or data theft; its figures come from its own customer environments.
Huntress says the tokens came from multiple sources: adversary-in-the-middle (AiTM) relays behind fake sign-in pages, device-code phishing, and social engineering during a legitimate login. It lists these for the campaign as a whole. It lists these for the campaign as a whole and gives no breakdown by method. It does tie some replays to a source: the browser sessions replayed from 193.26.115[.]199 and 193.26.115[.]210 came through AiTM relays, and sign-ins from 193.26.115[.]16 used the device-code flow. It does not say where the scripted Build A replays got their tokens, and it does not describe how the lures reached victims.
The device-code route shows up in the second phase, when Huntress recorded sign-ins through the Microsoft Office device-code flow from 193.26.115[.]16. In that flow the victim is tricked into entering a code on Microsoft's own sign-in page, and completing it hands the attacker a valid refresh token and access token.
Breakdown by method: not given; AiTM tied to the Build B replays, device code to 193.26.115[.]16
Lure delivery: not described
Device-code sign-ins: Microsoft Office client, from 193.26.115[.]16 (Phase 2)
Huntress gives one case in full. At 17:18:20 UTC on July 21, an AiTM relay at 185.238.2[.]195 caught the victim at the MFA prompt. The relay passed the prompt through to Microsoft and kept the resulting session. The session token is issued after MFA succeeds, so replaying it does not trigger MFA again.
Huntress describes the operation as two tiers on different providers: relays that capture sessions, and separate hosts that replay them. A later relay, an IPv6 address at Evoxt Sdn. Bhd., first appeared on September 2. On September 22 a victim reached the MFA prompt through it at 20:46 UTC and completed MFA a minute later.
Phase 4 relay: 2400:8d60:2::1:841d:5dd (Evoxt Sdn. Bhd.), first seen September 2
What the relay keeps: a session already past MFA
On July 21 the session was hijacked from 193.26.115[.]199 at 17:30:21 UTC, and at 17:43:15 the same session was in use from a second 1337 Services address, 124.198.132[.]33. Across the campaign the operator rotated through six addresses in 193.26.115.0/24 (1337 Services GmbH, AS210558) over four phases. Microsoft Entra ID Protection independently raised verified threat actor IP detections against four of the six, but flagged them one at a time, not as a range. Huntress calls the pattern token spraying: password spraying with stolen tokens in place of guessed passwords. It traced more than 200,000 failed login attempts in the campaign window to the same range, against at least 497 successful sign-in events.
Huntress saw two builds. Build A was scripted: a node user agent (a bare Mozilla/5.0 on one host) making OAuth2:Token requests with the Microsoft Office and Microsoft Authentication Broker client IDs against Microsoft Graph, Exchange Online, SharePoint Online and the Device Registration Service. Build B replayed browser sessions with a current Chrome or Edge user agent through the OfficeHome client. Huntress cannot say for certain why the operator rotated addresses. Huntress notes the effect: a block written for one address did nothing against the next, and blocking any single address would have stopped one phase at most.
The busiest burst came from 193.26.115[.]72 on September 11. Within two hours Huntress had sent incident reports to 22 customers. The report gives two different totals for that address: 303 successful sign-ins across 29 organizations over four days in its Phase 3 section, and 232 across 28 in its mitigation section. It does not reconcile them.
Capture to replay: 12 minutes (July 21), 4 minutes (September 22)
Build A: node UA, OAuth2:Token, clients d3590ed6-52b3-4102-aeff-aad2292ab01c (Office) and 29d9ed98-a469-4536-ade2-f981bc1d605e (Auth Broker)
Build B: browser UA, Login:reprocess, client 4765445b-32c6-49b0-83e6-1d93765276ca (OfficeHome)
Phase 3 (.72): 303 sign-ins in 29 orgs, or 232 in 28, depending on the section
Huntress first detected the campaign on July 14, 2026, as a sign-in from 193.26.115[.]221 by an Entra-joined device with a name of this form. A fake device appeared in 13 of the 14 incidents Huntress responded to that day. By August 3 the operator had signed in to 37 organizations and registered 37 rogue Entra devices, and Huntress counts at least 48 distinct devices across the campaign.
Huntress explains why the device matters: a registered device can give the attacker a more durable way to request tokens than the stolen session, and it stays in the directory until someone deletes it. The name format, DESKTOP- plus eight uppercase hex characters, does not match the default Windows gives a new machine. Huntress also says the pattern is rare but not unique to this campaign, so confirm a device before deleting it. The report gives no timing between first sign-in and device registration.
Count: at least 48 distinct devices
By August 3: 37 organizations signed in to, 37 devices registered
Resource: Device Registration Service, 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9
The existing methods were wiped through Microsoft's security-info registration service, and a new authenticator was registered minutes later. In the July 21 case a new authenticator app labelled iPhone 13 was activated at 18:08:50 UTC, about 38 minutes after the hijack and about 50 minutes after the relay caught the victim. The Hacker News reported this as less than 51 minutes after the hijack, which matches Huntress's timestamps only when measured from the relay capture. In one incident the operator used a deviceless authenticator method that was already on the account.
Resetting the password does not undo any of this. In Huntress's words, "A password reset alone does not remove attacker-registered devices or MFA methods." Microsoft described a similar swap in Storm-2949, where existing methods were removed and an attacker-controlled Microsoft Authenticator enrolled. There, Microsoft assessed with high confidence, the way in was abuse of self-service password reset, with the user talked into approving MFA prompts.
Replaced with: a new authenticator, minutes later
July 21: iPhone 13 authenticator activated at 18:08:50 UTC
Scope: 19 organizations, within three hours of the first campaign sign-in
The rules were named ., sss, ss, iT, ,., ........, s and d. Most marked mail as read and deleted it, or moved it to RSS Feeds, RSS Subscriptions or Conversation History. Rule s hid messages containing payroll, direct deposit, bank or bonus. Rule d moved all mail from one external CPA's address to Conversation History and marked it read. In four mailboxes the rules were created through the Outlook REST API rather than Outlook itself. Every rule came from a VPN or rented hosting (ExpressVPN, NordVPN, CrownCloud, DataWagon, GLOBALTELEHOST, LeaseWeb, Dynu, Interserver), and none from the 1337 Services network.
In the September 11 burst the operator used a compromised mailbox to send a payroll-related email to an external CPA, and in that mailbox the operator modified rule s and, five minutes later, created rule d, both from the same Interserver address, 167.148.41[.]96. Huntress reports no outcome for that email. In the first phase, a mailbox carrying the sss rule sent spam to hundreds of external recipients before Microsoft Entra ID Protection rated the account high risk. Huntress says access of this kind sets the stage for business email compromise; it does not report a completed fraud, a financial loss or data theft.
Destinations: RSS Feeds, RSS Subscriptions, Conversation History, or deleted
Rule s keywords: payroll, direct deposit, bank, bonus
Created from: VPNs and rented hosting, never 1337 Services; in four mailboxes, via the Outlook REST API
Payroll email to the CPA: sent; outcome not reported
🛡 How to Defend Against This Chain
DESKTOP-, Device- or Work Pc plus eight hex characters, particularly ones registered from hosting IP addresses. Confirm each before deleting, since the pattern is not unique to this campaign. For MFA, look for methods cleared and re-registered within minutes, remove any authenticator the user does not recognize, and check deviceless methods already on the account, which one incident here used. A device left in the directory can still give the attacker a way to request tokens after the stolen session is dead.OAuth2:Token and Cmsi:Cmsi sign-ins from hosting providers using the Microsoft Office or Authentication Broker client with a node or bare Mozilla/5.0 user agent, especially against mailboxes or the Device Registration Service; new enterprise applications, which can keep access to a tenant; and inbox rules with one-to-three-character or punctuation-only names, rules that route mail to RSS Feeds, RSS Subscriptions or Conversation History, and rules keyed to payroll or banking terms. Blocking the /24 would have covered all six main replay hosts, but not the relays, a few other 1337 Services addresses, or the VPN and hosting addresses that created the rules.