Microsoft 365 Token Spraying Bypasses MFA: Huntress Detection and Response Guide

The numbers are big enough to matter to anyone who runs a Microsoft 365 tenant. By Huntress's count, the campaign ran between July 14, 2026 and September 22, 2026, with 497 Microsoft 365 sign-in events across 79 victim organizations related to a token replay campaign using an IP address block from the German hosting provider 1337 Services GmbH.

What happened, in plain terms​

Huntress, the managed security vendor, published its findings on October 22. Its researchers said they responded to related incidents at 79 organizations, observing at least 497 successful sign-in events against more than 200,000 failed login attempts across our customer environments.

Some secondary write-ups describe "200,000 attempts including 497 successes." Huntress's own wording puts the 497 successes against more than 200,000 failures. These are also numbers from Huntress's own customer base. They are not a count of every Microsoft 365 tenant, and 497 sign-in events does not mean 497 separate compromised accounts.

Why this isn't password spraying:

• Huntress explained the name this way: "Because the attacker replayed many stolen tokens at volume across many organizations, we refer to this as 'token spraying': the same pattern as password spraying, but with stolen tokens instead of guessed passwords"
• Rather than guessing passwords, the attacker replayed sign-in tokens stolen from victims, and Huntress traced more than 200,000 failed login attempts from the campaign window back to the 193.26.115[.]0/24 IP range.
• Microsoft's own telemetry agreed. Microsoft Entra ID Protection independently flagged several of the replay addresses. It described them as linked to "nation state actors or cyber crime groups." However, neither company has named an actor.

A note on the hosting provider: Huntress describes 1337 Services GmbH as a legitimate company. As Arabian Post put it, the identification concerns servers used for the attacks and does not establish that the hosting company participated in the operation.

Summary: One rented IP block replayed stolen post-MFA sessions at scale. Huntress saw 497 successes in 79 organizations, and the failed attempts far outnumbered them.

How the tokens were stolen​

Huntress said the tokens came from three places:

• Adversary-in-the-middle (AiTM) phishing. In a relay attack, the victim sees Microsoft's real login and multifactor-authentication prompts, while the intermediary captures the session token issued after authentication. An attacker holding that token can reuse the authenticated session without completing the MFA challenge again.
• Device-code phishing. Victims were tricked into entering a code on Microsoft's legitimate sign-in page. Huntress first saw this in the August–September wave, coming through the Microsoft Office device-code flow.
• Social engineering during a normal login.

The theft and the replay ran on separate infrastructure. The relays capturing sessions and the servers replaying them operated on separate infrastructure. In one July 21 incident, the gap between the victim reaching the MFA prompt and the hijacked session appearing was 12 minutes. In the final takeover on September 22, the gap was four minutes.

That split matters for defense. Blocking the replay range does nothing about the phishing relays, and taking down a relay does nothing about tokens that were already stolen.

Summary: The phishing kits sat on one set of servers and the replay hosts on another. A stolen token could be in use within minutes.

Four phases, six addresses​

Huntress tracked six replay addresses in the /24 block, used one after another, plus a few other 1337 Services addresses:

The replay hosts ran two different toolsets:

• Build A (scripted): a node user agent, the Microsoft Office or Microsoft Authentication Broker clients, and OAuth2:Token requests. It targeted Microsoft Graph, Exchange Online, SharePoint Online and the Device Registration Service.
• Build B (browser): current Chrome or Edge on Windows, the OfficeHome client, and Login:reprocess / OAuth2:Authorize requests. On its own, this traffic looks like ordinary browsing.

Phase 3 carries the most useful lesson. Huntress said during one four-day burst in September, a single address logged 303 successful sign-ins across 29 organizations. Conditional Access blocked 1,052 more attempts, but all of those came from just four organizations. Huntress's mitigation section then cites a slightly different tally of 232 successes across 28 organizations for the same address, with no overlap with the blocked tenants. That inconsistency is in the source. Either way, the point holds: the noisiest tenants were the ones Conditional Access was already protecting.

Summary: The operator kept switching addresses, so blocking a single IP stopped one phase at most. Blocking the whole /24 would have covered all six main replay hosts, but not the relays or the VPNs used later.

How the attackers stayed in​

A stolen token eventually expires, so the attackers worked on access that would outlast it.

• Rogue devices. The attacker registered at least 48 fake computers in victims' Microsoft directories. Those devices used "DESKTOP-" followed by eight uppercase hexadecimal characters, differing from Windows' default of seven alphanumeric characters. Huntress notes the pattern is rare but not unique, so confirm before you delete anything.
• Replaced MFA methods. In 19 organizations, the victim's existing MFA methods were wiped and a new one registered within three hours of the first sign-in from a campaign address. In the July 21 case, a new authenticator app labeled "iPhone 13" appeared less than an hour after the token was captured. Some coverage says attackers "added their own phone numbers." Huntress's report describes replacement authenticator methods. And as SecurityOnline summarized, a rogue authenticator lets the attacker pass MFA again, and "that access survives a password reset."
• Hidden inbox rules. The rule names were made to be forgettable: sss, s, d, ,., or a row of dots. The rules moved mail to RSS Feeds, RSS Subscriptions or Conversation History. Every one was created from a VPN or rented hosting address, never from the 1337 Services network. In four mailboxes, the rules were created through the Outlook REST API.
• Business email compromise setup. In one case, an attacker modified a rule to catch mail mentioning payroll, direct deposit, bank or bonus. Five minutes later they added a rule that hid all replies from an external CPA. Huntress documented one case involving a payroll-related message sent from a compromised mailbox to an external accounting contact. One secondary summary says no payment was made. Huntress's report doesn't settle that either way.

Summary: The token got the attackers in. The fake devices, swapped authenticators and hidden rules were how they planned to stay.

Not the first campaign of this kind​

This fits a pattern Huntress has been reporting all year. Huntress also reported a separate June 2026 campaign in which threat actors using infrastructure operated by LSHIY LLC conducted a password-spraying attack against Microsoft's Azure CLI, using previously breached credentials through the deprecated OAuth ROPC flow, which bypassed MFA where Conditional Access did not cover that flow. Huntress's new report points back to that LSHIY research as evidence of what Conditional Access can catch when it's set up properly.

The broader trend, in my own reading: MFA has made stolen passwords less useful, so attackers are going after tokens instead. AiTM kits and device-code phishing are now common tools, and an MFA prompt alone doesn't stop them.

What Microsoft 365 admins should do now​

Huntress's guidance, grouped by job:

Prevent

• Configure Conditional Access to require MFA, or to block access, for all users, all cloud apps and all client app types, with no conditions.
• Use Conditional Access authentication-flow policies to restrict device-code flow. If you genuinely need it, confine it to service accounts with restricted permissions.
• Stop standard users from consenting to new enterprise applications. Make them request apps instead.

Contain a suspected replay, in this order

• Revoke sessions and reset the password. Huntress says a password reset alone leaves the current access token valid until it expires, roughly 90 minutes by its estimate. It also leaves attacker-added devices and MFA methods in place.
• Audit Entra devices. Look for names like DESKTOP-, Device- or Work Pc followed by eight hex characters, especially devices registered from hosting IP addresses.
• Audit MFA methods. Check for methods cleared and then re-registered within minutes, and remove any authenticator the user doesn't recognize.
• Review inbox rules. Watch for one- to three-character or punctuation-only names, rules that move mail to RSS or Conversation History folders, and rules keyed on payroll or banking terms.
• Check for new enterprise applications that may have been granted access to the tenant.

Hunt and triage

• Search sign-in logs for OAuth2:Token and Cmsi:Cmsi requests from hosting providers that use the Office or Authentication Broker client with a node or bare Mozilla/5.0 user agent. Prioritize any that touch mailboxes or the Device Registration Service. Some legitimate automation will match these filters.
• Don't read an AADSTS53003 Conditional Access block as a win. Huntress says the block happens after authentication succeeds, so the credential was valid.
• Don't rank incidents by how many failed attempts a tenant saw. Rank them by evidence that a credential actually worked. AADSTS50133 (SsoArtifactRevoked) means an old session was replayed and failed, which tells you the attacker tried but didn't get in that time.

The bottom line​

The numbers come from one vendor's customers, and some details differ between Huntress's own report and the news coverage. The method itself is consistent across all of them. The attacker steals a session after MFA, replays it from rented servers within minutes, and then sets up devices, authenticators and inbox rules that a password reset won't remove.

The fix doesn't need new products. It needs Conditional Access that covers everything without exceptions, tight limits on device-code flow, and a response checklist that goes beyond resetting the password.

Correction (October 25, 2026): An earlier version of this article described Huntress's June 2026 LSHIY campaign as an OAuth2 token-spray attack replaying stolen session tokens. That campaign was a password-spraying attack against Microsoft's Azure CLI using previously breached credentials via the deprecated OAuth ROPC flow, not a replay of stolen session tokens.