Huntress tracks 10-week Microsoft 365 token replay campaign

Huntress tracked a 10-week Microsoft 365 token replay campaign from July 14 to September 22, 2026, detecting 497 successful sign-ins across 79 victim organizations.

Huntress labels the approach token spraying, saying it mirrors password spraying except the attacker replays stolen tokens instead of guessing passwords. The attacker stole sign-in tokens after victims completed multifactor authentication and replayed them without passwords, using adversary-in-the-middle relays, device-code phishing, and social engineering.

Huntress traced more than 200,000 failed login attempts from the campaign window to the 193.26.115.0/24 IP range of German hosting provider 1337 Services GmbH, also known as AS210558. Six addresses in that block were used one after another: 193.26.115.221, 193.26.115.199, 193.26.115.16, 193.26.115.21, 193.26.115.72, and 193.26.115.210.

1337 Services GmbH is incorporated in Hamburg, Germany, and offers legitimate IP hosting. A February 2025 Krebs on Security article suggests the company’s founder may have operated the Cracked cybercrime forum.

Huntress first detected the activity on July 14, 2026, from 193.26.115.221 using an Entra-joined device named DESKTOP- plus eight hex characters. Phase 1 began July 14, 2026; in 13 of 14 incidents that day, the attacker registered a fake Windows-style computer in the victim directory.

By August 3, 2026, the attacker had signed in to 37 organizations and registered 37 rogue Entra devices from 193.26.115.221. Phase 2 returned on August 17, 2026, using 193.26.115.16 and 193.26.115.21, adding device-code phishing through Microsoft’s device-code flow and wiping multifactor authentication settings before re-registration.

Phase 3 began September 11, 2026; 193.26.115.72 completed 303 successful sign-ins across 29 organizations over four days, while Conditional Access blocked 1,052 attempts from only four organizations. After the Phase 3 burst, there was a full week of quiet before the September 22, 2026, takeover.

On September 22, 2026, the victim completed multifactor authentication at 20:46 UTC from a macOS browser using OfficeHome, and the attacker replayed the session at 20:50. Routing through a Remote Desktop Protocol virtual desktop tunnel changed the session operating system from macOS to Windows before email access.

Phase 4 paired an adversary-in-the-middle relay at Evoxt Sdn. Bhd. with replay from 193.26.115.210, ending in a session takeover on September 22, 2026, at 20:50 when the attacker accessed the victim’s email. Microsoft Entra ID Protection flagged the campaign addresses as “sign-in activity that is consistent with known IP addresses associated with nation state actors or cyber crime groups, based on Microsoft Security Intelligence (MSTIC).”

Huntress has not attributed the campaign to any known threat group. Microsoft described the flagged infrastructure only as consistent with nation state or cyber crime group activity. Attribution remains unresolved between the two vendors.

In 19 organizations, existing multifactor authentication methods were wiped and a new authenticator registered within three hours of the first campaign sign-in. Huntress says a registered authenticator lets the attacker pass multifactor authentication anytime, “that access survives a password reset.”

The threat actor registered at least 48 fake computers in victim Microsoft directories, including Entra-joined devices named DESKTOP- plus exactly eight uppercase hexadecimal characters. A password reset alone does not remove attacker devices or multifactor methods and does not invalidate an access token valid for approximately 90 minutes; sessions must also be revoked.

Hidden inbox rules moved messages from specific contacts out of sight, and at least one compromised mailbox was used to send a payroll-related e-mail to an outside contact. Four mailboxes had rules created through the Outlook REST API rather than Outlook itself, two within minutes of the first campaign sign-in.

In one incident, rules named s and d were created from Interserver address 167.148.41.96 to hide payroll and bank messages from an external CPA before a fraudulent payroll e-mail was sent.

Every suspicious inbox rule was created from VPN or rented hosting, including ExpressVPN, NordVPN, CrownCloud, DataWagon, GLOBALTELEHOST, LeaseWeb, Dynu, and Interserver, never from the 1337 Services GmbH network. Blocking any single campaign IP address would have stopped one phase at most; blocking the full 193.26.115.0/24 range would have covered all six main replay hosts.

IP address switches followed quiet periods of about two weeks between Phases 1 and 2 and one week before the September 22, 2026, takeover. A block, alert, or Conditional Access rule written for one campaign IP address does nothing against the next address. Blocking the 1337 range does not stop credential capture by adversary-in-the-middle relays, and blocking a relay does not stop replay of tokens already stolen.

The replay hosts ran two distinct toolsets, Build A and Build B. Build A sign-ins used a node user agent to replay tokens through the Microsoft Office client. Build A device names use eight uppercase hexadecimal characters, unlike the Windows default of seven alphanumeric characters. Build B replayed browser sessions straight from adversary-in-the-middle relays.

Huntress recommends auditing Entra devices named DESKTOP-, Device-, or Work PC plus eight hex characters, multifactor methods cleared and re-registered within minutes, and inbox rules with short or punctuation-only names. Huntress also recommends restricting device-code flows with Conditional Access, hunting OAuth2:Token and Cmsi:Cmsi sign-ins from hosting infrastructure, and blocking standard users from consenting to new enterprise applications.

Within two hours of Phase 3 activity from 193.26.115.72, Huntress sent incident reports to 22 customers. Access tokens remain valid unless identity sessions are revoked or disabled, even after the refresh token and session cookie expire.

Microsoft returns SsoArtifactRevoked error AADSTS50133 when a session is invalid after a password expires or changes. Repeated attempts to reuse a stolen session in Aug. 2026 from 193.26.115.199, 45.83.31.44, and 192.159.99.172 failed with Microsoft’s SsoArtifactRevoked error (AADSTS50133).

Huntress advises not to trigger response based on spray volume because it points to the most-sprayed, least-compromised tenants; prioritize by credential validity instead. Huntress advises treating Conditional Access blocks (AADSTS53003) as evidence of a valid credential, not a save, because the block happens after authentication succeeds.

Adversary-in-the-middle phishing kits have become commodity, according to M365 Forensics. MITRE ATT&CK maps adversary-in-the-middle to T1557 and web session cookie use to T1550.004. Microsoft described a 2021 adversary-in-the-middle campaign targeting more than 10,000 organizations where payment fraud began as little as five minutes after credential and session theft.

Microsoft’s June 2023 campaign write-up described a stolen cookie replayed hours later from another country, a new MFA method added without re-authentication by default, and inbox rules moving mail to Archive and marking it read. Entra ID Premium P2 risk fields include anomalousToken, unfamiliarFeatures, and user-level Attacker in the Middle detection.

Microsoft flags anomalous token as having more false positives than usual when set to low or medium levels. ThreatLocker says adversary-in-the-middle phishing pages act as live reverse proxies that validate credentials and MFA in real time against Microsoft APIs. Stolen session cookies enable persistent access to Exchange Online, SharePoint, OneDrive, and federated SaaS applications.

Recent adversary-in-the-middle campaigns use trusted platforms such as SharePoint to distribute malicious links as an initial access vector for business e-mail compromise. Phishing-resistant multifactor authentication methods are bound to the real site and cannot be relayed by a proxy.

ThreatLocker states that strong MFA does not solve replay once a valid session exists, and that sign-in risk policies can produce false positives and often score only at initial authentication, allowing token reuse after access is granted. Session revocation may not immediately invalidate all refresh tokens or third-party OAuth sessions.