Mirage2FA Hijacks Companies’ Microsoft 365 Sessions, with Over 4K Victims in the US

Mirage2FA is an active phishing-as-a-service toolkit built to steal Microsoft 365 credentials and authenticated sessions through Adversary-in-the-Middle (AiTM) attacks.

ANY.RUN research shows that 63.7% of identified victims are in the US, with Technologies, Manufacturing, and Education among the most targeted industries. The operation has generated thousands of compromise events between 2024 and 2026, including stolen session cookies, passwords, and SSO access.

Once an authenticated Microsoft 365 session is hijacked, attackers may gain access to corporate email, sensitive data, and trusted business accounts, creating a path for impersonation, fraud, and further compromise. Detecting the attack before stolen sessions are reused can help security teams contain account takeover earlier and reduce the potential business impact.

Key Takeaways

• Mirage2FA bypasses conventional MFA to hijack active Microsoft 365 sessions. The PhaaS toolkit uses an Adversary-in-the-Middle (AiTM) flow to capture credentials, 2FA codes, and authenticated session cookies.

• Mirage2FA activity was linked to 3,518 unique organization email domains, showing the campaign’s broad reach across US and EU corporate environments.*

• The kit shows a high potential compromise rate. Of 9,426 unique targeted email addresses, 4,532 were potentially compromised — about 48%.*

• The US is the main victim market. 2,885 victims, or 63.7% of the total, were located in the United States, while victim activity was recorded across 94 countries.

• Session theft is the most common compromise outcome. The dataset contains 9,332 potential compromise events, including 4,561 cookie-theft events, 3,044 password/2FA events, 1,339 SSO logins, and 388 other outcomes.*

• Mirage2FA relies on browser-based delivery rather than binary malware. .htm, .xhtml, and .svg stagers, QR codes, JavaScript obfuscation, and WebSocket-based AiTM activity allow the attack to run largely inside the browser.

• Mobile users make up a significant share of successful activity. 33.3% of successful login events came from mobile devices, where phishing pages can be harder to inspect due to limited URL visibility.

• Recurring technical patterns remain useful even as infrastructure changes. The /xls/*.js loader structure, and LINX* markers provide hunting opportunities beyond individual domains and IP addresses.

Note: All victim, compromise, and campaign-scale figures in this report are approximate estimates based on the available dataset and represent potential impact rather than independently confirmed compromises.

Mirage2FA Overview

Mirage2FA is a commercial phishing-as-a-service offering aimed at compromising corporate Microsoft 365 accounts and active sessions (session cookies) while bypassing two-factor authentication. The operator distributes malicious attachments that execute in the victim’s browser and silently fetch harvesting logic from a C2, proxying the login/2FA flow in real time (AiTM).

Business impact can include:

• Identity-driven access risk: Stolen sessions can give attackers trusted access to Microsoft 365 and connected cloud services.

• Fraud and impersonation exposure: Compromised accounts can be used to target employees, customers, suppliers, or finance teams.

• Higher containment costs: Session theft often requires more than a password reset, increasing response effort and investigation scope.

• Greater blast radius: One compromised identity can create follow-on access across email, SSO-connected apps, and internal workflows.

• Control gaps despite MFA: Successful AiTM attacks can expose weaknesses in authentication and session-management strategies.

Where Mirage2FA Hits Hardest: Targeted Industries, Regions, and Compromise Outcomes

Mirage2FA activity increased sharply throughout 2026, while victim data shows a clear concentration in the United States and in industries that depend heavily on Microsoft 365 for daily operations.

By the time data collection ended in July 2026, 445 Mirage2FA sandbox sessions had already been recorded for the month. Although the dataset does not cover the full month, the volume of observed activity confirms that Mirage2FA remained active during the reporting period.

Mirage2FA Activity Increased Sharply in 2026

ANY.RUN recorded a steady rise in Mirage2FA sandbox activity from March through July 2026:

Technology, MSSPs, and Manufacturing Face the Highest Exposure

Mirage2FA activity spans multiple industries, but ANY.RUN telemetry shows a higher concentration in several sectors:

Successful Microsoft 365 account takeover in these environments can expose more than one mailbox. Compromised identities may provide access to customer communications, internal documents, cloud applications, supplier relationships, or privileged workflows, increasing the potential impact of a single successful phishing attempt.

63.7% of Identified Victims Are in the United States

Mirage2FA shows a strong concentration in the United States, which accounts for 2,885 victims, or 63.7% of the total. Victim activity was also observed in India, Singapore, the United Kingdom, Canada, Saudi Arabia, South Africa, and other countries.

This distinction matters: sandbox submissions reflect where analysts encounter and investigate samples, not necessarily where the attackers are finding victims. The compromise data shows that Mirage2FA is particularly focused on US organizations, with Singapore also showing disproportionately high victim activity compared with its share of submissions.

Session Theft Is the Most Common Compromise Outcome

The open-source dataset records 9332 successful compromise events across several outcomes:

Session-cookie theft was the most common result, accounting for more than half of all recorded compromise events.

How Mirage2FA Attacks Organizations: The Full Attack Flow

To see how Mirage2FA moves from a phishing message to Microsoft 365 account takeover, you can check its behavior in an ANY.RUN sandbox session. The attack takes place almost entirely in the browser, using malicious attachments, remote JavaScript, and an AiTM proxy to intercept authentication in real time.

Here is how the compromise unfolds:

View analysis session with Mirage2FA

1. Delivery: A phishing email delivers a malicious .htm, .xhtml, or .svg attachment, or directs the victim to a QR-code link. Mirage2FA campaigns have also been distributed at scale through Amazon SES. (MITRE T1566.001 / T1566.002)

2. Execution: The victim opens the attachment, causing the browser to execute the embedded stager. (T1204.002)

3. Client-side staging: Obfuscated HTML smuggling or an SVG inline script decodes and executes in the browser. The stager reads a per-recipient token: the victim’s email, Base64-encoded as LINXB64EMAIL. (T1027 / T1027.006)

4. Loader retrieval: The stager retrieves the harvesting logic from a remote loader using the /xls/.js pattern. (T1105)

5. AiTM presentation: The victim is shown a fake Microsoft 365 login page backed by an Adversary-in-the-Middle reverse proxy.

6. Credential and 2FA capture: The victim enters their username, password, and one-time 2FA code into the phishing page.

7. Real-time relay: Mirage2FA relays the authentication data to the legitimate Microsoft 365 service over a WebSocket channel. Once authentication succeeds, the proxy receives a valid authenticated session, effectively bypassing MFA. (T1557 / T1111)

8. Session theft: The authenticated session cookies, together with captured credentials, are exfiltrated to the operator panel. Mirage2FA stores the stolen cookies as Base64-encoded .txt dumps. (T1539)

9. Account takeover: The attacker can reuse the stolen session to access the victim’s Microsoft 365 account, read email, and impersonate the user without having to enter the password or complete MFA again. (T1539 / T1071.001)

What Mirage2FA Attachments Look Like

Mirage2FA relies on browser-executed XHTML, .htm, and SVG attachments. Each acts as a stager, carrying a recipient-specific token such as LINXB64EMAIL, LINXEMAIL, or LINXCODERSEMAIL and retrieving the harvesting logic from the remote /xls/.js loader.

Across the samples analyzed, .htm was the dominant format:

• 629 .htm samples: 176 plain, 453 obfuscated

• 198 XHTML samples: 167 plain, 31 obfuscated

• 187 SVG samples: 175 plain, 12 obfuscated

Notably, the campaign uses .htm rather than .html, and researchers observed no binary malware in this dataset.

The attack is carried out through browser-readable files and JavaScript, making inspection of suspicious web attachments and their runtime behavior especially important.

How Mirage2FA Stagers Hide Their Activity

Although the attachments serve the same purpose, Mirage2FA uses several techniques to hide the redirect and loader logic from users and security controls.

XHTML: Non-Obfuscated (Dynamic Iframe + Remote Loader)

The page builds a full-screen iframe, writes a document into it, and injects an external script (a1p2i.js). The token is read from the ?ref= query parameter, defaulting to the placeholder LINXB64EMAIL.

XHTML: Obfuscated (Hex-String Decoder)

The obfuscated XHTML variant hides its logic behind a hex-to-string decoder (rsy) and reads the token from ?sdv= or the URL fragment, defaulting to LINXEMAIL.

HTML (.htm): Non-Obfuscated (Remote-Loader Stub)

The plainest HTML stager is a two-line loader: it sets the recipient token (uid) and pulls the remote harvesting script. This is the same /api/xls/a1p2i.js loader used by the XHTML variant, on a different domain.

HTML (.htm): Obfuscated (XOR + Base64 + eval)

The obfuscated HTML variant is self-contained: Base64-decodes a blob, XORs each byte with the key 0xAD (173), then evals the resulting source. The token placeholder is exposed as RSTRING2.

SVG: Non-Obfuscated (Inline-Script Redirect)

The SVG payload abuses the <script> element permitted in standalone SVG documents. On open, it navigates the browser directly to the phishing URL, passing the recipient token via a query parameter (LINXB64EMAIL).

SVG: Obfuscated (obfuscator.io _0x Wrapper)

A minority of SVGs (12 unique) wrap the same redirect in an shell and an obfuscator.io-style string-array decoder to conceal the destination.

Behavior Observed in the Sandbox

Across 1,249 Mirage2FA sandbox sessions, dominant behaviors included phishing, obfuscated JavaScript, and WebSocket activity linked to the toolkit’s real-time AiTM channel. Researchers also observed IP and browser fingerprinting, QR-code delivery, and Amazon SES activity.

Network Infrastructure

In total, we identified the entire cluster using a single Threat Intelligence Lookup query. This dataset is clearly visible in the new Connections block: all links, domains, and IP addresses, along with their reputations, are now in one place.

TI Lookup query: url:”/???/xls/?????*.js$”

The dataset is substantial. Therefore, the decision was made to proceed as follows: for each link X, take the malicious script M, deobfuscate it, and extract all the malicious links. To illustrate, we present the results of our work using a section of the interconnection graph.

Each script contained its own link to a PHP endpoint for data exfiltration and CAPTCHA solving. However, this endpoint had another feature: an open WebDAV/Opendir server. This feature allowed us to enrich the cluster data, significantly expanding our statistics.

Nevertheless, let us first describe what our sandbox has managed to discover over time.

C2 / loader (ANY.RUN):

• IP 185.174.100.224: ASN as-colocrossing.

• Domains: user.cheacker.store (TL2), hvr.volatilesour.store (TL2), ver.bandhiem.com (TL0), pynutech.store and others.

• Loader pattern: https:///<3-letter-code>/xls/.js — routing codes (api, ulr, eor, pxk, dsk, ncb, tsk, clr, vtk, bmr, …) match the paths seen in the SVG redirects; token suffixes: c2v, cpt, or none. Canonical endpoint: /api/xls/a1p2i.js.

Network signatures:

• GET /*/xls/*.js requests to *.cheacker.store / *.volatilesour.store (path regex: /[a-z]{3}/xls/[a-z0-9]+(?:c2v|cpt)?\.js. OR /???/xls/?????*.js$).

• DNS query of the form .cheacker.store, where the label decodes to an email address.

• Outbound WebSocket to the C2 after the loader executes (AiTM proxy).

Cluster Expansion

Operator infrastructure: IP activity

Drawing on data from open sources and information gathered during the study of the cluster, we began analyzing the developer’s characteristic patterns and the list of potential victims.

While analyzing the messages sent by the Mirage2FA, we observed a consistent pattern: the substring “LINX” (LinxCode, Linx…) is used pervasively by the author and sometimes appears as a placeholder in request parameters. We hypothesize that the author used this method to test their own infrastructure. Below is a list of the IP addresses from which the author conducted these tests.