Mirage2FA shows how attackers can steal Microsoft 365 sessions after MFA

Mirage2FA phishing infrastructure illustrates a critical limitation of MFA-led Microsoft 365 security: a victim can complete a legitimate authentication challenge while an attacker captures the authenticated session issued afterwards. The technique does not break Microsoft’s MFA cryptography; it relays the victim’s login to the genuine service in real time, then steals the browser session, cookies or token material created after sign-in.

The key distinction is between completing MFA and controlling the session that follows. The user has proved something to Microsoft; the criminal has captured what Microsoft issued afterwards.

Many organisations have treated MFA rollout as the finish line for identity security. It isn’t. MFA still stops a great deal of routine password theft, and turning it off or dismissing it would be a serious mistake. But adversary-in-the-middle phishing changes the incident from “someone may know a password” to “someone may already be using a valid session”.

The Mirage2FA evidence needs careful reading

The name Mirage2FA first appeared publicly in a Fortra research report published on 25 June 2026. Its researchers described an HTML-smuggling phishing artefact using obfuscated JavaScript to fetch a Microsoft-branded credential-collection stage. The recovered code included screens for password collection and several MFA methods. Fortra was appropriately cautious: it said some flows, including SMS verification, were present in the codebase but had not all been interactively validated.

A separate report published by Abnormal Intelligence on 11 August 2026 calls the service LinXcoded and says it confirmed that this tooling is the platform publicly reported as Mirage2FA. Abnormal reports real-time Microsoft 365 relaying over WebSockets, post-MFA session-cookie capture, compromised Microsoft 365 senders, HTML attachments without a message-body URL, and Telegram-based management infrastructure.

That is stronger than a screenshot of a fake login page, but it remains vendor threat intelligence rather than public law-enforcement attribution. The public material does not independently establish the operator’s real-world identity. It refers to LinXcoded, rather than providing substantiated attribution to a group called “LinX Coders”. The public reports have not provided independently verifiable totals for confirmed compromises, affected organisations, account takeovers, domain counts or geographic percentages. Precise figures from a campaign dashboard or secondary article should not be treated as settled fact.

There is enough evidence to take the attack model seriously. Both reports describe closely related HTML-loader behaviour, MFA-themed harvesting logic and a Microsoft 365 account-takeover objective. Mirage2FA is best understood as a reported phishing-kit family or commercial service associated with session-interception capability; its scale, customer base and attribution are less certain than marketing-friendly summaries suggest.

How the exposure happens

Traditional phishing steals a password and hopes it is enough. An adversary-in-the-middle, or AiTM, kit operates in real time. The victim opens a convincing lure, enters their address and password, and sees an MFA step resembling the legitimate Microsoft flow. The criminal’s infrastructure passes the interaction to Microsoft and relays the response back.

If the victim approves a push notification, supplies a time-based code or enters an SMS code, Microsoft can legitimately authenticate that transaction. The attacker’s proxy is then positioned to capture the resulting session artefact. Depending on the flow and application, that may mean browser cookies, access tokens or refresh-token material that enables access to Microsoft 365 services and connected single sign-on applications.

The attacker doesn’t need to defeat every layer of Microsoft’s identity platform. They need a convincing route through the legitimate one.

The reported delivery technique deserves attention too. HTML, XHTML and SVG files are not automatically malicious, and blocking all of them will disrupt legitimate business processes. But browser-capable formats can contain or initiate client-side logic. In the Mirage2FA reports, a small obfuscated HTML attachment reconstructed code locally and fetched a subsequent stage only after it was opened. That gives mail filters less obvious URL material to inspect before delivery, while the attachment may look like a secure document, remittance notice, benefits update or administrative request.

Attachment blocking is not a complete answer. Mail-security policies should distinguish document formats from browser-executable content, inspect attachment behaviour where possible, and give finance, HR and operational teams examples of the lures they are likely to receive.

A stolen session is a different incident from a stolen password

Once a criminal has a reusable session, an ordinary password reset may be too narrow a response. They may already be reading Exchange Online mail, accessing SharePoint or OneDrive, searching conversations, sending internal phishing, or using trusted supplier relationships to support payment fraud. A mailbox rule that hides replies or forwards messages externally can be more immediately damaging than the original password disclosure.

Persistence may extend beyond the browser. An intruder can attempt to register a new authentication method, enrol a device, add a Windows Hello credential, grant consent to an OAuth application, or create delegated access that survives an otherwise tidy-looking password reset. Microsoft’s guidance on illicit OAuth consent grants is clear that removing a malicious application or consent is a separate remediation task. Disabling an app prevents new token requests, but existing access tokens can remain usable until they expire.

“Reset the password” is one containment action, not an incident playbook.

What good Microsoft Entra protection looks like

The biggest improvement is moving higher-value users and actions towards phishing-resistant authentication: passkeys based on FIDO2, Windows Hello for Business, or certificate-based authentication where appropriate. FIDO credentials are bound to the legitimate relying party’s domain. A fake site cannot simply collect a reusable FIDO secret as it can a password and one-time code. Microsoft describes passkeys as phishing-resistant credentials that cannot be reused or replayed across services.

That does not eliminate the need to defend sessions after authentication. Malware on the endpoint, a compromised device or an attacker already inside an approved network present different problems. It does close the easy relay path used by a lookalike sign-in page. For privileged accounts, phishing-resistant authentication is no longer an aspirational maturity target; it is the sensible baseline.

Conditional Access should make a stolen session less portable and less useful. Microsoft recommends requiring fresh, phishing-resistant interactive authentication for sensitive operations through authentication contexts, and requiring it again for medium- or high-risk sign-ins. Device-compliance requirements, sign-in risk policies and carefully planned network-location controls provide useful extra signals. They are not magic policy switches. Broad exclusions, unmanaged browsers and legacy application requirements are where many otherwise sound designs lose their edge.

Microsoft Entra’s Continuous Access Evaluation (CAE) is particularly relevant. For supported services including Exchange Online, SharePoint Online and Teams, CAE can enforce events such as password reset, account disablement, explicit session revocation and high user risk in near real time. “Near” matters. Microsoft notes that event propagation can take up to around 15 minutes, while some workloads and scenarios have further limitations. Guest users are not covered by CAE’s instantaneous revocation model, not every client/resource combination supports every capability, and collaborative Office sessions can persist longer in certain circumstances.

CAE is valuable containment, not proof that a stolen token becomes harmless the moment an alert appears.

Token Protection is useful too, but its limits should be understood before it is sold internally as a universal cure. Microsoft Entra Token Protection cryptographically binds supported sign-in session tokens to a device, making a copied token unusable elsewhere. As of August 2026, support is strongest for native applications accessing Exchange Online, SharePoint Online and Teams; browser support remains limited and largely in preview for selected Azure Resource Manager web scenarios. Pilot it in report-only mode, test the real client estate, and retain compensating controls for browser-led Microsoft 365 access.

Detection needs to join email, browser and identity evidence

AiTM phishing can look deceptively normal when viewed from one product console. The email may come from a compromised Microsoft 365 tenant. The victim’s MFA event is genuine. The first successful session may look perfectly legitimate. The useful signal is the sequence: a suspicious attachment or lure, a successful interactive sign-in, then new session or resource access from an unfamiliar network, device or geography.

Microsoft recommends monitoring for its Anomalous Token, Attacker in the Middle and Unfamiliar sign-in properties risk detections, alongside Defender alerts such as possible AiTM phishing attempts and stolen session-cookie use where the relevant Defender products and integrations are deployed. Those labels are leads, not verdicts. A SOC needs the surrounding mail, endpoint, Entra sign-in and audit records, rather than closing an event because an MFA challenge was completed.

Smaller organisations without every premium Microsoft security component still have clear priorities: retain sign-in and audit logs long enough to investigate, restrict legacy authentication, reduce the number of unmanaged endpoints with broad Microsoft 365 access, and make explicit session revocation part of incident response.

The residual risk: trust the session less, not MFA less

Mirage2FA does not show that MFA has failed. It shows that passwords, push approvals and one-time codes are vulnerable when people can be persuaded to hand them through a hostile intermediary in real time.

The response is practical. Use phishing-resistant methods for privileged and high-impact access. Limit where sessions can be replayed from. Require managed, compliant devices where the work justifies it. Enable CAE and risk-based controls with a realistic understanding of their coverage. Rehearse revocation, mailbox review and OAuth-consent clean-up until they are quick operational actions rather than a document nobody has opened since last year.

Microsoft 365 security is no longer only about proving who started a sign-in. It is about protecting what gets issued once that sign-in succeeds.