Normal view

There are new articles available, click to refresh the page.
Before yesterdayAvast Threat Labs

GuptiMiner: Hijacking Antivirus Updates for Distributing Backdoors and Casual Mining

23 April 2024 at 09:00

Key Points

  • 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.

GuptiMiner’s infection chain

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.

Timeline illustrating GuptiMiner’s usage of domains in time

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. 

Timeline illustrating GuptiMiner’s usage of mutexes in time

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. 

Timeline illustrating PDBs contained in GuptiMiner in time

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. 

Update Package

c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3
(version.dll, 2018-04-19 09:47:41 UTC)

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: 

  1. The eScan updater triggers the update 
  2. The downloaded package file is replaced with a malicious one on the wire because of a missing HTTPS encryption (MitM is performed) 
  3. A malicious package updll62.dlz is downloaded and unpacked by eScan updater 
  4. 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 
  5. 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 
  6. 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.

Additional exported functions

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. 

Heaven’s gate to run the shellcode in x64 environment when required

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. 

Resolving function that ensures all the original version.dll exports are available

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. 

Embedded PE file loaded by the shellcode

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. 

Command line manipulation function

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

Code Virtualization 

7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6
(version.dll, 2018-06-12 03:30:01) 

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.

A new section with the virtualized code is called .v_lizer

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.

Stage 0.9 – Installation Improvements

3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c
(2021-03-28 14:41:07 UTC) 

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): 

  • de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739 *atiadlxx.dll 
  • e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee *BrLogAPI.dll 

WMI Events 

de48abe380bd84b5dc940743ad6727d0372f602a8871a4a0ae2a53b15e1b1739
(atiadlxx.dll, 2021-03-28 14:30:11 UTC) 

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:

WMI conditions to trigger sideloading

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.

Scheduled Tasks

e0dd8af1b70f47374b0714e3b368e20dbcfa45c6fe8f4a2e72314f4cd3ef16ee
(BrLogAPI.dll, 2021-03-28 14:10:27 UTC)

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 
  • Executes: C:\ProgramData\Brother\Brmfl14c\BrRemPnP.exe 
  • The execution is done under a folder containing the to-be-sideloaded DLL, e.g.: C:\Program Files (x86)\Brother\Brmfl14c\ 
  • The execution is performed with every boot (TASK_TRIGGER_BOOT) with SYSTEM privileges 

Deploy During Shutdown

3515113e7127dc41fb34c447f35c143f1b33fd70913034742e44ee7a9dc5cc4c
(2021-03-28 14:41:07 UTC)

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.

The main flow of the Stage 0.9 variant – drops final payload during system shutdown

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.

Function which adds GuptiMiner’s root certificate to Windows

The certificate is present in a plaintext form directly in the GuptiMiner binary file.

A certificate in the plaintext form which is added as root to Windows by the malware

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. 

Storing Payloads in Registry 

8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049
(upgradeshow.dll, 2023-11-23 16:41:34 UTC) 

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: 

  • SYSTEM\CurrentControlSet\Control\Nls\Sorting\Ids\en-US 
  • SYSTEM\CurrentControlSet\Control\PnP\Pci\CardList 
  • SYSTEM\CurrentControlSet\Control\Wdf\DMCF 
  • SYSTEM\CurrentControlSet\Control\StorVSP\Parsers 

Stage 1 – PNG Loader 

ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297
(2018-04-19 09:45:25 UTC) 

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.

DNS TXT response captured by Wireshark

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. 

Mutex is numbered by the shellcode’s version information

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.

Typical use of 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:

BOOL CryptHashData(
  [in] HCRYPTHASH hHash,
  [in] const BYTE *pbData,
  [in] DWORD      dwDataLen,
  [in] DWORD      dwFlags
); 

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: 

VUBw2mOgagCILdD3qWwVMQFPUd0dPHO3MS/CwpL2bVESh9OnF/Pgs6mHPLktvph2

After fully decoding and decrypting this string, we get: 

This result contains multiple fields and can be interpreted as: 

Name Value 
Version 1 
Version 2 
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 malware communicates the bitness of the running process to the C&C

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. 

PNG file containing the shellcode starting at 0x325

After the shellcode is loaded from the position 0x325, it proceeds with loading additional PE loader from memory to unpack next stages using Gzip. 

IP Address Masking

294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a
(2023-11-09 14:19:45 UTC) 

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: 

  1. Obtain an IP address of a hardcoded server name registered to the attacker by standard means of using gethostbyname API function 
  2. 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 
  3. 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 
  4. 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/ 

GuptiMiner is requesting the payload from a real IP address

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: 

Queried server URL path constant 
www.elimpacific[.]net elimp 
www.espcomp[.]net OpenSans 

Anti-VM and Anti-debug Tricks 

294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a
(2023-11-09 14:19:45 UTC) 

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: 

Process name prefix Tool name 
wireshar Wireshark 
windbg. WinDbg 
tcpview TCPView 
360 360 Total Security 
hips Huorong Internet Security (hipsdaemon.exe
proce Process Explorer 
procm Process Monitor 
ollydbg OllyDbg 

Storing Images in Registry

6305d66aac77098107e3aa6d85af1c2e3fc2bb1f639e4a9da619c8409104c414
(2023-02-22 14:03:04 UTC) 

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: 

  • SYSTEM\CurrentControlSet\Control\Arbiters\Class 
  • SYSTEM\CurrentControlSet\Control\CMF\Class 
  • SYSTEM\CurrentControlSet\Control\CMF\CORE 
  • SYSTEM\CurrentControlSet\Control\CMF\DEF 
  • SYSTEM\CurrentControlSet\Control\CMF\Els 
  • SYSTEM\CurrentControlSet\Control\CMF\ASN 
  • SYSTEM\CurrentControlSet\Control\MSDTC\BSR 

Stage 2 – Gzip Loader 

357009a70daacfc3379560286a134b89e1874ab930d84edb2d3ba418f7ad6a0b
(2019-04-02 07:30:21 UTC) 

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. 

Stage 3 – Puppeteer

364984e8d62eb42fd880755a296bd4a93cc071b9705c1f1b43e4c19dd84adc65
(2019-03-15 10:07:36 UTC) 

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.

A code ensuring the correct after-reboot execution

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. 

Patching the XMRig configuration on the fly, dynamically assigning mining threads

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: 
    • \Device\HarddiskVolume1\Program Files (x86)\eScan\download.exe 

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. 

Backdoor Setup

4dfd082eee771b7801b2ddcea9680457f76d4888c64bb0b45d4ea616f0a47f21
(2019-06-29 03:38:24 UTC) 

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: 

Example output of net group command

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. 

Pool Configuration

487624b44b43dacb45fd93d03e25c9f6d919eaa6f01e365bb71897a385919ddd
(2023-11-21 18:05:43 UTC) 

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: 

  • C:\Program Files (x86)\eScan\updll3.dll3 
  • C:\Program Files\Common Files\SYSTEM\SysResetErr\SysResetErr.DLL 
  • C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellChecking.DLL 
  • C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellCheckingHost.DLL 
  • C:\ProgramData\AMD\CNext\atiadlxx.dll 
  • C:\ProgramData\Microsoft\Assistance\LunarG\vulkan-1.dll 
  • C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll 
  • C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3 
  • C:\ProgramData\Microsoft\Network\Escan\AutoWake.dll 

Puppeteer Cleanup 

1c31d06cbdf961867ec788288b74bee0db7f07a75ae06d45d30355c0bc7b09fe
(2020-03-09 00:57:11 UTC)

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. 

Deploy Per-Quarter 

1fbc562b08637a111464ba182cd22b1286a185f7cfba143505b99b07313c97a4
(2021-03-01 10:43:27 UTC) 

In this particular version, the deployment of the backdoor was performed once every 3 months, indicating a per-quarter deployment.

The deployment happens at March, June, September, and December

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.

PuTTY Backdoor 

07beca60c0a50520b8dbc0b8cc2d56614dd48fef0466f846a0a03afbfc42349d
(2021-03-01 10:31:33 UTC)

E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb

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). 

Questionable conditioning for SMB scanning

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. 

Removal of RNG\FFFF key, deploying the backdoor after 51.84 days

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. 

Parameters used for plink main() function

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. 

The backdoor hand-crafts SMB packets on the fly

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.

SMB traffic captured by Wireshark

Interested reader can find the captured PCAP on our GitHub.

Modular Backdoor 

f0ccfcb5d49d08e9e66b67bb3fedc476fdf5476a432306e78ddaaba4f8e3bbc4
(2023-10-10 15:08:36 UTC) 

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. 

Example output of net group command

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.

Backdoor

8446d4fc1310b31238f9a610cd25ea832925a25e758b9a41eea66f998163bb34 

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.

Decrypted network module configuration

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 
Close everything 
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. 

Certificate on www.righttrak[.]net:443 as shown by Censys

Other Infection Vectors of Modular Backdoor

af9f1331ac671d241bf62240aa52389059b4071a0635cb9cb58fa78ab942a33b

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: 

A PowerShell script targeting eScan (formatted)

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: 

Stolen certificate SHA1 Signed GuptiMiner sample 
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 31dfba1b102bbf4092b25e63aae0f27386c480c10191c96c04295cb284f20878 
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049 
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B b0f94d84888dffacbc10bd7f9983b2d681b55d7e932c2d952d47ee606058df54 
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B f656a418fca7c4275f2441840faaeb70947e4f39d3826d6d2e50a3e7b8120e4e 

Possible Ties to Kimsuky 

7f1221c613b9de2da62da613b8b7c9afde2ea026fe6b88198a65c9485ded7b3d
(2021-03-06 20:13:32 UTC) 

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. 

Function that searches and terminates AhnLab’s real-time detection window class

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

The next stage is downloaded with a name 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: 

Kimsuky keylogger sections

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.

Evolution and Timelines 

Domains 

Domain
_spf.microsoft[.]com
acmeautoleasing[.]net
b.guterman[.]net
breedbackfp[.]com
crl.microsoft[.]com
crl.peepzo[.]com
crl.sneakerhost[.]com
desmoinesreg[.]com
dl.sneakerhost[.]com
edgesync[.]net
espcomp[.]net
ext.microsoft[.]com
ext.peepzo[.]com
ext.sneakerhost[.]com
gesucht[.]net
gesucht[.]net
globalsign.microsoft[.]com
icamper[.]net
m.airequipment[.]net
m.cbacontrols[.]com
m.gosoengine[.]com
m.guterman[.]net
m.indpendant[.]com
m.insomniaccinema[.]com
m.korkyt[.]net
m.satchmos[.]net
m.sifraco[.]com
ns.bretzger[.]net
ns.deannacraite[.]com
ns.desmoinesreg[.]com
ns.dreamsoles[.]com
ns.editaccess[.]com
ns.encontacto[.]net
ns.gravelmart[.]net
ns.gridsense[.]net
ns.jetmediauk[.]com
ns.kbdn[.]net
ns.lesagencestv[.]net
ns.penawarkanser[.]net
ns.srnmicro[.]net
ns.suechiLton[.]com
ns.trafomo[.]com
ns.trafomo[.]com
ns1.earthscienceclass[.]com
ns1.peepzo[.]com
ns1.securtelecom[.]com
ns1.sneakerhost[.]com
p.bramco[.]net
p.hashvault[.]pro
r.sifraco[.]com
spf.microsoft[.]com
widgeonhill[.]com
www.bascap[.]net

Mutexes 

Mutex 
ESOCESS_ 
Global\Fri Aug 13 02:17:49 2021 
Global\Fri Aug 13 02:22:55 2021 
Global\Mon Apr 19 06:03:17 2021 
Global\Mon Apr 24 07:19:54 2023 
Global\Mon Feb 27 08:11:25 2023 
Global\Mon Jun 14 03:22:57 2021 
Global\Mon Mar 13 07:29:11 2023 
Global\Mon Mar 22 09:16:00 2021 
Global\Sun Jun 13 08:22:07 2021 
Global\Thu Aug 10 03:25:11 2023 
Global\Thu Aug 12 02:07:58 2021 
Global\Thu Feb 23 08:37:09 2023 
Global\Thu Mar 25 02:03:14 2021 
Global\Thu Mar 25 09:31:19 2021 
Global\Thu Nov  2 08:21:56 2023 
Global\Thu Nov  9 06:19:40 2023 
Global\Tue Apr 25 08:32:05 2023 
Global\Tue Mar 23 02:37:32 2021 
Global\Tue Oct 10 08:07:11 2023 
Global\Wed Aug 11 09:16:37 2021 
Global\Wed Jan  5 09:15:56 2022 
Global\Wed Jun  2 09:43:03 2021 
Global\Wed Mar  1 01:29:48 2023 
Global\Wed Mar 23 08:56:01 2022 
Global\Wed Mar 23 09:06:36 2022 
Global\Wed May 10 06:38:46 2023 
Global1 
GlobalMIVOD_V4 
GMCM1 
MIVOD_6 
MTX_EX01 
Mutex_ONLY_ME_V1 
Mutex_ONLY_ME_V2 
Mutex_ONLY_ME_V3 
PROCESS_ 
SLDV014 
SLDV02 
SLDV024 
SLDV04 
SLDV10 
SLDV11 
SLDV13 
SLDV15 
SLDV17 
SLDV22 
SLDV26 

PDB paths 

PDB path
E:\projects\projects\RunCompressedSC\x64\Release\RunCompressedSC.pdb
E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb
F:\CODE-20221019\Projects\RunCompressedSC\x64\Release\RunCompressedSC.pdb
F:\Pro\MainWork\Release\MainWork.pdb
F:\Pro\MainWork\x64\Release\MainWork.pdb
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-IPHLPAPI\Release\MainWork.pdb
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-IPHLPAPI\x64\Release\MainWork.pdb
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-nvhelper\Release\MainWork.pdb
F:\Projects\2020-NEW\20200307-NEW\MainWork-VS2017-nvhelper\x64\Release\MainWork.pdb
F:\Projects\RunCompressedSC\x64\Release\RunCompressedSC.pdb
F:\V202102\MainWork-VS2017 – Monitor\Release\MainWork.pdb
F:\V202102\MainWork-VS2017 – Monitor\x64\Release\MainWork.pdb
H:\projects\MainWork\Release\MainWork.pdb

Stage 0 – Installation Process 

IoC Note 
http://update3[.]mwti[.]net/pub/update/updll3.dlz  
c3122448ae3b21ac2431d8fd523451ff25de7f6e399ff013d6fa6953a7998fa3 C:\Program Files\eScan\VERSION.DLL 
7a1554fe1c504786402d97edecc10c3aa12bd6b7b7b101cfc7a009ae88dd99c6 updll65.dlz 

Stage 0.9 – Installation Improvements 

Stage 1 – PNG Loader 

IoC Note 
ff884d4c01fccf08a916f1e7168080a2d740a62a774f18e64f377d23923b0297  
ext.peepzo[.]com  
crl.peepzo[.]com  
ns1.peepzo[.]com  
http://www.deanmiller[.]net/m/  
294b73d38b89ce66cfdefa04b1678edf1b74a9b7f50343d9036a5d549ade509a  
185.45.192[.]43/elimp/  
6305d66aac77098107e3aa6d85af1c2e3fc2bb1f639e4a9da619c8409104c414
SYSTEM\CurrentControlSet\Control\Arbiters\Class Registry 
SYSTEM\CurrentControlSet\Control\CMF\Class Registry 
SYSTEM\CurrentControlSet\Control\CMF\CORE Registry 
SYSTEM\CurrentControlSet\Control\CMF\DEF Registry 
SYSTEM\CurrentControlSet\Control\CMF\Els Registry 
SYSTEM\CurrentControlSet\Control\CMF\ASN Registry 
SYSTEM\CurrentControlSet\Control\MSDTC\BSR Registry 

Stage 2 – Gzip Loader 

IoC Note 
357009a70daacfc3379560286a134b89e1874ab930d84edb2d3ba418f7ad6a0b  

Stage 3 – Puppeteer 

Ioc Note 
364984e8d62eb42fd880755a296bd4a93cc071b9705c1f1b43e4c19dd84adc65  
C:\ProgramData\Microsoft\Crypto\Escan\dss.exe  
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3   
C:\Windows\system32\tasks\Microsoft\windows\autochk\ESUpgrade Scheduled task 
HKEY_LOCAL_MACHINE\SOFTWARE\AVC3 Registry 
\Device\HarddiskVolume1\Program Files (x86)\eScan\download.exe  
4dfd082eee771b7801b2ddcea9680457f76d4888c64bb0b45d4ea616f0a47f21  
SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server Registry 
net group ”domain computers” /domain Command 
https://m.airequipment[.]net/gpse/  
487624b44b43dacb45fd93d03e25c9f6d919eaa6f01e365bb71897a385919ddd  
C:\Program Files (x86)\eScan\updll3.dll3  
C:\Program Files\Common Files\SYSTEM\SysResetErr\SysResetErr.DLL  
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellChecking.DLL  
C:\Program Files\Microsoft SQL Server\SpellChecking\MsSpellCheckingHost.DLL  
C:\ProgramData\AMD\CNext\atiadlxx.dll  
C:\ProgramData\Microsoft\Assistance\LunarG\vulkan-1.dll  
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll  
C:\ProgramData\Microsoft\Crypto\Escan\updll3.dll3  
C:\ProgramData\Microsoft\Network\Escan\AutoWake.dll  
1c31d06cbdf961867ec788288b74bee0db7f07a75ae06d45d30355c0bc7b09fe  
1fbc562b08637a111464ba182cd22b1286a185f7cfba143505b99b07313c97a4  

Stage 4 – Backdoor 

IoC Note 
07beca60c0a50520b8dbc0b8cc2d56614dd48fef0466f846a0a03afbfc42349d  
E:\Projects\putty-src\windows\VS2012\x64\Release\plink.pdb PDB 
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\CMF\Class Registry 
HKEY_LOCAL_MACHINE\SYSTEM\RNG\FFFF  Registry 
gesucht[.]net  
f0ccfcb5d49d08e9e66b67bb3fedc476fdf5476a432306e78ddaaba4f8e3bbc4  
HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\DECLAG Registry 
8446d4fc1310b31238f9a610cd25ea832925a25e758b9a41eea66f998163bb34 Shellcode 
74D7F1AF69FB706E87FF0116B8E4FA3A9B87275505E2EE7A32A8628A2D066549  
www.righttrak[.]net:443   
185.248.160[.]141  
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PCB Registry 
af9f1331ac671d241bf62240aa52389059b4071a0635cb9cb58fa78ab942a33b  

Related and Future Research 

IoC Note 
“cmd.exe” /c type “\<domain>\SYSVOL\<domain>\scripts\gpon.inc” | “\<domain>\SYSVOL\<domain>\scripts\powAMD64.dat” -nop – Command 
C:\Windows\System32\Tasks\ScheduledDefrag Scheduled task 
529763AC53562BE3C1BB2C42BCAB51E3AD8F8A56 Certificate SHA1 
31070C2EA30E6B4E1C270DF94BE1036AE7F8616B Certificate SHA1 
31dfba1b102bbf4092b25e63aae0f27386c480c10191c96c04295cb284f20878  
8e96d15864ec0cc6d3976d87e9e76e6eeccc23c551b22dcfacb60232773ec049  
b0f94d84888dffacbc10bd7f9983b2d681b55d7e932c2d952d47ee606058df54  
f656a418fca7c4275f2441840faaeb70947e4f39d3826d6d2e50a3e7b8120e4e  
7f1221c613b9de2da62da613b8b7c9afde2ea026fe6b88198a65c9485ded7b3d  
F:\!PROTECT\Real\startW-2008\MainWork\Release\MainWork.pdb PDB 

The post GuptiMiner: Hijacking Antivirus Updates for Distributing Backdoors and Casual Mining appeared first on Avast Threat Labs.

Hitching a ride with Mustang Panda

2 December 2022 at 04:00

Avast discovered a distribution point where a malware toolset is hosted, but also serves as temporary storage for the gigabytes of data being exfiltrated on a daily basis, including documents, recordings, and webmail dumps including scans of passports from Asian, American and European citizens and diplomats applying for Burmese visas, from Burmese human rights activists and Burmese government institutions.

We recently came across a peculiar sample – a stager we believe is being used by Mustang Panda. The stager led us to the group’s distribution point, where we found malicious toolsets. We have analyzed the malware and were able to see relations between various campaigns that have been described by other cybersecurity firms over the course of the last years. Based on publicly published research and our own investigations, we can say with high confidence that the modus operandi and the malicious toolset show a strong link to a group related to Mustang Panda, which has previously been reported as a Chinese APT group. The group has been known for gathering intelligence on Mongolia, and further Asian countries, and most recently was suspected of targeting European entities.

The distribution point, an FTP server, is also used as a transition point for exfiltrated victim data, before the data is moved to an unknown location. We continue to observe new data being uploaded and moved from the point, meaning the campaign is still active, and has been going on for some time. Gigabytes of data are moved around, and the amount of data indicates severe compromise of many high-profile targets in Myanmar. The data types include various office documents and PDFs, stolen browser profiles, webmail dumps and even sound recordings. Browsing profiles were also extracted which can provide access to other infrastructures, services, and private data of the victims. Most of the stolen data seems to be in Burmese making it challenging to analyze. The sensitive data is mainly being collected from devices used by the Myanmar government, state administration, police, army, significant public organizations, or companies, and includes data related to diplomatic meetings, court hearings, military information, contracts and more.

Disclaimer: We have only seen partial snapshots of the exfiltrated data as they are deleted shortly after being moved from the distribution point, so it should be noted that the information we have on victims may be inaccurate or incomplete. Most of the documents are in Burmese, therefore, a language barrier has also to be taken into account. Finally, due to the limited scope and the sheer volume of the data, some assumptions had to be made during the research process. We have reached out to local CERTs, informing them of our findings.

Victimology

Nearly all of the victims have close ties to Myanmar and it seems that both the Burmese government and opposition groups are being targeted. We have seen data originating from various departments of several Burmese ministries. Even the Office of the State Administrative Council has been targeted. The government breach is not isolated to Myanmar – we have also seen Myanmar embassies among targets, for example, the embassy in Serbia. The data also contained dumps of a mailbox used to communicate in 2016 and 2017, as well as in 2020 with visa applicants from all around the world. These messages contained scans of passports from citizens and diplomats from various countries, such as China, Australia, Czech Republic, France, Israel, Netherlands, UK, and USA.

After such an extensive list of targets, it ought to be little surprise that Myanmar Police Force is also among the targets. Even some higher profile departments, such as the Office of the Information Police Chief or the Department of Special Investigation, seem to have been breached. Tatmadaw (Myanmar Armed Forces) is also not an exception – we have seen victims from the Bureau of Air Defense, Myanmar Army Engineering, and the United Wa State Army.

Political NGOs and the government’s opposition are also on the list of victims. It is possible that the list is even more extensive as we may not be able to find a straightforward association to said organizations as we would expect more common usage of personal computers or computers that are not centrally maintained by an IT department. We have seen data from devices belonging to the Karen National Union, Center for Diversity and National Harmony, National Reconciliation and Peace Centre, Ethnic Nationalities Affairs Center, and even the Union Civil Service Board.

Exfiltrated Data 

The most common file types being exfiltrated by the group are Microsoft Office documents (.docx, .xlsx, .pptx, etc.), PDF documents, and plain text files. Other file types exfiltrated include audiovisual data in various forms, including sound recordings (.mp3), and pictures (.jpg, .png, etc.) or drawings. Emails, including entire conversations are also exfiltrated.

It appears that the attackers are also looking for and collecting data from browser profiles from various web browsers, e.g. Chrome, Firefox, Opera, and more, a serious threat to victims’ privacy. The stolen browser profiles can provide access to other infrastructures, services, and the victims’ private data of the victims. The attackers are extracting information about browsing history, stored credentials (personal and work), credit cards, used tokens, and valid cookie sessions. Consequently, poorly secured services, such as services without two-factor authentication or without a safe cookie policy, can be easily abused by attackers. Attackers can steal the identity of victims and can use their email, Facebook, Telegram, or other accounts to collect additional information about the victim and their family, friends, and activities.

Highly sensitive data is being collected from victims’ computers, and, in most cases, these are computers used by the Myanmar government, state administration, police, army, significant public organizations, or companies. This in some cases included sensitive data and information belonging to international citizens and diplomats who have interacted with targeted departments.

The documents, and audiovisual data being exfiltrated by the group is massive. The files include everything from:

  • Email dumps including visa applications and scans of passports belonging to citizens and diplomats from various countries, such as China, Australia, Czech Republic, France, Israel, Netherlands, UK, and USA
  • A seating plan for the meeting between former US Ambassador to the United Nations Bill Richardson and Myanmar’s leader, Senior Gen. Min Aung Hlaing 
  • Myanmar’s constitution with proposed changes
  • Invitations for diplomatic meetings, meeting programs, calls, and talking points
  • Reports, maps, and screenshots from the Signal messaging app related to the UWSA (United Wa State Army)
  • Data from the Office of the Chief of Myanmar Air Defense Force, including meeting minutes, full staff/rank lists, photo IDs (some with fingerprints), salaries, personal details of employees’ families
  • Peace treaty documents
  • Interrogation reports
  • Contracts
  • Court hearings
  • Town plans
  • Contact information for police officers, including their names, addresses, telephone numbers, and salaries
  • Transcripts of meetings around politics, and elections
  • Meeting minutes and audio recordings of meetings between Myanmar senior officials (Prime minister, Chairman of State Administrative Council) and the President of Tatarstan
  • Military buildings drawings, including munitions storage, oil storage and aerial photos of proposed sites 
  • International banking records and records and transfers from supporters to a refugee group

Ties to known campaigns

Since getting our hands on the distribution point, we have established links between known campaigns already publicly reported and what we have discovered. This gives us clues as to how resourceful the group may be and will also help us assess its modus operandi.

We have found files strongly resembling (or even matching) samples and their relations described in a blogpost by ESET around the Korplug variant dubbed Hodur. The campaign they described was targeting various government organizations in Mongolia, Vietnam, and Myanmar, along with politically-oriented NGOs. This is in alignment with the victimology of the stolen data we have seen on the distribution point. Hodur was attributed to the Mustang Panda group. The related part of the uncovered toolset we analyzed also contained a USB launcher written in Delphi, similar to the one seen accompanying the Hodur variant of Korplug analyzed by ESET. This installer is responsible for firing up the infection chain leading to a variant of Korplug RAT.

Similarly, we’ve found similarities to operations attributed to LuminousMoth both in structure and purpose. For instance, we have seen a very similar structure as the one described in Bitdefender’s research on the LuminousMoth group. Namely, the usage of the same binaries for sideloading, same pattern for exfiltration – using RAR for collection and a sideloaded library for exfiltration via Google Drive. Perhaps the most common pattern was the usage of a USB launcher written in Delphi that was attributed to Mustang Panda, which was also described in Bitdefender’s research.

In some cases, we have seen some unreliable links to older campaigns such as Operation NightScout, a rather old KMPlayer supply-chain attack, or Operation Harvest. Namely, binaries used for sideloading or names of encrypted payloads matched the ones used in these old campaigns. Nevertheless, the specific payloads differ significantly, so while some of these were attributed to Mustang Panda, the similarity could also be coincidental.

Toolset overview

The storage we have discovered contains many archives with various tools to be downloaded by infected victims. We will use names of these archives to impose basic structure on the data we have found. It is worth noting that these names are partially consistent in successive versions. For instance, we have found an archive KKL which was later on accompanied by another version with a slightly different configuration called KKL1.

Some archives contained complete toolsets, whereas others only had single purpose tools in them that were meant to be used in connection with other tools; for instance, one contained a keylogger that obviously lacked any exfiltration functionality. This provides a strong indication that the tools are intended to be used modularly. We will build upon that and first talk about the usual Mustang Panda theme – Korplug. Then we’ll get to the more specific tools and end with the single purpose tools. Notably, nearly all the tools, aside from Korplug, its loaders, and Delphi installers, haven’t been described before. The RAT written in Go (JSX) or the  modular backdoor (US_2) deserve an extra mention due to their complexity 

From the data we have seen, we conjecture that the main exfiltration tools are variants of tools contained in archives named GDU, which use Google Drive for the exfiltration. Since we haven’t seen any exfiltration tool that uses the distribution point directly and the path on the server of exfiltrated files contains gd, we presume that the responsible group uses some other tools to move files from various Google Drives to the distribution point we saw.

A brief look at the toolsets brings up another interesting fact: almost all the files show approximately (up to a few cases within seconds) a seven or eight hour offset between the compilation timestamp and the “last modified” timestamp of the file itself. Since the compilation timestamp is usually in UTC and the archives use the local time for the contents’ last modification date, this places us at UTC-8 and UTC-7. Therefore, we presume that the build setup operated in a time resembling Pacific Standard Time (PST) and Pacific Daylight Time (PDT), used on the West Coast of the United States. There are a few caveats – SE3 and SE4 contain files that were compiled on November 1, 2021 and still have an eight hour offset even though none of the countries using PST/PDT transitions to PST that early (both USA and Canada transition to PST a few days later).

There is also a file with an obviously spoofed compilation timestamp. HT3 contains a DLL Vender.dll whose compilation timestamp dates more than a month after the last modification date. This further weakens hypotheses that build upon timestamp offsets. Unfortunately, we have no further leads explaining this outlier. The latest version of the uploader (multiUpload.exe), whose usage was spotted at the beginning of June, has a compilation timestamp of January 3, 2020. This is also very likely spoofed as analyses of the previous versions of this tool show clear evolution and, according to their respective timestamps, they were all compiled in April 2021. Not to mention that the corresponding infrastructure was only created at the end of May 2022.

The folder /pub/god, which contained the toolset archives, was removed on June 25, 2022. On the same day, a new folder /pub/god1 was created with two files to which we didn’t have read access. Two days later, the new folder was gone and /pub/god appeared again with a subset of the original tools.

Variations on Korplug

The first group of tools that we’ll introduce are various versions of Korplug. The binaries used for side-loading were already seen before. Even though the loaders were mostly new, they were rather uninteresting. A common theme was a Delphi binary that served as a launcher to be executed from an infected USB drive. As we’ve already mentioned, a similar installer was previously seen in campaigns attributed to Mustang Panda. It just executes the Korplug loader from a folder named “Kaspersky” that is on the very same USB drive. See the diagram below (based on a toolset from an archive named BMD) for more details. 

Note the usage of the folder name “Kaspersky” and usage of “Symantec” in the names of the executables; since the launcher relies on social engineering tricks, it depends on a common strategy using seemingly legitimate file names to dispel any doubts concerning the content.

Contents of an archive called BMD. Archive YK41 follows the same structure, with ShellselDb.dat being replaced with hp_ui.xslbcdsj and without the Delphi launcher.

There were also simpler infection chains, containing just a signed clean binary, a loader to be side-loaded, and an encrypted Korplug. These were contained in archives WD, 127C, and 1260M. The latter interestingly used the OleView.exe binary which then side-loaded the ACLUI.dll that decrypted and executed ACLUI.DLL.UI. The same signed binary, which surprisingly also has the same name of the encrypted payload, was used in the KMPlayer supply-chain attack in 2013. The accompanying research was only published in Chinese, likely due to the attack being limited to a few devices.

Exfiltration toolset

The exfiltrated data on the server in /pub/gd folder showed perfect correlation to the data produced by GDU toolsets (GDU_OLD, GDU, GDU1, GDU2, GDU1_NEW, GDU3, GDUPIZ). These tools collect the files on the victim’s disk, pack them into an archive whose name is prefixed with the victim’s ID and upload that archive onto a Google Drive. We presume that the name GDU is an acronym for Google Drive Uploader. While the tools themselves were technically rather simple, the exfiltration process and their evolution piqued our interest.

The analysis of the exfiltration process brought up several interesting observations. A few days after May 24, 2022, the day we started systematically monitoring Google Drives used for the exfiltration, we started to see more frequent token changes and new features being implemented. These features mitigated possible downtime caused by the migration to a new token. Since Google Drive has extensive logging functionality and the tokens have to be present on the infected devices, it is only a reasonable expectation that access to these drives is monitored to some extent.

On the contrary, we have not seen such behavior with the distribution point. This could be attributed to the fact that the distribution point is never exposed by the toolsets, which brings us to the assessment that the group presumes the distribution point to be secret or not worth monitoring.

Timeline of GDU exfiltration toolsets

Version overview

The oldest version GDU uses RAR executable to collect the data and an encrypted rar.dat to store parameters for the RAR binary. Starting from GDU_OLD, they migrated to their own collector piz.exe (this functionality was later moved to a DLL to be side-loaded) and retained an encrypted rar.dat where they stored their configuration. These toolsets also rely on two optional configuration files that are backed up by hard-coded values: token.dat containing an encrypted token for Google Drive and time.ini that contains last execution date along with the victim’s ID. The setup and the choice of binaries for side-loading bears resemblance to the LuminousMoth campaigns and tooling.

An archive GDU that contains a version relying on RAR instead of piz.exe for data collection.

The exfiltration process is usually handled by a variant of MyUpload.dll that is supplemented by the aforementioned configuration files. Quite recently, a new version of GDU1 has appeared on the distribution point (which we’ll call GDU1_NEW)  which came with its successor multiUpload.exe. multiupload.exe eschews hard-coded tokens and makes the exfiltration process more resilient to disruptions.

Archive GDU_OLD that uses its own collector piz.exe to collect potentially interesting files before the exfiltration.

The version we are calling GDU_OLD is basically the same as GDU1 and GDUPIZ, the most significant difference being a different PE being used for side-loading. GDU1 and GDUPIZ rely on CefSub.exe and subsequently on CefBrowser.dll instead of AtlTracetool.exe. GDUPIZ also uses a slightly different approach to execute the file collection tool piz.exe – the version included in this folder is in fact a renamed clean binary spoololk.exe which in turn side-loads vntfxf32.dll. This malicious binary implements the file-collecting functionality formerly contained in piz.exe. GDU2 is basically the same as GDUPIZ.

On June 8, 2022, we saw a new GDU1 toolset on the distribution point. This time MyUpload.dll has been upgraded to provide redundancy in the exfiltration process. It no longer uses token.dat but rather uses a Github repository as its source for the token. If this fails, there are two backups – one using HTTP PUT to www.watercaltropinfo[.]com with Basic HTTP Authorization (123:123). The other sends the data via HTTPS POST to m.watercaltropinfo[.]com. The collector is the same as in GDUPIZ. GDU3 uses basically the same process but uses different PE for side-loading (FwcMgmt.exe).

Tokens

A special chapter is devoted to Google Account tokens that are used in these tools, partially because our research may have forced the group’s hand to refresh the tokens once they discovered that we knew of their Google Drives. The fact that after each token decommission, every client had to have the token updated and that GDU toolsets do not have any remote update functionality suggests that these toolsets have to be accompanied by other tools that provide this update functionality. We have noticed a longer delay between the decommissioning of the token from May 29, 2022 and before a replacement token was being distributed. Its distribution coincides with the time a new version of GDU1_NEW was released. It’s exactly this version that has introduced new functionality in the exfiltration tool, namely smoother token swapping and failsaves for cases when Google Drive exfiltration fails. Therefore, we presume that this delay was caused by the development of this new functionality.

SourceRefresh TokenMetadata
GDU/GDU_OLD1//030YFi1XWWVY2CgYIARAAGAMSNwF-L9Ir_I6Aqhg4gn3UWyi3I5J_6q4VxHPYNkit3x9RtlpVkFCEOD4KU-E2u7NghS0hx5nPU8YFirst seen: 22.4.2021Not accessible
Distribution point1//0clbh_CVKereiCgYIARAAGAwSNwF-L9IrtPxC9zt-onaeeq2gTUwZTVa8f8ILvDYM8dyVVjmmKmNr5Pnsi27iMjLll2dxbDRxUQsFirst seen: 22.4.2021Not accessible
GDU1/GDU2/GDUPIZ1//0cZLNy7GH0LknCgYIARAAGAwSNwF-L9IrV7aXKTZb-WQM1aqXkjX0ph25dTZngOYAUlAXHB1NvCorgw62XI_TXsWNrK98KBYfbpAFirst seen: 17.3.2022Our first access: 24.5.2022Usable until: 26.5.2022
Distribution point1//0e29aixufumhCCgYIARAAGA4SNwF-L9IrX2w0GnjBQe4g5hQWKJlXjIQF7XZBnQ9VKArYhJVwOayZq9Ad-G8YHbsptTN5DhfXI2EFirst seen: 29.5.2022Our first access: 29.5.2022Usable until: 3.6.2022
Github1//0ewRnXWCf2AunCgYIARAAGA4SNwF-L9IradANDPAvIqPOaIfReqT1fQ0GO5A9FnUhdpdI0Q0V1IRye5RbTi-hcGQbbHKgDc02xfMFirst seen: 8.6.2022Our first access: 8.6.2022Still usable

Temporal analysis of exfiltrated data

We can also have a look at the metadata of the exfiltrated archives. What is rather unsurprising are the upload times which closely coincide with Burmese business hours – a smaller peak in the morning and a huge peak in the afternoon. Note that Myanmar is in UTC+6:30 time zone and China, presumed land of origin of Mustang Panda, is in UTC+8.

What is more interesting are events produced by the group itself – transfers from Google Drive onto the distribution point and deletion of files from the distribution point. The huge peak is around 18:00 MM time which coincides with the end of the work day in Myanmar. The spread of starts of upload windows is negligible, leading us to the presumption that the transfer is automated. We have seen a few archives being placed in the wrong directories which could indicate that the tooling is still under development or there’s still some manual work involved… Usually, the files have accumulated during the day on Google Drive and were transferred to the distribution point in the evening MM time.

As we already mentioned in the introduction of uncovered tools, we have found quite a lot of files that were “missing” something. By that we mean that on their own, they were either lacking communication functionality or implemented some techniques that were useless without being accompanied by another payload. Interestingly, while these were also using side-loading, they were not relying on external encrypted files, making their execution flow straightforward with 2-point graphs. For the sake of brevity, we will list these in a table:

ArchiveClean executableSideLoaded DLLPurpose (high-level)
MG/MG44dabs.ex/44.exSensorAware.dllfingerprinting/remote shell
AUDmcsync.exmcaltlib.dllaudio recording
CHRbrowser.exbrowser_elf.dllCookie dumping
T3YKygfdt.execorecrl.dllremote shell
UCmelt_64.exelibmlt-6.dllUAC bypass
KKL/KKL1mscorsvw.exemscorsvc.dll (contains KBE.dll)clipboard stealer, keylogger
Archive KKL contained a straightforward stealer in KBE.dll that was also hard-coded (in an encrypted form) in mscorsvc.dll from which it was unpacked after side-loading. The newer KKL1 was practically the same.

There are also a few standalone files such as x.ex in archive X which composes logs of registry entries (Run), services, and scheduled tasks along with checking all signatures of executable files in %WINDIR%. Archive NB contains nb.dat which is just the nbstat utility executable. There was also a coinminer in the archive INFO along with its encrypted configuration file.

An interesting utility is DISK2 (and its variant DISKM); it is responsible for monitoring the system drive for any changes. Both are accompanied by a configuration file that defines which files are of interest and where such files should be copied to. It also notifies its C&C server about these files via an encrypted message over HTTP. There is also a version of this tool named MF20211228 that does not contain any configuration file and does not copy files anywhere, it just sends messages to the C&C server.

Contents of an archive DISK2. This toolset is responsible for monitoring the system drive for any changes in files defined by its configuration.

Oddballs in the collection

JSX

JSX archives (JSX86 and newer JSX861 for 32 bit version and JSX64 and newer JSX641 for 64 bit version) deserve a separate mention as they use a rather uncommon setup; a JavaScript file is at the beginning of the chain and instead of side-loading, the respective DLL is launched as a service. mozload.dll is a RAT written in Go that uses HTTPS and websockets for its communication. Interestingly, the RAT uses TLS Client Authentication; see Appendix A.1 and Appendix A.2 for the private key and the certificate.

The execution flow of the packages from JSX archives.

HT3

HT3 simply does not fall into any of the previous categories – it is a backdoor with external configuration accompanied with a shellcode loader and UAC bypass.

Execution flow of HT3. Note that it contains both 32 bit and 64 bit versions of an UAC bypass tool.

SE

Now we are finally getting to a more complex setup. These archives include several versions with very similar structures and sometimes with varying payloads. Functional changes are presented below; note that these do not include changes in side-loading which will be discussed later on. All versions feature a few evasion tricks that use registry tricks to hide files and file extensions.

VersionVersion changes
SE1Uses volume name for USB installer executable
SE3/SE4/SSEUses Delphi launcher (the one attributed to Mustang Panda), persistence integrated into LPVDPOCX.OCX (equivalent of facesdk.dll from SE1)
SE5Uses volume name for USB installer executable, rollbacks to old USB installer
SE6No significant functional changes
SE7No significant functional changes

SE3 and therefore also SE4 and SSE (which are mostly the same) use vivaldi.exe and vivaldi_elf.dll for its evasion module. Also, FacialFeatureDemo.exe and facesdk.dll are replaced by Symantecs.exe and LDVPOCX.OCX; the latter integrating persistence into itself instead of having it in a separate module. Interestingly, the USB installer has been replaced with one similar to the one in the archive BMK; a Delphi launcher that executes Symantec.cmd which is actually Symantecs.exe. These versions are also the only ones that have renamed 3 of 4 payload bundles (using csdkset.dat for backdoor, EdrEpmpCStorages.dat for USB installer, and PchEpmpCStorages.dat with WTSAPI32.dll). Confusingly, WTSAPI32.dll does not seem to be used anywhere and will be used for side-loading by later versions when the USB installer replacement is roll-backed.

SE6 and SE7 abuse old Avast’s proxy executable wsc_proxy.exe to side-load wsc.dll which serves as the dispatcher. Aside from this change, there are no other significant changes to the functionality.

The schema of contents and the control flow of SE1. In newer versions, the persistence module is integrated in the dispatcher.

U5_2

The last complex toolset that we will present is from the archive U5_2. Most of the functional code is encrypted and bundled in AtiVir.csc. With the exception of a  chain to a removable drive watcher, all the parts share similar XOR keys: user_panda_%section_name%; a rather interesting choice if the toolset really belongs to Mustang Panda.

An interesting part of the toolset is a file install_.exe that reads a file from a given path, takes the serial number of the volume where the file is located, computes MD5 hash from the serial number and changes the  first bytes of the file to the hex-encoded computed hash value.

The schema of contents and the control flow of U5_2.

Server infrastructure

The distribution point is an FTP server located in Malaysia that is accessible without a password (username anonymous, password is empty). We have also encountered a different FTP server in late 2020 containing very similar archives to the ones we now know contain exfiltrated data. Unfortunately, we did not have enough information to process the archives it contained. We presume that these two FTP servers were closely related or that even the current FTP server may be successor of the one we found previously.

We have noticed that the FTP server has stopped responding in October. Fortunately, the server itself was still alive and the distribution has migrated to using HTTP instead of FTP. They also started using HTTP Authorization; nevertheless, they have reused a weak username:password combination (123:123). This has caused a downtime of a few days in our tracking, but with a quick fix, we’ve managed to get back on track. Presumably, this might have been another attempt to foil our tracking attempts.

Our telemetry data also revealed another server in Russia. A client from Myanmar tried to download an archive XYZ from it via HTTP. Upon further inspection, the archive was found to be identical to XYZ from the aforementioned FTP server. We have tried to crawl the server for archives and files we have already seen on the FTP server and found the following toolsets:

Archive on the HTTP serverMatching archive on the FTPNote
gdupiz.rarGDURetrieved from our telemetry
xcrs.exeXDiscovered by crawling
jsx861.rarJSX861Discovered by crawling

The fact that the affected client is from Myanmar, and the fact that the server contains some parts of the described toolset strongly indicates that it is part of the same campaign. Nevertheless, since at least one archive was renamed, we were unable to fully enumerate its contents. Similarly, we were not able to verify whether the server contains exfiltrated data.

C&C infrastructure

JSX RAT

The JSX RAT attempts to communicate with 103.169.90[.]132 using TLS client authentication. The certificate (see Appendix A.2) is hard-coded and we can try to use it to confirm related infrastructure. Looking at the server certificate data, we see that it imitates a real hosting company.

Common name:        blue.net
City, country:      San Francisco, CA, US
Fingerprint (sha1): e0adf667e287b0051988dda2b85e7541d7532703
Self-signed

Interestingly, the C&C’s certificate had the exact same subject as the client certificate. Searching for other servers that use the same certificate yielded a couple more servers. Furthermore, we were able to confirm that the majority of these servers are running the same C&C software because they accept the RAT’s hard-coded client certificate.

A server at 118.31.166[.]5 seems to be an outlier among these servers with port 4433 being exposed. Since it is the oldest one using the same certificate and the server exhibits the same communication traits on that port, we suspect that it might be a development server.

Two of these servers were open to RDP connections with a certificate that had o9c[.]pg as its CN (Common name). We tried to go further using these certificates to uncover further candidates for C&Cs. The timeline of uncovered servers is below:

Timeline of servers using the discovered certificates. Blue ones use a certificate with blue[.]net CN, red ones use o9c[.]pg as CN, purple ones have both. The highlighted line corresponds to JSX RAT C&C.

These are servers using the same certificate:

IPGeoNotes
103.169.90[.]132MYOriginal C&C Ports: 443, 22, 53, 3389
45.79.409[.]10USSuspected RAT C&C on port 443
118.31.166[.]5CNSuspected RAT C&C on port 443, different response codes
181.215.246[.]173MY
39.104.52[.]188CNSuspected RAT C&C on port 443
45.56.90[.]127USSuspected RAT C&C on port 443
154.204.176[.]249HK
47.244.2[.]17HKSuspected RAT C&C on port 443, RDP
47.96.236[.]105CN
134.122.129[.]170HKSuspected RAT C&C on port 443
172.105.158[.]102USSuspected RAT C&C on port 443, RDP
192.46.213[.]63INSuspected RAT C&C on port 443
Overview on the servers with ties to JSX RAT C&C.

These are RDP servers sharing the same certificate as the two C&Cs with open RDP port:

IPGeoNotes
47.75.123[.]100HK
47.242.171[.]26HK
47.57.87[.]221HK
172.105.118[.]92SG
172.105.159[.]130US
47.244.2[.]17HKIs also on the previous list.
47.242.95[.]126HK
8.210.16[.]197HK
172.104.92[.]7JP
45.33.34[.]11US
45.79.102[.]41US
47.57.108[.]231HK
194.195.240[.]87DE
47.56.65[.]198HK
8.210.128[.]37HK
172.105.158[.]102USIs also on the previous list.
47.57.110[.]128HK
47.242.6[.]26HK
23.92.26[.]127US
47.75.183[.]119HK

Other C&C servers:

FolderGeoC&CNotes
DISK2/DISKM/MF20211228RU188.127.249[.]169Stealer
HT3MY45.121.147[.]172Korplug
JSXMY103.169.90[.]132RAT
MG/MG44SG23.106.122[.]81Remote shell
SE4/SE5/SE6/SE7SG91.245.253[.]72Backdoor (ZIPDLL.dll)
SEEMY103.91.66[.]116Backdoor (ZIPDLL.dll)
T3YKMY111.90.148[.]95Remote shell
U5_2MY103.117.141[.]202RAT
YK51LOWMY
N/A
mod.mmgpms[.]com
txt.mm-film[.]com
Backdoor
1260MUS45.134.83[.]4Korplug
GDU1_NEW/GDU3https://github.com/YanNaingOo0072022/View2015Encrypted Google Drive token

Conclusion

It is not very often we stumble upon such a stash of samples that is used to distribute malware to infected devices; especially when we are talking about tools that are strongly correlated with a notorious APT group. We have shown links to multiple previously published research around campaigns both using tools and TTPs, providing us with high confidence that the threat actor in question is Mustang Panda.

The exfiltrated data indicates that the toolsets that we have found were actively used around Myanmar. For instance, we have found audio recordings that corresponded to the audio recording tools we have identified in the archive named AUD. Although many tools were simplistic in their nature and sometimes also in chosen obfuscation methods, some archives contained tools which seem to deserve further analysis; be it due to their complexity or technical implementation.

What was really surprising was the sheer scale of the compromitation. We have identified many high-profile government targets, some opposition entities along with a few NGOs. It is worth noting that given the sheer volume of data and the language barrier, we have only been able to associate some of the victims with a specific organization. This means that the list of targets is likely incomplete and should be considered as approximate. Nevertheless, the daily rate of gigabytes of exfiltrated data should be enough to give a strong hint on the scale of the operation.

Appendix

C&Cs

FolderC&CNotes
DISK2188.127.249[.]169Stealer
HT345.121.147[.]172Korplug
JSX103.169.90[.]132RAT
MG/MG4423.106.122[.]81Remote shell
SE4/SE5/SE6/SE791.245.253[.]72
193.42.36[.]214
Backdoor (ZIPDLL.dll)
SEE103.91.66[.]116Backdoor (ZIPDLL.dll)
T3YK111.90.148[.]95Remote shell
U5_2103.117.141[.]202RAT
YK51LOWmod.mmgpms[.]com
txt.mm-film[.]com
Backdoor
1260M45.134.83[.]4Korplug
GDU1_NEW/GDU3https://github.com/YanNaingOo0072022/View2015Encrypted Google Drive token

Certificates and keys

A.1 JSX private key

-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIPq1gFM9BHY6lKw+F09iQ4rY5ZDpZhpVuLbLEgKpN1EFoAoGCCqGSM49
AwEHoUQDQgAE8ReYJNz1RlchdTIxo0/4GqPVsJ2m6QFMW0vVMLKYWeINX4Ih9vPV
OgzHq6+qeNxzvAbS4D9jTETTMKssSssr0Q==
-----END EC PRIVATE KEY-----

A.1 JSX certificate

-----BEGIN CERTIFICATE-----
MIICBDCCAamgAwIBAgIUPAoKZshUkyHcTvej+gio/kTTd/AwCgYIKoZIzj0EAwIw
RTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1TYW4gRnJhbmNp
c2NvMREwDwYDVQQDEwhibHVlLm5ldDAeFw0yMTEwMTIwMzQ0MDBaFw0zMTEwMTAw
MzQ0MDBaMEUxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEWMBQGA1UEBxMNU2Fu
IEZyYW5jaXNjbzERMA8GA1UEAxMIYmx1ZS5uZXQwWTATBgcqhkjOPQIBBggqhkjO
PQMBBwNCAATxF5gk3PVGVyF1MjGjT/gao9WwnabpAUxbS9UwsphZ4g1fgiH289U6
DMerr6p43HO8BtLgP2NMRNMwqyxKyyvRo3cwdTAOBgNVHQ8BAf8EBAMCBaAwEwYD
VR0lBAwwCgYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQULCt+JQ1h
n+CNR27Lm0giuJbAHGAwIQYDVR0RBBowGIIIYmx1ZS5uZXSCDHd3dy5ibHVlLm5l
dDAKBggqhkjOPQQDAgNJADBGAiEA9c8UxcF/xYGVThbl3vfKpmJQKQLi8LP+2cui
o9Z3iZICIQCxJOXs+4ScVpyIkw8HYCCv3x0CDVv4xfiGHEEW+ZLZYA==
-----END CERTIFICATE-----

Side-loads

ArchiveBinaryDLL
BMD,YK41Symantec.exeSHELLSEL.ocx
YK41LOWGoogleUpdate.exeSbieDll.dll
YK41LOWatkexComSvcRes.exeCefBrowser.dll
HT3x.exeVender.dll
GDUSamvd.exeSmadHook32.dll
GDUPIZvsgraphics.exevsgResources.dll
GDU1/GDU2CefSub.exeCefBrowser.dll
GDU2/GDUPIZ/GDU1_NEW/GDU3piz.exevntfxf32.dll
GDU_OLDAltTraceTool.exeatltracetoolui.dll
GDU1_NEW/GDU3NitroPro.exeCefBrowser.dll
GDU3piz.exeFwcWsp.dll
WD HP.exeHPD.dll
DISK2/DISKM/MF2021188HPCustPartUI.exeHPCustPartUI.dll
127COleView.exeACLUI.dll
KKL/KKL1mscorsvw.exemscorsvc.dll
MG/MG44dabs.ex/44.exSensorAware.dll
AUDmsync.exmcaltib.dll
CHRbrowser.exbrowser_elf.dll
T3YKygfdt.execorecrl.dll
UCmelt_64.exelibmlt-6.dll
1260Mupservice.exebreakpad.dll
U5_2HPCustPartUI.exeHPCustPartUI.dll
U5_2PlugInInstallerUtility2.exePlugInInstallLib.exe
SE1FacialFeatureDemo.exefacesdk.dll
SE1/SE3/SE4/SE5/SE6/SE7/SEECUZ.exeZIPDLL.dll
SE1%volume_drive%.exeMSFTEDIT.dll
SE1/SE7GUP.exelibcurl.dll
SE1spoololk.exeWNTFXF32.dll
SE3/SE4/SE5/SE6/SEEvivaldi.exevivaldi_elf.dll
SE6/SE7wsc_proxy.exewsc.dll

File hashes

\1260M

1ded7b4cab302bc7229c92723056d07d5bd9563e88fe082da0a396942fba5958 breaklog.dat (Korplug)
2895fdac192a4b0ffd70b6b207d49cd7c8f68945eb5c09e3d51e2fded6c6c32f breakpad.dll (Loader)
ce13248fa2da5b27773f855c2dd0c6ce276b4a10b020e4da57bc47ab0fe07eae upservice.exe

\127C

1769c7778cbcd937ae317f4982f404b0d7ae7ee5e2b2af4efb160c5233a8f476 ACLUI.dll (Korplug)
8ff84f79455b84bd73e7c0641532a60e8132599c29d3f85fb54f3d7da53e1817 ACLUI.DLL.UI (Loader)
91f6547bceddfb2f241570ac82c00de700e311e4a38dea60d8619638f1ed3520 OleView.Exe

\AUD

cd6bcf240de87fe3f1b5a6a24db1b2728acad5f7bcfe124e5bc2d7bdac2f64a9 mcaltlib.dll (Audio recording)
075f9dfb6ab3379f69165c03991abf1a969ca0c21e04564543564dc536ea95dd mcsync.ex

\BMD

55eacabb7c054355d2e8c3a82c075338c9ac642d86ee5d3fa1fca3f621e43cb2 SHELLSEL.ocx (Loader)
d139940023fa2c602e2a31faa807b9df074f34747511bd61db961d20155b8c84 ShellselDb.dat (Korplug)
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantec.exe
491d9f6f4e754a430a29ac6842ee12c43615e33b0e720c61e3f06636559813f7 SymantecHp.exe (Launcher)

\CHR

e3e2164c54a5c8ab063695bc41b6c0c0ddc390c790de8ad24d6169dba46f7734 22.1.1.1543.manifest
4063cf4ba2d4e12c277479399d4489e45a48b1013d8d54b5a589784fe7158978 browser_elf.dll (cookie dumping)
12b15f31f295416417f1e028904a4e10a0c8ec39dd00bac7df4887c194f2865b browser.ex

\DISK2

8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HPCustParticUI.exe (Sideload)
7ea21215968c43f9fe28f94926e3547f2f7a0e35cdf40392b0b6aea80fe11314 HPCustPartUI.dll (Stealer)
c9121c7874d2fd88ff7af35eb3f3cd18ab7162390db008043037383cdad6ff56 HPCustPartUI.log (Ecnrypted stealer config)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR120.dll

\DISKM

8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HPCustParticUI.exe (Sideload)
788fe764f6f5e0fff31b06fd8b94ee0cf51a3082c1321d8db96708c2a6abc3ee HPCustPartUI.dll (Stealer)
62d770f240cecebd6cf725df05ab1e863d83895abc9396664a6090dbcc983d6f HPCustPartUI.log (Ecnrypted stealer config)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR120.dll

\GDU

d12a1750980ef3943c6d7e152948059261944b8afe06b8a280b7fbe61aba3c9b rar.dat (Config)
e64b533d60a21ca8ddbfcf8a1b154ed351383b0196d534bf229101a6cc4d1931 rar330.exe (RAR)
def8fdb95bb53514698b9df1c64e329adfca59adf2e898c3daab16f1e4760bc6 RarCon.SFX (Exfiltrator)
4f54a6555a7a3bec84e8193d2ff9ae75eb7f06110505e78337fa2f515790a562 Samvd.exe
375e88d1f38604c901f2b9fd5b9ada4c44c1f4c172f7cd58cd67e9248ff966ab SmadHook32c.dll (Loader)

\GDU-OLD

197d0ad8e3f6591e4493daaee9e52e53ecf192e32f9d167c67f2ffb408c76f2c AtlTraceTool8.exe
33f631c0b561199b5feb9020faa99e50efa9f421d7484ffa640c5561494726da mfc110u.dll
45a61f4b7e5798f1389a7d6abc8a924c37db6f51552b4cafc901e7e4a50dabc6 msvcr110.dll
db75b25b69b7b6f3206226461d8bde7c05049922dc463e8932d11710fad74833 piz.exe (Collector)
46811fc41623677637aaadcfbe89811d187b390bfd7e4f3e8efd2dd1d078a631 rar.dat (config)
0dcaf08b7b1f8de3999af567144b13f36bea3a68f46f81f8443a81a50a86a09c atltracetoolui.dll (Loader)

\GDU1

2c17b68040dda192939e4b7f65b2935cb6c467b8a4b2c3d512bde6cc5a60adaf cache (Exfiltrator)
e412569c23722c469ee533efb62bbded53d1909b58c8cf7bff9897c466c9df9a CefBrowser.dll (Loader)
cb8a83b590893daa9b02b8e1a1c9afb68d6f2a82c9e0d2d2c63a36a510f6fda3 CefSub.exe
beb44eadd141b7ae46e40e1bf888c302cb7096826e772f0b20ce6f213c69058d piz.exe (Collector)
46811fc41623677637aaadcfbe89811d187b390bfd7e4f3e8efd2dd1d078a631 rar.dat (config)

\GDU2

2c17b68040dda192939e4b7f65b2935cb6c467b8a4b2c3d512bde6cc5a60adaf cache (Exfiltrator)
e412569c23722c469ee533efb62bbded53d1909b58c8cf7bff9897c466c9df9a CefBrowser.dll (Loader)
cb8a83b590893daa9b02b8e1a1c9afb68d6f2a82c9e0d2d2c63a36a510f6fda3 CefSub.exe
390d75e6c7fc1cf258145dc712c1fac1eb183efccee1b03c058cec1d790e46b1 piz.exe (Collector)
46811fc41623677637aaadcfbe89811d187b390bfd7e4f3e8efd2dd1d078a631 rar.dat (config)
869b8dd87e402049eae435de3de1e15a021d9fcbf79a20be3b030d3782599903 vntfxf32.dll

\HT3

59cf961f7316656e73b269a86b04836a7a7254f021a8a3132a927b02373225d6 AUG.json (Encrypted and compressed data)
091408cdd56267bc4fb4cb54f2d91701aa8cdcede334a648566eea89f1682925 Vender.dll (Loader)
00bfbbe6e9d0c54312de906be79cc1e9f18b2957856a1215eaff1ac7bb20e66f x.exe

\JSX64

c617016fb8809655f9189648b9b41a727c0b49cdb79a28f13f710d23f3527a64 install.js (Executer)
21bf4631775b6c17f9e94c0901ffbb7718a0e6094582bcb1683b934aca24e18f mozload.dll (RAT)
f4a31d15cd5aa3441e5e31c1add6e0c3551a1aad5abb75f0abd76990f2824acc scx.exe (Installer)
645ee3601aea4c1af8b938f64698bf6c5978b1151aef53e183bb768791c927e2 svchost.dll

\JSX641

73903c2c46b5055380fc2a238c96f7f2ca2a5acf1cd1e568b2d2be0638c68fd1 install.js (Executer)
50bee35c965a99b3f8f722296e4ed6474ca62d96ea5fc4897e7d1563ed173d5e mozload.dll (RAT)
e27bfbe87c78945b1d79fc027c3f0a27a07d0dddc742783bf686c1a8133a2f48 scx.exe (Installer)
8cebfe33cd69747cc1333fe598d9b0331103e0869d6f1b1f75e28b3b8f11243d svchost.dll

\JSX86

c617016fb8809655f9189648b9b41a727c0b49cdb79a28f13f710d23f3527a64 install.js (Executer)
fd1ec183124d2d82dae1dd228de88440bc142cf6430c9c93518e25f1dde052fd mozload.dll (RAT)
9e3788cacb3d38e4e15da7e4887650efa6a3b17a65a314fcb4e059d9f88481a8 scx.exe (Installer)
5e8311c26091839a292e2d12f88378f8093fc739ced86aa1e9ba1b707ad516d8 svchost.dll

\JSX861

73903c2c46b5055380fc2a238c96f7f2ca2a5acf1cd1e568b2d2be0638c68fd1 install.js (Executer)
f9d94c1dcdbcefddb4f1d47291422c6198fd11052aea761acf8b5755802ca922 mozload.dll (RAT)
49a81878ec282c3c9d4dd72920d9283e2c86d0bb96b468e010901b3f4f9c75ed scx.exe (Installer)
79440abf29d1b56cb1c95a12f554fe052e21a865fea56a025e216f342ffbccbd svchost.dll

\KKL

fae5b61723106d44de46b3ec49e80067f63f82f09501142186984a658bc99c38 KBE.dll (Clipboard stealer, keylogger)
ed6b3af0edcd3b57c0616e1b7819b5e1c1e72327300172ff2664b158f65861b2 mscorsvc.dll (Loader)
0809e3b71709f1343086eeb6c820543c1a7119e74eef8ac1aee1f81093abec66 mscorsvw.exe

\KKL1

4afa4582975d31144b3af692f123f87b6400a45475e41fa1822c7acdb17590f0 KBE.dll (Clipboard stealer, keylogger)
9af8336050c40105864bf9314355471494dc631fd88a0b444291b63b941b7822 mscorsvc.dll (Loader)
0809e3b71709f1343086eeb6c820543c1a7119e74eef8ac1aee1f81093abec66 mscorsvw.ex

\MF20211228

8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HPCustParticUI.exe
9f1d1a94026c54396a4c0b6327d317836dc9dc67178810428302efcbf5225a42 HPCustPartUI.dll (Stealer)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR120.dll

\MG

473b4f8b8640a68d1092f6b54b521c6b0ccb1c567eca4a18a2c2da3481bc027a dabs.ex
cfe1447e7515ad831fcfedb9a5c1a721885b0542b775e4028a277a27e724ec73 SensorAware.dll (Figerpring, remote-shell)

\MG44

473b4f8b8640a68d1092f6b54b521c6b0ccb1c567eca4a18a2c2da3481bc027a 44.ex
cfe1447e7515ad831fcfedb9a5c1a721885b0542b775e4028a277a27e724ec73 SensorAware.dll (Figerpring, remote-shell)

\NB

c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e nb.dat (Nbtscan)

\SE1\Bin

8364bae4e2951957403cbe3a78362edb7d41c34f49c81f0336fcb28d1510d5e1 facesdk.dll (Dispatcher)
0d243cbcd1c3654ca318d2d6d08f4e9d293fc85a68d751a52c23b04314c67b99 FacialFeatureDemo.exe
e5bbbf34414426f63e6cd1354c306405e54bf31279829c7542dccfb7d85af0ec GUP.exe
92717951aae89e960b142cef3d273f104051896a3d527a78ca4a88c22b5216a5 gup.xml
7e1c49d45935fb5d20add5baf60400fb64fbf0299a3af3b0be764b2d265e368a libcurl.dll (hides malware files)
390d75e6c7fc1cf258145dc712c1fac1eb183efccee1b03c058cec1d790e46b1 spoololk.exe
abf7bb6eb92f2f358e8e57c1be03efe5a7f81e3d3eb4134257c3483e9e7782c0 VNTFXF32.dll (persistence)

\SE1\Data

1a4e92e09957578cc8d8c1fbdaba55e306e7bcbc6208ee00e33bb37e849156f9 aweu23jj46jm7dc
13cf1c57f1c143c592173b1e91ddb652d5dd1c2015289ac890a37253058b54be bjca3a0e2sfbs
12acd296a009d9e8fbd9511d3c0586f331d450b9c12f651e0554764e50cfb7e7 sf24acvywsake
4a6ed717a2d7f0953e4b25c2652c9a231146f60b35d9a5e3cf782c772727b1bc sf33kasliaeae

\SE3\Bin

61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantecs.exe
a8f3bc45ac0dcf351c028ecabfd68e8e551cd97f8dc0fc6e62e135668cde9277 LDVPOCX.OCX (Dispatcher)
bb6cf240bdabeea90321cab7d48e268df2b5240d84aab0d5ae5ffe415a6943e4 vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe

\SE3\Data

51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
6ded96d7609cc085db57764c40a38379cba50b965f959650ca8d1605ae0411e8 csdkset.dat
a8f0dff3c57621282a1262ddaa559f055f2f2cc717a7695d8bfbf7a6898b843c EdrEpmpCStorages.dat
7659be61fc1e16c4721b451225ec7c8f932e9e7357894ddea3a4ada9583996b5 PchEpmpCStorages.dat
9015378ed6d7537f07e61c78b3c35766d63465970b63d13c9b447dc8bb90e2d7 prodcltdef.dat

\SE4\Bin

61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantecs.exe
01cd1530b0db54c834ef275e0cc617645a23e1f250bc35c248d546c28da220fb vivaldi_elf.dll (hides malware files)
9fb4c9f1995b02ece99b62a4efc0df5c916a1858f57730225f3c419fce0de24c LDVPOCX.OCX (Dispatcher)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe

\SE4\Data

51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
01cd1530b0db54c834ef275e0cc617645a23e1f250bc35c248d546c28da220fb csdkset.dat
baaaffe80060fb89b06ff19dfb6c76835fc6639d81513e2d9e49716f1816ccc4 EdrEpmpCStorages.dat
9fb4c9f1995b02ece99b62a4efc0df5c916a1858f57730225f3c419fce0de24c LDVPOCX.OCX
f488e4e838fa447c9b08fc74d4180faeb465f9070c443625b7515aed7c282fa6 PchEpmpCStorages.dat
ab89d614923b92ce2eb7ed48357b2d1755b8a8f572ead3b32bb63a79e259186d prodcltdef.dat

\SE5\Bin

5828fd07716140e5fefec1b07751378d9b76952e66b2c0fb0a860313d4030b4d LDVPOCX.OCX (Dispatcher)
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantecsy.exe
bb6cf240bdabeea90321cab7d48e268df2b5240d84aab0d5ae5ffe415a6943e4 vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe

\SE5\Data

e6fdd0d22abe3484d57715bd83143e5810b74f3f9dc8780344c66af2c0894d76 aweu23jj46jm7dc
50814a35a9d157405252c8ba52c12d1cf5adf137598173c6522cbe058e14b7ff bjca3a0e2sfbs
1d68f4afd0fd908d35db6d9710ab2fc92fb5ca739d6351e1bf513e068fbd00a0 sf24acvywsake
5427cd51f0120a27ed75d3ac27d6f8eac6f27c54d8658236a52a281d6433496b sf33kasliaeae

\SE6\Bin

a67094334ae2135e50bf2074f08d3a99075a53a174da6bdf22eca54293bb8e9b vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe
bd4635d582413f84ac83adbb4b449b18bac4fc87ca000d0c7be84ad0f9caf68e wsc_proxy.exe
e0c240f5776d158da7529d8c0e3d5be4d6f007e51e4be570e05b744d0452011d wsc.dll (Dispatcher)

\SE6\Data

51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
7620acb11f0471515079a69ee2cec0cd74485fb13c779d41c2b43b87718c63ff aweu23jj46jm7dc
3fc3fb81a43b9ac155e42367769eb5c0d6dd08c06a025ba93697c6b2667bf1e7 bjca3a0e2sfbs
f2c5004450a749bef14ee779e1c8e4c08702f089248d0a282e6a679d29b0996d sf24acvywsake
10d58013b8a34e10e8548b016154963097dcff15e5673bf24e8ed18513ad4a64 sf33kasliaeae

\SE7\Bin

e5bbbf34414426f63e6cd1354c306405e54bf31279829c7542dccfb7d85af0ec GUP.exe
92717951aae89e960b142cef3d273f104051896a3d527a78ca4a88c22b5216a5 gup.xml
7e1c49d45935fb5d20add5baf60400fb64fbf0299a3af3b0be764b2d265e368a libcurl.dll (hides malware files)
bd4635d582413f84ac83adbb4b449b18bac4fc87ca000d0c7be84ad0f9caf68e wsc_proxy.exe
e4ddf5af63fdfe85c5a4573d4768699ebdaa5b5b67b7cb6834840c696808a8e5 wsc.dll (Dispatcher)

\SE7\Data

b7a38292131c131d75413133f101114a1b72bd02e27cc6aea7a836ff964f961f sf24acvywsake
28aadf5b14ba0cb38a33ab53796dba12e7d59479744f0cca225b10be44730b9c sf33kasliaeae
ec56a6fa6804e47f331daee1460c3d07e01fe45edac5d6b1feb01fbbd8396f91 aweu23jj46jm7dc
e32447bd309a6941a1fff4fa559376d9c723afd1b9ce2a1c2dced4b9db6a6f6a bjca3a0e2sfbs

\SSE

51c3d115e0173e3ba6eeaea3d53b86bce45367e50feed82d8efed2065d845d28 3.8.2259.42.manifest
5dafacfa147f087dd0a706cf274e20cbb58f634ba14424d3433efc2e829aa7cd csdkset.dat
b9924c66506ccad566d6c26b8db499e498a9dc840acacb2d8d3bf9d73818814a EdrEpmpCStorages.dat
180a2f3eb004f93590e4fb18cdc3dd6e18815587637ac354ca99f7513aa63633 LDVPOCX.OCX (Dispatcher)
9add5663bc846b4b7cdefcd0e09b882e2f16f755e2e6540efc6ea2072c93f3f2 PchEpmpCStorages.dat
756d1cb0e74b309d53d4f16b043514da128c8b3b89c7d5e46897b61f74bad2d7 prodcltdef.dat
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantec.exe
bb6cf240bdabeea90321cab7d48e268df2b5240d84aab0d5ae5ffe415a6943e4 vivaldi_elf.dll (hides malware files)
58e7af5eb1acb5c9bee821d59054c69263aed3dce1b95616255dea7114ad8494 vivaldi.exe

\T3YK

3c0d3783a5ccdecf3786db0053b1352d6fb5a37d9081cc32ec6d5bb611064ce3 coreclr.dll (remote shell)
f11009988b813821857c8d2db0f88e1d45b20762f62a3cf432339f352b12cefe ygfdt.exe

\U5_2

2a971ba79f9f7378e11a47dcafa78e9fe4b1f0c659f7f310209d3e6671d5dc31 Ativir.csc (bundled payloads)
9cd8c5d34fd460dd0e240f5e54ade689d808469d6da5e0bd087cc71e6f851c6a core.exe (executes path from config)
caeb48fd04a5fe8b0b4bd32b538ed5f1f303b0487037cf37864f0b5665ff093a install_.exe
2f2a5e5cdb262cd62b43b88bf1e9cfb40a26eac5897616b9eacec4e25d95cbb9 PlugInInstallerUtility2.exe
a90e048c74697775bba2e4c4bfa45d369e44e9a020a83956aa44a50ab8a9a249 PlugInInstallLib.dll

\UC

f349183462f1aeac8d3afb43c723af0252c157d376637f30fb7c87fdf80ee965 libmlt-6.dll (UAC bypass)
a23dbce5bcde8ce541b8f326a951d29f6241280d944a1e921ca8658d3d4b65ac melt_64.exe

\WD

8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6 HP
97efd0abf726acfc1a5b4a0b460a727724f43ef9f1e788bada4942d715d4ab87 HPD (Loader)
86e39b5995af0e042fcdaa85fe2aefd7c9ddc7ad65e6327bd5e7058bc3ab615f MSVCR1
5f31d558417528b4c635afd6c17347dc393c7dfcecfb79040fe97d9f1abf3776 S (korplug)

\X

28bed0d5bcfb2d5597af881a2be3098327f2d83f14948c6a46cde3cd0776eb1c x.ex (status checker)

\YK41

edab53d39734965a7cadc2a21662d6a16c9b04b2961dfe9eb76aeda040786e25 hp_ui.xslbcdsj (encrypted Korplug)
071558464f6d067f3044b7ee3819fcb3a049b8be3535043db41123c2fde5d451 SHELLSEL.ocx (Loader)
61d1943f0b702f4c16bb37228ade1d8f0ef4675b480921950d026c82e4a65fde Symantec.exe

\YK51LOW

cb8a83b590893daa9b02b8e1a1c9afb68d6f2a82c9e0d2d2c63a36a510f6fda3 atkexComSvcRes.exe
9bdccd5e4617dfbcaf85228c60703369a8848ad8bb86e00e75e504a26fbe932a CefBrowser.dll
b29b38217921a6b36113049bd9cb4fb2ec52816bff7cd731621ff2fa3dbc7b01 DP45126C.lfl (Decryptor)
90a29c688ce683fb2201145faac00cb44c3d5566697279b68960c6bc3208ae84 GoogleUpdate.exe
fa56ba25861f1b5040afd04bfbfd36353004cd6b2c457971fb01db26ff002f35 GoogleUpdateOnDemand.exe
c9ed69e7bf233ba1edd18a1f91671faee9b7756aa77fe517319098706e78cde5 SbieDll.dll (Loader)

The post Hitching a ride with Mustang Panda appeared first on Avast Threat Labs.

❌
❌