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:

threatName:”Tycoon”

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.

View sandbox session

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.

*Figure 1: Evasion Mechanisms in Stage 1 of Tycoon 2FA*

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.

*Figure 3: Domain Comparison Evasion Mechanism*

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.

*Figure 5: Example of Fake Litespeed 404 Page*

Purpose of Stage 1 Evasion Mechanisms

*Figure 6: Flowchart of Stage 1 Protective Checks in Tycoon 2FA*

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.

*Figure 7: Cloudflare CAPTCHA in Tycoon 2FA*

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.

*Figure 8: Debugger Timing Check Mechanism*

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.

*Figure 10: Code Fragment for Stage 3 Validation Checks*

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.

*Figure 11: Code for XOR-Base64 Deobfuscation*

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.

*Figure 12: Code for Sending POST Request*

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.

*Figure 13: Code for Decrypting POST Request Response*

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.

*Figure 14: Loading of Fake MS Outlook Login Page*

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.

*Figure 15: Base64/XOR Obfuscation in Stage 5*

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.

*Figure 16: Loaded Fake MS Outlook Login Page*

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.

*Figure 18: Code for Clipboard Manipulation*

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.

*Figure 19: Code for Payload Encryption/Decryption*

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.

*Figure 20: Code for Generating Random Exfiltration URLs*

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.

*Figure 21: Code for Redirect API Validation*

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.

Figure 23: Link to Next Tycoon 2FA Stage

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).

*Figure 24: Code fragment for phishing page State Machine*

Execution Chain Summary

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

*Detailed breakdown of Tycoon2FA’s attack*

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.

*Figure 25: Code for Detecting Debugging Runtime*

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.

*Figure 26: Code for Keystroke Interception*

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.

*Figure 27: Code for Disabling Context Menu*

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.

*Figure 28: Enhanced Debugger Timing Check Implementation*

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.

*Figure 29: Phishing page with custom background*

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

*Figure 30: Use of AADCDN for loading custom logos/backgrounds*

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.

*Figure 31: More sophisticated code in Stage 1*

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.

*Figure 32: Invisible obfuscation code #1*

*Figure 33: Invisible obfuscation code #2*

The form sent during the transition from Stage 2 to Stage 3 is now created as a FormData object, replacing the previous HTML

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.

*Figure 36: Example of custom fake page*

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.

*Figure 37: Custom CAPTCHA Code Fragment*

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.

*Figure 38: Code for Disabling Clipboard Copying*

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.

*Figure 39: Code for binary encoding of payload*

To see the payload example, we can use CyberChef. The result is decrypted data.

The decryption key is IV: 1234567890123456

*Figure 40: Example of decrypted payload*

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://

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.

*Figure 41: Code for calculating phishing page URL*

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:

*Figure 42: New redirect chain to Stage 1*

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.

*Figure 43: Use of Google reCAPTCHA in Tycoon 2FA*

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

*Figure 44: Example of IconCaptcha in Tycoon 2FA*

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.

View sandbox session

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.

*Figure 45: Suspicious onerror handler in image element*

Learn to analyze cyber threats

Follow along a detailed guide to using ANY.RUN’s Interactive Sandbox for malware and phishing analysis

Read full guide

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.

*Figure 46: Code for collecting execution environment data*

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

*Figure 47: Code for collecting browser 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.

*Figure 48: Invisible form for sending fingerprint data*

*Figure 49: Example of sent fingerprint data*

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.

*Figure 50: Example of failed C2 check redirect*

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

*Figure 51: Example of successful transition to 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.

*Figure 52: Code for obfuscation via encryption*

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.)		7 April 2025 - 14 April 2025
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:

https://code.jquery.com/jquery-3.6.0.min.js

https://github.com/fent/randexp.js/releases/download/v0.4.3/randexp.min.js

https://cdnjs.cloudflare.com/ajax/libs/crypto-js/4.1.1/crypto-js.min.js

Okta CSS:

https://ok4static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.18.0/css/okta-sign-in.min.css

https://ok4static.oktacdn.com/assets/loginpage/css/loginpage-theme.e0d37a504604ef874bad26435d62011f.css

Misc hyperlinks/web-content:

https://ok4static.oktacdn.com/fs/bcg/4/gfsh9pi7jcWKJKMAs1t7

https://www.okta.com/priv a cy

https://www.godaddy.com/

https://sso.godaddy.com/v1/account/reset?app=o365&realm=pass

https://www.godaddy.com/legal/agreements/privacy-policy?target=_blank

https://www.godaddy.com/legal/agreements/cookie-policy

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.