Identity
Stolen Microsoft 365 sessions replayed at 79 organizations
Huntress tracked stolen M365 sessions replayed without MFA at 79 organizations, with fake devices, swapped authenticators and hidden inbox rules. What to check.
Huntress has published a ten-week investigation into one attacker who signed in to Microsoft 365 accounts with stolen sessions instead of passwords. Between July 14 and September 22, 2026, Huntress responded to incidents at 79 organizations and counted at least 497 successful sign-ins against more than 200,000 failed attempts. The victims had already completed MFA when their sessions were captured, so the replayed sessions never triggered a new prompt.
Once inside, the attacker registered fake devices, replaced victims' MFA methods and created inbox rules that hid payroll and banking mail. None of that is undone by a password reset. If your tenant lets a session token work from any IP address and any device, this campaign shows what that costs, and the cleanup steps below apply to any account you suspect was taken this way.
How it works
When you sign in to Microsoft 365 and pass MFA, Microsoft Entra ID issues tokens: a short-lived access token for each service and a refresh token or session cookie that gets new access tokens without asking you again. These are bearer credentials. Whoever presents them is treated as you, unless a policy checks something else about the request, such as the device or the network.
The attacker collected those tokens three ways. Most came from adversary-in-the-middle (AiTM) pages, fake sign-in sites that relay every keystroke to the real Microsoft login, including the MFA prompt, and keep the session that comes back. Others came from device code phishing, where the victim types a code into the genuine Microsoft page and approves a session the attacker started, and from social engineering during real sign-ins.
Huntress calls what came next "token spraying": stolen sessions replayed in bulk, the way password spraying tries one password against many accounts. On July 21 the session was replayed 12 minutes after the victim reached the MFA prompt on the relay; on September 22 the gap was four minutes.
Huntress saw two replay builds. One was scripted, with a node user agent, asking for tokens for Microsoft Graph, Exchange Online, SharePoint Online and the Device Registration Service through the Microsoft Office and Microsoft Authentication Broker client apps. The other looked like a current Chrome or Edge browser on Windows signing in to OfficeHome. If you hunt only for odd user agents, you miss the second.
What the attacker did
The replays came mainly from six addresses in 193.26.115.0/24, part of the network of 1337 Services GmbH (AS210558), a hosting provider incorporated in Hamburg. As Arabian Post points out, that links the provider's servers to the attack without showing the company took part. Huntress also saw other 1337 Services addresses outside that block, so blocking the /24 would have caught some replays but not all of them.
Persistence came in two forms. At least 48 rogue devices were registered in victims' Entra directories, named DESKTOP- followed by eight uppercase hexadecimal characters, such as DESKTOP-54521F46. Real Windows machines default to DESKTOP- plus seven characters, which makes the fakes easy to search for. In 19 organizations the attacker wiped the victim's existing MFA methods and registered a new authenticator within three hours of the first malicious sign-in. In one case an authenticator named "iPhone 13" was active less than an hour after the hijack.
The inbox rules were built to stay unnoticed. Names were one to three characters or punctuation, such as ., sss and iT. They marked mail as read and either deleted it or moved it to the RSS Feeds or Conversation History folders, which nobody opens. In one incident the attacker sent a payroll-related email to an outside accountant, then added a rule hiding mail about payroll, direct deposit, banking or bonuses, and another hiding everything from that accountant, so any reply questioning a bank detail change would never be seen.
On September 11 the attacker moved to a new address and an automated tool, and over four days logged hundreds of successful sign-ins at close to 30 organizations. The same address was refused 1,052 times, all at four organizations whose Conditional Access policies blocked the sign-ins. Huntress's write-up gives two counts for that burst, 303 sign-ins at 29 organizations and 232 at 28.
The numbers also differ between outlets. The Hacker News headline says 97 accounts at 79 organizations. Huntress's report gives 79 organizations and 497 successful sign-ins but no account total, so we have not used the 97 figure.
What to do
There is no patch for this. The controls make a stolen token useless away from the device it was issued to.
- Tighten Conditional Access. Require a compliant or Entra hybrid joined device for Office 365 apps, so a session replayed from a hosting server fails with error 53003 (
BlockedByConditionalAccess). A device the attacker registered is not Intune compliant, so it does not satisfy this. Where your licences and clients allow it, pilot token protection, the Conditional Access session control that binds sign-in tokens to the Windows device they were issued to; Microsoft supports it only for a limited set of apps, so start in report-only mode. - Protect the persistence steps. Add Conditional Access policies on the user actions "Register security information" and "Register or join devices", requiring a compliant device or a trusted location. That stops a replayed session from adding an authenticator or a
DESKTOP-device from a hosting IP. - Restrict device code flow. Under Conditions, Authentication flows, block device code flow for everyone except named meeting-room and kiosk accounts. Our EvilTokens post covers that policy in more detail.
- Treat error 53003 as a warning. A sign-in blocked by Conditional Access means the attacker had a working credential or session. Investigate the account rather than counting it as a success.
To check whether you were hit, search the Entra sign-in logs for 193.26.115.0/24 and for sign-ins from hosting providers using the Office or Authentication Broker client with a node or bare Mozilla/5.0 user agent. Errors of 50133 (SsoArtifactRevoked) show someone replaying a session that was already revoked. In Entra ID, list devices by registration date and look for DESKTOP- names with eight hex characters (Huntress also saw Device- and Work Pc prefixes); the pattern is rare but not unique, so confirm before deleting. In the audit logs, look for "User deleted security info" followed shortly by "User registered security info".
For mailboxes, run Get-InboxRule -Mailbox <user> | fl Name,Description,Enabled in Exchange Online PowerShell and look for short or punctuation-only names, moves to RSS Feeds, RSS Subscriptions or Conversation History, and keywords such as payroll, deposit or bank.
For an account you confirm, revoke sessions with Revoke-MgUserSignInSession -UserId <id> and reset the password together, then remove the device, the unknown authenticator and the rules, and read what the rules hid. Tell any partner or payroll contact who received mail from the account during the window, and check for new enterprise application consents while you are in the tenant.
The four organizations that refused every replay on September 11 were protected by policy that rejected the sessions on arrival. MFA protects the moment of sign-in; Conditional Access decides whether the session that results is still trusted from somewhere else.
We review Conditional Access, device registration and authentication method policies in our safeguarding and hardening work, and hunt for replayed sessions and hidden inbox rules in security operations. To have your tenant checked against this campaign, open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Huntress, Help Net Security, The Hacker News, SecurityOnline, ID Tech, Arabian Post, Microsoft Learn: token protection.