Between July 14 and September 22, 2026, one operator signed in to Microsoft 365 accounts at 79 organizations without a password, according to a Huntress investigation published Oct. 22. The researchers counted 497 successful sign-ins and more than 200,000 failed attempts traced to one address range, and they describe a technique that sits behind a growing share of business email compromise: replaying a session token that the victim’s own MFA step had already produced.
What Huntress observed
Huntress’s authors, Andrea Hatcher, Susannah Matt, Matt Poto and Andrew Schwartz, summarize the method in one sentence: “Rather than guessing passwords, the attacker replayed sign-in tokens stolen from victims.” They call the pattern token spraying, the same shape as password spraying with stolen tokens in place of guessed passwords.
The campaign ran in four phases, each from a different address in the 193.26.115.0/24 block, with gaps of a week or two between some of them. A July wave ran from July 14 to Aug. 3 and had 37 organizations signed in by its end. A second wave began Aug. 17 and added device-code phishing. A burst of automated replay ran from Sept. 11 to 15, and a relay-and-replay phase ran from Sept. 2 to 22 and ended in a final takeover on Sept. 22. Huntress notes that blocking any single address would have stopped one phase at most, so an address blocklist alone leaves the next phase open.
Speed was part of the method. In a July 21 incident the relay caught the victim at the MFA prompt at 17:18:20 UTC and the session was replayed from a campaign address at 17:30:21, a gap of 12 minutes. On Sept. 22 the gap was four minutes, with replay at 20:50 UTC after the victim finished MFA about a minute after reaching the prompt. A token stolen at that moment is valid without a further MFA challenge, so no alert tied to a failed sign-in ever fires.
How the sessions were stolen
The report traces the stolen sessions to phishing routes. The victims reached fake sign-in pages backed by adversary-in-the-middle relays that pass the genuine Microsoft page and MFA prompt through to the user while keeping the session token issued afterward. Other tokens came from device-code phishing, where the victim types a code into a legitimate Microsoft page, and from social engineering during an ordinary login.
Palo Alto Networks’ Unit 42 published a broader survey of the same ground the day the Huntress report appeared. In The Current Landscape of OAuth Attacks, researchers Beliz Kaleli, Diva-Oriane Marty, Oleksii Alex Starov and Shawn He Shuang write that “stolen access and refresh tokens bypass MFA, survive password resets and grant durable access.” Unit 42 sorts OAuth-based phishing into account hijacking, permission hijacking and malicious redirects, and it names the device authorization flow as one of the abused paths. The overlap with Huntress is direct: the device-code phishing in the Microsoft 365 campaign is the account-hijacking category in Unit 42’s taxonomy.
What the operator did after sign-in
Once inside, the operator worked to outlast the stolen session. Huntress found at least 48 rogue computers registered in victims’ Entra directories, each named DESKTOP- followed by eight hexadecimal characters. Windows’ default naming uses seven alphanumeric characters, which gives defenders a search pattern. In 19 organizations the victim’s MFA methods were wiped and a new one registered within three hours of the first sign-in from a campaign address. A registered authenticator keeps working after a password reset.
The operator also hid the activity from mailbox owners. Inbox rules named with one to three characters or punctuation, such as a single period or “sss”, moved or deleted mail. One rule keyed on the words payroll, direct deposit, bank and bonus. In one incident a compromised mailbox sent a payroll-related email to an outside contact. Huntress puts the stakes plainly: “Access to a Microsoft 365 account sets the stage for business email compromise (BEC).”
The same pattern of identity-layer persistence appeared in our recent reporting, where ConnectWise suspended its cloud backup after unauthorized access to application identities. The durable foothold in both cases sat in the identity layer, with no malware on a host.
Why blocking addresses did not work
During the Sept. 11 burst the operator ran an automated replay tool that identified itself as node and used the Office or Authentication Broker client, mostly requesting tokens for Microsoft Graph. Over four days that address was blocked 1,052 times, and every block came from four organizations. Huntress attributes those blocks to Conditional Access and the AADSTS53003 error, which means the policy stopped a sign-in that carried a valid credential. The organizations where the operator got in had no comparable control.
That detail changes how the blocks should be read. Huntress tells responders to read AADSTS53003 events as evidence of a valid credential and warns against sizing a response by spray volume: “Do not trigger response based on spray volume, as it points at the most-sprayed, least-compromised tenants.”
What each Microsoft control covers
Three controls in Microsoft’s documentation apply to token replay. They cover different parts of the problem, and their limits are written down in Microsoft’s own pages.
Conditional Access. Huntress’s most direct finding is a conclusion about this control: “Token replay attacks can be prevented with properly implemented Conditional Access Policies.” Its first recommendation is a policy that requires MFA or blocks access for all users, all cloud apps and all client app types, with no exceptions. A second is to restrict the device-code flow through Conditional Access authentication-flow policies, and a third is to consider disabling user consent for new applications so users must request them.
Token Protection. Microsoft describes Token Protection as a Conditional Access session control that reduces token replay by accepting only device-bound sign-in session tokens, such as Primary Refresh Tokens, for protected resources. A token bound to a registered device cannot be used from another device. The documentation lists native-application enforcement on Windows, iOS and iPadOS, and macOS for Exchange Online, SharePoint Online and Teams, and lists browser-based enforcement as a preview limited to selected web apps that access Azure Resource Manager. Microsoft adds that Token Protection belongs in a broader defense-in-depth strategy. In our reading, the adversary-in-the-middle pages in this campaign collected browser sign-ins, which the current browser coverage list does not include for Microsoft 365 resources. Check the platform table against your own user population before counting on the control.
Continuous access evaluation. Microsoft’s continuous access evaluation page explains that access tokens are valid for one hour by default, and that CAE lets Exchange Online, SharePoint Online and Teams act on critical events in near real time, with up to 15 minutes of latency. The events include a disabled account, a password change or reset, an administrator revoking all refresh tokens, and high user risk detected by Entra ID Protection. For clients that negotiate CAE, token lifetime can rise to as long as 28 hours, because revocation is driven by events instead of a timer. Microsoft also states that token export to a machine outside a trusted network can be blocked by Conditional Access location policies, and that CAE can see only IP-based named locations. Revocation helps the responder after detection. It does nothing in the 4 to 12 minutes before anyone knows to revoke.
What it means for the security leader
Three conclusions follow from the sources, and the first is a question of ownership. Token theft sits between the identity team that owns Conditional Access, the endpoint team that owns device registration, and the email team that owns inbox rules. The Huntress indicators span all three: rogue devices in Entra, replaced authenticators, and rules that hide payroll mail. No single console shows the whole chain, so someone has to own the cross-cutting hunt by name.
The second is that MFA coverage reports overstate protection against this attacker. The operator completed no MFA challenge of its own. It borrowed one that a victim had just passed, and in 19 organizations it then replaced the methods that would have challenged it later. Measure session binding, device compliance and authentication-flow restrictions alongside MFA enrollment. Our earlier opinion pieces argued the same shift from the credential to the session, in A Token Security Playbook Landed Two Days Too Late and in the case for treating cloud billing admin as a privileged role.
The third is that the payroll rule is a business-process signal. Finance teams can add a verification step for any change to direct-deposit details that arrives by email, which protects the company even when the mailbox is already compromised.
A response checklist from the report
For a suspected replay, Huntress says to revoke sessions and reset the password, and it warns that a password reset alone leaves attacker-registered devices and MFA methods in place. The remaining steps exist for that reason, so work them in this order:
- Revoke all sessions for the user, then reset the password, and note that an issued access token can stay valid for roughly 90 minutes.
- Audit Entra devices named DESKTOP-, Device- or Work Pc followed by eight hex characters, especially those registered from hosting IP addresses, and confirm each with its owner before deleting.
- Audit MFA methods for entries cleared and re-registered within minutes, including an authenticator labeled iPhone 13 in the observed cases, and remove any the user does not recognize.
- Review inbox rules with one to three characters or punctuation-only names, rules that move mail to RSS Feeds or Conversation History, and rules keyed on payroll or banking terms.
- Hunt for OAuth2:Token sign-ins from hosting infrastructure that use the Office or Broker client with a node or bare Mozilla/5.0 user agent and touch mailboxes or the Device Registration Service.
- Hunt for newly granted enterprise applications and review user consent settings.
Huntress adds that the device-name pattern is rare but not unique to this campaign, so each hit should be confirmed before deletion. Start the Conditional Access change in report-only mode, as Microsoft recommends for Token Protection, so a legitimate workflow does not break on the first day.
Source: Huntress, Microsoft 365 token replay report, Oct. 22, 2026
