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/<token>.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/<token>.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 <html><body><svg> 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://<host>/<3-letter-code>/xls/<token>.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 <base64>.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.

How Mirage2FA Has Evolved

Mirage2FA has changed significantly since it was first observed in 2024, while retaining several recognizable patterns.

• Build markers: LINXCODERSEMAIL → LINXEMAIL → LINXB64EMAIL, followed by markers such as #LINXMASKEMAIL, #LINXRANDSTRING, and linxz.

• JavaScript obfuscation: plain loaders evolved into XOR + Base64 + eval, hex-based decoders, and obfuscator.io-style _0x wrappers. Obfuscation was most common in .htm samples, appearing in 453 of 629.

• Delivery methods: the operation expanded beyond .htm, .xhtml, and .svg attachments to include QR-code lures and Amazon SES distribution. HR and 401(k) benefits appeared repeatedly as lure themes.

• C2 structure: Mirage2FA introduced more /\<code\>/xls/*.js routes and token variations while rotating domains over time.

Attribution

The cluster we expanded is highly likely to be the Mirage2FA phishkit, given the observed similarities in indicators and URL patterns with another research. To this attribution, we add our own patterns (see the IOCs section for details) and the specific characteristics of the utility’s author.

• Brand/operator: LinX Coders. Corroborated by the placeholder LINXCODERSEMAIL (the substitution variable name), the bot names linxlogsss…bot / linxxlogss…bot, and the channel LinXcoded. Moreover, there is a bot to your subscription account and it’s still active (see below)

• Operator cross-bot test IPs (dry-run kit submissions where the email equals a placeholder):

• 185[.]174[.]100[.]20: 13 tests across 3 distinct bots, 2024-10 to 2025-09;

• 185[.]174.[.]00[.]76: 4 tests across 4 bots, 2025-02 to 03;

• 139[.]28[.]36[.]38: 4 tests across 3 bots (2025-02).

• Link to C2: The C2 185[.]174[.]100[.]224 is in the same subnet 185[.]174[.]100[.]0/24 and provider AS-Colocrossing. A single range serving both bot deployment/testing and the production loader points to centralized author/seller infrastructure.

• Continuity: bot 7010301660 links the 2024–2025 tests to the 2026 lure activity.

Caveat. IP/geo in the open-source collection come from the panel’s own self-logging (VPN/spoofing possible); the most reliable signal is IP reuse across multiple bots together with the subnet match against an independent source (ANY.RUN).

How Organizations Can Reduce the Risk from Mirage2FA

By stealing active Microsoft 365 sessions, Mirage2FA can give attackers access even after MFA has been completed. Defending against it means covering the whole path from the phishing email to session theft and account takeover.

Strengthen Email and Browser Controls

Block or quarantine .htm, .xhtml, and .svg attachments where possible, and add detection for HTML smuggling, attc-html, and obfuscated-js characteristics.

Security teams should also pay closer attention to suspicious QR-code campaigns and email delivered through services such as Amazon SES, especially when they contain browser-executed attachments.

Unknown files should be opened only in an isolated environment. ANY.RUN’s Interactive Sandbox can show what the attachment actually does, including JavaScript execution, redirects, fingerprinting, loader activity, WebSocket connections, and fake Microsoft 365 login pages.

Move Beyond Traditional MFA

Mirage2FA can intercept passwords and one-time 2FA codes in real time, which means conventional MFA alone may not be enough.

Organizations should move high-risk users toward phishing-resistant MFA such as FIDO2/WebAuthn and passkeys, particularly administrators, executives, finance teams, and other accounts with access to sensitive systems or business processes.

Shorter session lifetimes, token binding, and Continuous Access Evaluation in Microsoft Entra ID can also reduce the window in which a stolen authenticated session remains useful.

Detect Mirage2FA Behavior, Not Just Known IOCs

Domains and IP addresses can change quickly, so detection should not depend on static indicators alone.

SOC teams should alert on requests matching patterns such as /<3char>/xls/*.js, DNS queries where a Base64-encoded email address appears as a subdomain label, and outbound WebSocket connections to unknown hosts shortly after a JavaScript loader is fetched.

Fresh Threat Intelligence Feeds, built from real-world threat data contributed by 16,000 organizations and 700,000 security professionals, can push known malicious infrastructure into SIEM, EDR, firewalls, and other existing security controls. Behavioral detections can then provide coverage as Mirage2FA rotates domains, paths, and infrastructure.

Expand the Investigation with Threat Intelligence

One malicious attachment may be part of a much larger campaign.

Analysts can use ANY.RUN Threat Intelligence Lookup to pivot from a suspicious URL, domain, IP, or loader pattern to related infrastructure, previous sandbox sessions, and other connected activity.

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

This approach played an important role in the Mirage2FA investigation itself. Researchers followed the characteristic /xls/*.js loader pattern and used it to uncover a broader cluster instead of treating each phishing sample as a separate incident.

Hunt for Mirage2FA Across the Environment

Threat hunting should focus on recurring Mirage2FA patterns across mail gateways, proxy logs, EDR telemetry, and browser activity.

Useful hunting points include LINX* placeholder strings, /xls/*.js loader paths, suspicious HTML attachments, Base64-encoded recipient data, and WebSocket traffic following browser-executed JavaScript.

Findings from these hunts can then be checked against current threat intelligence and expanded further through TI Lookup.

Treat Session Theft as an Identity Incident

If Mirage2FA successfully steals a session cookie, resetting the user’s password may not be enough.

Response teams should revoke all active sessions and tokens, review Microsoft 365 mail-forwarding rules, check OAuth grants, and investigate activity performed through the compromised identity.

The goal is to remove the attacker’s access completely; not just change the credential they may no longer need.

Conclusion

Mirage2FA shows how far phishing has moved beyond simple credential theft. By intercepting Microsoft 365 authentication in real time and stealing active session cookies, the toolkit can bypass conventional MFA and give attackers access to trusted corporate accounts.

The campaign has remained active from 2024 through 2026, with the strongest victim concentration in the United States and significant exposure across Technology, MSSPs, Manufacturing, and Education. For businesses, a single successful attack can lead to email compromise, impersonation, data exposure, and further access through a legitimate user identity.

Reducing that risk requires more than blocking known domains. Organizations need phishing-resistant MFA, behavioral detection, safe analysis of suspicious attachments, current threat intelligence, and response procedures built specifically for session theft. The faster teams can connect a suspicious email to the wider campaign and revoke stolen access, the less room attackers have to turn one compromised account into a larger incident.

About ANY.RUN

ANY.RUN is a leading provider of interactive malware analysis and threat intelligence solutions trusted by more than 15,000 organizations worldwide, including 74 of the Fortune 100. 


Its Interactive Sandbox and Threat Intelligence solutions help SOC teams analyze suspicious 
files and URLs, uncover malicious behavior, enrich alerts with actionable context, and connect related activity across files, infrastructure, and campaigns. This enables faster investigations, more confident response decisions, and earlier containment of threats before they create wider business impact.

IOCs

Detection patterns

• Loader request path: GET /[a-z]{3}/xls/[a-z0-9]+(?:c2v|cpt)?\.js to a kit domain (canonical /api/xls/a1p2i.js).

• Outbound WebSocket to the C2 immediately after the JS loader is fetched (AiTM relay).

• HTML attachment containing atob(…).map(x => x.charCodeAt(0) ^ 173) followed by eval(…) (XOR key 0xAD).

• SVG document with an inline <script type=”application/ecmascript”> performing a window.location redirect.

Operator / build markers

• Placeholder tokens: LINXB64EMAIL, LINXEMAIL, LINXCODERSEMAIL, LINXCODERSRANDSTRING, #LINXMASKEMAIL, #LINXRANDSTRING.

• In-page variables exposing the token: uid, self.u, RSTRING2.

• Test / self markers: password value linxz; XOR key 0xAD; canonical loader filename a1p2i.js.

Phishing domains

FAQ