Mirage2FA AiTM stole M365 MFA and session cookies

Nearly half of the unique enterprise mailboxes targeted by one commercial phishing kit never needed a second try. According to ANY.RUN, Mirage2FA (also tracked as LinXcoded) is an adversary-in-the-middle phishing-as-a-service toolkit that proxied Microsoft 365 logins in real time, harvested passwords plus live MFA responses, then stole authenticated session cookies for replay. Across that dataset, about 4,532 of 9,426 unique targeted addresses looked compromised, spanning 3,518 organization email domains, with cookie theft the dominant outcome. 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. Number matching, TOTP, SMS, and voice all rode that wire. The cookie that followed did not ask for MFA again.

How Mirage2FA lures forced a proxied Microsoft 365 login

Delivery did not depend on a neat link sitting in the email body. According to ANY.RUN, operators favored HTML smuggling and related attachment tricks: hundreds of sampled stagers arrived as .htm, XHTML, or SVG payloads, often dressed as document or remittance notices. JavaScript was heavily obfuscated. Many messages carried no obvious URL at all. QR-code lures showed up as another path onto the same fake Microsoft 365 surface. Distribution included Amazon SES and, critically, compromised legitimate Microsoft 365 senders, which is how a lure can inherit trust a brand-new domain never earns.

Stagers were personalized. Per-recipient tokens (for example LINXB64EMAIL-style markers) loaded follow-on scripts from paths such as /xls/<token>.js, so each victim hit a tailored next stage rather than a single static page. Victims who opened the attachment met a fake CAPTCHA, then a login experience that looked like Microsoft 365. Behind that page, a WebSocket-backed reverse proxy talked to the real identity service. From the victim’s point of view, authentication was still in progress. From the operator’s point of view, every field and every second-factor response was already on the wire.

Campaign activity in the observed window runs from September 2024 through July 2026, with a sharp rise through 2026. ANY.RUN recorded steady growth in sandbox sessions from March through July 2026, including 445 sessions already logged in July before collection closed. The firm’s own note is mandatory reading for anyone quoting the scale: all victim, compromise, and campaign-scale figures are approximate estimates from the available dataset and represent potential impact, not independently confirmed org-by-org breaches. No single household-name victim is publicly named in the primary write-up. Geography in the set skews heavily toward the United States (about 2,885 victims, or 63.7% of the total), with activity touching 94 countries. Industry share leaders include technologies (19.2%), manufacturing (11.1%), and education (9.9%). Roughly one third of successful login events came from mobile devices.

Why live MFA responses still handed over the session

The credential phase is where conventional second factors failed in plain sight. Mirage2FA did not need to break cryptography. It needed victims to complete a real Microsoft 365 login through a hostile proxy. Passwords arrived first. Then the live MFA step arrived with them: Microsoft Authenticator prompts including number matching, TOTP codes, SMS codes, and voice calls. ANY.RUN’s key takeaway states that Mirage2FA “bypasses conventional MFA to hijack active Microsoft 365 sessions” by using an AiTM flow “to capture credentials, 2FA codes, and authenticated session cookies.” Read that carefully. The methods observed are transferable factors. A proxy can forward a push approval, a typed code, or a voice response as easily as it forwards a password. Number matching raises the bar against blind push fatigue. It does not stop a victim who is staring at a convincing fake page and typing the same number the real app just showed.

Across 9,332 potential compromise events in the dataset, ANY.RUN tallied about 4,561 cookie-theft events, 3,044 password/2FA events, 1,339 SSO login events, and 388 other. Session hijack was not a side effect. It was the product. Once the real identity service accepted the proxied ceremony, it issued normal authenticated Microsoft 365 session material. The kit stored stolen cookies as Base64-encoded text dumps. Operators then replayed those sessions for mailbox access, business-email compromise style impersonation, fraud, and further compromise without re-triggering MFA. According to ANY.RUN, once an authenticated Microsoft 365 session is hijacked, attackers may reach corporate email, sensitive data, and trusted business accounts along that path.

That second phase is token theft after authentication already succeeded. No second factor undoes a bearer cookie the attacker already holds. SSO makes the blast radius worse: one good cloud session becomes a skeleton key across mail, files, and every other app that trusts the same sign-in. Shortening token lifetime only forces the attacker to move faster. It does not erase a cookie already copied out of the proxy. If the operator also registers a new authenticator while the stolen session is live, lifetime limits stop mattering for the next login entirely.

What the campaign leaves defenders holding

Defenders who only ask “did users have MFA on?” miss the mechanism. The users in these flows often did have MFA on. The factors in play were phishable, so the proxy completed authentication on the attacker’s timeline. Device-bound, origin-bound authentication changes the credential phase because there is no reusable code or push approval for a remote kit to relay, and the private key never crosses the network for the attacker to replay. That is prevention at login. It is not a magic wipe for cookies already stolen through some other path, such as malware on an endpoint that already held a legitimate session. For Mirage2FA-class kits, the remote harvest dies when the login ceremony stops producing transferable secrets and replayable sessions for a proxy.

After a cookie is already out, the work is uglier: revoke sessions and refresh tokens, hunt anomalous token reuse and impossible travel, and lean on continuous access evaluation where the stack supports it. That containment is necessary hygiene. It is not a substitute for stopping the kit at the login page. Related reporting on the same LinXcoded kit family has also described compromised Microsoft 365 senders paired with post-MFA session replay, which matches the pattern ANY.RUN documented at campaign scale.

If you want to skip the attack details and go straight to what can stop this, read the related article on mfa2point0.com: how passkeys, phishing-resistant MFA, and session controls answer Mirage2FA-style M365 AiTM.

FAQ

How did Mirage2FA steal Microsoft 365 access if MFA was enabled?

Mirage2FA stole Microsoft 365 access by proxying the real login in real time, so victims typed passwords and completed live MFA (Authenticator with number matching, TOTP, SMS, or voice) through the attacker’s page. The kit captured those responses and the authenticated session cookies that Microsoft 365 issued afterward. MFA was not cryptographically broken; phishable factors were relayed, then bearer cookies were replayed without another prompt.

What is LinXcoded in relation to Mirage2FA?

LinXcoded is the other public tracking name for the same commercial AiTM phishing-as-a-service toolkit family described as Mirage2FA. According to ANY.RUN’s research published 18 August 2026, the kit delivers obfuscated HTML, XHTML, SVG, and QR lures that impersonate Microsoft 365 document or payment notices and relays authentication to capture credentials, MFA responses, and session cookies.

Did number matching stop the Mirage2FA AiTM proxy?

Number matching did not stop the Mirage2FA AiTM proxy. ANY.RUN observed Microsoft Authenticator with number matching among the methods captured live through the relay. Number matching helps against blind approval spam when the user never opened a fake page. It fails when the user is actively completing what they believe is a real Microsoft 365 sign-in on the attacker’s proxy.

How large was the Mirage2FA campaign according to public research?

According to ANY.RUN, the dataset showed about 4,532 potentially compromised addresses out of 9,426 unique targeted emails (roughly 48%), linked to 3,518 organization domains, and 9,332 potential compromise events including about 4,561 cookie thefts. The firm states these are approximate potential-impact estimates from sandbox and threat-intel telemetry, not fully confirmed breaches at each organization, and no household-name victim is named in the primary write-up.

What should IT do first after a suspected Mirage2FA session theft?

After a suspected Mirage2FA Microsoft 365 session theft, IT should revoke the affected sessions and refresh tokens immediately, hunt for anomalous token reuse and impossible-travel sign-ins, and review mailbox rules and outbound impersonation. Those steps contain cookies already stolen. Stopping the next relay requires replacing phishable login factors with device-bound authentication and tightening session controls such as continuous access evaluation.