Mirage2FA: The Victim Completes MFA Correctly — and the Attacker Takes the Session

On 18 August, sandbox vendor ANY.RUN published a report on Mirage2FA — a commercial phishing-as-a-service kit built to compromise Microsoft 365 accounts. Analysts ShiFu and raptur3 tracked the campaign from September 2024 to July 2026 and attribute it to a crew branding itself LinX Coders.

The kit does not break MFA. It lets the victim complete the sign-in fully and correctly — then walks off with the authenticated session.

What the numbers actually count

The figures are being quoted widely, usually without the qualification ANY.RUN attaches to them:

Important: ANY.RUN states explicitly that all victim and campaign figures are estimates based on the available dataset. They describe potential impact, not independently confirmed compromises. Anyone lifting these numbers into a board paper should carry that caveat with them, or the paper will claim a precision the source does not offer.

Technology, manufacturing and education are the most heavily targeted sectors. Europe's share is smaller than America's, but the infrastructure is rented: what works in the US is deployed here by different customers of the same vendor.

Why MFA loses here

Mirage2FA sits as a reverse proxy between the user and Microsoft. When someone enters username, password and one-time code on the cloned sign-in page, the kit relays all of it to the genuine Microsoft service in real time over a persistent WebSocket channel. Microsoft validates, accepts and issues a valid session cookie — and that cookie is what the proxy keeps.

From that point the attacker needs neither password nor second factor. Replaying the cookie reaches mailboxes, SharePoint, OneDrive and every application behind single sign-on, without triggering another authentication prompt.

The operative sentence: a forced password change does not end that access. The stolen cookie stays valid until the session is actively revoked or expires. The kit is designed around exactly that — it targets the one thing a password reset does not fix.

Delivery is where you can stop it

Mirage2FA ships no executable. The chain runs entirely inside the victim's browser:

• attachments in .htm, .xhtml and .svg format as the entry stage
• QR codes as an alternative route to the phishing page
• heavily obfuscated JavaScript — of 629 .htm samples examined, 453 were obfuscated
• loader paths following the pattern /xls/*.js

Two consequences for defenders. First, EDR sees nothing because there is nothing to see: no binary, no process launch, no endpoint persistence. Second, the delivery path is trivial to narrow — almost no organisation needs HTM, XHTML or SVG attachments arriving in the inbox. That is a gateway rule, not a project.

A second finding belongs in every awareness plan: 33.3 percent of successful sign-ins came from mobile devices. On a phone the URL bar is truncated or absent, so the check that training relies on is effectively unavailable.

Artefacts worth hunting

ANY.RUN lists markers that survive infrastructure changes:

• placeholders and build markers: LINXCODERSEMAIL, later LINXEMAIL, then LINXB64EMAIL
• in-page variables uid, self.u, RSTRING2
• canonical loader filename a1p2i.js, XOR key 0xAD, test password linxz
• Telegram bots linxlogsss…bot and linxxlogss…bot, and a channel LinXcoded advertising a "LinX Sender", a "2FA Cookies Attachment/Link" and a "LinXMail Token Link App"
• operator test traffic from the same 185.174.100.0/24 subnet as the production C2; the most recent test dates to 3 July 2026

The full report contains more than 60 phishing domains and 21 operator test IP addresses. Domains and IPs age out; the LINX* markers and the loader structure are the more durable hunting criteria.

What actually helps

TOTP apps, SMS codes and push approvals are all relayable through the proxy. What is not:

1. Phishing-resistant MFA — FIDO2 keys, passkeys, Windows Hello for Business. These bind the assertion cryptographically to the origin domain. The private key never leaves the device, and a proxy on a lookalike domain never obtains a valid assertion. This is the only control that prevents the attack rather than containing it.
2. Attachment filtering at the mail gateway for .htm, .xhtml and .svg. Effort: one rule. Effect: the entry stage disappears.
3. Entra Token Protection — binds session tokens to a device key, so a replayed token fails. Check availability against your licensing and workloads.
4. Conditional Access with a device-compliance requirement for Exchange Online, SharePoint and Teams. An attacker's access does not satisfy it.
5. Continuous Access Evaluation — revokes sessions on a risk signal instead of waiting out the token lifetime.
6. Alerting on mailbox-rule changes and new OAuth consents. The last line once prevention has failed.

The deadline that settles the decision anyway

From 1 September 2026, Microsoft makes passkeys the default sign-in experience in Entra ID. Accounts enabled for SMS or voice will be automatically enabled for passkeys and prompted to register at their next MFA. From 1 February 2027, Microsoft retires its own SMS and voice delivery; organisations that still need it must connect their own telecom provider.

That removes the argument about timing. If the migration is happening regardless, it can happen in an orderly way: a passkey registration campaign can be enabled now, ahead of automatic enablement, from the Entra admin centre under authentication methods. Sensible order: privileged accounts and IT first, then departments on modern managed devices, then the hard cases with shared devices and legacy systems.

Microsoft justifies the move with its own telemetry: AI-assisted phishing campaigns reach click-through rates as high as 54 percent, against roughly 12 percent for conventional ones.

After the fact: an identity incident, not a password problem

ANY.RUN's guidance for a confirmed case sets the right order, and it differs from what many playbooks contain:

1. Revoke all active sessions and tokens — not merely reset the password.
2. Review mailbox forwarding rules, including hidden and folder-scoped ones.
3. Review granted OAuth permissions — an application consent survives any password change.
4. Audit every action taken through the compromised identity, not just the sign-in itself.

Stop at step one and you have not locked the attacker out.

The regulatory reading

NIS2. Article 21(2)(i) requires access-control policies and 21(2)(j) explicitly requires multi-factor or continuous authentication. Neither specifies a strength — Article 21(1) ties the measures to the state of the art and to actual risk. In practice: TOTP is not unlawful today, but explaining after an AiTM incident why a bypass that is documented and rented out as a service went unaddressed is an uncomfortable conversation. Germany's NIS2UmsuCG carries the same catalogue into national law.

ISO/IEC 27001:2022. The relevant controls are A.5.17 (authentication information) and, more directly, A.8.5 (secure authentication). No external body issues a binding ruling on which MFA variant suffices — certification bodies audit against the organisation's own risk assessment. That is precisely the exposure: an organisation whose risk assessment does not name AiTM, while the attack is sold commercially as a kit, has a gap in its process, not only in its technology.

For NEOSEC XIEM customers

The standard Wazuh rule set includes alerting on suspicious mailbox-rule creation drawn from Microsoft 365 audit logs (rule IDs 200401–200404). Customers who have not yet moved to FIDO2 or passkeys receive the recommendation through their XIEM report; the rollout normally fits inside two change windows — and belongs before 1 September rather than after.