Executive Summary: Mirage2FA Microsoft 365 Phishing Kit and MFA Bypass Risk
Fortra Intelligence and Research Experts (FIRE) have identified a multi-stage Microsoft 365 phishing kit, which we have named Mirage2FA, delivered through a secure document and payment-themed email lure. The attack uses short-lived HTML smuggling and obfuscated JavaScript-loaders in a single phishing workflow, creating a “mirage” effect that helps it evade detection while targeting 2FA/MFA protections. It is an example of phishing campaigns increasingly using multiple tactics to harvest credentials and bypass or intercept 2FA/MFA workflows. The impact of such an attack on businesses could result in account takeover, fraudulent payment redirection, data theft, internal phishing, unauthorized access to sensitive documents, and more.
In the attack, the initial HTML payload uses obfuscated JavaScript to hide its behavior from static inspection, then decoded and executed concealed code using Base64, XOR with 0xAD, TextDecoder, and eval(). That code loaded a second-stage script from attacker-controlled infrastructure at user[.]cheacker[.]store.
The second-stage content presents a Microsoft-branded phishing interface with fake CAPTCHA verification, credential collection, and multiple MFA-themed collection screens. The flow includes prompts for email and password, and the codebase contained screens for authenticator app codes, SMS codes, and number-matching approval. The SMS verification capability has observed in the codebase only; FIRE has not interactively validated that SMS flow during analysis. These elements indicate the likely objective was Microsoft 365 account takeover through credential theft and possible MFA interception.
The domain cheacker[.]store was registered recently, on March 16, which supports the assessment that the infrastructure was created for short-term use. Users and defenders should also be aware that this scam was observed running locally in the browser after the HTML payload decoded and executed its embedded JavaScript. This means the initial phishing behavior did not depend on a traditional public webpage being indexed or easily discoverable.
Introduction: How the Mirage2FA Phishing Campaign Targets Microsoft 365 Users
This report was produced after review of a suspicious email-delivered HTML/JavaScript artifact, supporting DNS results, and second-stage phishing page content. The email sender and lure language referenced secure documents, remittance servicing, automated billing, and payment workflows. That theme aligned with the staged page, which used Microsoft branding and document-style loading visuals to make the victim believe they were accessing a protected business document.
The analysis was produced because the recovered second-stage content confirmed that the activity was not merely an obfuscated redirect. It was a functional Microsoft 365 phishing kit with credential harvesting behavior and MFA-themed code paths. The recent March 16 registration of cheacker[.]store also suggests the infrastructure was likely intended for a short-lived campaign rather than a legitimate long-standing service.
Threat Landscape: HTML Smuggling, MFA Phishing, and Microsoft 365 Account Takeover
Short-lived HTML smuggling and JavaScript-based phishing campaigns targeting organizations continue to increase. These attacks often use email attachments or linked HTML pages to reconstruct malicious content in the browser rather than exposing the final phishing logic directly in the email. This approach helps attackers evade static scanning, delay detection, and change the second-stage payload without resending the original lure.
MFA has resulted in phishing operators adapting new tactics. Instead of only stealing usernames and passwords, modern kits increasingly include fake verification gates, real-time prompts, and screens that collect or request authenticator codes, SMS codes, or approval interactions. Mirage2FA fits this pattern by combining an obfuscated HTML loader, disposable infrastructure, fake CAPTCHA gating, Microsoft impersonation, and multiple MFA-themed screens. In this case, some MFA behaviors were directly visible in the page logic, while the SMS verification flow was identified from the codebase but not interactively confirmed.
A key user-awareness point is that this scam was observed running locally after the HTML payload executed in the browser. In practice, a victim may not need to visit a well-known or searchable phishing website first; the malicious experience can be assembled locally from encoded script content and remote second-stage resources.
Threat Details: Obfuscated JavaScript Loader and Microsoft-Branded Phishing Pages
The initial payload used a string-array obfuscator, runtime array shifting, Base64-encoded content, XOR decoding, TextDecoder, and eval() to reconstruct hidden JavaScript at runtime. The concealed code loaded a second-stage script from https://user.cheacker[.]store/ulr/xls/u1l2r.js, with another related path observed at https://user.cheacker[.]store/eor/xls/e1o2r.js. It’s important to note that the victim email was sent as a payload to the destination path, after being decoded. This prevented analysts from being able to change the victim email once the second stage was loaded.
The second-stage page contained a Microsoft-styled sign-in experience. It loaded legitimate Microsoft visual assets to increase credibility, including Microsoft authentication icons and familiar footer links. These Microsoft-hosted assets were abused for visual realism and should not be treated as malicious infrastructure by themselves.
The page included a pre-entered email, password input, fake organization sign-in transition, CAPTCHA verification layer, authenticator app code prompt, and number-matching approval screen. The codebase also contained an SMS code prompt using identifiers such as text-2fa-code and verify-text-2fa; however, this SMS verification behavior was observed only in the code and was not interactively validated during analysis. Other visible form identifiers included ai, pr, submit-btn, 2fa-code, verify-2fa, and approve-number, all of which support the assessment that the kit was designed to collect credentials and potentially MFA material.
The infrastructure appeared lightweight and disposable. DNS records showed cheacker[.]store using dns1.registrar-servers.com and dns2.registrar-servers.com, with user.cheacker[.]store resolving to 185.174.100.224. Reverse DNS for the IP returned 185.174.100[.]224.deltahost-ptr. The domain also had registrar-style mail forwarding records. The recent March 16 registration date further supports the assessment that the domain was likely created for short-term phishing use. Additional phishing assets were loaded from miniapp.bereetro[.]it.com, including CSS and CAPTCHA imagery.
Business Impact: Microsoft 365 Credential Theft, MFA Interception, and Account Compromise
The likely goal is Microsoft 365 account takeover. If a user submitted credentials, the attacker may have been able to access email, files, Teams messages, SharePoint content, and other connected SaaS resources. If a user submitted MFA information or followed approval prompts, the attacker may have been able to complete an active login attempt in real time. The observed codebase suggests support for several MFA-themed flows, but not every flow was interactively verified during analysis.
The local execution aspect increases user risk because the phishing experience may begin from an HTML file or embedded script running in the browser, rather than from a normal-looking website that users can easily evaluate by reputation, search results, or public history. This can make the lure feel like a document-opening workflow while still allowing the attacker to retrieve remote scripts, images, and styling.
Potential impacts to a targeted organizations include mailbox compromise, business email compromise, fraudulent payment redirection, data theft, internal phishing, unauthorized access to sensitive documents, and persistence through mailbox rules, OAuth grants, or stolen sessions. The current evidence supports urgent hunting and containment, but additional telemetry is needed to confirm scale, attribution, and whether any accounts were successfully compromised.
How to Detect and Block Mirage2FA Phishing Activity
Organizations should block and hunt for cheacker[.]store, user.cheacker[.]store, 185.174.100[.]224, miniapp.bereetro[.]it.com, /eor/xls/e1o2r[.]js, and /ulr/xls/u1l2r[.]js. Security teams should review DNS, proxy, email, EDR, and identity-provider logs for user interaction with these indicators.
Any user who opened the phishing page or submitted information should have their password reset, active sessions and refresh tokens revoked, MFA methods reviewed, mailbox rules inspected, and OAuth grants checked. Sign-in logs should be reviewed for unfamiliar IPs, impossible travel, new device activity, failed and successful MFA attempts, and suspicious authentication method changes.
Detection should prioritize HTML attachments and web pages that combine atob(), TextDecoder, eval(), and byte-wise XOR operations. Additional detections should look for dynamic script creation, requests to suspicious /*/xls/*.js paths, Microsoft-branded login pages hosted outside Microsoft domains, fake CAPTCHA screens preceding credential entry, and forms or scripts referencing authenticator codes, SMS codes, or number-matching approvals.
User-awareness guidance should emphasize that phishing pages may be assembled locally from an opened HTML file or script, not only from a visible external website. Users should be cautious with secure-document, payment, billing, and remittance messages that prompt them to open HTML content or complete Microsoft sign-in and MFA steps outside a known trusted workflow.
Longer-term controls should include phishing-resistant MFA (like a cryptographically bonded hardware key), conditional access policies, session risk controls, attachment sandboxing, HTML-smuggling detection, user training for secure document lures, and monitoring for suspicious mailbox and OAuth activity after any credential exposure.
Defending Against Microsoft 365 Phishing Kits Like Mirage2FA
Mirage2FA showcases how attackers are increasingly combining tactics such as short-lived HTML smuggling, obfuscated JavaScript loaders, newly registered disposable domains, and more into a single phishing workflow.
In order to protect against attacks such as Mirage2FA, it is critical that security teams validate the exfiltration endpoint inside the second-stage JavaScript, determine whether additional domains or campaign variants exist, identify any affected users, and publish detections that cover both the confirmed indicators and the broader behavior. Claims about SMS verification should remain limited to code-observed capability unless future analysis confirms that the flow was active during victim interaction. However, FIRE did find reference to the use of SMS verification after logging into the spoofed MFA page so caution is advised.
