Stolen Login Tokens Opened 97 Microsoft 365 Accounts, No Password Needed

One campaign replayed stolen Microsoft 365 sign-in tokens to take over 97 accounts across 79 organizations between July 14 and Sept. 22, according to Huntress. Huntress calls it token spraying: the attackers don’t guess passwords. They capture the token issued after a real login and MFA prompt, then reuse it from rented servers, sometimes within four minutes. Huntress counted 497 successful sign-ins and more than 200,000 failed ones. It hasn’t tied the campaign to a named group.

193.26.115[.]221
193.26.115[.]199
193.26.115[.]16
193.26.115[.]21
193.26.115[.]72
193.26.115[.]210
185.238.2[.]195
167.148.41[.]96
124.198.132[.]33
45.83.31[.]44
192.159.99[.]172

Source article: M365 token spray and replay campaign
Publisher: Huntress (Andrea Hatcher, Susannah Matt, Matt Poto, Andrew Schwartz)
Published: Oct. 22, 2026
URL: https://www.huntress.com/blog/token-replay-spray

Executive Summary

Huntress tracked an unnamed, financially motivated operator, not attributed to any known group, that took over 97 Microsoft 365 accounts at 79 organizations between July 14 and Sept. 22, 2026, with at least 497 successful sign-ins and more than 200,000 failed attempts traced to one hosting range, 193.26.115[.]0/24 (1337 Services GmbH, AS210558). Huntress calls the technique token spraying: instead of guessing passwords, the operator captures the session or token issued after a real login and MFA prompt, through adversary-in-the-middle phishing relays, Microsoft Office device-code phishing, or social engineering during a genuine sign-in, then replays it from rented servers, in one case four minutes after the victim approved MFA. Two replay builds were seen: a scripted one (node or bare Mozilla/5.0 user agent, OAuth2:Token requests, Microsoft Office and Microsoft Authentication Broker client IDs, aimed at Graph, Exchange Online, SharePoint and the Device Registration Service) and a browser-session one (current Chrome or Edge, Login:reprocess and OAuth2:Authorize, the OfficeHome client). Once in, the operator registered at least 48 rogue Entra devices named DESKTOP- plus eight hex characters, wiped the victim’s MFA methods and added an authenticator labeled “iPhone 13” in 19 organizations within three hours of first access, and created inbox rules with names such as ., sss and iT that deleted mail or moved payroll, deposit and partner messages into RSS Feeds, RSS Subscriptions or Conversation History. The objective appears to be business email compromise and payroll diversion; the persistence survives a password reset unless rogue devices and MFA methods are removed. Hunt leads, false-positive expectations, the absence of published rules or file hashes, and the indicators are detailed below.

ATT&CK chain: Initial Access → Credential Access → Defense Evasion → Persistence → Command and Control

Hunt Lead Grid

Replay and Relay Infrastructure Sweep in Entra Sign-in Logs

Huntress traced the replay activity to rented hosts at 1337 Services GmbH (AS210558): 193.26.115[.]221 (scripted replay with rogue device joins, July 14 to Aug. 3), 193.26.115[.]199 (browser-session replay, July 21), 193.26.115[.]16 (device-code phishing, Phase 2), 193.26.115[.]21 (bare Mozilla/5.0, SharePoint replay), 193.26.115[.]72 (the Sept. 11 burst of a few hundred successful sign-ins) and 193.26.115[.]210 (browser-session replay in September), plus 124.198.132[.]33, which continued a hijacked session, and 45.83.31[.]44 and 192.159.99[.]172, which made failed replays in August. The adversary-in-the-middle relays were 185.238.2[.]195 (July 21) and 2400:8d60:2::1:841d:5dd (Evoxt Sdn. Bhd., September), and 167.148.41[.]96 (Interserver) created payroll-hiding inbox rules. The detection logic is a retrospective search of Entra ID interactive and non-interactive sign-in logs, Unified Audit Log mailbox and rule events, and directory audit logs for any of these addresses or the whole 193.26.115[.]0/24 range, followed by an alert on any future match.

Query both interactive and non-interactive sign-in logs, since the scripted replays appear as non-interactive token sign-ins, along with Microsoft Graph activity logs where enabled. Entra keeps sign-in logs for only 30 days by default, so this sweep back to July 1, 2026 depends on logs exported to a SIEM or Log Analytics; if they were not exported, the sweep can only cover the last 30 days, and the device and inbox-rule leads below become more important. Scope to all users. Blocking 193.26.115[.]0/24 with a Conditional Access named location is reasonable, but Huntress notes it would not cover other 1337 Services ranges or the consumer VPNs and hosting providers the operator also used, so it is not a complete control. Any successful sign-in from these addresses is a confirmed compromise: revoke sessions, reset the password, and remove rogue devices, unknown MFA methods and inbox rules for that user, in that order of urgency.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Defense Evasion and Lateral Movement → T1550.001 (Use Alternate Authentication Material: Application Access Token) (mapping per source article); Credential Access → T1557 (Adversary-in-the-Middle) (mapping per source article)

Sources: “M365 token spray and replay campaign”, Huntress, Oct. 22, 2026, https://www.huntress.com/blog/token-replay-spray (source article)

Rogue DESKTOP-Hex Devices and the “iPhone 13” Authenticator

The operator registered at least 48 rogue Entra devices whose names are DESKTOP- followed by exactly eight uppercase hexadecimal characters, for example DESKTOP-54521F46, DESKTOP-BAF88EF4 and DESKTOP-CA85907C; Huntress points out that Windows’ own default is DESKTOP- plus seven alphanumeric characters. In 19 organizations the operator also wiped the user’s MFA methods through Microsoft’s security-info registration service and, minutes later, registered an authenticator labeled “iPhone 13”, in one case with the push device token apns2-d8a3fedb1a3cd1287ca47c6851a49e6052ab6116b43666e674765ca892d798ce. The detection logic is an inventory sweep of Entra devices for display names matching ^DESKTOP-[0-9A-F]{8}$ (Huntress also suggests the Device- and Work Pc prefixes with eight hex characters), registered from a hosting IP or by a user with no matching Intune-managed device, plus a sweep of user authentication methods for authenticator devices named “iPhone 13” added in the campaign window and for the published device token.

Use the Entra device inventory (via the admin portal export or Microsoft Graph), Entra audit logs for “Register device” and “Add registered owner to device” events, and the authentication-methods activity report or audit events for “User registered security info” and “User deleted security info”. Sweep all users back to July 2026; device objects persist indefinitely, so the inventory check works even where sign-in logs have aged out. Expect some real matches on the device-name pattern from imaging tools and on “iPhone 13” from genuine phones; confirm by checking the registration IP and whether the user recognizes the device, and treat a device registered from 193.26.115[.]0/24 or another hosting range as confirmed. Do not simply delete every DESKTOP- device in bulk, which can break legitimate machines; disable and investigate first. A confirmed rogue device or authenticator means the account is compromised and a password reset alone is insufficient: delete the device and method, revoke sessions and reset the password together.

Hunt Lead Level: 1 (Junior Analyst)

ATT&CK: Persistence → T1098.005 (Account Manipulation: Device Registration) (mapping per source article); Persistence and Defense Evasion → T1556.006 (Modify Authentication Process: Multi-Factor Authentication) (mapping per source article)

Sources: “M365 token spray and replay campaign”, Huntress, Oct. 22, 2026, https://www.huntress.com/blog/token-replay-spray (source article)

Punctuation-Named Inbox Rules Routing Mail to RSS or Conversation History

Huntress lists the operator’s inbox rules: . and sss mark all mail as read and delete it; ss moves mail that mentions a business partner’s domain to RSS Feeds; iT and ,. move all mail to Conversation History; ........ moves all mail to RSS Subscriptions; s hides mail whose subject or body contains payroll, direct deposit, bank or bonus; and d moves one external accounting firm’s mail to Conversation History, all marked as read. Four mailboxes had rules created through the Outlook REST API rather than the Outlook client, two of them within minutes of the first campaign sign-in, and one mailbox used sss while sending spam to hundreds of external recipients. The detection logic is an alert on New-InboxRule, Set-InboxRule and UpdateInboxRules events whose rule name is one to eight characters made up only of punctuation or one to three letters, or whose action moves mail to RSS Feeds, RSS Subscriptions or Conversation History, or marks as read and deletes all mail, with added weight for payroll, bank, deposit and bonus keywords and for creation through the REST API or from a hosting IP.

Use the Microsoft 365 Unified Audit Log (Exchange mailbox and admin events) and, for a point-in-time check, a mailbox rule export across all users. Sweep 90 days of audit data, and run the full rule export regardless of age, since rules persist until removed. Scope to all mailboxes with priority on payroll, HR, finance and executive assistants, the targets of deposit fraud. Users do create rules that file newsletters away, so tune on the combination of a meaningless name and a hiding destination rather than on either alone. Any confirmed rule from this pattern means the mailbox is compromised: remove the rule, check sent items for fraud or spam sent from the account, and warn finance to verify any recent payroll or bank-detail changes by phone. The lead generalizes to almost every business email compromise.

Hunt Lead Level: 2 (Pro)

ATT&CK: Defense Evasion → T1564.008 (Hide Artifacts: Email Hiding Rules) (mapping per source article)

Sources: “M365 token spray and replay campaign”, Huntress, Oct. 22, 2026, https://www.huntress.com/blog/token-replay-spray (source article)

Scripted OAuth2:Token Sign-ins With node or Bare Mozilla/5.0

The scripted build replayed refresh tokens with OAuth2:Token requests (and Cmsi:Cmsi in some sign-ins), using the user agent node or a bare Mozilla/5.0, the client IDs d3590ed6-52b3-4102-aeff-aad2292ab01c (Microsoft Office) and 29d9ed98-a469-4536-ade2-f981bc1d605e (Microsoft Authentication Broker), and target resources 00000003-0000-0000-c000-000000000000 (Microsoft Graph), 00000002-0000-0ff1-ce00-000000000000 (Exchange Online), 00000003-0000-0ff1-ce00-000000000000 (SharePoint Online) and 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 (Device Registration Service). The detection logic is a rule on Entra non-interactive and interactive sign-ins where the user agent is exactly node or exactly Mozilla/5.0 with nothing after it, the application is the Office or Authentication Broker client, and the source IP belongs to a hosting, VPS or VPN provider rather than a residential ISP or a known corporate egress, with the highest severity when the resource is the Device Registration Service.

Use Entra sign-in logs with an IP-to-ASN enrichment (most SIEMs provide this, or a hosting-ASN list maintained by your team), exported to a SIEM for retention. Back-test 90 days and run continuously. Expect noise from developers and automation using Node.js libraries; most of that uses its own registered application ID, so excluding first-party Office and Broker client IDs removes little legitimate traffic, and any remaining developer hits can be allowlisted by user and corporate egress IP. Do not block the user-agent string at a proxy, which does nothing for cloud sign-ins; enforce token protection or compliant-device Conditional Access instead. A hit to the Device Registration Service from a hosting IP should be treated as compromise and handled with the device and MFA lead above. The rule generalizes to other token-replay toolkits that use scripted HTTP clients.

Hunt Lead Level: 2 (Pro)

ATT&CK: Defense Evasion and Lateral Movement → T1550.001 (Use Alternate Authentication Material: Application Access Token) (mapping per source article)

Sources: “M365 token spray and replay campaign”, Huntress, Oct. 22, 2026, https://www.huntress.com/blog/token-replay-spray (source article)

AADSTS53003 From Hosting Infrastructure as a Valid-Credential Signal

Huntress stresses that the error AADSTS53003 (BlockedByConditionalAccess) is returned after authentication succeeds, so a block means the credential or token was valid. In the Sept. 11 burst it recorded 1,052 blocked sign-ins, all from four organizations where Conditional Access was in effect, and it advises prioritizing tenants by credential validity rather than spray volume. It also uses AADSTS50133 (SsoArtifactRevoked) to spot replays of sessions that had already been revoked, such as the failed replays from 45.83.31[.]44, 192.159.99[.]172 and 193.26.115[.]210. The detection logic is a rule on Entra sign-in failures with result code 53003 from a hosting or VPN ASN, alerting on the affected user as having a working credential or token in an attacker’s hands, and a companion rule on 50133 from hosting ranges as evidence that a previously stolen session is still being tried.

Use Entra interactive and non-interactive sign-in logs with ASN enrichment, retained in a SIEM. Back-test 90 days and run continuously. Many 53003 events are legitimate users on unmanaged devices or while traveling, so scope the alert to hosting, VPS and anonymizing VPN networks, and to users with no recent successful sign-in from that ASN. The common wrong response is to treat a block as a win and close the alert; Huntress’s point is that the password, or the session behind it, is already compromised. A hit should lead to a password reset, session revocation and a check for rogue devices, MFA changes and inbox rules, even though no successful sign-in was recorded. This generalizes to any password-spray or token-replay campaign against a tenant with Conditional Access.

Hunt Lead Level: 2 (Pro)

ATT&CK: Defense Evasion, Persistence, Privilege Escalation and Initial Access → T1078.004 (Valid Accounts: Cloud Accounts) (our mapping; Huntress does not map this step)

Sources: “M365 token spray and replay campaign”, Huntress, Oct. 22, 2026, https://www.huntress.com/blog/token-replay-spray (source article)

MFA Wipe-and-Replace or Device Join Within Three Hours of a New Hosting-IP Sign-in

In 19 organizations the operator removed the victim’s existing MFA methods and registered a new authenticator within three hours of its first campaign sign-in, and on July 21 the timeline was tight: the relay captured MFA at 17:18 UTC, the session was replayed from 193.26.115[.]199 at 17:30, continued from 124.198.132[.]33 at 17:43, and an “iPhone 13” authenticator was activated at 18:08. Rogue device joins followed the same pattern from 193.26.115[.]221. The detection logic is a per-user sequence correlation: a successful sign-in from an ASN never seen for that user and classified as hosting or VPN, followed within three hours by any of “User deleted security info”, “User registered security info” (especially when deletion precedes registration within minutes), or a device registration, from the same session, IP or ASN.

This needs Entra sign-in logs, Entra audit logs (security info and device events) and ASN enrichment joined per user in a SIEM, with a per-user ASN baseline of at least 30 days. Back-test against July to September 2026 if logs were retained, then run continuously. Real users do replace phones, but they normally re-register from a residential or corporate network and after a help-desk reset, so exclude registrations that follow a help-desk Temporary Access Pass issuance and those from known corporate egress. The control that would be the wrong choice is relying on MFA itself, which this campaign bypassed; phishing-resistant methods, token protection and blocking device code flow are the preventive pair. Any hit should be escalated immediately: revoke sessions, remove the new method and device, reset the password, and check inbox rules and recent payment changes. The correlation generalizes to most AiTM and device-code takeovers.

Hunt Lead Level: 3 (Elite)

ATT&CK: Persistence and Defense Evasion → T1556.006 (Modify Authentication Process: Multi-Factor Authentication) (mapping per source article); Persistence → T1098.005 (Account Manipulation: Device Registration) (mapping per source article)

Sources: “M365 token spray and replay campaign”, Huntress, Oct. 22, 2026, https://www.huntress.com/blog/token-replay-spray (source article)

Hash Appendix

No file hashes: this campaign is identity-based and Huntress publishes no malware or files. Huntress also publishes no KQL, Sigma or YARA rules; its hunting guidance is in prose, which the leads above follow. The host and account artifacts (device name pattern, authenticator label and device token, inbox rule names, client and resource IDs) are listed in the relevant leads.

References Appendix

• “M365 token spray and replay campaign”, Huntress (Andrea Hatcher, Susannah Matt, Matt Poto, Andrew Schwartz), Oct. 22, 2026, https://www.huntress.com/blog/token-replay-spray (source article; timeline, replay builds, infrastructure, client and resource IDs, device and MFA artifacts, inbox rules, error codes, ATT&CK mapping, mitigation guidance)
• MITRE ATT&CK Enterprise technique pages linked above, MITRE, https://attack.mitre.org/