XWorm: Technical Analysis of a New Malware Version 

In this article, we will take a look at the latest version of an XWorm sample — a widespread malicious program that is advertised for sale on underground forums. 

We will analyze the functionality of our sample, as well as extract its configuration. 

Let’s get started. 

What is XWorm Malware? 

XWorm is a malware that targets Windows operating systems. It is known for its stealth and persistence, and a wide range of malicious activities, spanning from remote desktop control to ransomware and information theft.  

Unfortunately, adversaries employ this threat widely —it’s not uncommon to see it in ANY.RUN’s top 10 most used malware by uploads. 

TOP10 last week's threats by uploads 📊
⬆️ #Redline 219 (215)
⬆️ #Njrat 144 (84)
⬆️ #Agenttesla 112 (102)
⬆️ #Lumma 84 (65)
⬆️ #Asyncrat 84 (49)
⬆️ #Remcos 82 (58)
⬆️ #Amadey 80 (65)
⬇️ #Arkei 54 (57)
⬇️ #Xworm 43 (55)
⬇️ #Vidar 33 (35)https://t.co/sSi7yan9BV pic.twitter.com/0VNaiRojZh

— ANY.RUN (@anyrun_app) August 7, 2023

XWorm dynamic sandbox analysis 

While searching for new threats, we discovered an interesting sample, uploaded by our users to Public submissions. It was downloaded from the file hosting “Mediafire” in a RAR archive with a password: 

After launching, the threat was identified by Suricata’s network rules as XWorm: 

We decided to check the sample on VT to confirm that it was indeed XWorm, but at the time of writing this article, we were unable to find it there: 

The initial analysis, according to the indicators set on process 2784, revealed that the software adds its shortcut to the startup (MITRE T1547.001) and uses the task scheduler (MITRE T1053.005): 

The use of the scheduler is necessary to restart the software with elevated privileges, as indicated by the “/RL HIGHEST” parameter. 

According to the file operation data, the software is installed in the Public directory (MITRE T1074.001): 

Interestingly, the software attempts to connect to a remote server, but no response is received (MITRE T1571): 

We decided to restart the sample and check for additional activities. Unfortunately, it crashed almost immediately after launch: 

We became interested in investigating the cause of the “crash,” and we found that the user-launched sample and the sample restarted by us exhibited different behavior patterns. Specifically, the restarted sample queries a service to determine the external IP address (MITRE T1590.005) before crashing. Typically, in addition to the IP address, such services provide the ability to determine whether the software is running on a virtual host: 

This is precisely what XWorm does — it attempts to verify whether it’s running on a user’s physical machine or not. 

To solve this problem, ANY.RUN has a useful feature called Residential Proxy which allows you to hide your actual location and convinces the software that it’s running on a real user’s machine. You can choose any location, in case it’s targeted malware requiring IP addresses from specific countries: 

Restarting with the Residential Proxy option enabled was successful, and XWorm exhibited its activity.  

Additionally, we activated the MITM proxy option to find out what data is being transmitted to Telegram (MITRE T1102): 

It’s evident that the software transmits its version (XWorm V3.1), the machine’s username, the operating system version, and likely a hash of a new victim (MITRE T1082). 

Xworm static analysis 

The first step is to place our subject into the DIE — a utility for initial analysis. 

As we can see, we are dealing with a .NET variation, so we promptly opened it in dnSpy. 

We are immediately met with an unfavorable picture — all the program’s members were subjected to obfuscation (MITRE T1027). DIE could not recognize the packer even with the “Heuristic scan” being checked. 

Our first thought was to try using de4dot to simplify further analysis. 

As we can see, not much has changed, so we must continue analyzing what we have. 

Reverse engineering: additional anti-evasion techniques and persistence gain 

To slow down the analysis and hide from detection systems, the sample employs the following technologies: 

1. Virtualization detection using the WMI query “Select * from Win32_ComputerSystem” and checking for operation within VmWare or VirtualBox environments (MITRE T1047) 

2. Debugger detection using the CheckRemoteDebuggerPresent API function 

3. Checking for the loaded dynamic library SbieDll.dll, characteristic of Sandboxie, which is a sandbox-based isolation program. 

4. A query to check whether the current machine is hosted or located in a data center (this finally clarifies why the sample initially “crashed”) 

The sample also gains a foothold by utilizing the registry and the task scheduler: 

Reverse engineering: Xworm config extraction 

After a brief review of the methods’ contents, a constructor was found that bears a striking resemblance to a block containing settings. 

After examining cross-references, we arrive at a method that looks like this: 

As we can see, some fields undergo a reassignment stage, after processing by the method “Vc1fSJ4D04O6qGeP2fzA5lFCv8a7buXvJb4sHwuhuifI09pX.” Let’s take a closer look at it. 

First, an MD5 hash is computed from the value of the field “hArf0quX6jL4F88ywQTiLn52eBzsJ6HreaOqb0WGSa89u” from the presumed settings section.  

Then the obtained value is copied twice into a temporary array (perhaps the malware developer made an off-by-one error when using the Array.Copy method, resulting in the MD5 not being copied entirely twice; the last copied byte after the first copying is overwritten by the subsequent copying, so that the last byte in the resulting array is always zero). The obtained array is used as a key to decrypt the incoming base64 strings using AES in ECB mode. 

It’s also interesting that the field used is also a mutex. 

Now we have all the necessary information for decrypting the settings. 

Our final AES key looks like this: “01d31d5e811fce422987107f962c4001d31d5e811fce422987107f962c406600.” 

And here we have reached the core of our target’s sample. 

The result can be viewed in CyberChef here. 

The final config mapping is as follows: 

When the goal isn’t to study the malware in-depth but rather to quickly obtain the configuration, this can be efficiently achieved by running the sample in ANY.RUN. This method provides a straightforward way to access the necessary information without the need for extensive analysis, saving potentially hours of work. 

See it in action for yourself here. 

IOCs 

Analyzed files

MITRE (ARMATTACK)

DNS requests 

• 6[.]tcp[.]eu[.]ngrok[.]io 

More samples for your research

https://app.any.run/tasks/d3858744-f1b2-4a9b-8ef7-deccada2a160/

https://app.any.run/tasks/75f66fd6-d989-4f06-a348-c65e135e8ab4/

https://app.any.run/tasks/5fab7db5-267e-46f6-a374-0f42de1cb328/

https://app.any.run/tasks/b9275944-39fe-42cb-9eae-6b2e05f0892f/

https://app.any.run/tasks/803758bf-387b-42e2-80cc-f20e7140cac4/

Interested in more content like this? Check out our in-depth analysis of the latest .NET variant of LaplasClipper or read a break-down and guide to GuLoader deobfuscation strategies. 

A few words about ANY.RUN 

ANY.RUN is a cloud malware sandbox that handles the heavy lifting of malware analysis for SOC and DFIR teams. Every day, 300,000 professionals use our platform to investigate incidents and streamline threat analysis.  

Request a demo today and enjoy 14 days of free access to our Enterprise plan. 

Request demo →