HIGH: Microsoft 365 Token Replay Attacks Hit 97 Accounts at 79 Orgs

Somebody out there has figured out that guessing passwords is a lot of work when you can simply steal the thing Microsoft hands you after the password and MFA prompt are already done. That is the short version of a campaign Huntress published research on this week, and if you manage Microsoft 365 tenants for a living, it deserves your full attention before your second cup of coffee.

Between July 14 and September 22, 2026, Huntress tracked an operator who compromised 97 Microsoft 365 accounts across 79 organizations by replaying stolen sign-in tokens at scale. The researchers counted 497 successful sign-ins against a backdrop of more than 200,000 failed login attempts, along with 48 rogue devices registered into victims' Entra ID directories. There is no CVE here and no patch coming, because nothing is technically broken. The attacker is using Microsoft's own authentication flows exactly as designed, just with somebody else's session.

Token spraying, explained

Huntress researchers Andrea Hatcher, Susannah Matt, Matt Poto, and Andrew Schwartz describe the technique as token spraying, a deliberate nod to password spraying. "Rather than guessing passwords, the attacker replayed sign-in tokens stolen from victims," they wrote. The tokens came from several places. Some were captured through adversary-in-the-middle relays sitting behind fake Microsoft sign-in pages, where the victim types a password and approves an MFA prompt while the relay quietly forwards everything to the real login page and keeps the resulting session for itself. Others came from device code phishing, which tricks a user into entering a code on Microsoft's legitimate device login page and thereby authorizing the attacker's session. A third bucket came from plain old social engineering during an otherwise legitimate login.

What makes this campaign notable is speed and volume. Replay happened within minutes of capture. On July 21 the gap between theft and reuse was 12 minutes, and by September 22 it had dropped to four. The operator replayed tokens across many organizations in quick succession from attacker-controlled hosts, which is exactly the kind of industrialized workflow that turns a phishing kit into a business.

The replay infrastructure lived almost entirely in the 193.26.115.0/24 range belonging to 1337 Services GmbH (AS210558), a German hosting provider. The campaign was first spotted from 193.26.115.221, an address VirusTotal also associates with AsyncRAT. Huntress tied additional replays to .199, .16, .21, .72, and .210 in the same block, plus 124.198.132.33, 45.83.31.44, and 192.159.99.172 elsewhere in the provider's space. That provider has history. It is linked to StarkRDP and rdp.sh, VPS rental services whose domains were seized in January 2025 during the international law enforcement action known as Operation Talent. StarkRDP denied wrongdoing at the time and promised to come back under a new name. It did, as exy.sh, and both platforms are reportedly operating today. Takedowns make great press releases. They are rarely the end of the story.

Two builds and a lot of persistence

Huntress split the tooling into two builds. Build A announced itself with a user agent of node or a bare Mozilla/5.0, authenticated through the Microsoft Office and Microsoft Authentication Broker client apps, and issued OAuth2:Token requests. Build B was sneakier, presenting a current Chrome or Edge on Windows user agent, signing in through OfficeHome, and generating Login:reprocess and OAuth2:Authorize events that look a lot like a normal person opening a browser. Targets included Microsoft Graph, Exchange Online, SharePoint Online, and the Device Registration Service, and that last one is where things get ugly.

The attacker registered 48 rogue Entra devices, with names following a DESKTOP- plus eight hex characters pattern such as DESKTOP-54521F46. Huntress points out that real Windows machines default to seven alphanumeric characters, so the naming is close enough to fool a hurried admin and wrong enough to hunt for. In the first phase alone, 13 of the 14 incidents on July 14 involved a rogue device. "A registered device can give the attacker a more durable way to request tokens than the stolen session alone," the researchers noted. A device registration persists until someone deletes it, which in most small tenants means forever.

MFA got the same treatment. In at least 19 organizations, the operator wiped existing MFA methods through Microsoft's security info registration service and enrolled a new authenticator within three hours of the first sign-in. In one July 21 incident, an authenticator app labeled "iPhone 13" was activated less than 51 minutes after the session was hijacked. Here is the line every helpdesk should tape to a monitor. "A password reset alone does not remove attacker-registered devices or MFA methods." If your incident response playbook for a compromised mailbox is to reset the password and close the ticket, this attacker is counting on you.

Follow the payroll

Once inside, the goal looked depressingly familiar. Inbox rules were created with names chosen to be forgettable, things like ., sss, ss, iT, ,., ........, s, and d. They marked mail as read, deleted it, or shuffled it into the RSS Feeds, RSS Subscriptions, and Conversation History folders that nobody ever opens. The rule named s targeted messages mentioning payroll, direct deposit, bank, or bonus. The rule named d moved everything from one external CPA's address out of sight, and in that same payroll incident the attacker emailed the CPA directly. That is textbook payroll diversion, the kind of business email compromise that ends with an employee asking why a paycheck never arrived. Four mailboxes had rules created through the Outlook REST API rather than Outlook itself, and the rule activity originated from consumer VPNs and rented hosting such as ExpressVPN, NordVPN, and LeaseWeb rather than the 1337 Services range, so blocking a single /24 will not save you.

Not every intrusion was subtle. In one mailbox, the attacker set a rule to read and delete all incoming mail and then blasted spam to hundreds of external recipients before Entra ID Protection finally rated the account as high risk. Better late than never, but that tenant's domain reputation probably had a rough week. Huntress has not attributed the activity to a named group, and nothing in the research points to a nation state. This looks like financially motivated crime run with startup efficiency.

What to do this week

Huntress' most pointed advice is about Conditional Access. "Businesses setting up CAPs should require MFA (or block) for All Users, All Cloud Apps, and All Client App types, unconditionally." Exclusions, legacy client carve-outs, and the policy someone promised to tighten later are where token replay lives. The researchers also warn defenders not to take comfort in a block. "Treat Conditional Access blocks (AADSTS53003) as a sign of a valid credential, not a save." A blocked sign-in with a correct password means the password is burned.

They also caution against triaging by noise. "Do not trigger response based on spray volume, as it points at the most-sprayed, least-compromised tenants." Prioritize by whether a credential or token was actually valid, not by which tenant got hammered hardest.

For any account you suspect is compromised, containment means revoking all sessions, resetting the password, removing any attacker-registered devices, and removing any MFA methods the user does not recognize. Do all four, because skipping any one of them leaves the door propped open. Then audit Entra devices across every tenant you manage for names starting with DESKTOP-, Device-, or Work Pc followed by eight hex characters, paying special attention to devices registered from hosting provider IP space. Confirm before deleting, since Huntress notes the pattern is not unique to this campaign. Review MFA registration logs for methods cleared and re-added within minutes. Sweep inbox rules for names that are one to three characters or pure punctuation, rules that route mail into RSS or Conversation History folders, and rules keyed on payroll and banking terms.

Device code flow deserves its own conversation. Most organizations have no business reason to allow it for regular users, and Conditional Access authentication flow policies can block it outright. If you genuinely need it for conference room hardware or similar gear, scope it to restricted service accounts. While you are in there, hunt for newly granted enterprise applications and consider disabling user consent to new apps, since OAuth consent is the next logical persistence trick for anyone already this comfortable in your tenant.

For threat hunters, the sign-in log signature is fairly specific. Look for OAuth2:Token and Cmsi:Cmsi sign-ins coming from hosting infrastructure, using the Office or Authentication Broker client apps with node or bare Mozilla/5.0 user agents, particularly when followed by mailbox access or Device Registration Service activity. Alert on 193.26.115.0/24 while you are at it, knowing that the operator rotates infrastructure and the mailbox activity already came from elsewhere.

Longer term, this campaign is one more argument for phishing resistant authentication. Passkeys and FIDO2 security keys bind the sign-in to the legitimate origin, which breaks the relay model that fed much of this operation. Token protection policies that tie sessions to the device that requested them are worth piloting too, licensing permitting. Push notifications and SMS codes are better than nothing, but this operator has demonstrated over and over that "MFA enabled" and "account protected" are not the same sentence.

The MSP angle

Every one of those 79 organizations presumably believed MFA had them covered, and they still got owned, which makes this the cleanest possible opener for a Conditional Access and identity threat review with your clients. Package an Entra hygiene audit covering rogue devices, MFA method changes, inbox rules, and app consents as a fixed fee assessment, then convert the findings into a managed identity threat detection and response service paired with a phishing resistant MFA rollout.