- The developer of the Typhon Reborn information stealer released version 2 (V2) in January, which included significant updates to its codebase and improved capabilities.
- Most notably, the new version features additional anti-analysis and anti-virtual machine (VM) capabilities to evade detection and make analysis more difficult.
- We assess Typhon Reborn 2 will likely appear in future attacks, as we have already observed samples in the wild and multiple purchases of the malware.
- The stealer is currently offered on underground forums for $59 per month but also offers a lifetime subscription for $540, which is inexpensive compared to competing infostealers.
- The stealer can harvest and exfiltrate sensitive information and uses the Telegram API to send stolen data to attackers.
Typhon Reborn V2 release
Typhon is an information stealer first publicly reported in mid-2022. It steals sensitive information, such as cryptocurrency wallet data, from a variety of applications and uses a “file grabber” to collect a predefined list of file types, then exfiltrates them via Telegram. Since its initial arrival, it has undergone continuous development, with Typhon Reborn being released just several months later in late 2022. The malware’s developer announced the release of Typhon Reborn V2 on Jan. 31, 2023 on the popular Russian language dark web forum XSS. Samples uploaded to public repositories indicate that the new version of Typhon Reborn has been in the wild since December 2022.
In the latest version, the malware developer claimed to have refactored the codebase and significantly improved existing capabilities present within the malware, which Cisco Talos independently confirmed. It is available for $59 per month or a lifetime subscription for $540, which is inexpensive compared to competing infostealers. Analysis of the cryptocurrency wallet from which the attacker collects payments suggests that multiple adversaries have purchased access to the stealer, making it likely that it will be used in attacks moving forward.
Notable changes in Typhon Reborn V2
The code in Version 2 of Typhon Reborn was heavily modified compared to Version 1, based on our analysis.
For example, Version 2 has significantly more anti-analysis and anti-virtualization capabilities, as evidenced by comparing the anti-analysis routines present in each version. For example, the developer made several changes to the logic that prevents the malware from infecting systems that match predefined criteria. That includes heavily expanding this list of criteria to include present usernames, CPUIDs, applications and processes present on the system, debugger/emulation checks, and geolocation data for countries that attackers may wish to avoid.
Finally, in Typhon Reborn V2 samples that we analyzed, the developer appeared to have removed the functionality that establishes persistence across reboots. Instead, V2 simply terminates itself after data exfiltration.
Dissecting Typhon Reborn V2
In Typhon Reborn V2, the malware complicates analysis via string obfuscation by using Base64 encoding and applying the XOR function to various strings. During execution, the malware decodes the Base64, generating a UTF-8 character-encoded string that is then deobfuscated using an XOR key stored in the malware’s configuration or hard-coded into
DecryptString(). The XOR key used is based on the mode passed when the function is called each time. The resulting string is then decoded from Base64 again, creating a plain text string to continue the operation.
The malware’s operations are determined by a series of parameters stored in the malware’s configuration that dictate what information should be collected, keys used for string deobfuscation and geolocations where the malware should not execute.
Anti-analysis and sandbox evasion
When Typhon Reborn V2’s
main() method is executed, it checks the malware configuration to determine if anti-analysis has been enabled. If it is enabled, the malware will attempt to conduct a series of anti-analysis checks to determine if it is being executed in an analysis or sandbox environment.
If any of the checks fail, the malware will call a
SelfRemove() class, creating a batch file in the temp directory with the following contents.
chcp 65001 TaskKill /F /IM [MALWARE_PID] Timeout /T 2 /Nobreak
This batch file is then executed via the Windows command processor, thus terminating the malware’s execution.
The overall execution flow of the various anti-analysis checks is shown below.
The malware uses Windows Management Instrumentation (WMI) to retrieve information about the Graphics Processing Unit (GPU) on the system.
SELECT * FROM Win32_VideoController
It then checks the returned value to determine if it contains the string vmware svga.
Then, it makes an HTTP request to the following URL to determine if the system is located in a network associated with a hosting provider, colocation facility, or data center environment. The API returns either a “True” or “False” response based on the location of the system which is used to determine the type of environment in which the system is located.
Then, it checks for the presence of the following DLLs associated with common security products that may be installed.
- SbieDLL.dll (Sandboxie)
- SxIn.dll (360 Total Security)
- Sf2.dll (Avast)
- Snxhk.dll (Avast)
- cmdvrt32.dll (Comodo Internet Security)
It also retrieves the system manufacturer and model via WMI using the following query:
Select * from Win32_ComputerSystem
The retrieved information is checked to determine if it contains the following hypervisor-related strings.
The malware also uses WMI to collect information about the system’s video controller.
SELECT * FROM Win32_VideoController
This information is then checked to determine if it contains the strings VMware or VBox.
Next, the malware uses
CheckRemoteDebuggerPresent to determine if the process is being debugged.
The malware then obtains the current system time, initiates a short (10ms) sleep, then obtains the system time again. It compares the delta between the two times to what is expected during normal operations to determine if the process is being run in a debugging session.
The command line argument used to initially launch the malware is then obtained to determine if the sample was executed using the file name
detonate.exe or if the argument
-–detonate was passed when initiating execution.
The malware also checks the Windows Registry (
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall) to determine if any subkeys reference the following common analysis tools:
Next, WMI is queried to obtain the ProcessorId (CPUID) for the system using the following query.
Select ProcessorId From Win32_Processor
The CPUID is then checked against the following list of CPUIDs under which the malware will not execute:
The malware also determines the user account context under which the malware is executing and will terminate if the username matches the following values:
The malware then obtains the list of currently running processes on the system and checks the executable path associated with them against the following list of executable file names associated with common analysis tools.
It then attempts to test internet connectivity by making an HTTP request to
The malware again obtains the execution environment to determine if its filename matches the following list:
Next, the malware checks the Programs subdirectory under the Windows Start Menu for the presence of the following analysis tools:
It then attempts to locate
wine_get_unix_file_name to determine if Wine is being used in an analysis environment.
Next, it checks the
SYSTEM_CODEINTEGRITY_INFORMATION structure to determine if unsigned or test-signed drivers are allowed on the system (
The malware also checks the
SYSTEM_KERNEL_DEBUGGER_INFORMATION structure to determine if kernel mode debugging is enabled (
Then, the malware checks various system DLLs for the presence of instructions that may indicate that the environment is instrumented for analysis.
The malware also features two geolocation avoidance mechanisms. The first one allows for the specification of a list of countries in the malware’s config that the attacker does not want to infect systems in. The malware uses the IP-API service to determine where the system is located and compares it against the user-supplied list.
If the system is located in one of these countries, the malware calls the
SelfRemove() functionality previously described.
The malware also contains a
RunAntiCIS() feature that specifically avoids infecting systems located in Commonwealth of Independent States (CIS) countries.
System and network data collection
If the victim’s environment passes all the malware’s anti-analysis checks, Typhon Reborn V2 begins collecting and exfiltrating sensitive information. First, the malware creates a randomly named subdirectory under
%LOCALAPPDATA%, then the malware begins generating stealer logs that will ultimately be staged in that subdirectory for exfiltration.
To generate the logs, the malware retrieves survey information about the infected system and writes it to the stealer log. It collects a variety of system information including user data, system data and network information, using various mechanisms such as WMI queries, environment variables, and registry keys. The malware uses
api[.]ipify[.]org to obtain the public IP of the infected system. This information is saved in the malware’s working directory (
UserData.txt) along with a text file (
BuildID.txt) containing the Telegram channel for the malware’s developer. A list of installed software is also generated using WMI and saved (
InstalledSoftwares.txt). A list of hard drives present within the system is also saved (
The malware also captures screenshots from infected systems saved in the same directory as the stealer logs.
The stealer also collects saved Wi-Fi network information and stores it (
Wifi Passwords.txt) using the following system commands:
cmd.exe /C chcp 65001 && netsh wlan show profile | findstr All
cmd.exe /C timeout /t 5 /nobreak > nul && netsh wlan show profile name=<PROFILE_NAME> key=clear | findstr Key
It also attempts to scan for available wireless networks and stores information about them (
cmd.exe /C timeout /t 5 /nobreak > nul && netsh wlan show networks mode=bssid
A list of currently running processes and process executable paths is collected and saved as well (
Application data collection
Once basic system information has been collected and saved, the stealer begins iterating through specific applications and collecting data based on the malware’s configuration. The stealer currently supports collecting passwords, tokens, and other sensitive information from the applications shown below.
Typhon Reborn V2 can steal data from additional applications, including various gaming clients. However, this functionality was never actually called from the
main() method of the malware in the latest version analyzed.
The malware also contains a
FileGrabber() feature that is used to collect and exfiltrate files of interest from victim environments. It iterates through all drives detected on the system and attempts to determine whether any are removable storage devices, network storage locations or optical drives.
Each drive that meets this criterion has its root directory added to a list of target directories. The malware then iterates through all of the target directories, copying contents that match the parameters in the malware’s configuration to the malware’s working directory.
The two parameters
Config.GrabberFileExtensions defined in the malware’s configuration determine the operation of the file collection capability.
Once the stealer has finished collecting information from infected systems, the data is stored in a compressed archive and exfiltrated via HTTPS using the Telegram API. First, the malware sends an overview log containing survey information and basic statistics related to the data collected.
Then, the malware sends another Telegram message containing the data being exfiltrated from the infected system.
Once the data has been successfully transmitted to the attacker, the archive is then deleted from the infected system. The malware then calls
SelfRemove.Remove() to terminate execution.
Ways our customers can detect and block this threat are listed below.
Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.
Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.
Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.
Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.
Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.
Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.
Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.
Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
The following Snort SIDs are applicable to this threat: 61532-61533, 300476.
Cisco Secure Endpoint users can use Orbital Advanced Search to run complex OSqueries to see if their endpoints are infected with this specific threat. For specific OSqueries on this threat, click here.
Indicators of Compromise (IOCs)
IOCs for this research can also be found at our Github repository here