More than 200,000 Microsoft 365 sign-in attempts from one German hosting range failed, yet at least 497 still landed across 79 organizations. According to Huntress, operators spent ten weeks from 14 July through 22 September 2026 capturing cloud sessions through adversary-in-the-middle relays, device-code coaching, and social engineering during real Microsoft sign-ins, then replaying the minted tokens without the victim password or a fresh multifactor challenge. Preventing that campaign means stopping reverse-proxy completion of workforce login so a stealable primary session is never issued, hardening enrollment so a stolen session cannot wipe and replace authenticators, and using Conditional Access plus explicit revoke against bearer reuse that no login prompt can undo.
What Huntress documented across 79 Microsoft 365 tenants
Huntress first tied campaign activity to 14 July 2026, including a sign-in from 193.26.115.221 linked to an Entra-joined device named DESKTOP- plus eight hexadecimal characters. On 21 July 2026, an adversary-in-the-middle relay caught a victim at the multifactor prompt, hijacked the session, and reused it from 1337 Services GmbH addresses within about an hour while a new authenticator app was activated the same day.
An adversary-in-the-middle attack places a reverse proxy between the user and the real identity provider so the victim finishes a full sign-in, including multifactor, while the operator captures the session the provider issues. Huntress also observed parallel device-code phishing and social engineering while users completed genuine Microsoft login ceremonies. Those paths still delivered access and refresh material to attacker-controlled clients. 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.
Successful replays originated in 193.26.115.0/24 under 1337 Services GmbH (AS210558) and were presented through Microsoft Office, Authentication Broker, and OfficeHome clients. Microsoft Entra ID Protection raised verified threat-actor IP detections on multiple addresses in that range. In 19 organizations, existing multifactor methods were wiped and a new authenticator registered within three hours of the first campaign sign-in. Huntress counted at least 48 rogue Entra-joined devices with the DESKTOP- hex naming pattern. Operators later created hidden inbox rules from rented and VPN addresses outside that block and, in at least one case, sent a payroll-themed outbound email as business-email-compromise staging.
If you want more detailed information about this attack, read the related post on legacymfa.sucks: Huntress M365 token replay across 79 organizations.
Why multifactor prompts still produced stealable cloud sessions
The reverse-proxy path did not skip multifactor. Victims completed prompts on attacker-controlled pages. The identity provider still minted a valid post-MFA bearer token, and that token moved into operator hands. Huntress stated the property directly: because that token is minted after MFA, whoever holds it does not need to pass MFA again. OTP, SMS, email codes, and push approvals are transferable factors. A live relay can collect them while the real ceremony finishes, then present the resulting session from bulletproof hosting.
Device-code coaching and social engineering during legitimate Microsoft sign-ins are a parallel capture path. The user is steered through a real provider page, yet the tokens land with an attacker client. That flow is not the same as a fake origin proxy, but the outcome is the same class of transferable session material. Related workforce reverse-proxy harvest showed up earlier in industrial AiTM login relay analysis, where live sessions likewise followed multifactor completed through a kit.
Replay from 193.26.115.0/24 required no victim password and no fresh multifactor challenge. Bearer cloud sessions behave like reusable tickets once issued. Classic SSO and federation widen the blast radius: mail, files, chat, and Graph-backed services ride the same identity plane without a new proof at each app. That design conflicts with zero-trust “never trust, always verify” at every access boundary. One stolen Microsoft 365 session becomes a skeleton key until someone revokes it.
Persistence made the first token more valuable than a short mailbox window. A holder of a valid session could wipe existing multifactor methods and register a new authenticator when self-service enrollment lacked strong step-up, approval, or compliance gates. Attacker-registered methods, including authenticators labeled like an iPhone 13, and rogue Entra joins survive a password reset unless defenders remove them. Huntress containment guidance is explicit: revoke sessions, reset the password, then remove attacker-registered devices and multifactor methods, which a password reset alone leaves in place.
Mailbox rules and outbound payroll mail are ordinary post-sign-in actions. No multifactor prompt sits in front of those API calls once the session is valid. Huntress notes that token replay can be prevented with properly implemented Conditional Access policies. Device compliance, trusted locations, continuous access evaluation, and explicit session revocation raise the cost of presenting a stolen bearer from AS210558. Shortening token lifetime alone does not stop the first theft. It only forces earlier reuse, and it stops mattering if the operator already registered their own authenticator during the access window.
| Phase in this campaign | What operators held | What closes it |
|---|---|---|
| AiTM reverse-proxy login | Post-MFA primary session | Origin-bound device keys at sign-in |
| Device-code coaching | Tokens on attacker client | Block or tightly gate device-code flow |
| Replay from German block | Bearer presented without MFA | Conditional Access, CAE, revoke |
| MFA wipe within three hours | Attacker authenticator and DESKTOP- joins | Protected enrollment and compliance gates |
| Hidden rules and payroll mail | Mailbox API access | Session kill and mailbox controls |
What phishing-proof device-bound authentication changes here
Device-bound, origin-bound authentication changes the reverse-proxy math. The private key never leaves hardware, and signatures are bound to the real relying-party origin. A fake login page is the wrong origin. There is no OTP, push, or recovery secret to type or read out through the relay. The provider never completes a real sign-in through the attacker page, so the kit never receives a freshly minted primary session to spray from 1337 Services space. That is prevention, not detection: the cheap remote capture path fails before a bearer exists.
Once a legitimate session already exists on a machine, local malware or memory theft is a different and harder problem. Login cryptography does not erase a cookie already sitting in attacker infrastructure. For the Huntress spray, the industrial cheap path was remote capture plus replay, not infostealers on every victim PC. Closing phishable factors at sign-in stops the reverse proxy from minting the token the German block later presented.
Device-code phishing on a genuine Microsoft page still needs identity policy that refuses or tightly constrains that flow. Origin-bound keys stop a fake proxy origin. They do not, by themselves, stop a user who willingly completes device-code on the real provider. Pair phishing-proof sign-in with Conditional Access controls that block high-risk client apps and untrusted networks, continuous access evaluation that re-checks session posture, and immediate revoke when Entra ID Protection flags verified threat-actor IPs in ranges like 193.26.115.0/24.
Federation blast radius needs an architectural answer beyond bolting more alerts onto classic SSO. Secure Explicit Sign-On keeps one-tap user experience while authenticating each application with its own fresh, device-bound signature. No shared, reusable federation cookie exists to replay across mail, files, and chat. When operators held a Microsoft 365 session long enough to create inbox rules and stage payroll mail, a single transferable SSO token was exactly the skeleton key zero trust warns against.
Protected enrollment closes the three-hour wipe Huntress saw in 19 organizations. Registering or replacing a factor must require an already-enrolled device, not a phishable code or a session alone. Device-compliance gates block silent Entra joins named DESKTOP- plus eight hex characters. Without that lifecycle control, the first stolen token buys durable identity ownership that outlives password rotation.
The same industrial pattern that failed against device-bound login in UK reverse-proxy campaigns applies here: stop the kit from finishing sign-in, then treat any token already captured as revoke-and-contain work rather than another prompt.
Passkeys and FIDO2 against reverse-proxy capture
Passkeys and FIDO2 put a key pair on the user device. The private key stays in hardware. Each login produces an origin-bound signature instead of a typed secret. Industry language correctly calls that phishing-resistant at the login act: a reverse proxy cannot complete the ceremony on a spoofed host the way it relays OTP or push. On a generic enterprise identity provider that issues only hardware-bound signatures, the fake page never obtains a usable assertion. Passkeys harden authentication. They do not automatically harden every enrollment or recovery path unless the deployment forbids phishable step-up.
Closing the enrollment gap Huntress exposed
FIDO2 and passkeys remain phishing-resistant at login only when enrollment still accepts email codes, SMS, or session-only self-service. In this campaign, operators who already held a valid session wiped existing methods and registered new authenticators within three hours in 19 organizations, then left rogue Entra devices in place after password resets. Phishing-proof coverage means no phishable factor at registration, device onboarding, authorisation, authentication, or decommissioning. Enrolment policy that demands an already-enrolled device for replacement, plus compliance gates on Entra joins, is what stops silent factor takeover after the first token lands.
Key Takeaways for Defenders
- Prefer origin-bound, device-bound sign-in for Microsoft 365 so reverse proxies cannot mint primary sessions on fake origins.
- Block or tightly Conditional-Access-gate device-code flow and high-risk clients such as unexpected Authentication Broker use from untrusted networks.
- Treat 193.26.115.0/24-class verified threat-actor IP hits as immediate session revoke events, not ticket noise.
- Require already-enrolled device step-up to register or replace multifactor methods; remove attacker authenticators and DESKTOP- hex Entra joins after every incident.
- Replace classic SSO blast radius with per-app device-bound proof where federation would otherwise turn one bearer into mailbox, files, and BEC staging access.
Huntress mapped a campaign that started with transferable login factors and ended with authenticator ownership and payroll-themed mail. The fix is not a louder push prompt. It is phishing-proof sign-in that never issues the stealable session through a relay, enrollment that refuses silent replacement, and session controls that make a minted bearer die on arrival from bulletproof hosting.
FAQ
Would phishing-proof MFA have stopped Huntress AiTM session capture?
Phishing-proof device-bound MFA would have stopped the Huntress campaign’s reverse-proxy path from finishing a real Microsoft 365 sign-in on a fake origin, so operators would not have received a freshly minted primary session to replay from 193.26.115.0/24. Signatures are origin-bound and the private key never leaves hardware, so OTP and push relay through an adversary-in-the-middle kit fails. Device-code coaching on a genuine Microsoft page still needs Conditional Access that blocks or constrains that flow, and any token already stolen still needs revoke.
Why can login MFA not undo Huntress-style token replay?
Login MFA cannot undo Huntress-style token replay because the multifactor ceremony had already succeeded before operators presented the bearer from 1337 Services infrastructure. According to Huntress, because that token is minted after MFA, whoever holds it does not need to pass MFA again. Conditional Access, continuous access evaluation, token protection where available, and explicit session revocation address reuse. Another prompt at sign-in does not erase possession of a minted cloud session.
How does protected enrollment stop the MFA wipe Huntress saw?
Protected enrollment stops the MFA wipe Huntress documented in 19 organizations by refusing factor replacement and new device registration based on a stolen session alone. Operators wiped existing methods and registered new authenticators within three hours of the first campaign sign-in, and at least 48 rogue Entra-joined DESKTOP- devices appeared. Requiring an already-enrolled device for replacement, plus compliance gates on joins, keeps attacker authenticators and devices from surviving password reset.
Why does MFA 2.0 avoid classic SSO for Microsoft 365 blast radius?
MFA 2.0 avoids classic SSO because one stolen Microsoft 365 session in the Huntress campaign unlocked mailbox rules, outbound payroll staging, and broad Graph-backed access without a fresh proof per app. Secure Explicit Sign-On keeps one-tap UX while each application receives its own fresh, device-bound signature. No shared replayable federation cookie exists to spray across integrated workloads the way a single SSO bearer did for these operators.
What should defenders combine with phishing-proof sign-in after this campaign?
Defenders responding to Huntress-style Microsoft 365 token replay should combine phishing-proof sign-in with Conditional Access that Huntress says can prevent token replay when properly implemented, immediate revoke on verified threat-actor IP detections, removal of attacker-registered MFA methods and Entra devices, and blocks on device-code abuse. Password reset alone leaves rogue factors in place. Short token lifetimes do not stop first capture and stop mattering after authenticator replacement.
