XWorm V6: Advanced Evasion and AMSI Bypass Capabilities Revealed

Summary

In September 2024, Netskope Threat Labs reported on the XWorm malware and its infection chain. We revealed new XWorm command and control (C2) commands and dissected its notable features. After nearly a year of tracking this malware, we discovered a new version (version 6.0) in the wild, which introduced new features such as process protection and enhanced anti-analysis capabilities. Consistent with the previously reported infection chain, XWorm is still being executed in memory and continues to employ execution evasion techniques. In this blog post, we will dissect the infection chain along with the updates in the latest XWorm version.

Key Findings

The emergence of a new XWorm variant indicates the malware is still under active development and likely to be used in the near future.
This latest version includes additional features for maintaining persistence and evading analysis.
The loader includes new Antimalware Scan Interface (AMSI)-bypass functionality using in-memory modification of CLR.DLL to avoid detection.

VBScript dropper

XWorm 6.0 starts its infection chain through a VBScript file likely delivered via social engineering. The VBScript embeds and reconstructs another obfuscated VBScript payload at runtime. It starts with a variable array of character codes. It iterates over the array in reverse order using UBound, and each numeric value is converted to its corresponding Unicode character using VBScript’s ChrW function. These characters are then concatenated to form the actual malicious VBScript and execute it using the eval function.

The reconstructed VBScript performs the following functions:

Removes its own Zone.Identifier Alternate Data Stream.
Executes a PowerShell command using the Run method. The PowerShell command downloads a PowerShell script and saves it locally as “wolf-8372-4236-2751-hunter-978-ghost-9314.ps1” in the temporary files (TEMP) folder.
Copies the running VBScript to a new file named update.vbs in both the temporary files (TEMP) folder and the Application Data (APPDATA) folder.
Adds persistence on the victim’s device by adding the update.vbs in both the TEMP and APPDATE folder to the Run registry key.

Persistence

XWorm 6.0 achieves persistence by storing the update.vbs in both the TEMP and APPDATA folders and adding these paths to the registry run key. This differs from our previously reported XWorm sample, which relied on scheduled tasks to maintain access.

The XWorm client builder offers attackers the flexibility to select persistence methods, including the registry run key, scheduled tasks, or the startup folder, indicating that we will continue to see variants using any of these persistence methods.

AMSI bypass through CLR.DLL patching

The PowerShell script wolf-8372-4236-2751-hunter-978-ghost-9314.ps1 begins by implementing an Antimalware Scan Interface (AMSI) bypass by modifying the instance of the Common Language Runtime library (CLR.DLL) in memory.

It does so by retrieving system memory information and iterating through all memory regions of the current process using the GetCurrentProcess() function. It searches for CLR.DLL within these regions and looks for the string “AmsiScanBuffer”. When found, it replaces the string with null bytes.As a result, the CLR can no longer resolve the AmsiScanBuffer method, preventing it from submitting suspicious memory content to AMSI for inspection. The attacker copied the script from a public GitHub repository, replacing some function names.

It then downloads the XWorm binary from a public GitHub repository using the .NET HTTP.client class. It then loads it into memory using the Assembly.Load method, invoking it at its entry point.

XWorm V6.0

This XWorm 6.0 sample, named Microsoft.exe, retains the same operational design as the previously reported version, with some additional improvements. This section explores the key differences.

The application begins by retrieving its configuration from a base-64 encoded string. The XWorm includes a hardcoded Command and Control (C2) server. While this behavior is common among other samples, it differs from Netskope Threat Labs’ earlier reported version, which receives the C2 address through a command line argument from a PowerShell script.

XWorm running as a critical process

Another new feature we discovered is XWorm’s ability to prevent process termination by marking itself as a critical process. Setting a process critical requires elevated privilege, which is why it checks first if it is running with administrator privileges by verifying if the current user belongs to the WindowsBuiltInRole.Administrator group, which corresponds to the value 544.

If XWorm is executed with administrator privileges, it invokes EnterDebugMode to enable SeDebugPrivilege, permitting it to flag the XWorm process as critical. Users cannot terminate a critical process without administrator privileges. If an elevated user forcefully stops it, the system will crash and require a reboot, upon which XWorm will be started again using the registry run key.

Anti-analysis

XWorm incorporates multiple anti-analysis techniques. While the previous anti-analysis techniques remain in place, we have identified a new technique that was not present in earlier samples.

XWorm now terminates itself when it detects execution on Windows XP. This change may be an effort to prevent researchers or analysts from running the payload in a sandbox or legacy analysis environment. This anti-analysis technique is also seen in the open-source AsyncRAT.

Another anti-analysis technique named ‘Anyrun’ suggests that it detects the Any.Run sandbox. However, it actually uses the IP-API service to check if the device’s IP address is associated with data centers or hosting providers. If it detects that the IP belongs to either of these categories, the XWorm process will be terminated.

Netskope Detection

Netskope Threat Protection
- GT:VB.ObfDldr.15.BCAA3F9E

Netskope Advanced Threat Protection provides proactive coverage against this threat.
- Gen.Detect.By.NSCloudSandbox.tr

Conclusions

The latest XWorm version observed in the wild introduces new features. Notably, it marks its process as critical to prevent termination, and improves anti-analysis by avoiding execution in devices running Windows XP. Additionally, XWorm is still executed directly in memory, and bypasses AMSI by using in-memory patching of clr.dll. These details can assist defenders in detecting XWorm within their environments and developing detection strategies based on its techniques.