Stop Mirage2FA AiTM at the Microsoft 365 login

A convincing Microsoft 365 page does not need to break cryptography when the second factor still travels as a code, push, or voice response. Mirage2FA (also tracked as LinXcoded) is a commercial adversary-in-the-middle phishing-as-a-service kit that proxied real Microsoft 365 sign-ins, harvested passwords plus live MFA responses, and stole authenticated session cookies for replay. According to ANY.RUN research published 18 August 2026, about 4,532 of 9,426 unique targeted addresses looked compromised across 3,518 organization email domains, with cookie theft the dominant outcome. Device-bound, origin-bound authentication stops that kit at login because there is no transferable secret a remote proxy can complete on the attacker’s behalf.

Why Mirage2FA still finished Microsoft 365 sign-ins

According to ANY.RUN, operators delivered obfuscated HTML, XHTML, and SVG stagers, plus QR lures, often with no obvious body URL. Many messages rode Amazon SES or compromised legitimate Microsoft 365 senders. Victims opened a personalized attachment, passed a fake CAPTCHA, and completed what looked like a normal cloud sign-in. Behind the page, a WebSocket-backed reverse proxy spoke to the real identity service. Passwords crossed first. Live MFA crossed next: Microsoft Authenticator including number matching, TOTP, SMS, and voice. After the real service accepted the ceremony, the kit captured authenticated Microsoft 365 session cookies and related SSO material, stored as Base64 text dumps, and replayed them for mailbox access, impersonation, and fraud without another MFA prompt.

ANY.RUN tallied roughly 9,332 potential compromise events in its dataset, including about 4,561 cookie-theft events, 3,044 password or 2FA events, and 1,339 SSO login events. The firm states these figures are approximate potential-impact estimates from sandbox and threat-intel telemetry, not independently confirmed breaches at each organization. No household-name victim is named in the primary write-up. Observed activity runs from September 2024 through July 2026, with a sharp 2026 rise and heavy United States share (about 63.7%). Roughly one third of successful login events came from mobile devices.

An adversary-in-the-middle attack is a reverse-proxy phishing flow that sits between the victim and the real login service so every typed secret and every approved factor passes through the attacker first. That is the whole product.

During initial access, Mirage2FA stole credentials in the broad sense: passwords plus live second-factor responses while authentication was still completing from the victim’s point of view. The methods ANY.RUN observed are transferable. A proxy can forward a number-match approval, a TOTP code, an SMS code, or a voice response as easily as it forwards a password. Number matching raises the bar against blind push spam when nobody opened a fake page. It fails when the user is actively typing the same number the real app just showed into a hostile Microsoft 365 lookalike.

That is a credential-phase failure of phishable MFA, not a cryptographic break of Microsoft’s servers. ANY.RUN’s key takeaway puts it plainly: Mirage2FA “bypasses conventional MFA to hijack active Microsoft 365 sessions” by capturing “credentials, 2FA codes, and authenticated session cookies.” Read the mechanism, not the marketing. The second factor ran. The attacker simply stood in the middle of it.

The next phase is different. After the identity service issued a normal authenticated session, the kit stole bearer cookies and SSO tokens. Replaying those tokens required no further MFA. Shortening token lifetime does not prevent the theft. It only forces the operator to move faster. If the operator also registers a new authenticator while the stolen session is live, lifetime limits stop mattering for later logins. SSO widens the blast radius: one good cloud session becomes a skeleton key across mail, files, chat, and every app that trusts the same federation proof. Classic SSO auto-login collides with zero-trust’s never-trust, always-verify rule the moment a single cookie leaves the browser.

Containment after cookie theft is revoke-and-hunt work. Kill sessions and refresh tokens. Look for anomalous token reuse and impossible travel. Lean on continuous access evaluation where the stack supports it. That hygiene matters. It is not a substitute for stopping the proxy from finishing the login in the first place.

If you want the full attack-chain narrative, read the related post on legacymfa.sucks: how Mirage2FA stole Microsoft 365 MFA responses and session cookies.

How device-bound keys stop the Mirage2FA relay

Prevention starts at the ceremony the kit needs to complete. Device-bound credentials built on public-key cryptography keep the private key inside hardware. The server stores only public keys. Authentication is a fresh, origin-bound signature for the real login origin, not a reusable code or a push the user can approve on a fake page. A remote AiTM proxy cannot extract that private key, cannot forge the origin-bound signature for the real Microsoft 365 host while presenting a different site to the victim, and cannot relay a secret that never leaves the device. For Mirage2FA-class kits, that means the credential phase dies. No completed proxied login means no attacker-held session cookie from that path.

That is prevention, not detection: remove the transferable factor so the commercial kit has nothing useful to sell. Phishing-proof MFA 2.0 applies that rule across registration, device onboarding, authorisation, authentication, and decommissioning, not only at the password prompt. Passkeys and FIDO2 harden the login act and are correctly called phishing-resistant. Full-lifecycle coverage with no phishable factor at any stage is what makes MFA 2.0 phishing-proof on the strength ladder: password, then OTP or SMS, then push, then phishing-resistant login, then phishing-proof lifecycle controls.

Once a valid session token already exists and is copied by malware on an endpoint that already held a legitimate session, no MFA step undoes that access. Fooling a user into finishing a proxied login is easy at internet scale. Planting malware is harder. Against Mirage2FA, the remote harvest is the primary problem, and it is preventable at authentication. Revoke, short lifetimes, and token-reuse hunting remain backup for the harder endpoint path, not the main lesson of a PhaaS reverse proxy.

SSO needs a separate architectural answer. Classic federation issues one shared proof many apps trust, so one stolen Microsoft 365 session unlocks the estate. Do not bolt more detection onto that design. Secure Explicit Sign-On keeps the same one-tap user experience while authenticating each application independently with its own fresh, device-bound signature. No shared, reusable federation cookie exists to replay across mail, CRM, and file apps after a single proxied ceremony.

Passkeys harden login; lifecycle proof closes the rest

Passkeys and FIDO2 create a device-held key pair for a specific relying party. The private key never leaves the authenticator hardware. When a user signs in to an enterprise identity provider that demands a hardware-bound signature, the browser passes an origin-bound challenge the authenticator signs locally. A Mirage2FA-style proxy that presents a lookalike origin cannot obtain a signature that the real Microsoft 365 identity tier will accept as if it came from the legitimate ceremony. Industry language correctly calls that phishing-resistant at login. It is the right control class against live OTP and push relay.

This Mirage2FA campaign abused live login factors, not helpdesk re-enrollment. The enrollment gap still matters for defenders designing the replacement. Passkeys remain phishing-resistant at the authentication step only. If an organisation onboards devices or recovers accounts with email OTP, SMS, or push, an attacker who controls that channel can enroll their own authenticator and thereafter produce signatures that look legitimate. Phishing-proof coverage refuses phishable factors at registration, device onboarding, authorisation, authentication, and decommissioning. Closing AiTM today while leaving a phishable recovery door open simply moves the kit’s business model to the next lifecycle stage. The enrolment model has to match the login cryptography, or the ladder stops at resistant instead of proof.

Key takeaways for defenders

• Require phishing-proof authentication (passkeys or FIDO) for all Microsoft 365 and federated app sign-ins so AiTM kits cannot relay push, TOTP, SMS, or voice.
• Number matching is insufficient against reverse-proxy phishing; it does not stop a user completing a fake page.
• Prefer per-app, device-bound proof (Secure Explicit Sign-On) over long-lived shared SSO cookies that become skeleton keys after one successful proxy.
• On suspected Mirage2FA exposure, revoke sessions and refresh tokens immediately, hunt token reuse and impossible travel, and enable continuous access evaluation.
• Align recovery and device onboarding with the same hardware-bound standard used at login so phishable reset paths cannot reintroduce the kit.

The operators selling Mirage2FA are not inventing new mathematics. They are industrializing the gap between “MFA enabled” and “no transferable factor on the wire.” Close that gap at every lifecycle stage, and the commercial reverse proxy loses its inventory before the cookie is ever minted.

FAQ

Would passkeys have stopped Mirage2FA from stealing Microsoft 365 session cookies?

Passkeys would have stopped Mirage2FA from completing the proxied Microsoft 365 login that produced those cookies, because there is no OTP, SMS code, or push approval for the AiTM relay to capture and forward. According to ANY.RUN’s description of the kit, session cookies were harvested after conventional MFA succeeded through the proxy. Passkeys are phishing-resistant at login; they do not magically invalidate a cookie already stolen by malware on an endpoint that already held a legitimate session. Against this PhaaS path, preventing the ceremony is what keeps the cookie out of attacker hands.

How is phishing-proof MFA 2.0 different from phishing-resistant passkeys for Mirage2FA-style AiTM?

Phishing-resistant passkeys harden the Microsoft 365 login act with origin-bound, device-held signatures, which blocks Mirage2FA’s live factor relay. Phishing-proof MFA 2.0 goes further by removing phishable factors from every identity-lifecycle stage, including registration, device onboarding, authorisation, authentication, and decommissioning. Mirage2FA itself hit the login wire, not helpdesk recovery, but organisations that deploy passkeys with email or SMS enrollment still leave a lifecycle gap a future kit can target.

Why avoid classic SSO after a Mirage2FA-style cookie theft?

Classic SSO should be avoided after Mirage2FA-style cookie theft because one stolen Microsoft 365 session or federation token unlocks every integrated app without a fresh proof, which is exactly how operators extended mailbox access into broader compromise. Secure Explicit Sign-On keeps one-tap user experience while each application receives its own fresh, device-bound signature. No shared replayable SSO cookie exists to become a skeleton key after a single AiTM success.

Does continuous access evaluation replace stronger MFA against Mirage2FA?

Continuous access evaluation does not replace stronger MFA against Mirage2FA. CAE and session revocation contain bearer tokens after authentication has already succeeded and a cookie is already in attacker hands. The kit’s root enablement was a phishable login the proxy could finish. Device-bound authentication prevents that harvest; CAE is residual hygiene when a token still leaks through malware or an older session.

What should security teams change first to blunt Mirage2FA-class Microsoft 365 AiTM?

Security teams should first enforce phishing-resistant, device-bound authenticators on Microsoft 365 and high-value federated apps so push, TOTP, SMS, and voice cannot be relayed, then pair that with rapid session revoke playbooks and continuous access evaluation. According to ANY.RUN, cookie theft was the dominant outcome once conventional MFA succeeded through the proxy. Fix the login factors that feed the proxy, then shorten and bind what little session material remains.