Evolution of Tycoon 2FA Defense Evasion Mechanisms: Analysis and Timeline
Attackers keep improving ways to avoid being caught, making it harder to detect and investigate their attacks. The Tycoon 2FA phishing kit is a clear example, as its creators regularly add new tricks to bypass detection systems.
In this study, we’ll take a closer look at how Tycoon 2FA’s anti-detection methods have changed over the past several months and suggest ways to spot them effectively.
This article will discuss:
- A review of old and new anti-detection techniques.
- How the new tricks compared to the old ones.
- Tips for spotting these early.
Knowing how attackers dodge detection and keeping user detection rules up to date are key to fighting these anti-detection methods.
What is Tycoon 2FA
Tycoon 2FA is a modern Phishing-as-a-Service (PhaaS) platform designed to bypass two-factor authentication (2FA) for Microsoft 365 and Gmail. It was first identified by Sekoia analysts in October 2023, though the Saad Tycoon group, which promotes this tool through private Telegram channels, has been active since August 2023.
Tycoon 2FA uses an Adversary-in-the-Middle (AiTM) approach, where attackers set up a phishing page through a reverse proxy server. After a user enters their credentials and completes the 2FA process, the server captures session cookies, allowing attackers to reuse the session and bypass security measures.
Currently, Tycoon 2FA is highly popular and widely used by cybercriminals, including the Saad Tycoon group. The platform offers ready-made phishing pages and an easy-to-use admin panel, making it accessible even to less technically skilled attackers.
Discover the latest examples of Tycoon 2FA attacks using this search query in ANY.RUN’s Threat Intelligence Lookup:
In 2024, an updated version of Tycoon 2FA was released, featuring enhanced evasion techniques, including dynamic code generation, obfuscation, and traffic filtering to block bots. Phishing emails are now frequently sent from legitimate, potentially compromised email addresses.
The evolution of this phishing kit continues, with ANY.RUN researchers noting regular updates and new evasion mechanisms in its malicious software. This article aims to investigate and provide technical details on how Tycoon 2FA has evolved, is evolving, and may continue to evolve.
Before We Begin
Tune in to ANY.RUN’s live webinar on Wednesday, May 14 | 3:00 PM GMT. We welcome heads of SOC teams, managers, and security specialists of different tiers who want to:
- Solve common security issues
- Optimize their work processes
- Find out how to save company’s resources
Analysis of a Tycoon2FA Attack from 01.10.2024
Let’s begin the analysis with a typical Tycoon2FA attack observed October of 2024. The attack begins with a malicious URL and employs multiple evasion techniques to avoid detection. Below, we well break down each stage of the attack, highlighting its protective mechanisms and their purposes.
Stage 1: Initial Attack Mechanisms
The attack starts with a request to the following URL:
hxxps://stellarnetwork[.]sucileton[.]com/EQn1RAKa/
Evasion Mechanism #1: Basic Code Obfuscation
The page’s source code is obfuscated, making it difficult for automated systems or analysts to interpret its functionality.

This is a foundational defense to hinder initial analysis.
Evasion Mechanism #2: “Nomatch” Check
The code compares the URL (part of the attacker’s infrastructure) against a “nomatch” value. This check appears to be a decoy or placeholder, as the comparison always returns False. It may serve as a flag for services like Cloudflare.

Evasion Mechanism #3: Domain Comparison
The code verifies whether the current page’s domain matches the attacker’s designated infrastructure domain. If the domains match, the attack proceeds to load Stage 2 (the malicious payload) into the Document Object Model (DOM). If not, a fake error page is displayed.

Evasion Mechanism #4: Redirect to Fake Litespeed 404 Page on Failed Checks
If the domain check fails, the user is redirected to a fake “Litespeed 404” error page.

The page is designed to appear legitimate and deter further investigation.

Purpose of Stage 1 Evasion Mechanisms

These mechanisms are designed to prevent the malicious code from executing or revealing its behavior in isolated scenarios, such as:
- Malware analysis sandboxes.
- Offline inspection of saved HTML files.
By ensuring the code only runs in the attacker’s controlled environment, these checks reduce the likelihood of detection.
If all Stage 1 checks are passed, the malicious payload (Stage 2) is injected into the page’s DOM, advancing the attack to its next phase.
Stage 2: Main Evasion Mechanisms
Evasion Mechanism #5: Cloudflare Turnstile CAPTCHA
Before loading the main content, Tycoon 2FA requires users to pass a Cloudflare Turnstile CAPTCHA. This protects the malicious page from web crawlers, Safebrowsing services, or automated systems that could capture and analyze the page’s content.

Evasion Mechanism #6: Debugger Timing Check
During Stage 2, the code also measures the time taken to launch a debugger, a technique used to detect whether the page is running in a real browser or a sandboxed environment. In this sample, the check is rudimentary, and the timing result is not actively used, suggesting it may be a placeholder or incomplete feature.

Evasion Mechanism #7: C2 Server Queries
Tycoon 2FA sends a series of requests to the attacker’s Command-and-Control (C2) servers to determine whether to proceed to Stage 3. This process involves two steps:
- GET Request to Secondary C2 Domain:
A GET request is sent to another C2 domain, expecting a single-byte response: ‘0’ or ‘1’.- If ‘1’ is received, the attack halts, and the user is redirected to a legitimate page.
- If ‘0’ is received, the attack continues.

If all Stage 2 checks are successfully passed, the page reloads, and the Stage 3 payload, the core malicious component, is retrieved and executed.
Stage 3: Payload Unpacking
Evasion Mechanism #8: Base64 + XOR Obfuscation
The payload in Stage 3 is obfuscated using a combination of Base64 encoding and XOR encryption with a predefined key. This protects the malicious code from being easily analyzed or detected.

After deobfuscation (use this CyberChef recipe), the next stage is revealed, advancing the attack.
Stage 4: Dynamic Payload Retrieval
During the payload retrieval, a POST request is sent to the attacker’s C2 server. The request body contains data derived from the initial phishing URL, with logic that varies based on whether the victim’s email is included in the URL.

Evasion Mechanism #9: Encrypted Payload Delivery
The C2 server responds with a JSON file containing ciphertext and decryption parameters. The specific data received depends on the contents of the POST request. The payload is decrypted to reveal the URL for the next stage.

To see the sample of the retrieved payload and its decryption, visit JSFiddle. The result of this action is the URL for Stage 5.
Stage 5: Fake Login Page Delivery
The content in Stage 5 is mostly unobfuscated, presenting a fake Microsoft Outlook login page designed to deceive the victim. It includes SVG assets and a stylesheet to mimic the legitimate interface.

At the end of the page’s source code, an additional JavaScript script reuses the Base64 + XOR obfuscation technique (previously seen in Stage 3) to hide further malicious code.

Deobfuscating this script reveals the next stage of the attack.
Stage 6: Fake Authorization and Data Exfiltration
The frontend mimics a Microsoft Outlook login page, designed to trick victims into entering their credentials.

At the end of the source code, a JavaScript script implements several new protective and operational mechanisms:
Evasion Mechanism #10: Browser Detection
The script identifies the victim’s browser to tailor the attack or detect analysis environments (e.g., sandboxes).

Evasion Mechanism #11: Clipboard Manipulation
The script replaces the clipboard contents with junk data to interfere with analysis or debugging attempts.

Evasion Mechanism #9 (Reused): Payload Encryption/Decryption
The script encrypts and decrypts the payload using hardcoded keys and initialization vectors (IVs), protecting data sent to and received from the C2 server.

Evasion Mechanism #12: C2 Routing with Dynamic URLs
A randomly generated URL for data exfiltration is created using the RandExp library, following a pattern determined by the Tycoon 2FA operation mode (e.g., checkmail, checkpass, twofaselected). This ensures varied C2 communication paths, complicating detection.

Evasion Mechanism #13: Redirect API Validation
The script checks the validity of a redirect API, likely used by Tycoon 2FA operators to monitor client status or subscription activity.

Finally, the stolen data (e.g., credentials) is exfiltrated to a third C2 domain in the attack chain. The response from the C2 server dictates the phishing page’s behavior, such as prompting for 2FA or updating the account status.

A JSFiddle snippet demonstrates the encryption/decryption of sent/received data.
At the end of Stage 6, there is a link to another script, which loads the next stage of the attack.

Stage 7: Phishing Framework Enhancements
After deobfuscation, Stage 7 reveals additional functionality for the Phishing-as-a-Service (PhaaS) framework, defining critical operations for the phishing interface.
The code includes logic for:
- Managing the user interface behavior.
- Handling transitions between frames.
- Rendering core page elements.
- Implementing a state machine for the phishing page.
- Validating user inputs (e.g., email, password, OTP).

Execution Chain Summary
The complete execution chain, combining all mechanisms from Stages 1–7, is visualized below:

With a comprehensive understanding of Tycoon 2FA’s attack flow, we can now analyze newer samples and compare them to this baseline to identify changes or additions to its anti-detection mechanisms.
New Tycoon2FA Evasion Mechanisms: Timeline
As we’ve discussed, Tycoon 2FA is steadily evolving, with its developers rolling out more sophisticated anti-detection mechanisms.
Let’s now examine the latest evasion methods that have emerged in attacks since October.
Attack Detected on 6 December 2024
This sample introduces new anti-detection mechanisms in Stage 2, enhancing the malicious payload’s ability to avoid analysis and debugging environments. The following mechanisms were observed:
Evasion Mechanism #14: Debug Environment Detection
The script checks if the page is loaded in a legitimate browser rather than a debugging environment, such as Selenium (WebDriver), PhantomJS, or Burp Suite. If a debugging runtime is detected, the attack stops, and the user is redirected to about:blank.

Evasion Mechanism #15: Keystroke Interception
The code intercepts keyboard shortcuts associated with opening browser developer tools or other debugging functions, preventing their default actions. This hinders manual analysis by users or researchers.

The intercepted shortcuts include:
- F12: Opens DevTools (Firefox).
- Ctrl + U: Displays page source code.
- Ctrl + Shift + I: Opens DevTools (Generic).
- Ctrl + Shift + C: Opens DevTools (Chrome).
- Ctrl + Shift + J: Opens browser console (Firefox).
- Ctrl + Shift + K: Duplicates current tab (Edge).
- Ctrl + H: Opens browser history (Generic).
- Meta + Alt + I: Opens insert menu (varies by browser).
- Meta + Alt + C: Copies selected text.
- Meta + U: Shows page source or accessibility menu.
Evasion Mechanism #16: Context Menu Blocking
The script disables the right-click context menu, preventing access to browser tools or page source inspection.

Improved Evasion Mechanism #6: Debugger Timing Check
Building on the rudimentary version in earlier samples, this implementation fully measures the time taken to launch a debugger. If the timing is abnormally long (suggesting a sandbox environment), the script redirects to a legitimate page, halting execution.

Attack Detected on 17 December 2024
In another attack from December, the threat introduced a new capability to enhance the phishing page’s authenticity, making it more convincing to victims.
Evasion Mechanism #17: Dynamic Multimedia via Legitimate CDN
Specifically, the phishing page dynamically loads a logo and custom background tailored to the domain of the victim’s email address, increasing its visual credibility.

The multimedia content is delivered through Microsoft’s legitimate AADCDN network, leveraging trusted infrastructure to evade detection and reduce suspicion.

Attack Detected on 3 April 2025
This sample introduces multiple new evasion mechanisms across various stages, reflecting Tycoon 2FA’s continued evolution in obfuscation, redirection, and anti-analysis techniques.
Stage 1: Enhanced Obfuscation
Evasion Mechanism #18: Complex JavaScript Code
The payload uses Base64 obfuscation for JavaScript keywords, and method calls (e.g., document.write()) are invoked via object property access, complicating static analysis.
The next stage’s content involves URL-encoding/decoding, further obscuring the code.

Stage 2: New Evasion Techniques
When Stage 2 code is deobfuscated, we can observe new evasion methods.
Evasion Mechanism #19: Invisible Obfuscation
The code employs whitespace-based “invisible” obfuscation, using proxy object calls and getter methods to retrieve and execute code via eval(). This technique makes the code harder to read and analyze.


The form sent during the transition from Stage 2 to Stage 3 is now created as a FormData object, replacing the previous HTML <form> element approach, reducing detectability.


Evasion Mechanism #20: Custom Fake Page Redirect
Unlike earlier samples that redirected to legitimate sites (e.g., eBay) upon failing checks, this revision redirects to a custom fake HTML page, enhancing deception and avoiding reliance on external domains.

Evasion Mechanism #21: Custom CAPTCHA
A custom CAPTCHA replaces the previously used Cloudflare Turnstile, likely to complicate signature-based and behavioral analysis and mitigate potential issues with Cloudflare’s security services.


Stage 5: Clipboard Protection
Evasion Mechanism #22: Disabling Clipboard Copying
In addition to filling the clipboard with junk data (as seen in earlier samples), this revision prevents copying from the login form’s input fields, further hindering analysis.

Stage 6: Enhanced Data Exfiltration
Evasion Mechanism #23: Custom Binary Encoding
Data exfiltration now uses binary encoding for payloads, adding an additional layer of obfuscation.

To see the payload example, we can use CyberChef. The result is decrypted data.
The decryption key is IV: 1234567890123456

Attack Detected on 14 April 2025
This sample introduces a more complex method for launching the Stage 1 payload, leveraging redirect chains to obscure the attack’s entry point.
Evasion Mechanism #24: Extended Redirect Chain
Clicking the initial phishing link triggers a redirect to Google Ads, followed by another redirect to a malicious URL that uses the following format:
hxxps://<domain>/?<2nd_domain>=<base64_payload>
A script then extracts the Base64 payload from location.search(), decodes it, and constructs the URL for the Stage 1 payload.
This extended redirect chain makes it harder to trace the attack’s origin.

Tycoon 2FA has become more sophisticated in initiating its malicious payload, employing a longer redirect chain to obscure the entry point of the attack.
The process is as follows:

Additionally, in POST requests, the cf-turnstile-response field (previously used for Cloudflare validation) is now filled with a placeholder value (qweqwe), confirming Tycoon 2FA’s shift away from Cloudflare.
Evasion Mechanism #25: Rotating CAPTCHAs
This revised version replaces the previously used custom CAPTCHA with Google reCAPTCHA.

Historical data shows Tycoon 2FA has cycled through different CAPTCHAs, such as IconCaptcha (observed in a submission on April 7, 2025).

The use of varying CAPTCHAs complicates signature-based detection.
Attack Detected on 23 April 2025
Around this period, Tycoon 2FA introduced a new anti-detection mechanism focused on browser fingerprinting to detect sandbox environments and bot activity.
Evasion Mechanism #26: Browser Fingerprinting
After opening the phishing link, a page is loaded requesting image element and executing a Base64-encoded script in case of an error.

After decoding with CyberChef, the script reveals functionality for:
- Collecting browser environment details: screen parameters, browser/platform name, URL, host, protocol, console properties, and document body.

- Gathering additional data: timezone, JavaScript runtime internals, iframe checks, and graphical interface properties.

- Collecting miscellaneous technical information.
The collected data is formatted as JSON, inserted into an invisible form, and sent to the attacker’s server via a POST request.


The server analyzes the fingerprint data and returns a response with a Location header, leading to one of two outcomes:
- Redirect to a Legitimate Page: If checks fail (e.g., sandbox detected), the user is redirected to a legitimate site like Emirates, Tesla, or SpaceX.

- Redirect to Stage 1 Payload: If checks pass, the user is directed to the Tycoon 2FA Stage 1 phishing page.

This mechanism also allows the attacker to geographically restrict the operation of the malware, enabling Tycoon2FA to launch in certain regions while terminating the attack process in others.
Attack Detected on 6 May 2025
Evasion Mechanism #27: Obfuscation through Encryption
In this sample, we can observe that the Tycoon2FA operator began using AES encryption for payload obfuscation, not just for uploading/downloading stolen and service data in the final stages of execution.

In all other parts, the execution chain of the new samples remains similar to the original.
All Tycoon2FA Evasion Mechanisms
# | Description | Sample | Date Observed |
---|---|---|---|
1 | Basic Obfuscation | https://app.any.run/tasks/7a87388b-8e07-4944-8d65-1422f56d303f | 1 October 2024 |
2 | Nomatch Check | ||
3 | Current Page Location Check | ||
4 | Redirect to Fake Litespeed 404 Page on Failed Checks | ||
5 | Cloudflare Turnstile | ||
6 | Debugger Timing Check | ||
7 | C2 Server Authorization for Payload Execution | ||
8 | Base64/XOR Obfuscation | ||
9 | Encryption of C2 Control/Exfiltrated Data | ||
10 | Victim Browser Detection | ||
11 | Clipboard Content Manipulation | ||
12 | C2 Request Routing | ||
13 | Redirect API Validation | ||
14 | Debug Environment Detection (Selenium, etc.) | https://app.any.run/tasks/57f31060-cc3e-4a65-9fa9-f460ede5f39c | 6 December 2024 |
15 | Keystroke Interception | ||
16 | Context Menu Blocking | ||
17 | Use of Legitimate CDN for Corporate Logos/Backgrounds | https://app.any.run/tasks/9700f36a-d506-4e5e-8f96-cdddc83e37a0 | 17 December 2024 |
18 | Complex JavaScript Code | https://app.any.run/tasks/d40e75ba-e4e8-4b51-b4a5-6614c8be7891 | 03 April 2025 |
19 | Invisible (Hangul) Obfuscation | ||
20 | Redirect to Custom Fake Page on Failed Checks | ||
21 | Use of Custom CAPTCHA Instead of Cloudflare | ||
22 | Disabling Clipboard Copying | ||
23 | Binary Encoding for Exfiltrated Data | ||
24 | Extended Redirect Chain Before Payload Execution | https://app.any.run/tasks/3bb9892b-4c3d-4c5e-a44d-d569cab8578e | 7 April 2025 – 14 April 2025 |
25 | Use of Different CAPTCHAs (reCAPTCHA, IconCaptcha, etc.) | ||
26 | Browser Fingerprinting | https://app.any.run/tasks/7c54c46d-285f-491c-ab50-6de1b7d3b376 | 23 April 2025 |
27 | Obfuscation via Encryption | https://app.any.run/tasks/c43d00a5-60d9-433a-8aee-d359eaadf0ab | 6 May 2025 |
Conclusion
The operators and developers of the Tycoon 2FA Phishing-as-a-Service (PhaaS) framework continue to actively enhance their product, focusing on complicating analysis of the malicious software.
Tycoon 2FA is adopting increasingly sophisticated anti-bot techniques, such as rotating CAPTCHAs (e.g., Google reCAPTCHA, IconCaptcha, custom CAPTCHAs) and browser fingerprinting, to protect its infrastructure from crawlers and Safebrowsing solutions.
The analysis indicates that there are several different versions or types of Tycoon 2FA active at the same time. This is evident because the methods used to avoid detection vary across different samples and time periods. Some techniques show up, disappear, and come back later.
Alongside the primary focus on Microsoft Outlook authentication phishing, variants targeting Google account authentication have been observed:
https://app.any.run/browses/b9c0b778-df32-4073-a580-18d7fc330518
https://app.any.run/tasks/a487cada-21b9-48e2-a7f3-470e3eddab0d
Despite the addition of new evasion techniques, some methods lack sophistication and remain relatively easy to bypass:
- Obfuscation: Most obfuscation relies on public tools like obfuscate.io, which can be reversed using deobfuscate.io.
- Limited JavaScript Exploitation: Tycoon 2FA does not fully leverage advanced JavaScript runtime capabilities, such as prototype manipulation, reflection mechanisms, or other dynamic code restructuring techniques.
In certain aspects, Tycoon 2FA’s evasion mechanisms seem quite amateur. For example, across all observed samples, C2 payloads and exfiltrated data are encrypted/decrypted using hardcoded keys and initialization vectors (1234567890123456 for both key and IV). Ideally, unique keys should be generated per session to enhance security.
The core architecture of Tycoon 2FA remains unchanged, relying on three domains:
- Primary phishing domain: Hosts the phishing page.
- Controller domain: Authorizes or denies further execution based on protective checks.
- Exfiltration domain: Receives stolen data.
Similarly, the execution chain of the framework has remained consistent, enabling detection through behavioral analysis despite the introduction of new evasion mechanisms.
Recommendations for Detecting Tycoon 2FA
Given the constant changes in the source code of Tycoon 2FA phishing pages, signature-based analysis is largely ineffective, and behavioral analysis is essential for reliable detection.
Tycoon 2FA employs a “triangle” of Command-and-Control (C2) domains from a specific pool of top-level domains (TLDs), including .ru, .es, .su, .com, .net, and .org. It also consistently loads a predictable set of JavaScript libraries, CSS stylesheets, and other web content, which can be leveraged for detection: Libraries:
Okta CSS:
Misc hyperlinks/web-content:
To detect Tycoon 2FA, security teams can implement a heuristic based on the following behavioral patterns observed in a single session:
- C2 Domain Triangle: Communication with a set of domains from the TLD pool (e.g., .ru, .es, .su, .com, .net, .org).
- Resource Loading: Retrieval of the specific JavaScript libraries, CSS stylesheets, or web content listed above.
- Session Redirect: A redirect to the official Microsoft authentication page at the end of the session.
Then there is a high probability that the activity involves Tycoon 2FA phishing.
The post Evolution of Tycoon 2FA Defense Evasion Mechanisms: Analysis and Timeline appeared first on ANY.RUN’s Cybersecurity Blog.
ANY.RUN’s Cybersecurity Blog – Read More