Imagine receiving an email that says Google has received a subpoena to release the contents of your account. The email looks perfectly “Googley”, and the sender’s address appears legitimate too: no-reply@accounts.google.com. A little unnerving (or maybe panic-inducing?) to say the least, right?

And what luck — the email contains a link to a Google support page that has all the details about what’s happening. The domain name in the link looks legit, too, and seems to belong to Google…

Regular readers of our blog have probably already guessed that we’re talking here about a new phishing scheme. And they’d be right. This time, the scammers are exploiting several genuine Google services to fool their victims and make the emails look as convincing as possible. Here’s how it works…

How phishing email mimics an official Google notification

The screenshot below shows the email that kicks off the attack; and it does a really credible job of pretending to be an alert from Google’s security system. The message informs the user that the company has received a subpoena requesting access to the data in their Google account.

The “from” field contains a genuine Google address: no-reply@accounts.google.com. This is the exact same address Google’s security notifications come from. The email also contains a few details that reinforce the illusion of authenticity: a Google Account ID, a support ticket number, and a link to the case. And, most importantly, the email tells the recipient that if they want to learn more about the case materials or contest the subpoena, they can do so by clicking a link.

The link itself looks quite plausible, too. The address includes the official Google domain and the support ticket number mentioned above. And it takes a savvy user to spot the catch: Google support pages are located at support.google.com, but this link leads to sites.google.com instead. The scammers are, of course, counting on users who either don’t understand such technicalities or don’t notice the word substitution.

If the user isn’t logged in, clicking the link takes them to a genuine Google account login page. After authorizing, they land on a page at sites.google.com, which quite convincingly mimics the official Google support site.

Now, it just so happens that the sites.google.com domain belongs to the legitimate Google Sites service. Launched back in 2008, it’s a fairly unsophisticated website builder — nothing out of the ordinary. The important nuance about Google Sites is that all websites created within the platform are automatically hosted on a google.com subdomain: sites.google.com.

Attackers can use such an address to both lull victims’ vigilance and circumvent various security systems, as both users and security solutions tend to trust the Google domain. It’s little wonder that scammers have increasingly been using Google Sites to create phishing pages.

Spotting fakes: the devil’s in the (email) details

We’ve already described the first sign of a dodgy email: the address of the fake support page located at sites.google.com. Look to the email header for more red flags:

The fields to pay attention to are “from“, “to“, and “mailed-by“. The “from” one seems fine: the sender is the official Google email, no-reply@accounts.google.com.

But lo and behold, the “to” field just below it reveals the actual recipient address, and this one sure looks phishy: me[@]googl-mail-smtp-out-198-142-125-38-prod[.]net. The address is trying hard to imitate some technical Google address, but the typo in the company domain name is a dead giveaway. Moreover, it has absolutely no business being there — this field is supposed to contain the recipient’s email.

As we keep examining the header, another suspicious address pops up in the “mailed-by” field. Now, this one is clearly nowhere near Google territory: fwd-04-1.fwd.privateemail[.]com. Yet again, nonsense like this has no place in an authentic email. For reference, here’s what these fields look like in a real Google security alert:

Unsurprisingly, these subtle signs would likely be lost on the average user — especially when they’re already freaked out by the looming legal trouble. Adding to the confusion is the fact that the fake email is actually signed by Google: the “signed-by” field shows accounts.google.com. In the next part of this post, we explain how the criminals managed to achieve this, and then we’ll talk about how to avoid becoming a victim.

Reconstructing the attack step by step

To figure out exactly how the scammers managed to send such an email and what they were after, cybersecurity researchers reenacted the attack. Their investigation revealed that the attackers used Namecheap to register the (now-revoked) googl-mail-smtp-out-198-142-125-38-prod[.]net domain.

Next, they used the same service again to set up a free email account on this domain: me[@]googl-mail-smtp-out-198-142-125-38-prod[.]net. In addition, the criminals registered a free trial version of Google Workspace on the same domain. After that the scammers registered their own web application in the Google OAuth system, and granted it access to their Google Workspace account.

Google OAuth is a technology that allows third-party web applications to use Google account data to authenticate users with their permission. You’ve likely encountered Google OAuth as a way to authenticate for third-party services: it’s the system you use every time you click a “Sign in with Google” button. Besides that, applications can use Google OAuth to obtain permission to, for example, save files to your Google Drive.

But let’s get back to our scammers. After a Google OAuth application is registered, the service allows sending a notification to the email address associated with the verified domain. Interestingly enough, the administrator of the web application is free to manually enter any text as the “App name” — which seems to be what the criminals exploited.

In the screenshot below, researchers demonstrate this by registering an app with the name “Any Phishing Email Text Inject Here with phishing URLs…”.

Google then sends a security alert containing this phishing text from its official address. This email goes to the scammers’ email address on the domain registered through Namecheap. This service allows forwarding the received notification from Google to any addresses. All they need do is set a specific forwarding rule and specify the email addresses of potential victims.

How to protect yourself from phishing attacks like this one

It’s not entirely clear what the attackers were hoping to achieve with this phishing campaign. Using Google OAuth to authenticate doesn’t mean the victim’s Google account credentials are shared with the scammers. The process generates a token that only provides limited access to the user’s account data — depending on the permissions the user authorized and the settings configured by the scammers.

The fake Google Support page the deceived user lands on suggested that the goal was to convince them to download some “legal documents” supposedly related to their case. The nature of these documents is unknown, but chances are they contained malicious code.

The researchers reported this phishing campaign to Google. The company acknowledged this as a potential risk for users and is currently working on a fix for the OAuth vulnerability. However, how long it will take to resolve the issue remains unknown.

In the meantime, here’s some advice to help you avoid becoming a victim of this and other intricate phishing schemes.

• Stay calm if you get an email like this. Begin by carefully examining all the email header fields and comparing them to legitimate emails from Google — you likely have some in your inbox. If you see any discrepancies, don’t hesitate to hit “Delete”.
• Be wary of websites on the google.com domain that are created with Google Sites. Lately, scammers have been increasingly exploiting it for a wide range of phishing schemes.
• As a general rule, avoid clicking links in emails.
• Use a robust security solution that will provide timely warnings about danger and block phishing links.

Follow the links below to read about five more examples of out-of-the-ordinary phishing.

• Turnkey phishing
• Progressive phishing: how PWAs can be used to steal passwords
• Browser-in-the-browser attack: a new phishing technique
• Malware lurking in “official” GitHub and GitLab links
• When two-factor authentication is useless

Kaspersky official blog – ​Read More

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.  

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. 

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.  

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 

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

• https://www.godaddy.com/ 

• https://sso.godaddy.com/v1/account/reset?app=o365&amp;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.

ANY.RUN’s Cybersecurity Blog – ​Read More