SpiderLabs Blog

Breakdown of Tycoon Phishing-as-a-Service System

Written by Rodel Mendrez | Feb 20, 2024 4:14:52 PM

Just weeks after Trustwave SpiderLabs reported  on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

The team found Tycoon Group during a regular investigation into a phishing incident, and its distinctive method of communication to its phishing server convinced the team to further explore this active PaaS operation.

 

Tycoon Group

Tycoon Group PaaS is sold and marketed on Telegram for as low as $120. Its key selling features include the ability to bypass Microsoft two-factor authentication, achieve "link speed at the highest level," and leveraging Cloudflare to evade antibot measures, ensuring the persistence of undetected phishing links.

 

Figure 1. Tycoon Group phishing-as-a-service as advertised on Telegram

 

SpiderLabs has investigated scanned sessions in Urlscan.io containing artifacts and filenames related to this PaaS. The scans show the earliest Tycoon Group’s phishing page submission occurred on August 25, 2023, suggesting that the group likely introduced this service around that timeframe.

In mid-October 2023, the group released an update claiming that “link and attachment will be smooth,” which coincides with the integration of WebSocket in their phishing page to enhance browser-to-server communication. This information corresponds with URLScan.io scanned sessions , highlighting the use of socket.io, a WebSocket JavaScript library, in their phishing pages starting around late October 2023. This allows the phishing page to transmit data to the actor’s server in a more streamlined fashion.

In February 2024, Tycoon Group introduced a new capability to bypass two-factor authentication targeting Gmail users. The release also includes Gmail “Display” login page and Google Captcha expanding its potential target list to non-Microsoft 365 users.

 

Figure 2. Tycoon Group introducing Gmail 2FA support

 

And most recently, the group introduced support for enabling subscribers to steal Active Directory Federation Services (ADFS) cookies, specifically targeting organizations' authentication mechanisms that use ADFS.

 

Figure 3. New update by the Tycoon Group, introducing “Link Speed at the highest level

 

Phishing Attack Chain

Figure 4. Phishing Attack Chain using the Tycoon Group Phishing-as-a-Service

 

The attack chain starts with a run-of-the-mill phishing campaign that uses trusted domains and cloud-based services to mask the true destination URL of the main phishing landing page. This technique involves using a reputable online mailer and marketing services, newsletters, or document-sharing services, used either as URL redirectors or to host decoy documents containing links to the final phishing page. Some of the services we have seen abused are listed below.

Docusign

Microsoft Cloud

OneDrive

Dropbox

Sharepoint

Google Drive

Microsoft Dynamics

Adobe Cloud

Flipsnack.com

Baidu.com

Paperless.io

Feedblitz.com

Marsello.com

RetailRocket.net

Padlet.com

Doubleclick

Figure 5. Some of the legitimate cloud services that the phishing actor abuses as a redirector or host for a decoy document

 

Tycoon Landing Page

Redirection is accomplished by clicking a lick in the email. This leads to either to a decoy document containing a link to the main phishing page or directly to the primary phishing landing page enabled by a redirector.

Figure 6. Examples of landing pages that redirect to a Tycoon PaaS main phishing page

The landing page is composed of two primary components: a PHP script named "index.php," which is responsible for loading its secondary component, a .JS file prefixed with the name "myscr." This second component’s function is to generate the HTML code for the phishing page.

 

“Index.php” Component

The “index.php” comes in two versions. The earlier versions feature HTML source code in non-obfuscated plain text, as shown in the example code below (Figure 6).

Figure 7. Landing page version with no obfuscation.

 

A different version of “index.php” uses code obfuscation. This involves using randomly generated variable names, as well as a combination of Base64 encoding and XOR operations to hide the JavaScript link.

Figure 8. The rawindex.php script code as hosted on the PHP server controlled by the phishers

 

Figure 9. The resulting obfuscated index.php page when accessed via a client browser, where the JavaScript link is obfuscated using Base64 and XOR operations, along with a concealed variable name.

 

“Myscr” JavaScript Component

The second component is a JavaScript file prefixed with the name “myscr.” This script also uses multiple obfuscation techniques to evade bot crawlers and antispam engines. One obfuscation method involves a very long array of characters represented as decimal integers. Each integer value undergoes conversion from decimal to character and is then concatenated to construct the HTML source code of the phishing page. In addition, the script uses an obfuscation technique known as an "opaque predicate," inserting unnecessary code in the program flow to obscure the underlying logic of the script.

Figure 10. The obfuscation technique used in the landing page

 

Initially, the JavaScript does prefiltering by using the CloudFlare Turnstile service to authenticate that the link is being clicked by a human, differentiating it from automated bot crawlers. The subscriber of this PaaS can enable this feature in the admin panel and supply CloudFlare keys associate with the subscriber’s account. This integration also adds more metrics for the phisher via the CloudFlare dashboard.

Figure 11. Phishing page utilising CloudFlare’sTurnstile human verification

 

Upon successful verification, the JavaScript loads a fake sign-in page based on the phishing theme configured by the subscriber. An example screenshot below corresponds to the chosen theme mimicking a Microsoft 365 login page:

Figure 12. Sample of a Fake Microsoft 365 login page

 

Exfiltration Via WebSocket

The phishing page uses a distinctive method of exfiltrating the victim’s credentials . It uses a JavaScript WebSocket library known as socket.io to establish communication with the phisher's server, enabling the exfiltration of the data entered into the fake sign-in page.

Usually, the phisher's WebSocket server is hosted on the same domain as the phishing page. Below is the initial WebSocket request:

 

 

Initially, the JavaScript on the phishing page transmits a message to the WebSocket server, sending information such as the maximum payload size, WebSocket ping interval and timeout, unique ID, and additional upgrade details.

 

Figure 13. Initial WebSocket communication

 

The phisher's WebSocket server then confirms receipt of this message by sending a received that includes a randomly generated alphanumeric character. When a user enters their username and password into the form, the phishing page sends a WebSocket message to the server, encapsulating the following details:

 

Figure 14. The WebSocket message transmitted to the phisher’s server when the victim enters their credential into the fake sign-in form

 

Field

Definition

"send_to_browser"

Specifies the action to be performed.

"route"

Specifies the specific route or type of data. The value is “enteremail” when the victim entered their email, and the value is “enterpassword” when the victim entered their password

"arguments"

An array containing additional data or parameters for the specified route. In this example, it includes ["user credentials", "sid", "browser type", "IP"], providing details such as the email, victim identification, browser type, and IP address.

"getresponse"

A flag indicating whether a response from the browser is expected (1 for true, 0 for false). In this case, it is set to 1, suggesting that the sender anticipates receiving a response.

 

Once the message is received, the server responds with a corresponding message. During a test scenario, we entered an arbitrary email address, and the server replied with an error message, indicating that the entered username did not match their target, as shown below:

 

Figure 15. Response from the phisher’s server indicating that the email that was entered was not correct

 

Field

Definition

"response_from_browser"

Indicates that the data represents a response received from the browser.

"message"

Specifies the nature of the response, in our case, "error," indicating that the entered username did not match their target.

"bottomsection"

An array containing objects that represent clickable elements in the bottom section of the response. Each object may have properties such as a_text (anchor text), a_id (anchor ID), type (link type), and text (displayed text).

"backbutton"

A binary flag (0 or 1) indicating whether a back button should be displayed or not. In this case, it is set to 0, suggesting the absence of a back button.

"description"

An object providing additional details or instructions. It may include properties such as a_text (anchor text), a_id (anchor ID), type (link type), and text (displayed text).

 

Figure 16. The fake form and the Websocket transaction behind the scenes

 

Tycoon Group Admin Panel

The Tycoon Group PaaS provides an admin panel accessible to subscribers/renters, enabling them to log in, generate, and oversee campaigns, as well as manage phished credentials.

Depending on their subscription plan, subscribers may access the panel for a limited duration. Within the settings section, users can generate new campaigns, selecting the desired phishing theme and toggling various PaaS features on or off. Additionally, subscribers can manage phished credentials, including usernames, passwords, and session cookies. The service further also allows subscribers to forward phishing results to their Telegram account.

 

Figure 17. Tycoon Group login page

 

Figure 18. Tycoon group admin panel and settings section

 

Figure 19. The admin panel displaying a roster of successfully phished credentials. Also displayed are telemetry data showcasing metrics such as Bot Blocked, Total Visits, Valid Logins, Invalid Logins, and the count of Single Sign-On logins.

 

Figure 20. Also, the dashboard displays a list of valid single sign-on accounts that were stolen.

 

On the dashboard table, each row features a “Get Cookies” button that enables adversaries to download a JavaScript file that allows them to set stolen cookies onto the browser, which can be used alongside the stolen password for unauthorized access to the victim’s Microsoft 365 account.

 

Figure 21. A sample JavaScript file containing code to set the stolen session cookie in the browser

 

Conclusion

The rise of the phishing-as-a-service model as offered by groups like Tycoon Group and Greatness Phishing has made sophisticated phishing attacks very accessible, even for unskilled criminals. This ease of use is demonstrated by the greater number of phishing attacks using these types of services that we have observed. What makes the Tycoon Group distinctive is the use of WebSocket in the phishing page that allows a more efficient transmission of data between the browser and the phisher’s server. Furthermore, it also allows actors who subscribe to this service to easily manage their campaign and phished credentials.

 

Indicators of Compromise

We’ve tracked Tycoon Group landing URLs, and these can be found in this link:

https://gist.github.com/drole/1469713841ab9a5121011e2eb88c5e87

YARA rule to detect Tycoon Group landing page:

 

rule Tycoon_Phish_Landing_Page {
  meta:
    description = "Tycoon_Phish_Landing_Page"
  strings:
   $obf_str1 = "emailcheck" ascii
   $obf_str2 = "ccturnhtml" ascii
   $obf_str3 = "ccelehtml" ascii
   $obf_str4 = "cchtml" ascii
   $obf_str5 = "bchtml" ascii
   $obf_str6 = "atob" ascii
   $obf_str7 = "String.fromCharCode" ascii
   $obf_str8 = "document.write" ascii
   $plain_str1 = /language=\"Javascript\"/
   $plain_str2 = /src=\"http.{2,99}\/myscr\d{4,6}\.js\"/
  condition:
   (all of ($obf_str*)) or (all of ($plain_str*) and filesize < 250)
}