Securify

A sophisticated campaign that bypassed multi-factor authentication to compromise Microsoft 365 accounts at 79 organizations has been exposed by threat detection firm Huntress, highlighting a growing blind spot in how enterprises defend cloud identities.

The operation, which ran for roughly ten weeks between mid-July and late September 2026, did not rely on stolen passwords or brute-force guessing. Instead, the attackers captured authenticated session tokens — the digital proof that a user has already completed login and MFA — and replayed them at scale against Microsoft 365 tenants. Huntress is calling the technique “token spraying,” a deliberate echo of the well-known password-spraying method, but far more dangerous because each replayed token already carries valid post-MFA authorization.

How the Attack Worked

The campaign used two primary methods to steal session tokens. The first was adversary-in-the-middle (AiTM) phishing: victims were directed to a convincing fake Microsoft sign-in page that silently relayed their credentials and MFA challenge to the real Microsoft servers, then intercepted the resulting session token before passing the legitimate response back to the victim. From the user’s perspective, the login appeared normal. From the attacker’s, they now held a fully authenticated session.

The second technique, introduced in an August wave, was device-code phishing. In this variant, victims were tricked into entering an attacker-controlled device code on Microsoft’s legitimate sign-in page, inadvertently handing over valid refresh and access tokens without any spoofed page required.

Once tokens were captured, the attackers replayed them from rented infrastructure at 1337 Services GmbH, a Hamburg-based hosting provider operating under AS210558. The speed was alarming: in one July incident, the stolen session was replayed just 12 minutes after the victim completed MFA. By September, that gap had narrowed to four minutes.

Scale and Phases

Huntress tracked 497 successful sign-ins across the 79 targeted organizations, alongside more than 200,000 failed login attempts. The campaign unfolded in four distinct phases, each escalating in automation and aggression.

Phase 1 (July 14 to August 3) saw the attackers compromise accounts at 37 organizations and register 37 rogue devices in victims’ Microsoft Entra ID directories. Phase 2 (from August 17) introduced device-code phishing and began manipulating victims’ MFA settings directly. Phase 3, a four-day burst starting September 11, was the most intense: an automated tool replayed captured tokens across roughly 29 organizations, racking up hundreds of successful sign-ins. At the same time, four organizations with properly configured Conditional Access policies blocked 1,052 attempts from a single attacker address. Phase 4 (through September 22) saw the final browser-based replay activity paired with a new AiTM relay hosted at Malaysian provider Evoxt.

Huntress identified two distinct toolsets the attackers rotated through. “Build A” used scripted token exchanges through the Microsoft Office and Authentication Broker client IDs, targeting Microsoft Graph, Exchange Online, SharePoint, and the Device Registration Service. “Build B” replayed browser sessions through the OfficeHome application, mimicking legitimate user agents. The capture relays and replay hosts ran on separate infrastructure, meaning blocking one would not automatically neutralize the other.

What the Attackers Did Once Inside

The post-compromise activity revealed careful planning aimed at persistence and financial fraud. At least 48 rogue devices — all named with a “DESKTOP-” prefix followed by eight hexadecimal characters — were registered in victims’ Entra ID directories. These registrations persist even after a password reset, giving attackers a durable foothold unless security teams specifically audit and remove them.

In 19 organizations, existing MFA methods were wiped and replaced with attacker-controlled authenticators within three hours of the first campaign-linked sign-in. One frequently observed pattern was the addition of an authenticator labeled “iPhone 13,” registered minutes after the initial hijack. This MFA manipulation is particularly insidious: even if defenders reset the compromised password, the attacker’s authenticator remains registered and can be used for future access.

Inbox rules with deliberately inconspicuous names — single characters like “.” or “s,” short strings like “sss” or “iT,” or strings of punctuation — were created to silently redirect or delete incoming mail. Messages were moved to rarely checked folders such as RSS Feeds, RSS Subscriptions, and Conversation History. Some rules specifically targeted financial keywords: in one case, the attackers flagged messages containing “payroll,” “direct deposit,” “bank,” or “bonus,” then sent a payroll-related email to an external accountant. Other compromised accounts sent spam to hundreds of external recipients before Entra ID Protection flagged the activity.

Why MFA Alone Is Not Enough

This campaign is a textbook demonstration of why MFA, while essential, is not a silver bullet. AiTM attacks do not crack or bypass MFA — they let the victim complete it legitimately and then steal the result. The security boundary shifts from “did the user prove their identity” to “is this session being used by the person who created it,” a question that traditional MFA was never designed to answer.

Token-based attacks have been gaining momentum throughout 2026. Microsoft itself has warned about the rise of AiTM phishing kits, and CISA has issued guidance on defending against token theft. What makes this particular campaign notable is its industrial scale — 79 organizations, automated tooling, and a clear progression from opportunistic token capture to systematic business email compromise.

Defending Against Token Replay

Huntress recommends several defensive measures. First and most critically, Conditional Access policies should be configured to require MFA or block access for all users, all cloud apps, and all client app types — not just selected high-risk scenarios. The four organizations that blocked over a thousand attacks in this campaign did so because their Conditional Access policies were comprehensive.

Beyond Conditional Access, organizations should regularly audit Entra ID for unrecognized device registrations, especially those originating from hosting provider IP addresses. MFA method changes — particularly any pattern of existing methods being cleared followed by rapid re-registration — should trigger immediate investigation. Inbox rules with very short, punctuation-only, or randomly generated names warrant scrutiny, as do rules that route mail to RSS or Conversation History folders.

Restricting device-code authentication flow through authentication-flow policies can eliminate one of the two token-theft vectors this campaign relied on. Security teams should also hunt proactively for sign-ins from hosting infrastructure using unusual user agents — specifically the bare node string or a standalone Mozilla/5.0 without a full browser identifier.

For organizations that have already been compromised, session revocation and password reset are necessary but not sufficient. Defenders must also remove unauthorized devices from Entra ID, delete attacker-registered MFA methods, review and remove suspicious inbox rules, and audit newly granted application permissions.

What to Watch Next

As organizations increasingly adopt cloud-first identity architectures, token-based attacks represent the next frontier in credential abuse. The economics favor attackers: a single successful AiTM phish yields a fully authenticated session that can be replayed, scaled, and monetized through business email compromise — all without ever needing the victim’s password.

Expect Microsoft to accelerate the rollout of token binding and continuous access evaluation as countermeasures, and expect phishing kits to evolve in response. For defenders, the lesson from this campaign is clear: identity security in 2026 requires thinking beyond the authentication moment and monitoring the entire lifecycle of every session.