Stop Mirage2FA AiTM at the Microsoft 365 login

Number matching was supposed to kill blind push spam. Mirage2FA still walked away with the cookie.

According to ANY.RUN research published 18 August 2026, Mirage2FA (also tracked as LinXcoded) proxied real Microsoft 365 sign-ins, harvested passwords plus live MFA responses, and stole authenticated session cookies for replay. About 4,532 of 9,426 unique targeted addresses looked compromised across 3,518 organization email domains. Cookie theft was the dominant outcome.

Same mold as Greatness. Different kit. Same transferable factor. MFA 2.0 binds proof to device and origin so the proxy has nothing worth replaying.

Why OTP, push, and number matching finished Microsoft 365 login for the wrong party

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 between the victim and the real login service. Every typed secret and every approved factor passes through the attacker first. That is the whole product. Same mold as Greatness. Different kit. Same transferable factor.

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. A proxy can forward that approval as easily as it forwards a password.

That is a credential-phase failure of phishable MFA, not a cryptographic break of Microsoft's servers. ANY.RUN 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. Containment after cookie theft is revoke-and-hunt work. Kill sessions and refresh tokens. Hunt anomalous 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.

For the attack-side walkthrough, see the related post on legacymfa.sucks: how Mirage2FA stole Microsoft 365 MFA responses and session cookies.

How phishing-proof MFA 2.0 keeps the session from issuing at all

Stop the kit at the login it tried to complete. Device-bound credentials use public-key cryptography on enrolled hardware. The private key never leaves the device, never crosses the network, and never appears in a proxy transcript. Each authentication produces a fresh signature origin-bound to the real enterprise identity provider. A lookalike domain cannot obtain a valid signature for the legitimate origin. There is no OTP to relay, no SMS code to forward, and no push or number-match approval to complete on a fake page.

Against Mirage2FA, that means the AiTM path dies before a Microsoft 365 session is minted for the attacker. No transferable factor. No replayable cloud cookie from that path. That is prevention of the exact failure ANY.RUN documented, not another detection rule on sessions that should never have been issued.

Passkeys and FIDO2 are phishing-resistant at the login act when private keys stay device-bound and origin-bound with no OTP or push fallback. That hardens the ceremony Mirage2FA abused. Phishing-proof MFA 2.0 goes further across the identity lifecycle: registration, device onboarding, authorisation, authentication, and decommissioning use no phishable factor. This wave's documented path was the login ceremony, not helpdesk re-enrolment. The next operator who switches to recovery is why the full lifecycle still matters.

It is not a claim about malware reading memory after a good login already happened. With no phishable step at sign-in, the attack has nothing to capture. Malware on a machine that already holds a session is a separate attack with a higher cost.

SSO turned one stolen proof into a skeleton key

SSO multiplies damage when the first proof is stolen. Classic federation issues one session many integrated apps trust. Mail, files, chat, and every app that trusts the same federation proof ride the same earlier success. Zero-trust language says never trust, always verify at each access boundary. Classic SSO does the opposite. It auto-signs the user into many workloads from one earlier proof. When that proof was captured by a commercial reverse proxy, the blast radius is the federated surface, not a single mailbox.

Bolting more detection onto broken SSO is not the answer. Secure Explicit Sign-On keeps one-tap UX while authenticating each application independently with its own fresh, device-bound signature. No shared reusable federation cookie exists to steal once and replay everywhere. For a Microsoft 365 estate hit by Mirage2FA-style harvest, that shrinks blast radius even if some other path later appears.

Residual risk after the login path is closed is different. A phishing kit then has no usable session to harvest. The remaining way to steal a live token is malware or an infostealer on an endpoint that already holds a legitimate session. Tricking a user into an HTML or SVG lure costs an attacker little; compromising a device that is already signed in costs far more. Revoke of access and refresh tokens, continuous access evaluation, and shorter lifetimes remain hygiene for that harder path. They are not equivalent controls to stopping the kit at authentication.

The operators selling Mirage2FA are not inventing new mathematics. They are industrializing the gap between "MFA enabled" and "no transferable factor on the wire." Same gap Greatness sold. Stop minting those sessions. Private key on the device. Signature bound to the real origin. The commercial reverse proxy becomes an expensive way to capture nothing useful.

If you want the control-side walkthrough of phishing-proof, device-bound authentication, start at prevention, not detection.

FAQ

Would phishing-proof MFA 2.0 have stopped Mirage2FA from stealing Microsoft 365 session cookies?

Yes, at initial access. Private keys never leave enrolled hardware and signatures are origin-bound, so a Mirage2FA reverse proxy cannot complete authentication or receive a replayable Microsoft 365 session cookie. Passkeys would have hardened the same login act if they stayed device-bound with no OTP or push fallback. Token or cookie theft after malware already holds a legitimate session is a separate residual problem. Prevention keeps that residual path from opening via a PhaaS kit.

How is phishing-proof MFA 2.0 different from phishing-resistant passkeys here?

Passkeys are phishing-resistant at login when private keys stay device-bound and origin-bound. That blocks Mirage2FA's live factor relay. Phishing-proof MFA 2.0 removes phishable factors from registration, device onboarding, authorisation, authentication, and decommissioning. Mirage2FA hit the login wire, not helpdesk recovery. Organisations that deploy passkeys with email or SMS enrolment still leave a lifecycle gap a future kit can target.

Why is shortening token lifetime or CAE not enough?

Lifetime limits and continuous access evaluation do not stop Mirage2FA from harvesting a valid session during login. According to ANY.RUN, cookie theft was the dominant outcome once conventional MFA succeeded through the proxy. A shorter TTL only forces faster reuse. CAE and revoke contain bearer tokens after authentication has already succeeded. They are residual hygiene, not a substitute for a phishable front door.

How does Secure Explicit Sign-On differ from classic SSO here?

SES authenticates each application with its own fresh, device-bound signature instead of issuing one shared session many apps trust. In this campaign, a stolen Microsoft 365 session or federation token unlocked mailbox access and broader compromise without another MFA prompt. Classic SSO conflicts with zero-trust verify-at-each-boundary design. SES keeps one-tap UX while removing the reusable federation cookie that became a skeleton key after the AiTM harvest.

What should change first after this Mirage2FA wave?

Retire transferable OTP, push, SMS, voice, and number matching from interactive Microsoft 365 authentication so a proxy cannot finish MFA and receive the session. Reduce reliance on a single cloud SSO cookie across mail, files, and chat by moving toward per-app device-bound proof. Keep revoke, CAE, and token-reuse hunting as containment for residual malware-grade theft, not as the primary answer to a phishable front door.