X32bridge.dll Was Not Found

[Sandra Grady]

The team's attention was first drawn to the command line execution of D:\RECYCLER.BIN\files\x32dbg.exe which was flagged by a VisionOne Workbench alert. Further investigation revealed that this path led to a hidden folder on the USB storage device, which was found to contain a number of threat components.

Subsequently, the file C:\ProgramData\UsersDate\Windows_NT\Windows\User\Desktop\x32dbg.exe, a duplicate of the original file, was invoked. The following command line was used to invoke the dropped file:

As a result, a full set of the same files were present in three different directories. This indicated a clear attempt to establish persistence and evade detection by placing copies of the malicious files in multiple locations in the compromised system, specifically:

To ensure continued access to the compromised systems, attacker used techniques involving the installation of persistence in the registry, the creation of scheduled tasks to maintain access (even in case of system restarts), the implementation of changes in credentials, and other potential disruptions that could result in lost access.

We noticed the creation of a scheduled task via the schtasks command line utility to run a task at a specific time. In this case, the scheduled task is set to execute the x32dbg.exe file, the open source debugger tool that side loads PlugX, every five minutes. The task is disguised under the name "LKUFORYOU_1" to make it more difficult to detect.

Further evidence supporting the persistence created by the scheduled task was discovered in the event logs via Event ID 100, which clearly showed the successful execution of the file (depicted in Figure 10).

Figure 11 depicts where run registry keys were installed for persistence, and the data associated with them. These registry keys and values enable the threat to maintain persistence by automatically executing the x32dbg.exe file every time the user logs in.

Through reverse engineering, we were able to gain a deep understanding of how the threat operates. By analyzing the tactics and techniques used by the attacker, we can identify and prevent similar attacks in the future.

Our analysis of this attack in VisionOne revealed that the threat heavily relied on DLL sideloading, which is a typical behavior of PlugX. However, this variant was unique in that it employed several components to perform various functions, including persistence, propagation, and backdoor communication. As a result, we were able to identify and isolate the different files used by the attacker in their routine.

The file x32dbg.exe is a legitimate executable of a debugging software which, when executed, imports x32bridge.dll and calls on the functions BridgeStart and BridgeInit. The attackers took advantage of this and replaced the DLL with their own, containing the same export functions but executing entirely different codes:

It then enumerates all drives and takes note of removable drives for its propagation routine. When found, it will delete files from any existing RECYCLER.BIN folder before creating a new one. It will copy its components that have the file extensions .exe, .dll, and .dat to the newly created folder and add a desktop.ini file.

The discovery and analysis of the malware attack using the open-source debugger tool x32dbg.exe shows us that DLL side loading is still used by threat actors today because it is an effective way to circumvent security measures and gain control of a target system. Despite advances in security technology, attackers continue to use this technique since it exploits a fundamental trust in legitimate applications. This technique will remain viable for attackers to deliver malware and gain access to sensitive information as long as systems and applications continue to trust and load dynamic libraries.

This incident highlights the importance of having a strong and robust cybersecurity system in place, as threat actors continue to find new ways to exploit vulnerabilities and launch sophisticated attacks. Trend Micro Managed Extended Detection and Response (MxDR) helps in the prevention of DLL sideloading attacks by taking a comprehensive approach to detecting, investigating, and responding to security incidents.

Trend XDR integrates a variety of security technologies, such as endpoint protection, network security, and cloud security, to provide a comprehensive picture of an organization's security posture. This enables MxDR to detect and prevent DLL sideloading attacks by detecting and blocking malicious activity at various stages of the attack lifecycle before it can cause harm. Furthermore, XDR can perform in-depth analysis and investigation of security incidents, allowing organizations to understand the impact and scope of an attack and respond appropriately.

Recently, our Unit 42 incident response team was engaged in a Black Basta breach response that uncovered several tools and malware samples on the victim's machines, including GootLoader malware, Brute Ratel C4 red-teaming tool and an older PlugX malware sample. The PlugX malware stood out to us as this variant infects any attached removable USB media devices such as floppy, thumb or flash drives and any additional systems the USB is later plugged into.

This PlugX malware also hides actor files in a USB device using a novel technique that works even on the most recent Windows operating systems (OS) at the time of writing this post. This means the malicious files can only be viewed on a Unix-like (*nix) OS or by mounting the USB device in a forensic tool.

We also discovered a similar variant of PlugX in VirusTotal that infects USB devices and copies all Adobe PDF and Microsoft Word files from the host. It places these copies in a hidden folder on the USB device that is created by the malware.

PlugX is a second-stage implant used not only by multiple groups with a Chinese nexus but also by several cybercrime groups. It has been around for over a decade and has been observed in some high-profile cyberattacks, including the U.S. Government Office of Personnel Management (OPM) breach in 2015. It is a modular malware framework, supporting an evolving set of capabilities throughout the years.

It's not uncommon for multiple malware samples to be discovered during an investigation, as occurred in this situation with GootLoader, Brute Ratel C4 and PlugX. Numerous threat actors compromise targets and can coexist simultaneously on the affected machine.

Historically, a PlugX infection begins by hijacking a known and trusted, digitally signed software application to load an actor-created encrypted payload. This technique has been used since 2010 and is listed in the MITRE ATT&CK techniques as Hijack execution flow DLL-Side loading ID: T1574.002 Sub-technique T1574.

In this case, the threat actors decided to hijack a popular and free open source debugging tool for Windows called x64dbg, which is used by the malware analysis/reverse engineering community. X64dbg applications are digitally signed by "Open Source Developer Duncan Ogilvie."

The developers of this tool offer two types of debugger applications: x64 for 64-bit applications and x32 for 32-bit applications. In this case, the actors used x32dbg.exe, which is the 32-bit debugger of x64dbg.

Upon execution of x32dbg.exe, Microsoft Windows will attempt to resolve any dependency files necessary to run the application. That search starts locally (i.e., in the current working directory). If found, the necessary files are loaded and executed.

Once loaded and decrypted in memory, the malware infects the host and any removable USB devices attached with the PlugX malware. Figure 1 below illustrates PlugX DLL side loading using x64dbg DLL hijacking.

Both the hijacking of x64dbg and the association of this behavior with the PlugX malware were reported by Sophos back in November 2020. Their blog refers to this malware as KilllSomeOne, based on a Program Database (PDB) string found in one of the binaries.

Sophos performed an excellent analysis of the samples and touched on the USB infection. We confirmed that our sample matched the behaviors described in their report. From there, we wanted to expand our research by focusing on the USB infection, other USB variants in the wild and links to the PlugX malware.

The technique used by the PlugX malware to hide files in a USB device involves using a certain Unicode character. This hinders Windows Explorer and the command shell (cmd.exe) from displaying the USB directory structure and any files, concealing them from the victim.

The Unicode character used by this PlugX malware for the directories is 00A0 (a whitespace character called a no-break space). The whitespace character prevents the Windows Operating System from rendering the directory name, concealing it rather than leaving a nameless folder in Explorer.

To achieve code execution of the malware from the hidden directory, a Windows shortcut (.lnk) file is created on the root folder of the USB device. The shortcut path to the malware contains the Unicode whitespace character, which is a space that does not cause a line break, but this is not visible when viewed via Windows Explorer, as shown below in Figure 2.

The PlugX malware uses the Component Object Model (COM) interface to create the .lnk files and includes the Unicode character 00A0. It does this by creating an instance of a shell desktop to create the associated Windows shortcut files. The ShellLink SetArguments method is used to set the command line arguments, which include the white space no break Unicode character, as shown in Figure 4 below.

The PlugX malware x32bridge.dll loads x32bridge.dat, which is responsible for implanting the host with malware and infecting any attached removable media USB devices such as floppy, thumb or flash drives. If a removable media device is found, the following steps are performed:

The Windows OS uses a single file to retrieve icon images that are displayed on the desktop as shortcuts or from Windows Explorer files and folders. The Shell32.dll file contains a list of icons and a unique number. In this case, the drive icon and the number 7 are used, as shown below in Figure 5.

c80f0f1006