O Netskope Threat Labs revela as técnicas furtivas do novo XWorm

Sumário

XWorm is a relatively new versatile tool that was discovered in 2022. It enables attackers to carry out a variety of functions, which include accessing sensitive information, gaining remote access, and deploying additional malware. The multifaceted nature of XWorm is appealing to threat actors, as evidenced by its alleged use earlier this year by threat actors such as NullBulge and TA558.

Through Netskope Threat Labs hunting efforts, we uncovered XWorm’s latest version in the wild. In this blog post, we will breakdown the following:

• The infection chain leading to the execution of XWorm.
• Evasive execution of XWorm’s DLL loader through reflective code loading. 
• The injection of XWorm into a legitimate process.
• XWorm’s new features, which include removal of plugins and a network command that reports XWorm’s response time, along with other noteworthy commands.
• Attacker notification after infection using Telegram.

XWorm execution flow

The following is the summary of XWorm’s execution flow:

1. Infection chain starts with WSF downloading and executing a PowerShell script hosted on paste.ee
2. The PowerShell script performs the following actions:
   A. Creates three scripts namely VsLabs.vbs, VsEnhance.bat, and VsLabsData.ps1.
   B. Creates a scheduled task.
   C. Sends a Telegram notification to the attacker.
3. Scheduled task executes the VBScript named VsLabs.vbs.
4. VBScript executes a batch file named VsEnhance.bat.
5. Batch file executes a PowerShell script named VsLabsData.ps1.
6. The PowerShell script loads a malicious DLL through reflective code loading.
7. The malicious DLL injects XWorm on a legitimate process and executes it.

XWorm dropper delivered via Windows Script File (WSF)

The infection chain starts with a Windows Script File (WSF), likely delivered through phishing. The WSF file starts with several paragraphs about the Social Security Administration through a series of commented lines. However it ends with a VBScript that downloads and executes a PowerShell script using Wscript.Shell. To avoid static detection, the command to download the PowerShell script is hex encoded and requires string concatenation.

PowerShell script analysis

The VBScript downloads a PowerShell script stored on Paste.ee, a legitimate Pastebin website. Using legitimate websites to store malicious code helps attackers fly under the defender’s radar. To avoid detection over the wire, the PowerShell script performs multiple string obfuscation, including escape characters and string concatenation. The PowerShell script creates a folder named “Visuals” on the path: “C:\ProgramData\Music\Visuals”. Afterwards, it generates PowerShell, batch and VBScripts (VsLabsData.ps1, VsEnhance.bat, and VsLabs.vbs) and stores it in the folder created.

The VBScript named VsLabs.vbs starts the execution chain by running a batch file named VsEnhance.bat using WScript.Shell. And the VsEnhance.bat executes the PowerShell script named VsLabsData.ps1.

VsLabsData.ps1

VsLabsData.ps1 performs the following actions:

1. Define two payloads as hex strings using variable $cake for XWorm (XClient3.exe) and $oven for the DLL loader (NewPE2).
2. Create a scheduled task named ‘MicroSoftVisualsUpdater’. 
3. Send a notification to the attacker via Telegram.
4. Execute the DLL loader that injects XWorm into a legitimate process.

Let’s take a closer look at how the PowerShell script accomplishes these steps.

Persistence

Persistence of XWorm is achieved through a scheduled task named MicrosoftVisualUpdater. This task is triggered a minute after it is created, and will then continue to trigger every 15 minutes. It is set to execute the VBscript VsEnhance.bat.

Telegram notification

Once the PowerShell script VsLabsData.ps1 completes its routine, it will send a Telegram message to the attacker. The message contains the public IP address of the victim with an attribution to “XYZCRYPTER” as the attacker.

NewPE2 executed through code loading, injecting XWorm into a legitimate process

Unlike previously reported XWorm instances where the payload was downloaded, the analyzed file stores the actual payloads inside the PowerShell script using the variables $cake and $oven. To avoid static detection, the XWorm and NewPE2 are defined as hex strings and are separated with an underscore. Once underscores are replaced the loader is executed using reflective code loading.