006 - Decodificando XWorm: Introducción
This article is also available in english
- Introducción
- Exploración inicial y técnicas anti-análisis
- Próximamente: Evasión de defensas y persistencia
- Próximamente: Movimiento lateral
- Próximamente: Keylogger y captura de criptomonedas
- Próximamente: Comunicación con Telegram, obtención de nueva variante
- Próximamente: Comando y Control
Si quieres enterarte cuando se publiquen los nuevos posts de esta serie, no olvides suscribirte al blog!
1. 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:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
151.20.37.49 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.
2. 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.
3. 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);
}
}
3.1 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.
4. 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!
¿Tienes algún comentario o sugerencia? ¡Puedes dejar tu feedback en el formulario de abajo!