XWorm 6.0: New Variant Uses AMSI Bypass & Critical Process Trick to Evade Detection and Crash Systems
Do Son 
According to the latest report from Netskope Threat Labs, a new version of the XWorm malware—XWorm 6.0—has been discovered in the wild. This sophisticated variant brings with it new persistence, evasion, and anti-analysis techniques, making it a threat to enterprises and security teams alike.
“The emergence of a new XWorm variant indicates the malware is still under active development and likely to be used in the near future,” Netskope’s researchers warn.
While the new XWorm retains the in-memory execution style of its predecessors, it now arrives via a VBScript dropper, likely delivered through a social engineering vector. The script reconstructs a secondary, obfuscated VBScript at runtime using a reverse iteration of character codes and the ChrW function, eventually executing it via eval().
This reconstructed script performs several key actions:
- Deletes its Zone.Identifier to hide download origin.
- Downloads a PowerShell payload, stored as wolf-8372-4236-2751-hunter-978-ghost-9314.ps1.
- Copies itself as update.vbs to both TEMP and APPDATA.
- Establishes persistence by adding update.vbs to the Windows Run registry key.
“This differs from our previously reported XWorm sample, which relied on scheduled tasks to maintain access,” the report notes.
One of the more advanced techniques used by XWorm 6.0 is its bypass of the Windows Antimalware Scan Interface (AMSI). The PowerShell script manipulates memory directly:
“It searches for CLR.DLL… and looks for the string ‘AmsiScanBuffer’. When found, it replaces the string with null bytes,” preventing the AMSI from scanning XWorm’s malicious code.
This AMSI bypass is based on open-source code publicly available on GitHub, subtly modified to evade signature-based detection.
Once loaded into memory, the malware retrieves its configuration from a Base64-encoded string and initiates communication with a hardcoded Command and Control (C2) server—unlike previous versions, which accepted C2 addresses dynamically.
More notably, XWorm now marks itself as a critical process—an aggressive technique that prevents users from killing the malware without administrator privileges. If a user does force it closed, the entire system will crash and reboot, only for XWorm to reactivate via the registry key.
“Users cannot terminate a critical process without administrator privileges… if an elevated user forcefully stops it, the system will crash,” the report explains.
To avoid sandboxing and analysis, XWorm 6.0 has adopted environment-aware execution conditions. The malware now terminates itself if it detects it’s running on Windows XP, a common OS in sandbox environments.
“This change may be an effort to prevent researchers or analysts from running the payload in a sandbox or legacy analysis environment.”
It also uses the IP-API service to detect if the system IP address belongs to a data center or cloud provider, terminating the process if such an environment is detected.
Related Posts:
- XWorm’s Shape-Shifting Arsenal: RAT Evolves to Deliver LockBit Ransomware, Evades Detection
- XWorm Unveils Stealthier Techniques in Latest Malware Evolution
- Microsoft Enhances Exchange and SharePoint Security with AMSI Integration
- Over 18,000 Devices Compromised in XWorm RAT Builder Campaign
- With null characters, Malicious code bypassed security checking in Windows 10
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
