More than 200,000 Microsoft 365 sign-in attempts from one German hosting block failed, yet at least 497 still succeeded. According to Huntress, operators spent ten weeks from 14 July through 22 September 2026 replaying stolen cloud sessions across 79 organizations. Victims had already finished multifactor prompts on reverse-proxy pages, or had been steered through device-code and social-engineering paths during real Microsoft sign-ins. Once those sessions existed, replay no longer needed the victim password or a new multifactor challenge.
How reverse-proxy capture turned into hundreds of cloud sign-ins
An adversary-in-the-middle attack places a reverse proxy between the user and the real identity provider. The victim completes a full sign-in, including multifactor, while the operator captures the session the provider issues. Huntress documented that path in detail. On 21 July 2026, a relay caught a victim at the multifactor prompt, hijacked the session, and reused it from hosting addresses under 1337 Services GmbH within about an hour. A new authenticator app was activated on that account the same day.
Capture was not limited to reverse proxies. Huntress also saw users coached through device-code flows and other social engineering while they completed genuine Microsoft sign-in ceremonies. Those paths still handed access and refresh material to an attacker-controlled client. Public reporting does not name the victim organizations, does not pin exact multifactor product brands beyond general prompts and authenticator registration, and does not state how many unique users were compromised.
Replay traffic came from the 193.26.115.0/24 block announced by that German host under AS210558. Successful presentations used Microsoft Office, Authentication Broker, and OfficeHome client applications. Microsoft Entra ID Protection raised verified threat-actor IP detections on multiple addresses in that range. The ratio still matters: more than 200,000 failures against at least 497 successes produced cross-tenant reach into 79 organizations over roughly ten weeks.
Huntress put the core property in plain language: because that token is minted after multifactor succeeds, whoever holds it does not need to pass multifactor again. The authentication ceremony was already finished before the German block ever presented the bearer credential. Password material was not required on reuse. Related workforce reverse-proxy tradecraft showed up earlier in UK industrial reverse-proxy campaigns that likewise harvested live sessions after multifactor completed through a proxy.
| Capture path | What Huntress observed | What the operator held |
|---|---|---|
| Reverse-proxy login | Multifactor finished on attacker page | Replayable cloud session |
| Device-code coaching | Code entered on real Microsoft login | Tokens to attacker client |
| Social engineering at login | Users steered through real flows | Usable sessions |
| Replay from the German block | Office, Auth Broker, OfficeHome clients | 497 successes, no fresh multifactor |
Federation widened the blast radius. A Microsoft 365 cloud session is not a single-app cookie in practice. Mail, files, chat, and Graph-backed services ride the same identity plane once the session exists. Classic SSO auto-sign-in concentrates trust into one proof. When that proof is a transferable bearer token, every integrated workload inherits the compromise until someone revokes the session.
Authenticator wipe, rogue DESKTOP- joins, and password-reset leftovers
Token possession did not stay temporary. In 19 organizations, existing multifactor methods were wiped and a new authenticator registered within three hours of the first campaign sign-in. Huntress recorded attacker-registered methods, including authenticators labeled like an iPhone 13. At least 48 rogue Entra-joined devices appeared with names matching DESKTOP- followed by eight hexadecimal characters. Huntress tied an early example of that naming pattern to a sign-in from 193.26.115.221 on 14 July 2026, the day the campaign window opens in their timeline.
Those attacker-owned factors and devices survive a password reset. According to Huntress key takeaways, containment means revoking the user's sessions, resetting the password, then removing any attacker-registered devices and multifactor methods, which a password reset alone leaves in place. Defenders who only rotated passwords after odd sign-ins from AS210558 still faced second factors and Entra joins the operator controlled.
Self-service enrollment without strong step-up is what made the swap cheap. A holder of a valid session could change methods and join devices when policy allowed it. The first usable token bought a durable foothold on the identity, not just a few hours of mailbox reading.
Hidden inbox rules and the payroll message that followed
With mailbox access established, operators created hidden inbox rules from rented and VPN addresses outside the German hosting block. In at least one case they sent a payroll-themed outbound email as business-email-compromise staging. Creating a rule or sending mail as the user is ordinary post-sign-in mailbox work. No multifactor prompt sits in front of those API calls once the session is valid.
Huntress states that token replay can be prevented with properly implemented Conditional Access policies. Device compliance, trusted locations, and continuous access evaluation raise the cost of presenting a stolen bearer from bulletproof hosting. Session revocation limits how long a stolen token remains useful. Shortening lifetime alone does not stop the first theft; it only forces the operator to re-steal or re-use sooner, and it stops mattering if the operator already registered their own authenticator during the access window.
The industrial path Huntress mapped started at transferable login factors and coached legitimate flows, not malware on every victim PC. Closing transferable factors at sign-in stops a reverse proxy from finishing a real ceremony on a fake origin. Device-code coaching on a genuine Microsoft page still needs policy that refuses or tightly gates that flow. Endpoint malware that lifts cookies after a clean login is a different and harder problem. Here the cheap path was remote capture plus spray replay, then multifactor replacement and mailbox staging.
If you want the prevention view of the same campaign, read how phishing-proof MFA and Conditional Access cut off M365 token replay.
FAQ
How did attackers get Microsoft 365 access in the Huntress token replay campaign?
Attackers in the Huntress Microsoft 365 token replay campaign obtained sessions after victims completed multifactor on adversary-in-the-middle relays, or when device-code phishing and social engineering occurred during genuine Microsoft sign-ins, then replayed those minted tokens from the 193.26.115.0/24 range. According to Huntress, that produced at least 497 successful sign-ins across 79 organizations between 14 July and 22 September 2026 without needing the victim password again on replay.
Did multifactor stop the Huntress campaign once tokens were stolen?
No. In the Huntress M365 token replay campaign, multifactor prompts had already succeeded before operators reused the sessions, so replay from the 1337 Services block required no fresh multifactor challenge. Huntress summarized the property directly: because that token is minted after multifactor, whoever holds it does not need to pass multifactor again. Conditional Access, session revocation, and removal of rogue factors address reuse; another login prompt does not undo possession of a bearer token.
What persistence did Huntress see after the first campaign sign-in?
In 19 organizations in the Huntress campaign, existing multifactor methods were wiped and a new authenticator registered within three hours of the first sign-in from a campaign address. Huntress also found at least 48 rogue Entra-joined devices named DESKTOP- plus eight hex characters. Those attacker-registered methods and devices remain after a password reset unless defenders remove them along with revoking sessions.
Which IP range and clients showed up in the successful replays?
Successful token replays in the Huntress campaign originated in 193.26.115.0/24 under 1337 Services GmbH (AS210558) and were presented through Microsoft Office, Authentication Broker, and OfficeHome client applications. Huntress counted more than 200,000 failed attempts from that range against at least 497 successes, and Microsoft Entra ID Protection flagged multiple addresses there as verified threat-actor IPs.
What mailbox activity followed compromised Microsoft 365 sessions?
After establishing mailbox access in the Huntress-tracked campaign, operators created hidden inbox rules from non-campaign rented or VPN addresses and in at least one case sent a payroll-themed outbound email as BEC staging. Those steps are post-authentication mailbox actions. Multifactor does not gate rule creation or outbound mail once a valid session already exists.
