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:
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)
}
MITRE TTP :
Initial Access (TA0001):
- Phishing (T1566): The Tycoon Group uses phishing emails that redirect victims to malicious landing pages designed to steal credentials.
Execution (TA0002):
- User Execution (T1204): Victims are tricked into executing the phishing attack by clicking on links in emails that lead to the phishing landing pages.
Persistence (TA0003):
- Web Session Cookie (T1506): The group introduced support for stealing ADFS cookies, which can be used for persistent access to the victim’s account.
Defense Evasion (TA0005):
- Obfuscated Files or Information (T1027): The phishing landing pages use obfuscation techniques, such as Base64 encoding and XOR operations, to hide the malicious JavaScript and evade detection.
- Masquerading (T1036): The phishing pages mimic legitimate login pages, such as Microsoft 365 and Gmail, to deceive victims.
Credential Access (TA0006):
- Input Capture (T1056): The phishing pages capture user inputs, such as usernames and passwords.
- Steal Web Session Cookie (T1539): The group’s recent update enables the theft of ADFS cookies.
Discovery (TA0007):
- System Network Configuration Discovery (T1016): The WebSocket communication used by the phishing pages may include the victim’s IP address and browser type, which can be used for further reconnaissance.
Collection (TA0009):
- Email Collection (T1114): The phishing operation targets email accounts for credential theft.
- Input Capture (T1056): The group collects credentials entered into the fake login pages.
Command and Control (TA0011):
- Web Protocols (T1071): The use of WebSocket for communication between the phishing page and the server allows for real-time data exfiltration and command execution.
Exfiltration (TA0010):
- Exfiltration Over Alternative Protocol (T1048): The stolen credentials and session cookies are exfiltrated using WebSocket communication to the phisher’s server.