A new Traffic Direction System (TDS) we are calling Parrot TDS, using tens of thousands of compromised websites, has emerged in recent months and is reaching users from around the world. The TDS has infected various web servers hosting more than 16,500 websites, ranging from adult content sites, personal websites, university sites, and local government sites.
Parrot TDS acts as a gateway for further malicious campaigns to reach potential victims. In this particular case, the infected sites’ appearances are altered by a campaign called FakeUpdate (also known as SocGholish), which uses JavaScript to display fake notices for users to update their browser, offering an update file for download. The file observed being delivered to victims is a remote access tool.
The newly discovered TDS is, in some aspects, similar to the Prometheus TDS that appeared in the spring of 2021 [1]. However, what makes Parrot TDS unique is its robustness and its huge reach, giving it the potential to infect millions of users. We identified increased activity of the Parrot TDS in February 2022 by detecting suspicious JavaScript files on compromised web servers. We analysed its behaviour and identified several versions, as well as several types of campaigns using Parrot TDS. Based on the appearance of the first samples and the registration date of the Command and Control (C2) domains it uses, Parrot TDS has been active since October 2021.
One of the main things that distinguishes Parrot TDS from other TDS is how widespread it is and how many potential victims it has. The compromised websites we found appear to have nothing in common apart from servers hosting poorly secured CMS sites, like WordPress sites. From March 1, 2022 to March 29, 2022, we protected more than 600,000 unique users from around the globe from visiting these infected sites. In this time frame, we protected the most users in Brazil, more than 73,000 unique users, India, nearly 55,000 unique users, and more than 31,000 unique users from the US.
Compromised Websites
In February 2022, we identified a significant increase in the number of websites that contained malicious JavaScript code. This code was appended to the end of almost all JavaScript on the compromised web servers we discovered. Over time, we identified two versions (proxied and direct) of what we are calling Parrot TDS.
In both cases, web servers with different content management systems (CMS) were compromised. Most often WordPress in various versions, including the latest one or Joomla, were affected. Since the compromised web servers have nothing in common, we assume the attackers took advantage of poorly secured servers, with weak login credentials, to gain admin access to the servers, but we do not have enough information to confirm this theory.
Proxied Version
The proxied version communicates with the TDS infrastructure via a malicious PHP script, usually located on the same web server, and executes the response content. A deobfuscated code snippet of the proxied version is shown below.
This code performs basic user filtering based on the User-Agent string, cookies and referrer. Briefly said, this code contacts the TDS only once for each user who visits the infected page. This type of filtering prevents multiple repeating requests and possible server overload.
The aforementioned PHP script serves two purposes. The first is to extract client information like the IP address, referrer and cookies, forward the request from the victim to the Parrot TDS C2 server and send the response in the other direction.
The second functionality allows an attacker to perform arbitrary code execution on the web server by sending a specifically crafted request, effectively creating a backdoor. The PHP script uses different names and is located in different locations, but usually, its name corresponds to the name of the folder it is in (hence the name of the TDS, since it parrots the names of folders).
In several cases, we also identified a traditional web shell on the infected web servers, which was located in various locations under different names but still following the same “parroting” pattern. This web shell likely allowed the attacker more comfortable access to the server, while the backdoor in the PHP script mentioned above was used as a backup option. An example of a web shell identified on one of the compromised web servers is shown below.
Since we have seen several cases of reinfection, it is highly likely that the server automatically restores possibly deleted files using, for example, a cron job. However, we do not have enough information to confirm this theory.
Direct Version
The direct version is almost identical to the previous one. This version utilises the same filtering technique. However, it sends the request directly to the TDS C2 server and, unlike the previous version, omits the malicious backdoor PHP script. It executes the content of the response the same way as the previous version. The whole communication sequence of both versions is depicted below. We experimentally verified that the TDS redirects from one IP address only once.
Identified Campaigns
The Parrot TDS response is JavaScript code that is executed on the client. In general, this code can be arbitrary and exposes clients to further danger. However, in practice, we have seen only two types of responses. The first, shown below, is simply setting the __utma cookie on the client. This happens when the client should not be redirected to the landing page. Due to the cookie-based user filtering mentioned above, this step effectively prevents repeated requests on Parrot TDS C2 servers in the future.
The next code snippet shows the second type, which is a campaign redirection targeting Windows machines.
FakeUpdate Campaign
The most prevalent “customer” of Parrot TDS we saw in the wild was the FakeUpdate campaign. The previous version of this campaign was described by MalwareBytes Lab in 2018 [2]. Although the version we identified slightly differs from the 2018 version, the core remains the same. The user receives JavaScript that changes the appearance of the page and tries to force the user to download malicious code. An example of what such a page looks like is shown below.
This JavaScript also contains a Base64 encoded ZIP file with one malicious JavaScript file inside. Once the user downloads the ZIP file and executes the JavaScript it contains, the code starts fingerprinting the client in several stages and then delivers the final payload.
User Filtering
The entire infection chain is set up so that it is complicated to replicate and, therefore, to investigate it. Parrot TDS provides the first layer of defence, which filters users based on IP address, User-Agent and referrer.
The FakeUpdate campaign provides the second layer of defence, using several mechanisms. The first is using unique URLs that deliver malicious content to only one specific user.
The last defence mechanism is scanning the user’s PC. This scan is performed by several JavaScript codes sent by the FakeUpdate C2 server to the user. This scan harvests the following information.
Name of the PC
User name
Domain name
Manufacturer
Model
BIOS version
Antivirus and antispyware products
MAC address
List of processes
OS version
An overview of the process is shown in the picture below. The first part represents the Parrot TDS filtering based on the IP address, referrer and cookies, and after the user successfully passes these tests, the FakeUpdate page appears. The second part represents the FakeUpdate filtering based on a scan of the victim’s device.
Final Payload
The final payload is then delivered in two phases. In the first phase, a PowerShell script is dropped and run by the malicious JavaScript code. This PowerShell script is downloaded to a temporary folder under a random eight character name (e.g. %Temp%\1c017f89.ps1). However, the name of this PowerShell is hardcoded in the JavaScript code. The content of this script is usually a simple whoami /all command. The result is sent back to the C2 server.
In the second phase, the final payload is delivered. This payload is downloaded to the AppData\Roaming folder. Here, a folder with a random name containing several files is dropped. The payloads we have observed so far are part of the NetSupport Client remote access tool and allow the attacker to gain easy access to the compromised machines [3].
The RAT is commonly named ctfmon.exe (mimicking the name of a legitimate program). It is also automatically started when the computer is switched on by setting an HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Runregistry key.
The installed NetSupport Manager tool is configured so that the user has very little chance of noticing it and, at the same time, gives the attacker maximum opportunities. The tool basically gives the attacker full access to the victim’s machine. To run unnoticed, chat functions are disabled, and the silent option is set on the tool, for example. A gateway is also set up that allows the attacker to connect to the client from anywhere in the world. So far, we’ve seen Chinese domains in the tool’s configuration files used as gateways. The following picture below shows the client settings.
Phishing
We identified several infected servers hosting phishing sites. These phishing sites, imitating, for example, a Microsoft office login page, were hosted on compromised servers in the form of PHP scripts. The figure below shows the aforementioned Microsoft phishing observed on an otherwise legitimate site. We don’t have enough information to assign this to Parrot TDS directly. However, a significant number of the compromised servers contained phishing as well.
Conclusion and Recommendation
We have identified an extensive infrastructure of compromised web servers that served as TDS and put a large number of users at risk. Given that the attacker had almost unlimited access to tens of thousands of web servers, the above list of campaigns is undoubtedly not exhaustive.
The Avast Threat Labs has several recommendations for developers to avoid their servers from being compromised.
Scan all files on the web server with Avast Antivirus.
Replace all JavaScript and PHP files on the web server with original ones.
Use the latest CMS version.
Use the latest versions of installed plugins.
Check for automatically running tasks on the web server (for example, cron jobs).
Check and set up secure credentials. Make sure to always use unique credentials for every service.
Check the administrator accounts on the server. Make sure each of them belongs to you and have strong passwords.
When applicable, set up 2FA for all the web server admin accounts.
Use some of the available security plugins (WordPress, Joomla).
* In attempts to prevent further attacks onto the infected servers, we are providing this hash on demand. Please DM us on Twitter or reach us out at [email protected].
We’ve been closely monitoring an information stealer called ViperSoftX. ViperSoftX was first reported on Twitter in 2020, and by Fortinet in the same year. Some aspects of ViperSoftX were also described previously by Colin Cowie. However, it has undergone very intensive development since then, intensifying throughout 2022. The malware authors’ constant game of hide-and-seek in which they continually improve their strategies and techniques to avoid detections shows no signs of stopping. We, therefore, decided to put the pieces together to provide a comprehensive analysis.
This multi-stage stealer exhibits interesting hiding capabilities, concealed as small PowerShell scripts on a single line in the middle of otherwise innocent-looking large log files, among others. ViperSoftX focuses on stealing cryptocurrencies, clipboard swapping, fingerprinting the infected machine, as well as downloading and executing arbitrary additional payloads, or executing commands.
One of the payloads ViperSoftX distributes is a specific information stealer in the form of a browser extension for Chromium-based browsers. Due to its standalone capabilities and uniqueness, we decided to give it its own name, VenomSoftX. The malicious extension provides full access to every page the victim visits, carries out man-in-the-browser attacks to perform cryptocurrency addresses swapping by tampering with API requests’ data on popular cryptocurrency exchanges, steals credentials and clipboard content, tampers with crypto addresses on visited websites, reports events using MQTT to the C&C server, and more.
ViperSoftX is mostly spread via cracked software such as Adobe Illustrator, Corel Video Studio, Microsoft Office, and more, commonly distributed over torrents.
Campaign overview
Since the beginning of 2022, we have protected more than 93,000 of our users. As the malware is mostly spread via torrents and software-sharing sites, ViperSoftX activity is distributed all over the world. The most impacted countries are India (7,000+), USA (6,000+), and Italy (5,000+).
Monetary gain
Both ViperSoftX and VenomSoftX focus on stealing cryptocurrencies from infected computers, either by scanning local files or by using more sophisticated techniques. In the table below, we show an estimation of the attackers’ total earnings for relevant cryptocurrency wallets.
Cryptocurrency
Earnings in cryptocurrency
~Earning in USD
Bitcoin
5.947 BTC
$116,812.81
Ethereum
5.312 ETH
$7,826.13
Dogecoin
34,355.528 DOGE
$3,474.47
Bitcoin Cach
9.11997194 BCH
$1,021.39
Cosmos (ATOM)
65.153 ATOM
$846.44
Tezos
191.445553 XTZ
$241.32
Dash
4.72446445 DASH
$199
Table with monetary gain (data refreshed 2022-11-08)
The amounts in the wallets ViperSoftX and VenomSoftX redirect stolen cryptocurrencies to add up to about $130,421.56, as of November 8, 2022. This is just the amount sent to cryptocurrency wallets, and doesn’t include other possible profits from other activities.
Technical analysis
Overview of the infection chain
From cracked software to fake logs
In the beginning, ViperSoftX is served to victims when they download what they believe to be cracked software. It is commonly named Activator.exe or Patch.exe. Upon execution, however, the victim is infected with ViperSoftX.
Activator.exe extraction
Activator.exe is in fact a loader that decrypts data from itself using AES in CBC mode.
The decryption algorithm performs a checksum as follows:
Read 4 bytes at offset 0x24 from the end of the file which gives an offset
Hash the offset value using SHA256
Read the rest of the bytes (from -0x20) and compare it to the hash
If the checksum holds, the offset points to the location where the data is stored at offset+0x24 from the end of the binary. Since the data is stored from the end of the binary, offset is also the size of the data blob. This blob can be decrypted straight away using a hardcoded key as well as IV inside the binary:
The decrypted data blob is a serialized protocol buffer structure. The structure template contains two protobuf messages as shown below:
We can use this template to deserialize the structure, revealing five different files:
A log file with a hidden additional payload resulting in the ViperSoftX PowerShell (see next subsections)
XML file for the task scheduler
SyncAppvPublishingServer.vbs (clean) that is used to create a scheduled task for persistence
Application binary (usually clean) that is supposed to be cracked
Manifest file
Last but not least, you can find the extraction Python script in our GitHub repository.
Analyzing the files
The most interesting file is the aforementioned “log file” which is usually more than 5 MB in size and contains a single malicious line of code (usually from 17,302 lines in total, but this might vary in different versions).
This log file is usually named and stored as: C:\Windows\Logs\system-logs.txt although we saw variants dropping the same “log” files disguising as a “driver” or a “text” file, e.g. C:\Windows\System32\Drivers\p4kizn\e12de1ae-2139-45f6-b883-3c58243f23d6.sys C:\Windows\2ZQ2UoL\5A7C4B54-4404-4424-83DA-CC696BED43D3.txt where the subfolder names and the GUIDs are randomized.
An example of such a malicious line can be found below. As we will see later, this line actually contains a script that is decoded and executed.
The malware creates a scheduled task using the legacy SyncAppvPublishingServer.vbs script for executing these hidden scripts afterward as well for ensuring persistence. Note that the line number varies depending on the malware configuration provided in the scheduled task.
Hidden Script Variants
We have seen two variants of hidden scripts lurking in the logs so far.
The first variant is a simple dropper that downloads another payload from a hardcoded C&C server and executes it. We have only seen the ViperSoftX information stealer downloaded as a payload so far. We will cover the stealer separately in the subsection below.
The second variant is in the form of a PowerShell script without the encoding. This script contains two parts, the first one is a set of decryption functions and the second is an encrypted data blob.
The script uses AES in CBC mode to decrypt the payload, the ViperSoftX stealer. The AES key is passed via the command line by the scheduled task created by Activator.exe. You can find the decryption process in this CyberChef template.
ViperSoftX Information Stealer
When the payload is dropped, an obfuscated ViperSoftX PowerShell script is presented to us. We have seen multiple variants of ViperSoftX, suggesting that the malware is under active development. In the text below, we will cover the stealer’s features as a whole.
Stealing Capabilities
First, let’s have a look at what ViperSoftX is actually capable of stealing. ViperSoftX performs fingerprinting of the infected machine, focusing on various types of information, including:
Computer name
Username
OS information and its architecture
Installed antivirus or other security software and whether the solution is active
The malware focuses on stealing cryptocurrencies. To do so, it searches the typical locations for web browser extensions and locally stored wallets. The full list of locations can be found in the Appendix. More generic information, such as OS, architecture, and username, is obtained using WMI and system variables.
ViperSoftX searches for cryptocurrencies stored locally on the infected device in cryptocurrency software and browser extensions, and monitors the clipboard for cryptocurrency wallet addresses to perform clipboard swapping.
The gathered data, as well as the fingerprint, is then concatenated together into a single string, encoded by base64, and sent to the hardcoded C&C server in the User-Agent HTTP header. Note that C&C servers vary across versions: http://api.private-chatting[.]com/connect
Each time the victim copies anything to their clipboard, ViperSoftX scans the content using predefined regular expressions in the background. If the expression matches one of the configured wallet addresses belonging to the specific cryptocurrency, the malware replaces the content with the attacker’s address and sends a notification to the C&C server in the X-Notify HTTP header in a form of three values: Cryptocurrency type - victim’s address - attacker’s address
The cryptocurrency type reflects what type of cryptocurrency was matched and can be one of the following: BTC, BCH, BNB, ETH, XMR, XRP, DOGE, or DASH.
The malware also checks title texts of opened windows (MainWindowTitle property) and if it spots an application focused on cryptocurrencies or finance, it logs its presence into: %SystemDrive%\Users\Public\log.dat The full list of searched keywords can be found in the Appendix.
On top of the information-stealing core, ViperSoftX provides RAT functionalities as well, like executing arbitrary commands on the command line, downloading an additional arbitrary payload provided by the C&C server, and executing it, as well as removing itself completely from the system. The RAT functionality can also be used, for example, to steal cryptocurrencies from their locations, which it previously identifies and sends to the C&C server.
Host Header Spoofing
Aside from trying to steal cryptocurrencies, the malware spoofs host headers to obfuscate its communication with the C&C servers.
The spoofed host header consists of five to 10 lowercase alpha letters, but the true destination is in the hardcoded $meta_host variable. This way, the real C&C server address is obfuscated by a random-looking domain that doesn’t exist.
VenomSoftX Browser Extensions
Newer versions of ViperSoftX information stealer are capable of loading a custom malicious browser extension to Chromium-based browsers installed on infected computers. The extension is provided by the C&C server. The extension is basically another standalone information stealer, we are calling VenomSoftX, but is installed by ViperSoftX, as described below. The extension disguises itself as various popular browser extensions to avoid user detection.
The main goal VenomSoftX is also to steal cryptocurrencies from the unsuspecting victim. The difference is, VenomSoftX mainly does this by hooking API requests on a few very popular crypto exchanges victims visits/have an account with. When a certain API is called, for example, to send money, VenomSoftX tampers with the request before it is sent to redirect the money to the attacker instead. Although similar in principle to what information stealers like ViperSoftX do and rather a common clipboard swapping, this technique is performed at a lower level, meaning the victim has little to no chance of noticing the money is being transferred elsewhere.
Installing the extension
ViperSoftX’s approach is simple. The malware downloads a VenomSoftX PowerShell installer from the C&C server e.g. by base64-decoding a hardcoded request metadata directly from the PowerShell script, following a request to: http://apps-analyser[.]com/api/v1/<HASH> depending on the malware version. This can hold different payloads, but we will focus on the VenomSoftX browser extension.
After the installer script is downloaded from the C&C server and the VenomSoftX browser extension is extracted, the installer searches several locations for .lnk files and if such a link file belongs to Chrome, Brave, Opera, or Edge, it modifies the link file with a parameter --load-extension=<path_to_the_malicious_extension>. This way, when the user starts their favorite browser, they actually load the malicious extension with it.
These locations are checked for link files leading to browsers:
The extension ID is randomly generated, provided random lowercase characters to represent the extension folder and randomly generated version number of the extension:
We observed further versions of ViperSoftX containing a full update mechanism. These versions were able to walk through the modified .lnk files, parse the manifest.json file of the malicious extension, and when an older version or an old write timestamp of the extension was detected on the infected system than what was advertised by the C&C server, the malware requested an update and replaced the extension files to the newest version by a dedicated command (provided by the C&C server).
The extension tries to disguise itself as well known and common browser extensions such as Google Sheets. In reality, the VenomSoftX is yet another information stealer deployed onto the unsuspecting victim with full access permissions to every website the user visits from the infected browser.
Diving into javascript shenanigans
The extension contains several files, as shown in the table below. Each file has a different purpose:
File name
Purpose
128.png
Google Sheets icon to disguise the extension
content.bootstrap.js
Orchestrates the malicious activity, sends results using MQTT
manifest.json
The extension’s manifest file
rules.json
URL filter rules for Kucoin
webpack_block.js
Request tampering and credential theft on Blockchain.com
webpack_bnb.js
Request tampering and cryptocurrency theft on Binance
webpack_cb.js
Request tampering and cryptocurrency theft on Coinbase
webpack_common.js
Contains an address book for pattern matching, clipboard monitoring and stealing
webpack_content.js
When no exchange is detected – attacker’s addresses are replaced on the visited websites with the ones that victim entered earlier
webpack_gt.js
Request tampering and cryptocurrency theft on Gate.io
webpack_kuc.js
Request tampering and cryptocurrency theft on Kucoin
The malware focuses on five big cryptocurrency exchanges, reflected by abbreviations in the modules names.
In the paragraphs below, we’ll focus on what each of the modules do, in detail.
content.bootstrap.js
This module is the starting point of VenomSoftX and it is loaded with every site visit. It orchestrates what modules to load and it is also responsible for sending stolen data to the C&C server.
The scripts are loaded depending on the visited domain. The bootstrap checks what site is being loaded and if it is one of the following: Blockchain.com, Binance, CoinBase, Gate.io, or Kucoin, the module loads an appropriate “webpack”. If the user is on any other site, webpack_content.js is loaded. The module webpack_common.js is loaded by default regardless of which site the victim visits.
All the modules serve their own purpose. However, two of the modules, webpack_common.js and webpack_block.js, are capable of sending data back to the collector server using a Paho MQTT client present in the content.bootstrap.js. The MQTT client has an event listener set to a hardcoded value b8b0becb-080a-46af-9688-e3671fcc4166 that indicates data should be sent to an MQTT broker, harvesting the data: broker.emqx[.]io Note that the collector address can vary in different versions.
The sent data are structured as follows: MSG: time: <utc_datetime> ip: <client_ip> data: <data>
The time and ip fields are obtained using a public service (https://worldtimeapi.org/api/ip).
The data field is either clipboard content with a cryptowallet and other metadata, or stolen credentials for blockchain.com. See further sections below for details.
webpack_common.js
The “common” module is loaded to every website, regardless of whether it is a cryptocurrency exchange or something else. It is used to define an address book with regular expression patterns, which is used for crypto address matching on several occasions in other modules.
The structure of the address book is in the form of a dictionary, where the key is the regular expression and the value is yet another dictionary containing three values: coin, address, and network. An example of such an address book can be seen in the below snippet. For the full address book, see Appendix.
Furthermore, each time the user pastes anything into any website (except the malicious address from the address book), this module checks whether the clipboard content matches any of the regular expressions from the address book and if they do, it sends the following data to the collector server encoded using base64. The data for the MQTT message has a following construct:
This module monitors two input elements for content the user fills into websites and it is loaded when the victim is outside of any of the mentioned exchange sites:
HTMLInputElement
HTMLTextAreaElement
This is done by implementing hooks in getters of these elements to try to find a compatible crypto address for the user’s input and if found, the malware creates new localStorage entry with a combination of visited site and the compatible address: website_attackerAddress: userAddress The compatible address is found when the provided address matches any of the regular expressions from the address book described in the previous section.
After that, a custom MutationObserver watches for dynamic changes in the site (e.g. loading the page, displaying a message sent earlier in the user’s messenger client, etc.) and if such a change occurs, the malware replaces all mentions of the malicious address (if found) with the user’s address using the localStorage. This effectively hides all traces of the malicious address in the website’s body.
Note that since the information is stored directly in the persistent localStorage, the functionality survives a browser restart, PC restart, or re-visiting the page anytime in the future. The victim has to clear the user data in their browser or uninstall the malware extension altogether to get rid of the malicious behavior.
For the sake of demonstrating this behavior, we decided to create a demo PoC of a simple page that illustrates the whole process of content tampering while the malware is active:
First two buttons, Attacker address and User address, fill in attacker address or user address to the “Dynamic content to be pasted” line on the webpage
“Get value” button triggers the getter but the hook is inactive since the provided address doesn’t match cryptowallet address pattern (it is too short)
The user fills in a compatible address
“Get value” button creates a localStorage entry with the entered address
The attacker’s address is always replaced with the one from localStorage
Draining the victim’s accounts
As we already mentioned, VenomSoftX focuses on five different crypto exchanges/websites, namely on Blockchain.com, Binance, Coinbase, Gate.io, and Kucoin.
In these modules, the malware tries to tamper with API requests the sites use for several actions like money withdrawal or sending security codes. This is done by creating hooks on the API calls (or rather functions responsible for sending those requests), parsing their structure, and replacing the response’s body with the desired attacker’s contents – commonly meaning that the recipient’s address is replaced by the attacker’s one as well as the amount is set to the value of an available account balance if known. The request is then processed by the malware without the user noticing anything, completely draining the victim’s portfolio as a result.
Note that the user has little to no chance to notice this. In comparison to a rather common clipboard swapping, for example, this “swapping” is performed on a lower level. Since the transactions on blockchains/ledgers are inherently irreversible, when the user checks the transaction history of payments afterward, it is already too late.
The complete list of hooked API functions can be found in the Appendix. The only file that differs from the rest is webpack_block.js. This module focuses on www.blockchain.com and it tries to hook https://blockchain.info/wallet. It also modifies the getter of the password field to steal entered passwords. Once the request to the API endpoint is sent, the wallet address is extracted from the request, bundled with the password, and sent to the collector as a base64-encoded JSON via MQTT.
Since the rest of the hooks are the same on the higher level if we ignore API differences, we will use the Binance module as an illustration example.
The Binance module recognizes six different API calls invoking malicious interactions. When the user logs in to the site, it is expected that at some point the API function https://www.binance.com/bapi/asset/v3/private/asset-service/asset/get-user-asset will be called. VenomSoftX then parses and saves all assets available on the victim’s account. When the user tries to manipulate their savings, e.g. withdrawing their money, the malware intercepts the request https://www.binance.com/bapi/capital/v3/private/capital/withdraw/apply and tampers with the request body, modifying the address to redirect the money to the attacker’s address if a compatible attacker’s address was found. The amount of the request is also set to the maximum amount available obtained by the previous step. After the tampering, the request is passed further like nothing happened, effectively draining the victim’s wallet.
Conclusion
In this blog post, we took a closer look at ViperSoftX, a long-standing information stealer, and its malicious browser extension payload VenomSoftX. We described both information stealers’ infection chains, and how the original payload hides and decrypts on the infected system.
We described what both ViperSoftX and VenomSoftX steal and how the browser extension leverages its full access to every page the victim visits and carries out man-in-the-browser attacks by silently tampering with the API requests popular cryptocurrency exchanges use, resulting in draining the victim’s accounts.
Avast discovered and analyzed a malware campaign hijacking an eScan antivirus update mechanism to distribute backdoors and coinminers
Avast disclosed the vulnerability to both eScan antivirus and India CERT. On 2023-07-31, eScan confirmed that the issue was fixed and successfully resolved
The campaign was orchestrated by a threat actor with possible ties to Kimsuky
Two different types of backdoors have been discovered, targeting large corporate networks
The final payload distributed by GuptiMiner was also XMRig
Introduction
We’ve been tracking a curious one here. Firstly, GuptiMiner is a highly sophisticated threat that uses an interesting infection chain along with a couple of techniques that include performing DNS requests to the attacker’s DNS servers, performing sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others.
The main objective of GuptiMiner is to distribute backdoors within big corporate networks. We’ve encountered two different variants of these backdoors: The first is an enhanced build of PuTTY Link, providing SMB scanning of the local network and enabling lateral movement over the network to potentially vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands from the attacker to install more modules as well as focusing on scanning for stored private keys and cryptowallets on the local system.
Interestingly, GuptiMiner also distributes XMRig on the infected devices, which is a bit unexpected for such a thought-through operation.
The actors behind GuptiMiner have been capitalizing on an insecurity within an update mechanism of Indian antivirus vendor eScan to distribute the malware by performing a man-in-the-middle attack. We disclosed this security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.
GuptiMiner is a long-standing malware, with traces of it dating back to 2018 though it is likely that it is even older. We have also found that GuptiMiner has possible ties to Kimsuky, a notorious North Korean APT group, by observing similarities between Kimsuky keylogger and parts of the GuptiMiner operation. In this analysis, we will cover the GuptiMiner’s features and its evolution over time. We will also denote in which samples the particular features are contained or introduced to support the overall comprehension in the vast range of IoCs.
It is also important to note that since the users rarely install more than one AV on their machine, we may have limited visibility into GuptiMiner’s activity and its overall scope. Because of this, we might be looking only at the tip of the iceberg and the true scope of the entire operation may still be subject to discovery.
Infection Chain
To illustrate the complexity of the whole infection, we’ve provided a flow chart containing all parts of the chain. Note that some of the used filenames and/or workflows can slightly vary depending on the specific version of GuptiMiner, but the flowchart below illustrates the overall process.
The whole process starts with eScan requesting an update from the update server where an unknown MitM intercepts the download and swaps the update package with a malicious one. Then, eScan unpacks and loads the package and a DLL is sideloaded by eScan clean binaries. This DLL enables the rest of the chain, following with multiple shellcodes and intermediary PE loaders.
Resulted GuptiMiner consists of using XMRig on the infected machine as well as introducing backdoors which are activated when deployed in large corporate networks.
Evolution and Timelines
GuptiMiner has been active since at least 2018. Over the years, the developers behind it have improved the malware significantly, bringing new features to the table. We will describe the specific features in detail in respective subsections.
With that said, we also wanted to illustrate the significant IoCs in a timeline representation, how they changed over time – focusing on mutexes, PDBs, and used domains. These timelines were created based on scanning for the IoCs over a large sample dataset, taking the first and last compilation timestamps of the samples, then forming the intervals. Note that the scanned dataset is larger than listed IoCs in the IoC section. For more detailed list of IoCs, please visit our GitHub.
Domains in Time
In general, GuptiMiner uses the following types of domains during its operations:
Malicious DNS – GuptiMiner hosts their own DNS servers for serving true destination domain addresses of C&C servers via DNS TXT responses
Requested domains – Domains for which the malware queries the DNS servers for
PNG download – Servers for downloading payloads in the form of PNG files. These PNG files are valid images (a logo of T-Mobile) that contain appended shellcodes at their end
Config mining pool – GuptiMiner contains two different configurations of mining pools. One is hardcoded directly in the XMRig config which is denoted in this group
Modified mining pool – GuptiMiner has the ability to modify the pre-defined mining pools which is denoted in this group
Final C&C – Domains that are used in the last backdoor stage of GuptiMiner, providing additional malware capabilities in the backdoored systems
Other – Domains serving different purposes, e.g., used in scripts
Note that as the malware connects to the malicious DNS servers directly, the DNS protocol is completely separated from the DNS network. Thus, no legitimate DNS server will ever see the traffic from this malware. The DNS protocol is used here as a functional equivalent of telnet. Because of this, this technique is not a DNS spoofing since spoofing traditionally happens on the DNS network.
Furthermore, the fact that the servers for which GuptiMiner asks for in the Requested domain category actually exist is purely a coincidence, or rather a network obfuscation to confuse network monitoring tools and analysts.
From this timeline, it is apparent that authors behind GuptiMiner realize the correct setup of their DNS servers is crucial for the whole chain to work properly. Because of this, we can observe the biggest rotation and shorter timeframes are present in the Malicious DNS group.
Furthermore, since domains in the Requested domain group are irrelevant (at least from the technical viewpoint), we can notice that the authors are reusing the same domain names for longer periods of time.
Mutexes in Time
Mutexes help ensure correct execution flow of a software and malware authors often use these named objects for the same purpose. Since 2018, GuptiMiner has changed its mutexes multiple times. Most significantly, we can notice a change since 2021 where the authors changed the mutexes to reflect the compilation/distribution dates of their new versions.
An attentive reader can likely observe two takeaways: The first is the apparent outliers in usage of MIVOD_6, SLDV15, SLDV13, and Global\Wed Jun 2 09:43:03 2021. According to our data, these mutexes were truly reused multiple times in different builds, creating larger timeframes than expected.
Another point is the re-introduction of PROCESS_ mutex near the end of last year. At this time, the authors reintroduced the mutex with the string in UTF-16 encoding, which we noted separately.
PDBs in Time
With regard to debugging symbols, the authors of GuptiMiner left multiple PDB paths in their binaries. Most of the time, they contain strings like MainWork, Projects, etc.
Stage 0 – Installation Process
Intercepting the Updates
Everyone should update their software, right? Usually, the individual either downloads the new version manually from the official vendor’s site, or – preferably – the software itself performs the update automatically without much thought or action from the user. But what happens when someone is able to hijack this automatic process?
Our investigation started as we began to observe some of our users were receiving unusual responses from otherwise legitimate requests, for example on:
http://update3[.]mwti[.]net/pub/update/updll3.dlz
This is truly a legitimate URL to download the updll3.dlz file which is, under normal circumstances, a legitimate archive containing the update of the eScan antivirus. However, we started seeing suspicious behavior on some of our clients, originating exactly from URLs like this.
What we uncovered was that the actors behind GuptiMiner were performing man-in-the-middle (MitM) to download an infected installer on the victim’s PC, instead of the update. Unfortunately, we currently don’t have information on how the MitM was performed. We assume that some kind of pre-infection had to be present on the victim’s device or their network, causing the MitM.
Throughout the analysis, we will try to describe not just the flow of the infection chain, malware techniques, and functionalities of the stages, but we will also focus on different versions, describing how the malware authors developed and changed GuptiMiner over time.
The first GuptiMiner sample that we were able to find was compiled on Tuesday, 2018-04-19 09:47:41 and it was uploaded to VirusTotal the day after from India, followed by an upload from Germany: c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3
This file was named C:\Program Files\eScan\VERSION.DLL which points out the target audience is truly eScan users and it comes from an update package downloaded by the AV.
Even though this version lacked several features present in the newer samples, the installation process is still the same, as follows:
The eScan updater triggers the update
The downloaded package file is replaced with a malicious one on the wire because of a missing HTTPS encryption (MitM is performed)
A malicious package updll62.dlz is downloaded and unpacked by eScan updater
The contents of the package contain a malicious DLL (usually called version.dll) that is sideloaded by eScan. Because of the sideloading, the DLL runs with the same privileges as the source process – eScan – and it is loaded next time eScan runs, usually after a system restart
If a mutex is not present in the system (depends on the version, e.g. Mutex_ONLY_ME_V1), the malware searches for services.exe process and injects its next stage into the first one it can find
Cleanup is performed, removing the update package
The malicious DLL contains additional functions which are not present in the clean one. Thankfully the names are very verbose, so no analysis was required for most of them. The list of the functions can be seen below.
Some functions, however, are unique. For example, the function X64Call provides Heaven’s gate, i.e., it is a helper function for running x64 code inside a 32-bit process on a 64-bit system. The malware needs this to be able to run the injected shellcode depending on the OS version and thus the bitness of the services.exe process.
To keep the original eScan functionality intact, the malicious version.dll also needs to handle the original legacy version.dll functionality. This is done by forwarding all the exported functions from the original DLL. When a call of the legacy DLL function is identified, GuptiMiner resolves the original function and calls it afterwards.
Injected Shellcode in services.exe
After the shellcode is injected into services.exe, it serves as a loader of the next stage. This is done by reading an embedded PE file in a plaintext form.
This PE file is loaded by standard means, but additionally, the shellcode also destroys the PE’s DOS header and runs it by calling its entry point, as well as it removes the embedded PE from the original location memory altogether.
Command Line Manipulation
Across the entire GuptiMiner infection chain, every shellcode which is loading and injecting PE files also manipulates the command line of the current process. This is done by manipulating the result of GetCommandLineA/W which changes the resulted command line displayed for example in Task Manager.
After inspecting this functionality, we believe it either doesn’t work as the authors intended or we don’t understand its usage. Long story short, the command line is changed in such a way that everything before the first --parameter is skipped, and this parameter is then appended to the process name.
To illustrate this, we could take a command: notepad.exe param1 --XX param2 which will be transformed into: notepad.exeXX param2
However, we have not seen a usage like power --shell.exe param1 param2 that would result into: powershell.exe param1 param2 nor have we seen any concealment of parameters (like usernames and passwords for XMRig), a type of behavior we would anticipate when encountering something like this. In either case, this functionality is obfuscating the command line appearance, which is worth mentioning. An interested reader can play around with the functionality at the awesome godbolt.org here.
Another version with a mutex ONLY_ME_V3 introduced a code virtualization. This can be observed by an additional section in the PE file called .v_lizer. This section was also renamed a few times in later builds.
Thankfully the obfuscation is rather weak, provided the shellcode as well as the embedded PE file are still in the plaintext form.
Furthermore, the authors started to distinguish between the version.dll stage and the PE file loaded by the shellcode by additional mutex. Previously, both stages used the shared mutex ONLY_ME_Vx, now the sideloading uses MTX_V101 as a mutex.
The installation process has undergone multiple improvements over time, and, since it is rather different compared to older variants, we decided to describe it separately as an intermediary Stage 0.9. With these improvements, the authors introduced a usage of scheduled tasks, WMI events, two differently loaded next stages (Stage 1 – PNG loader), turning off Windows Defender, and installing crafted certificates to Windows.
There are also multiple files dropped at this stage, enabling further sideloading by the malware. These files are clean and serve exclusively for sideloading purposes. The malicious DLLs that are being sideloaded, are two PNG loaders (Stage 1):
At this stage, WMI events are used for loading the first of the PNG loaders. This loader is extracted to a path: C:\PROGRAMDATA\AMD\CNext\atiadlxx.dll
Along with it, additional clean files are dropped, and they are used for sideloading, in either of these locations (can be both): C:\ProgramData\AMD\CNext\slsnotif.exe C:\ProgramData\AMD\CNext\msvcr120.dll or C:\Program Files (x86)\AMD\CNext\CCCSlim\slsnotify.exe C:\Program Files (x86)\AMD\CNext\CCCSlim\msvcr120.dll
The clean file slsnotify.exe is then registered via WMI event in such a way that it is executed when these conditions are met:
In other words, the sideloading is performed on a workday in either January, July, or November. The numbers represented by %d are randomly selected values. The two possibilities for the hour are exactly two hours apart and fall within the range of 11–16 or 13–18 (inclusive). This conditioning further underlines the longevity of GuptiMiner operations.
Similarly to the WMI events, GuptiMiner also drops a clean binary for sideloading at this location: C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe
The malicious PNG loader is then placed in one (or both) of these locations: C:\Program Files (x86)\Brother\Brmfl14c\BrLogAPI.dll C:\Program Files\Brother\Brmfl14c\BrLogAPI.dll
The scheduled task is created by invoking a Task Scheduler. The scheduled task has these characteristics:
It is created and named as C:\Windows\System32\Tasks\Microsoft\Windows\Brother\Brmfl14c
Let’s now look at how all these files, clean and malicious, are being deployed. One of GuptiMiner’s tricks is that it drops the final payload, containing PNG loader stage, only during the system shutdown process. Thus, this happens at the time other applications are shutting down and potentially not protecting the user anymore.
From the code above, we can observe that only when the SM_SHUTTINGDOWN metric is non-zero, meaning the current session is shutting down, as well as all the supporting clean files were dropped successfully, the final payload DLL is dropped as well.
An engaged reader could also notice in the code above that the first function that is being called disables Windows Defender. This is done by standard means of modifying registry keys. Only if the Defender is disabled can the malware proceed with the malicious actions.
Adding Certificates to Windows
Most of the time, GuptiMiner uses self-signed binaries for their malicious activities. However, this time around, the attackers went a step further. In this case, both of the dropped PNG loader DLLs are signed with a custom trusted root anchor certification authority. This means that the signature is inherently untrusted since the attackers’ certification authority cannot be trusted by common verification processes in Windows.
However, during the malware installation, GuptiMiner also adds a root certificate to Windows’ certificate store making this certification authority trusted. Thus, when such a signed file is executed, it is understood as correctly signed. This is done by using CertCreateCertificateContext, CertOpenStore, and CertAddCertificateContextToStore API functions.
The certificate is present in a plaintext form directly in the GuptiMiner binary file.
During our research, we found three different certificate issuers used during the GuptiMiner operations:
GTE Class 3 Certificate Authority
VeriSign Class 3 Code Signing 2010
DigiCert Assured ID Code Signing CA
Note that these names are artificial and any resemblance to legitimate certification authorities shall be considered coincidental.
At later development stages, authors behind GuptiMiner started to integrate even better persistence of their payloads by storing the payloads in registry keys. Furthermore, the payloads were also encrypted by XOR using a fixed key. This ensures that the payloads look meaningless to the naked eye.
We’ve discovered these registry key locations to be utilized for storing the payloads so far:
When the entry point of the PE file is executed by the shellcode from Stage 0, the malware first creates a scheduled task to attempt to perform cleanup of the initial infection by removing updll62.dlz archive and version.dll library from the system.
Furthermore, the PE serves as a dropper for additional stages by contacting an attacker’s malicious DNS server. This is done by sending a DNS request to the attacker’s DNS server, obtaining the TXT record with the response. The TXT response holds an encrypted URL domain of a real C&C server that should be requested for an additional payload. This payload is a valid PNG image file (a T-Mobile logo) which also holds a shellcode appended to its end. The shellcode is afterwards executed by the malware in a separate thread, providing further malware functionality as a next stage.
Note that since the DNS server itself is malicious, the requested domain name doesn’t really matter – or, in a more abstract way of thinking about this functionality, it can be rather viewed as a “password” which is passed to the server, deciding whether the DNS server should or shouldn’t provide the desired TXT answer carrying the instructions.
As we already mentioned in the Domains timeline section, there are multiple of such “Requested domains” used. In the version referenced here, we can see these two being used:
ext.peepzo[.]com
crl.peepzo[.]com
and the malicious DNS server address is in this case:
ns1.peepzo[.]com
Here we can see a captured DNS TXT response using Wireshark. Note that Transaction ID = 0x034b was left unchanged during all the years of GuptiMiner operations. We find this interesting because we would expect this could get easily flagged by firewalls or EDRs in the affected network.
The requests when the malware is performing the queries is done in random intervals. The initial request for the DNS TXT record is performed in the first 20 minutes after the PNG loader is executed. The consecutive requests, which are done for the malware’s update routine, wait up to 69 hours between attempts.
This update mechanism is reflected by creating separate mutexes with the shellcode version number which is denoted by the first two bytes of the decrypted DNS TXT response (see below for the decryption process). This ensures that no shellcode with the same version is run twice on the system.
DNS TXT Record Decryption
After the DNS TXT record is received, GuptiMiner decodes the content using base64 and decrypts it with a combination of MD5 used as a key derivation function and the RC2 cipher for the decryption. Note that in the later versions of this malware, the authors improved the decryption process by also using checksums and additional decryption keys.
For the key derivation function and the decryption process, the authors decided to use standard Windows CryptoAPI functions.
Interestingly, a keen eye can observe an oversight in this initialization process shown above, particularly in the CryptHashData function. The prototype of the CryptHashData API function is:
The second argument of this function is a pointer to an array of bytes of a length of dwDataLen. However, this malware provides the string L"POVO@1" in a Unicode (UTF-16) format, represented by the array of bytes *pbData.
Thus, the first six bytes from this array are only db 'P', 0, 'O', 0, 'V', 0 which effectively cuts the key in half and padding it with zeroes. Even though the malware authors changed the decryption key throughout the years, they never fixed this oversight, and it is still present in the latest version of GuptiMiner.
DNS TXT Record Parsing
At this point, we would like to demonstrate the decrypted TXT record and how to parse it. In this example, while accessing the attacker’s malicious DNS server ns.srnmicro[.]net and the requested domain spf.microsoft[.]com, the server returned this DNS TXT response:
After fully decoding and decrypting this string, we get:
This result contains multiple fields and can be interpreted as:
Name
Value
Version 1
1
Version 2
5
Key size
\r (= 0xD)
Key
Microsoft.com
C&C URL
http://www.deanmiller[.]net/m/
Checksum
\xde
The first two bytes, Version 1 and Version 2, form the PNG shellcode version. It is not clear why there are two such versions since Version 2 is actually never used in the program. Only Version 1 is considered whether to perform the update – i.e., whether to download and load the PNG shellcode or not. In either case, we could look at these numbers as a major version and a minor version, and only the major releases serve as a trigger for the update process.
The third byte is a key size that denotes how many bytes should be read afterwards, forming the key. Furthermore, no additional delimiter is needed between the key and the URL since the key size is known and the URL follows. Finally, the two-byte checksum can be verified by calculating a sum of all the bytes (modulo 0xFF).
After the DNS TXT record is decoded and decrypted, the malware downloads the next stage, from the provided URL, in the form of a PNG file. This is done by using standard WinINet Windows API, where the User-Agent is set to contain the bitness of the currently running process.
The C&C server uses the User-Agent information for two things:
Provides the next stage (a shellcode) in the correct bitness
Filters any HTTP request that doesn’t contain this information as a protection mechanism
Parsing the PNG File
After the downloaded file is a valid PNG file which also contains a shellcode appended at the end. The image is a T-Mobile logo and has exactly 805 bytes. These bytes are skipped by the malware and the rest of the file, starting at an offset 0x325, is decrypted by RC2 using the key provided in the TXT response (derived using MD5). The reason of using an image as this “prefix” is to further obfuscate the network communication where the payload looks like a legitimate image, likely overlooking the appended malware code.
After the shellcode is loaded from the position 0x325, it proceeds with loading additional PE loader from memory to unpack next stages using Gzip.
In late 2023, the authors decided to ditch the years-long approach of using DNS TXT records for distributing payloads and they switched to IP address masking instead.
This new approach consists of a few steps:
Obtain an IP address of a hardcoded server name registered to the attacker by standard means of using gethostbyname API function
For that server, two IP addresses are returned – the first is an IP address which is a masked address, and the second one denotes an available payload version and starts with 23.195. as the first two octets
If the version is newer than the current one, the masked IP address is de-masked and results in a real C&C IP address
The real C&C IP address is used along with a hardcoded constant string (used in a URL path) to download the PNG file containing the shellcode
The de-masking process is done by XORing each octet of the IP address by 0xA, 0xB, 0xC, 0xD, respectively. The result is then taken, and a hardcoded constant string is added to the URL path.
As an example, one such server we observed was www.elimpacific[.]net. It was, at the time, returning:
The address 23.195.101[.]1 denotes a version and if it is greater than the current version, it performs the update by downloading the PNG file with the shellcode. This update is downloaded by requesting a PNG file from the real C&C server whose address is calculated by de-masking the 179.38.204[.]38 address:
The request is then made, along with the calculated IP address 185.45.192[.]43 and a hardcoded constant elimp. Using a constant like this serves as an additional password, in a sense: 185.45.192[.]43/elimp/
When the PNG file is downloaded, the rest of the process is the same as usual.
We’ve discovered two servers for this functionality so far:
Along with other updates described above, we also observed an evolution in using anti-VM and anti-debugging tricks. These are done by checking well known disk drivers, registry keys, and running processes.
GuptiMiner checks for these disk drivers by enumerating HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Disk\Enum:
vmware
qemu
vbox
virtualhd
Specifically, the malware also checks the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Cylance for the presence of Cylance AV.
As other anti-VM measures, the malware also checks whether the system has more than 4GB available RAM and at least 4 CPU cores.
Last but not least, the malware also checks the presence of these processes by their prefixes:
Similarly to Storing Payloads in Registry, in later stages of GuptiMiner, the authors also started to save the downloaded PNG images (containing the shellcodes) into registry as well. Contrary to storing the payloads, the images are not additionally XORed since the shellcodes in them are already encrypted using RC2 (see DNS TXT Record Decryption section for details).
We’ve discovered these registry key locations to be utilized for storing the encrypted images containing the shellcodes so far:
This stage is the shortest, the Gzip loader, which is extracted and executed by the shellcode from the PNG file, is a simple PE that decompresses another shellcode using Gzip and executes it in a separate thread.
This thread additionally loads Stage 3, which we call Puppeteer, that orchestrates the core functionality of the malware – the cryptocurrency mining as well as, when applicable, deploying backdoors on the infected systems.
Throughout the GuptiMiner operations, Gzip loader has not been changed with later versions.
Let’s now look at the biggest Stage 3, the Puppeteer. It pulls its strings everywhere across the infected system, manipulating the GuptiMiner components to do its bidding, hence the name we’ve chosen. It orchestrates further actions and deploys two core components of the malware – an XMRig coinminer and two types of backdoors that target devices present in large corporate networks. Of course, Puppeteer also introduces additional tricks to the arsenal of the whole GuptiMiner operation.
This stage also uses one of the many Global\SLDV mutexes which we described in the Mutex timeline. For example, this particular sample uses SLDV01 as its mutex.
Puppeteer Setup
Puppeteer performs several steps for a proper setup. Firstly, it adds a new power scheme in Windows so the PC does not go to sleep. If the CPU has only one core (anti-VM) or the mutex already exists, the malware ceases to function by going to infinite sleep.
In the next phase, the malware kills all the processes with a name msiexec.exe, cmstp.exe, or credwiz.exe. After that, it creates a separate thread that injects XMRig into a credwiz.exe process freshly created by the malware. The malware also disables Windows Defender by setting its service start status to disabled.
For the persistence, Puppeteer chose an interesting approach. Firstly, it creates a scheduled task with the following configuration:
A legitimate rundll32.exe file is copied and renamed into C:\ProgramData\Microsoft\Crypto\Escan\dss.exe and this file is executed from the scheduled task
The malicious DLL is placed to C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 and this file is loaded by dss.exe (exported function ValidateFile)
The task is executed with every boot (TASK_TRIGGER_BOOT) and TASK_RUNLEVEL_HIGHEST priority
The task is named and located at C:\Windows\system32\tasks\Microsoft\windows\autochk\ESUpgrade
With that, the malware copies the content of updll3.dll3 into memory and deletes the original file from disk. Puppeteer then waits for a system shutdown (similarly to Stage 0.9) by waiting for SM_SHUTTINGDOWN metric to be set to non-zero value, indicating the shutdown. This is checked every 100 milliseconds. Only when the shutdown of the system is initiated, the malware reintroduces the updll3.dll3 file back onto disk.
Putting the malicious DLL back just before the system restart is really sneaky but also has potentially negative consequences. If the victim’s device encounters a crash, power outage, or any other kind of unexpected shutdown, the file won’t be restored from memory and Puppeteer will stop working from this point. Perhaps this is the reason why authors actually removed this trick in later versions, trading the sophistication for malware’s stability.
The repetitive loading of updll3.dll3, as seen in the code above, is in fact Puppeteer’s update process. The DLL will ultimately perform steps of requesting a new PNG shellcode from the C&C servers and if it is a new version, the chain will be updated.
XMRig Deployment
During the setup, Puppeteer created a separate thread for injecting an XMRig coinminer into credwiz.exe process. Before the injection takes place, however, a few preparation steps are performed.
The XMRig configuration is present directly in the XMRig binary (standard JSON config) stored in the Puppeteer binary. This configuration can be, however, modified to different values on the fly. In the example below, we can see a dynamic allocation of mining threads depending on the robustness of the infected system’s hardware.
The injection is standard: the malware creates a new suspended process of credwiz.exe and, if successful, the coinmining is injected and executed by WriteProcessMemory and CreateRemoteThread combo.
Puppeteer continuously monitors the system for running process, by default every 5 seconds. If it encounters any of the monitoring tools below, the malware kills any existing mining by taking down the whole credwiz.exe process as well as it applies a progressive sleep, postponing another re-injection attempt by additional 5 hours.
taskmgr.exe
autoruns.exe
wireshark.exe
wireshark-gtk.exe
tcpview.exe
Furthermore, the malware needs to locate the current updll3.dll3 on the system so its latest version can be stored in memory, removed from disk, and dropped just before another system restart. Two approaches are used to achieve this:
Reading eScan folder location from HKEY_LOCAL_MACHINE\SOFTWARE\AVC3
If one of the checked processes is called download.exe, which is a legitimate eScan binary, it obtains the file location to discover the folder. The output can look like this:
The check for download.exe serves as an alternative for locating eScan installation folder and the code seems heavily inspired by the example code of Obtaining a File Name From a File handle on MSDN.
Finally, Puppeteer also continuously monitors the CPU usage on the system and tweaks the core allocation in such a way it is not that much resource heavy and stays under the radar.
The backdoor is set up by the previous stage, Puppeteer, by first discovering whether the machine is operating on a Windows Server or not. This is done by checking a DNS Server registry key (DNS Server service is typically running on a Windows Server edition): SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server
After that, the malware runs a command to check and get a number of computers joined in a domain: net group “domain computers” /domain
The data printed by the net group command typically uses 25 characters per domain joined computer plus a newline (CR+LF) per every three computers, which can be illustrated by the example below:
In this version of the backdoor setup, Puppeteer checks whether the number of returned bytes is more than 100. If so, Puppeteer assumes it runs in a network shared with at least five computers and downloads additional payloads from a hardcoded C&C (https://m.airequipment[.]net/gpse/) and executes it using PowerShell command.
Note that the threshold for the number of returned bytes was different and significantly higher in later versions of GuptiMiner, as can be seen in a dedicated section discussing Modular Backdoor, resulting in compromising only those networks which had more than 7000 computers joined in the same domain!
If the checks above pass, Puppeteer uses a PowerShell command for downloading and executing the payload and, interestingly, it is run both in the current process as well as injected in explorer.exe.
Furthermore, regardless of whether the infected computer is present in a network of a certain size or not, it tries to download additional payload from dl.sneakerhost[.]com/u as well. This payload is yet another PNG file with the appended shellcode. We know this because the code uses the exact same parsing from the specific offset 0x325 of the PNG file as described in Stage 1. However, during our analysis, this domain was already taken down and we couldn’t verify what kind of payload was being distributed here.
The Puppeteer’s backdoor setup process was improved and tweaked multiple times during its long development. In the upcoming subsections, we will focus on more important changes, mostly those which influence other parts of the malware or present a whole new functionality.
Later Puppeteer Versions
In later versions, the attackers switched to the datetime mutex paradigm (as illustrated in Mutexes in Time section) and also introduced additional process monitoring of more Sysinternals tools like Process explorer, Process monitor, as well as other tools like OllyDbg, WinDbg, and TeamViewer.
Additionally, the GuptiMiner authors also started to modify pool addresses in XMRig configurations with a new approach. They started using subdomains by “r” and “m” depending on the available physical memory on the infected system. If there is at least 3 GB of RAM available, the malware uses: m.domain.tld with auto mode and enabled huge pages.
If the available RAM is lesser than 3 GB, it uses: r.domain.tld with light mode and disabled huge pages.
In order to not keep things simple, the authors later also started to use “p” as a subdomain in some versions, without any specific reason for the naming convention (perhaps just to say it is a “pool”).
The usage of all such domains in time can be seen in the Domains timeline.
Variety in Used DLLs
Puppeteer used many different names and locations of DLLs over the years for sideloading or directly loading using scheduled tasks. For example, these might be:
We’ve also seen “cleaner” Puppeteers, meaning they didn’t contain the setup process for backdoors, but they were able to delete the malicious DLLs from the system when a running monitoring tool was detected.
In this particular version, the deployment of the backdoor was performed once every 3 months, indicating a per-quarter deployment.
Stage 4 – Backdoor
Since no one who puts such an effort into a malware campaign deploys just coinminers on the infected devices, let’s dig deeper into additional sets of GuptiMiner’s functionalities – deploying two types of backdoors on the infected devices.
One of the backdoors deployed by GuptiMiner is based on a custom build of PuTTY Link (plink). This build contains an enhancement for local SMB network scanning, and it ultimately enables lateral movement over the network to potentially exploit Windows 7 and Windows Server 2008 machines by tunneling SMB traffic through the victim’s infected device.
Local SMB Scanning
First, the plink binary is injected into netsh.exe process by Puppeteer with the Deploy per-quarter approach. After a successful injection, the malware discovers local IP ranges by reading the IP tables from the victim’s device, adding those into local and global IP range lists.
With that, the malware continues with the local SMB scanning over the obtained IP ranges: xx.yy.zz.1-254. When a device supporting SMB is discovered, it is saved in a dedicated list. The same goes with IPs that don’t support SMB, effectively deny listing them from future actions. This deny list is saved in specific registry subkeys named Sem and Init, in this location: HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\CMF\Class where Init contains the found IP addresses and Sem contains their total count.
There are conditions taking place when such a scan is performed. For example, the scan can happen only when it is a day in the week (!), per-quarter deployment, and only at times between 12 PM and 18 PM. Here, we denoted by (!) a unique coding artefact in the condition, since checking the day of the week is not necessary (always true).
Finally, the malware also creates a new registry key HKEY_LOCAL_MACHINE\SYSTEM\RNG\FFFF three hours after a successful scan. This serves as a flag that the scanning should be finished, and no more scanning is needed.
An even more interesting datetime-related bug can be seen in a conditioning of RNG\FFFF registry removal. The removal is done to indicate that the malware can perform another SMB scan after a certain period of time.
As we can see in the figure below, the malware obtains the write time of the registry key and the current system time by SystemTimeToVariantTime API function and subtracts those. The subtraction result is a floating-point number where the integral part means number of days.
Furthermore, the malware uses a constant 60*60*60*24=5184000 seconds (60 days) in the condition for the registry key removal. However, the condition is comparing VariantTime (days) with seconds. Thus, the backdoor can activate every 51.84 days instead of the (intended?) 60 days. A true blessing in disguise.
Lateral Movement Over SMB Traffic
After the local SMB scan is finished, the malware checks from the received SMB packet results whether any of the IP addresses that responded are running Windows 7 or Windows Server 2008. If any such a system is found on the local network, the malware adds these IP addresses to a list of potential targets.
Furthermore, GuptiMiner executes the main() legacy function from plink with artificial parameters. This will create a tunnel on the port 445 between the attacker’s server gesucht[.]net and the victim’s device.
This tunnel is used for sending SMB traffic through the victim’s device to the IP addresses from the target list, enabling lateral movement over the local network.
Note that this version of Puppeteer, deploying this backdoor, is from 2021. We also mentioned that only Windows 7 and Windows Server 2008 are targeted, which are rather old. We think this might be because the attackers try to deploy an exploit for possible vulnerabilities on these old systems.
To orchestrate the SMB communication, the backdoor hand-crafts SMB packets on the fly by modifying TID and UID fields to reflect previous SMB communication. As shown in the decompiled code below, the SMB packet 4, which is crafted and sent by the malware, contains both TID and UID from the responses of the local network device.
Here we provide an example how the SMB packets look like in Wireshark when sent by the malware. After the connection is established, the malware tries to login as anonymous and makes requests for \IPC$ and a named pipe.
Interested reader can find the captured PCAP on our GitHub.
Another backdoor that we’ve found during our research being distributed by Puppeteer is a modular backdoor which targets huge corporate networks. It consists of two phases – the malware scans the devices for the existence of locally stored private keys and cryptocurrency wallets, and the second part is an injected modular backdoor, in the form of a shellcode.
Checks on Private Keys, Wallets, and Corporate Network
This part of the backdoor focuses on scanning for private keys and wallet files on the system. This is done by searching for .pvk and .wallet files in these locations:
C:\Users\*
D:\*
E:\*
F:\*
G:\*
If there is such a file found in the system, its path is logged in a newly created file C:\Users\Public\Ca.txt. Interestingly, this file is not processed on its own by the code we have available. We suppose the data will be stolen later when further modules are downloaded by the backdoor.
The fact that the scan was performed is marked by creating a registry key: HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\DECLAG
If some private keys or wallets were found on the system or the malware is running in a huge corporate environment, the malware proceeds with injecting the backdoor, in a form of a shellcode, into the mmc.exe process.
The size of the corporate environment is guessed by the same approach as Puppeteer’s backdoor setup with the difference in the scale. Here, the malware compares the returned list of computers in the domain with 200,000 characters. To recapitulate, the data printed by the net group command uses 25 characters per domain joined computer plus a newline (CR+LF) per every three computers.
This effectively means that the network in which the malware operates must have at least 7781 computers joined in the domain, which is quite a large number.
This shellcode is a completely different piece of code than what we’ve seen so far across GuptiMiner campaign. It is designed to be multi-modular with the capability of adding more modules into the execution flow. Only a networking communication module, however, is hardcoded and available by default, and its hash is 74d7f1af69fb706e87ff0116b8e4fa3a9b87275505e2ee7a32a8628a2d066549 (2022-12-19 07:31:39 UTC).
After the injection, the backdoor decrypts a hardcoded configuration and a hardcoded networking module using RC4. The RC4 key is also hardcoded and available directly in the shellcode.
The configuration contains details about which server to contact, what ports to use, the length of delays that should be set between commands/requests, among others. The domain for communication in this configuration is www.righttrak[.]net:443 and an IP address 185.248.160[.]141.
The network module contains seven different commands that the attacker can use for instructing the backdoor about what to do. A complete list of commands accepted by the network module can be found in the table below. Note that each module that can be used by the backdoor contains such a command handler on its own.
Command
Description
3.0
Connect
3.1
Read socket
3.2
Write socket
3.3
Close socket
4
Close everything
6
Return 1
12
Load configuration
The modules are stored in an encrypted form in the registry, ensuring their persistence: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCB
The backdoor also uses an import by hash obfuscation for resolving API functions. The hashing function is a simple algorithm that takes each byte of the exported function name, adds 1 to it, and then multiplies the previously calculated number (calculated_hash, starts with 0) by 131 and adds it to the byte:
The server www.righttrak[.]net:443 had, at the time, a valid certificate. Note for example the not-at-all-suspicious email address the authors used.
During our research, we have also found a 7zip SFX executable containing two files:
ms00.dat
notepad.exe
notepad.exe is a small binary that decrypts ms00.dat file using RC4 with a key V#@!1vw32. The decrypted ms00.dat file is the same Modular Backdoor malware as described above.
However, we have not seen this SFX executable being distributed by GuptiMiner. This indicates that this backdoor might be distributed by different infection vectors as well.
Related and Future Research
We’ve also observed other more or less related samples during our research.
PowerShell Scripts
Interestingly, we’ve found the C&C domain from the backdoor setup phase (in Puppeteer) in additional scripts as well which were not distributed by traditional GuptiMiner operation as we know it. We think this might be a different kind of attack sharing the GuptiMiner infrastructure, though it might be a different campaign. Formatted PowerShell script can be found below:
In this case, the payload is downloaded and executed from the malicious domain only when an antivirus is installed, and its name has more than 4 letters and starts with eS. One does not have to be a scrabble champion to figure out that the malware authors are targeting the eScan AV once again. The malicious code is also run when the name of the installed AV has less than 5 letters.
We’ve found this script being run via a scheduled task with a used command: "cmd.exe" /c type "\<domain>\SYSVOL\<domain>\scripts\gpon.inc" | "\<domain>\SYSVOL\<domain>\scripts\powAMD64.dat" -nop - where powAMD64.dat is a copy of powershell.exe. The task name and location was C:\Windows\System32\Tasks\ScheduledDefrag
Usage of Stolen Certificates
We have found two stolen certificates used for signing GuptiMiner payloads. Interestingly, one of the used stolen certificates originates in Winnti operations. In this particular sample, the digital signature has a hash: 529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56
This certificate is the same as mentioned by Kaspersky more than 10 years ago. However, we’ve also seen this certificate to be used in multiple malware samples than just GuptiMiner, though, indicating a broader leak.
A complete list of stolen certificates and their usage can be found in the table below:
During our research, we’ve also found an information stealer which holds a rather similar PDB path as was used across the whole GuptiMiner campaign (MainWork): F:\!PROTECT\Real\startW-2008\MainWork\Release\MainWork.pdb
However, we haven’t seen it distributed by GuptiMiner and, according to our data, it doesn’t belong to the same operation and infection chain. This malware performs stealing activities like capturing every keystroke, harvesting HTML forms from opened browser tabs, noting times of opened programs, etc., and stores them in log files.
What is truly interesting, however, is that this information stealer might come from Kimsuky operations. Also known as Black Banshee, among other aliases, Kimsuky is a North Korean state-backed APT group.
It contains the similar approach of searching for AhnLab real-time detection window class name 49B46336-BA4D-4905-9824-D282F05F6576 as mentioned by both AhnLab as well as Cisco Talos Intelligence in their Information-gathering module section. If such a window is found, it will be terminated/hidden from the view of the infected user.
Furthermore, the stealer contains an encrypted payload in resources, having a hash: d5bc6cf988c6d3c60e71195d8a5c2f7525f633bb54059688ad8cfa1d4b72aa6c (2021-02-19 19.02.2021 15:00:47 UTC) and it has this PDB path: F:\PROTECT\Real\startW-2008\HTTPPro\Release\HTTPPro.pdb
This module is decrypted using the standard RC4 algorithm with the key messi.com. The module is used for downloading additional stages. One of the used URLs are: http://stwu.mygamesonline[.]org/home/sel.php http://stwu.mygamesonline[.]org/home/buy.php?filename=%s&key=%s
The domain mygamesonline[.]org is commonly used by Kimsuky (with variety of subdomains).
The keylogger also downloads next stage called ms12.acm:
With this, we see a possible pattern with the naming convention and a link to Modular Backdoor. As described in the Other Infection Vectors section, the 7z SFX archive contains an encrypted file called ms00.dat with which we struggle to ignore the resemblance.
Last but not least, another strong indicator for a possible attribution is the fact that the Kimsuky keylogger sample dddc57299857e6ecb2b80cbab2ae6f1978e89c4bfe664c7607129b0fc8db8b1f, which is mentioned in the same blogpost from Talos, contains a section called .vlizer, as seen below:
During the GuptiMiner installation process (Stage 0), we wrote about the threat actors introducing Code Virtualization in 2018. This was done by using a dedicated section called .v_lizer.
Conclusion
In this analysis, we described our findings regarding a long-standing threat we called GuptiMiner, in detail. This sophisticated operation has been performing MitM attacks targeting an update mechanism of the eScan antivirus vendor. We disclosed the security vulnerability to both eScan and the India CERT and received confirmation on 2023-07-31 from eScan that the issue was fixed and successfully resolved.
During the GuptiMiner operation, the attackers were deploying a wide chain of stages and functionalities, including performing DNS requests to the attacker’s DNS servers, sideloading, extracting payloads from innocent-looking images, signing its payloads with a custom trusted root anchor certification authority, among others.
Two different types of backdoors were discovered, targeting large corporate networks. The first provided SMB scanning of the local network, enabling lateral movement over the network to potentially exploit vulnerable Windows 7 and Windows Server 2008 systems on the network. The second backdoor is multi-modular, accepting commands on background to install more modules as well as focusing on stealing stored private keys and cryptowallets.
Interestingly, the final payload distributed by GuptiMiner was also XMRig which is a bit unexpected for such a thought-through operation.
We have also found possible ties to Kimsuky, a notorious North Korean APT group, while observing similarities between Kimsuky keylogger and fragments discovered during the analysis of the GuptiMiner operation.
eScan follow-up
We have shared our findings and our research with eScan prior to publishing this analysis. For the sake of completeness, we are including their statement on this topic:
“I would also like to highlight some key points: 1. Our records indicate that the last similar report was received towards the end of the year 2019. 2. Since 2020, we have implemented a stringent checking mechanism that utilizes EV Signing to ensure that non-signed binaries are rejected. 3. Multiple heuristic rules have been integrated into our solution to detect and block any instances of legitimate processes being used for mining, including the forking of unsigned binaries. 4. While our internal investigations did not uncover instances of the XRig miner, it is possible that this may be due to geo-location factors. 5. Our latest solution versions employ secure (https) downloads, ensuring encrypted communication when clients interact with our cloud-facing servers for update downloads.”
According to our telemetry, we continue to observe new infections and GuptiMiner builds within our userbase. This may be attributable to eScan clients on these devices not being updated properly.
Indicators of Compromise (IoCs)
In this section, we would like to summarize the Indicators of Compromise mentioned in this analysis. As they are indicators, it doesn’t automatically mean the mentioned files and/or domains are malicious on their own.
For more detailed list of IoCs of the whole GuptiMiner campaign, please visit our GitHub.