The Tycoon 2FA phishing kit is a sophisticated Phishing-as-a-Service (PhaaS) platform that emerged in August 2023, designed to bypass two-factor authentication (2FA) and multi-factor authentication (MFA) protections, primarily targeting Microsoft 365 and Gmail accounts. Utilizing an Adversary-in-the-Middle (AiTM) approach, it employs a reverse proxy server to host deceptive phishing pages that mimic legitimate login interfaces, capturing user credentials and session cookies in real-time. According to the Any.run malware trends tracker, Tycoon 2FA leads with over 64,000 reported incidents this year.
This allows attackers…
The Tycoon 2FA phishing kit is a sophisticated Phishing-as-a-Service (PhaaS) platform that emerged in August 2023, designed to bypass two-factor authentication (2FA) and multi-factor authentication (MFA) protections, primarily targeting Microsoft 365 and Gmail accounts. Utilizing an Adversary-in-the-Middle (AiTM) approach, it employs a reverse proxy server to host deceptive phishing pages that mimic legitimate login interfaces, capturing user credentials and session cookies in real-time. According to the Any.run malware trends tracker, Tycoon 2FA leads with over 64,000 reported incidents this year.
This allows attackers to steal authentication (2FA) codes and gain access to a victim’s account, even if 2FA is enabled.
Targeted Accounts
The Tycoon 2FA campaign specifically targets:
- Microsoft accounts
- Gmail accounts
- Organizational accounts that use Gmail business account
How the Attack Spreads
The phishing links associated with the Tycoon 2FA campaign are distributed through a variety of methods designed to trick unsuspecting users. Attackers share these links using:
PDF documents
*
*

SVG Files
Malicious Website


PowerPoint (PPT) Presentations
*
*
*
*
Emails

Amazon S3 Storage
The Tycoon threat actors are using Amazon S3 buckets to host the malicious fake login page.
https://click.mailchimp.com/track/click/30010842/s3.ap-northeast-3.=amazonaws.com?p=3DeyJzIjoiUUhxQS1jMmJmNW9QeS1lNUFZT2RMeVE4WlJjIiwidiI6Miwic=CI6IntcInVcIjozMDAxMDg0MixcInZcIjoyLFwidXJsXCI6XCJodHRwczpcXFwvXFxcL3MzLmFw=LW5vcnRoZWFzdC0zLmFtYXpvbmF3cy5jb21cXFwvYmFzc2V0dGhvdXNlaW5uLmNvbVxcXC9pbmR=leC5odG1sXCIsXCJpZFwiOlwiZTFjOTg0N2U5YzM1NDc0NjhhZGIyYTAxMGNhZWQxNGZcIixcIn=VybF9pZHNcIjpbXCJhMTlmMmI4NzE3MjNjNGU4YTFmYjU2Mjc2OTY2NDE3ZTQzYTkzNWYyXCJdL=FwibXNnX3RzXCI6MTc1NDkxMTMzM30ifQ"
Canva and Dropbox

Pre-Redirection Checks
These pre-redirection checks are a key part of the phishing kit’s defense against detection. They include:
- **Domain check: **This verifies the user is coming from an expected source.
- **CAPTCHA check: **This is used to filter out bots and automated tools.
- Bot/Scanning tools check: The system actively looks for indicators that the user might be a security scanner or an automated bot.
- Debugger check: The kit checks to see if the user has a web browser’s developer tools or a debugger open, which is a common practice for security analysts.
The Tycoon 2FA phishing kit utilizes boilerplate templates to dynamically generate a fake login page based on responses from Microsoft’s servers. One of these templates prompts users to input their multi-factor authentication (MFA) code, which is then relayed to Microsoft’s servers in real-time, effectively bypassing this critical security step.
Understanding Organization Policies
A particularly advanced feature of the Tycoon 2FA campaign is its ability to understand an organization’s specific security policies. By analyzing error messages from the login process, the phishing kit can tailor its attacks to create highly targeted campaigns, increasing its chances of successfully stealing credentials.
Technical Analysis
Bot Check
The Tycoon 2FA attack begins with a CAPTCHA check to filter out automated bots. This is a key step in ensuring that the campaign only targets real people.


First Stage (Email Extraction)

The initial HTML page includes a JavaScript file with a base64-encoded payload. This payload is compressed using the LZ-string algorithm. The script then uses the LZ-string library to decompress and execute the hidden payload.
JavaScript 1 (Domain Check)
The second stage of the attack uses a technique called DOM Vanishing Act to evade detection. The malicious JavaScript code removes itself from the Document Object Model (DOM) but the JavaScript is executed in the memory after leaving no visible trace for security tools that inspect the page’s code.

The malicious script contains three different base64-encoded payloads, each of which is designed to run under a specific condition.
Payload 1
This payload is obfuscated using an XOR cipher. Once deobfuscated, it drops the second-stage payload script. This payload is executed only if a specific condition is met: the window.location.pathname.split must contain an exclamation mark (!) or a dollar sign ($). This check likely enables the attacker to confirm that the user was redirected via the intended malicious document or link, rather than an automated security scanner. The string following a dollar sign ($) represents a victim’s email address encoded in base64.
Sample URL: https://qaok5hty3.vraudo.es/ITITRt408hJWgm!5Cj/$ZmhhZ2tZWllckBwdGMuY29t

Payload 2 & 3
If the above condition is not met, it loads the following error page.

JavaScript 2 – Email Extraction
When the script detects that a debugger is active, it redirects the user to https://google.com by replacing the window.location variable.
If a debugger is not detected, the script retrieves the current URL using the window.location property to check for an embedded email address.
The script performs the following actions to extract and transmit data:
- **URL Parameter Check: **It looks for URL-encoded characters and converts them to their original form.
- **Email Extraction: **The script extracts the email address from the current URL.
- **Data Creation: **It creates a custom string by appending “WQ” to the beginning of the email address (e.g., WQtest@outlook.com).
- **Exfiltrating Data: **This custom string containing the email is sent to the attacker’s command-and-control (C2) server via a POST request to the following URL.
url: “/zcYbH5gqRHbzSQXiK8YtTbhpNSGtkZc6xbMyRBGazbWU8fjfq”,

The C2 server’s response contains the next-stage payload, which is encrypted using the AES algorithm and the CryptoJS library. The script then decrypts and loads the payload to continue the attack.
Second Stage (Debugger check & Bot Check)

The script is composed of two main parts, both designed to evade detection and deliver the final payload.
Evasion and Redirection
The first part of the script is heavily obfuscated using base64 encoding and CryptoJS encryption. When this code is deobfuscated, it performs a crucial debugger check. If a debugger is detected, the script immediately redirects the user to a benign website, such as https://www.target.com, by using window.location.replace. This first script is executed using a global Windows object.
Decrypting the Payload
If no debugger is found, the second part of the script is executed. Similar to the first, this script is also obfuscated, but it uses a combination of base64 encoding, concatenation, and CryptoJS encryption. Once decrypted, this code is responsible for decrypting and launching the next stage of the attack—the final payload. Like the first script, this part is also loaded and executed through a global Windows object.

Bot Check Payload
The next stage of the attack is a bot check designed to weed out automated scanners and security tools.The next stage of the attack is a bot check designed to weed out automated scanners and security tools.
If a bot is detected, it will immediately try to connect to a specific, hardcoded URI. (‘https://egk1w.onkttyhqjycn.es/sunel$bqtaxtc’).The script then redirects the user to https://www.target.com using window.location.replace, parameter.

If no bot is detected, the script uses a setTimeout function to pause for 150 milliseconds before attempting a connection. The script proceeds with the next step, sending a POST request with form data to the attacker’s endpoint (“../eypkDtn5lPJjyOMUrofhYfQwPk9fbGCAjUgZztc9dMlLdgv”;).
Third Stage

JavaScript Payload 1
The script contains the two different base64 payload and Microsoft O365 graphics code.
Microsoft O365 login graphics code
The first payload is the Microsoft O365 login graphics code. This is responsible for creating a realistic-looking Microsoft login page, which tricks the user into entering their credentials.

Debugger Check
The second payload checks for the presence of a debugger.
Encrypted JavaScript Payload
The third payload is a CryptoJS-encrypted payload. Once decrypted, this payload loads the next stage JavaScript payload.

JavaScript Payload 2
The script contains the two different base64 payload:
- Base64 encoded payload to load the next Javascript payload
- Debugger check

HTML Payload 3
The script contains a dual-purpose component that includes both a debugger check and a Boilerplate template code.
How the Attack Unfolds
When a victim enters their credentials into the fake login page, the attacker immediately receives this information. Acting as a man-in-the-middle, the attacker uses these stolen credentials to send a new login request to the legitimate Microsoft server.
The website that the victim sees is then dynamically updated based on the response from the Microsoft server. The webpage is dynamically updated using the following webparts.




Based on the error messages received from the login process, the attacker can reverse-engineer an organization’s specific email configurations. This allows them to create more effective, targeted phishing campaigns.
Final JavaScript Payload
The malicious JavaScript code executes a series of actions to gather user data, transmit it to an attacker, and then serve a dynamic phishing page.
Data Collection and Transmission
The script first gathers information from the user’s browser:
- It retrieves the user agent string using navigator.userAgent, which provides details about the browser and operating system.

- It sends a request to a legitimate IP geolocation service (https://get.geojs.io/v1/ip/geo.json) to collect the user’s** IP address and country**.
This collected data—including the user’s geolocation and user agent—is then encrypted using CryptoJS with a hardcoded key and IV (1234567890123456). The encrypted data is converted to a binary format and sent to an attacker’s endpoint via an AJAX POST request.( /tdwsch3h8IoKcUOkog9d14CkjDcaR0ZrKSA95UaVbbMPZdxe)

Once a user enters their credentials, the script tracks their actions based on the request type: checkemail, checkpass, twofaselect, or twofaselected.
To identify the user’s choice, a unique, randomized pattern is generated for each action:
- checkemail: pq or rs
- checkpass: yz or 12
- twofaselect: 56, 78, or 90
- twofaselected: 23 or 45

After a user submits their information, the script encrypts the stolen password and a session token, then sends them to a different attacker-controlled endpoint.
‘https[:]//3eJBE8eo5f13oigGmQkDKhEkKNK9c2TlnVZPVRc16Hnhi0G4kxTsXEf2gH[.]jgcrrouu[.]es/sZzqqvSHaFLRSRFbpIgHEzUhFBimCQAHTCPYNKQFZGMAFYFZUSEVATEOXHQKEXAQDWFXJOAYHETC‘

The attacker, acting as a middleman, submits the stolen credentials to the Microsoft server. Based on the server’s response (e.g., successful login, incorrect password, or MFA required), the attacker’s server sends back an encrypted payload. The victim’s browser then decrypts this response and loads the appropriate webpage template. This makes the phishing attempt appear seamless and highly convincing, as the page’s behavior mimics a genuine login process.
Debugger Check
The script first performs a user agent check to see if the browser is being controlled by an automated tool, PhantomJS or Burp Suite. If any of these are detected, the script immediately loads a blank page to prevent further analysis.

Detecting a Debugger
The script also actively tries to detect if a debugger is being used. It checks for specific key presses that activate a browser’s debugging modules. The script monitors how long the debugger has been open. If it has been on for more than 0.1 seconds, it assumes a security researcher is present and redirects the user to google.com to terminate the attack.

Conclusion
The Tycoon 2FA phishing attack is increasingly targeting organizations, enabling attackers to gain unauthorized access to Microsoft and Google accounts. This access exposes sensitive resources such as emails, OneDrive, Google Drive, and other applications. Attackers leverage stolen data to conduct targeted phishing campaigns against high-value accounts, move laterally within the environment, exfiltrate data, and deploy ransomware.
Recommendations
To safeguard against these phishing attacks, organizations should implement the following measures:
-
User Education on Phishing Awareness
-
Train users to recognize suspicious activities and phishing attempts to minimize reinfection risks.
-
Teach identification of modified or misspelled URLs and grammatical errors in communications.
-
Educate users on the risks of malicious files (e.g., PDFs, PPTs, Word documents, and SVG files) that may redirect to phishing websites.
-
Strengthen Authentication
-
Deploy robust multi-factor authentication (MFA) methods to enhance account security.
-
Implement Anti-Phishing Solutions
-
Utilize advanced anti-phishing tools to effectively detect and block phishing attempts.
About The Researcher
Hema Loganathan, T2 GSOC Analyst
Hema Loganathan is a GSOC Analyst with the Cybereason Global SOC team. She is involved in MalOp Investigation, Malware Analysis, Reverse Engineering and Threat Hunting. Hema has a Master of Science degree in Information Systems.


