Article Details

Inside the Code of a New XWorm Variant. XWorm is a relatively new representative of the remote access trojan cohort that has already earned its spot among the most persistent threats across the globe. Since 2022, when it was first observed by researchers, it has undergone a number of major updates that have significantly enhanced its functionality and solidified its staying power. The analyst team at ANY.RUN came across the newest version of the malware and could not refuse the opportunity of taking it apart to examine XWorm mechanics configurations. Here is how they did it and what they found. The XWorm sample's source The sample in question was discovered in ANY. RUN's database of malware, a repository containing detailed analysis reports on all files and links that have been uploaded by users of the sandbox in public mode. A quick look at the results of the analysis revealed that the sample was initially distributed via MediaFire, a file-hosting service. The malware was packaged in a RAR archive and protected by a password. Upon execution, the threat was instantly detected by Suricata rules and identified as XWorm. XWorm's Tactics, Techniques, and Procedures (TTPs) The sandbox report highlighted several techniques used by the sample: MITRE T1547.001: XWorm added its shortcut to the Startup directory. MITRE T1053.005: It used the task scheduler to restart itself with elevated privileges, as indicated by the "/RL HIGHEST" parameter. MITRE T1074.001: The software was installed in the Public directory. MITRE T1571: The malware tried to connect to a remote server, but no response was received. XWorm's failed attempt to evade sandbox analysis Since the initial analysis report was several days old, the team decided to run the sample through the sandbox once again to check for new activities. However, after launch, the malware crashed almost immediately. A short investigation made it apparent that the sample now queried a special service to determine if it was running in a virtual sandbox. Essentially, XWorm developers implemented an evasion technique, which caused the malicious software to shut down as soon as it sensed a virtualized environment. To overcome this, the team enabled Residential Proxy in the sandbox settings. This feature replaces the virtual machine's datacenter IP address with one from an actual ISP, making the malware think it is running on a real user's machine. After rerunning the sample with Residential Proxy enabled, XWorm was successfully executed and began its activity. Sign up and get INSTANT access to analyze this sample, and any other, on ANY.RUN. Don't miss out on the ultimate tool to understand and combat threats. On top of that, with the help of the MITM proxy feature, it was possible to extract the information transmitted by XWorm to Telegram (MITRE T1102). The data included: the malware's version (XWorm V3.1), the machine's username, the OS version, and likely the victim's hash. Static analysis of the new XWorm variant After gathering all the crucial information provided by the sandbox, the analysts began the static analysis phase of their research. The first step was to load the sample into Detect it Easy (DIE), an industry standard for initial malware analysis. The program quickly determined that it was a .NET variation of XWorm. From there, the only logical step for the team was to open the file in dnSpy, a .NET debugger, which promptly revealed that the binary was subject to heavy obfuscation. However, DIE failed to recognize the packer even using Heuristic scanning. Employing de4dot, a .NET deobfuscator and unpacker, also did not have any effect. More of XWorm's evasion and persistence techniques Further investigation of the malicious binary allowed the team to uncover additional pieces of the puzzle. Specifically, a number of extra mechanics utilized by the malware were found: Virtualization detection: XWorm used the WMI query "Select * from Win32_ComputerSystem" to check for VmWare or VirtualBox environments. Debugger detection: It also ran the CheckRemoteDebuggerPresent API function to see if it was being debugged. Sandboxie detection: The binary scanned the system to see if the SbieDll.dll library was loaded. Datacenter IP check: Xworm queried the machine to determine if it was hosted in a data center. Persistence: XWorm used the registry and the task scheduler to establish a persistent presence on the system. Extraction of XWorm's configuration Next, the analysts found a constructor that looked like a block containing settings. They used a function to reassign some of its fields. The malware first computed an MD5 hash from a value in the presumed settings section. It then copied the obtained value twice into a temporary array, but due to an off-by-one error, the MD5 was not being copied entirely twice. The team used the obtained array as a key to decrypt the incoming base64 strings using AES in ECB mode. They also found that the field used was a mutex. The entire process is described in detail in ANY.RUN's blog article "XWorm: Technical Analysis of a New Malware Version." XWorm's configuration The complete configuration of XWorm's new variant is as follows: Conclusion Obtaining configurations of the latest malware is crucial but time-consuming. To make it more efficient, you can run your samples through the ANY.RUN sandbox to access the necessary information in seconds. Check it yourself using the XWorm sample. Plus, ANY.RUN offers a 14-day free trial of its top plan to security teams to help them test the capabilities of the service.