006 - Decoding XWorm: Introduction

Este artículo también está disponible en español

1. Introduction
2. Initial Exploration and Anti-Analysis Techniques
3. Coming Soon: Defense Evasion and Persistence
4. Coming Soon: Lateral Movement
5. Coming Soon: Keylogger and Cryptocurrency Hijacking
6. Coming Soon: Communication with Telegram, Retrieving a New Variant
7. Coming Soon: Command and Control

If you want to be notified when new posts in this series are published, don’t forget to subscribe to the blog!

1. Introduction #

XWorm, a sophisticated Remote Access Trojan (RAT) developed in .NET, is a favorite tool among cybercriminals due to its extensive feature set and constant updates. From anti-analysis techniques and communication with its creators via Telegram to Bitcoin theft, this malware exemplifies the current threat landscape.

In this seven-part series, we will analyze XWorm step by step, uncovering its internal mechanisms and the techniques it employs to achieve its objectives.

In this first post, we’ll lay the groundwork for understanding XWorm and its analysis. We’ll explore how to identify the type of binary we’re working with, review some basic .NET concepts, and introduce the tools we’ll use throughout the series.

Background #

XWorm was first identified in 2022; since then, it has constantly evolved, incorporating new techniques to evade analysis and remain relevant in the current threat landscape. The Netskope team recently discovered that XWorm underwent a new update to include additional capabilities, such as:

• The ability to remove plugins (earlier versions introduced plugin usage).
• The ability to measure response time between the C2 server and the malware; this capability enhances a method previously found in earlier samples of this malware, including the one we will analyze in this series.
• The ability to modify the Operating System’s Hosts file, enabling an attacker to redirect web traffic to their server:

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	127.0.0.1       localhost
#	::1             localhost
151.20.37.49	    bank.com   <-- When the user accesses bank.com, their system connects to 151.20.37.49, overriding the DNS configuration.

XWorm is a Remote Access Trojan; the main difference between this type of malware and a reverse shell is that it comes preloaded with built-in capabilities to perform various functions, such as keylogging, password exfiltration, execution of new programs, and more. By offering pre-customized functionalities, it enables individuals without technical knowledge to interact with it through administrative panels.

XWorm is sold on multiple criminal forums at varying prices. According to a study conducted by Trellix, version 4 of this malware was sold for $400 in 2023. As a result, it has been used to target multiple countries and industries. A quick internet search reveals that XWorm has recently been used to attack Ukraine, industry sectors in the United Kingdom, and to deploy the LockBit ransomware.

2. Static Analysis #

Disclaimer: Running malware on a personal or corporate device can put your information or your company’s information at risk. Never execute malware on a device that has not been specifically configured for analysis.

We begin the analysis with the Detect It Easy tool, which shows us that the file’s type is PE32 (Portable Executable, a Windows executable). It shows that the malware uses the .NET framework; this is important because depending on the framework/language, we can decide on the best tool for analyzing the malware.

Additionally, we see that it identifies the malware as XWorm. While this is a strong indicator, we should not rely 100% on this identification, as Detect It Easy, like OLEVba and other static analysis tools, looks for patterns and can incorrectly label certain patterns as malicious. Furthermore, there have been cases where threat actor groups (APTs) intentionally included IOCs from other threat groups in their tools to deceive investigators.

Finally, we see that Detect It Easy identifies the malware as obfuscated and with anti-debug and anti-VM capabilities.

If we analyze the binary with PEStudio, we can detect some interesting strings:

Within the strings, we see references to DDOS, commands for the computer (PCShutdown, PCLogoff), and the string "-ExecutionPolicy Bypass", which can be used to bypass PowerShell script verification, among others. Additionally, if we explore the other tabs in PEStudio, we can gain a better understanding of the .NET namespaces present, libraries it imports, and more.

3. Managed code vs Unmanaged code #

Earlier in the article, I mentioned that, depending on the programming language, we could use different tools to analyze our sample. To understand this, it is important to know about managed and unmanaged languages:

Unmanaged code is code that runs directly on the machine without the need for a runtime environment. Here are its key characteristics:

• Direct interaction with the system: This code has direct access to memory and system resources.
• Faster but less secure: Although unmanaged code programs are faster and more lightweight, they require the programmer to carefully manage memory and other resources.
• Example in C: In this language, programmers must manually manage memory, which can lead to vulnerabilities like buffer overflows if not done correctly.

Example of unmanaged code (in C):

#include <stdio.h>
#include <string.h>

int main() {
    char buffer[10];
    printf("Enter some text: ");
    gets(buffer);  // Unsafe function, vulnerable to buffer overflow
    printf("You entered: %s\n", buffer);
    return 0;
}

Managed code is executed in a controlled environment provided by a “runtime” or execution environment, such as the .NET CLR (Common Language Runtime) for .NET applications. This offers advantages in terms of security and portability, as the environment manages memory and exceptions automatically

• Automatic resource management: The CLR handles memory management, making the code more secure and less prone to errors like memory leaks.

• Portability: Managed code is easier to port across different operating systems since the runtime takes care of translating the code into something understandable by the machine.

Example of managed code (in C#):

using System;

class Program
{
    static void Main()
    {
        string input = Console.ReadLine();  // Safe input handling
        Console.WriteLine("You entered: " + input);
    }
}

3.1 Intermediate Language (IL) #

When we write code in .NET, whether in C# or Visual Basic, the compiler does not produce a binary that can be executed directly. Instead, it generates a binary in Intermediate Language (IL), which is a set of instructions that need to be converted to machine code by the CLR to be executed on the machine.

When you double-click a .EXE program that uses the .NET framework, the CLR performs a process known as Just In Time (JIT) compiling, which transforms the intermediate code into machine code that can be executed by the CPU:

If we compare two programs that do the same thing, one written in C and the other in C#, we can observe the significant size difference

This is important for our analysis because Intermediate Language binaries contain a large amount of metadata that makes the analysis easier. Instead of having to disassemble the binary with a tool like Ghidra, we can decompile it using DNSpy.

4. Conclusions #

In this first article, we have laid the groundwork for understanding XWorm: we now know what type of binary it is, some potential functions to look for during the analysis, as well as the tools we can use to approach it. While this is a theoretical article, I believe the foundation of managed and unmanaged languages is important for future analyses.

In the next article, we will begin analyzing the actions performed by XWorm, how it evades defenses, decrypts configuration parameters while running, and more.

See you in the next article!

Do you have any comments or suggestions? Feel free to leave your feedback in the form below!