Dentro del código de una nueva variante de XWorm

XWorm es un representante relativamente nuevo de la cohorte de troyanos de acceso remoto que ya se ha ganado su lugar entre las amenazas más persistentes en todo el mundo.

Desde 2022, cuando los investigadores lo observaron por primera vez, ha pasado por una serie de actualizaciones importantes que han mejorado significativamente su funcionalidad y solidificado su poder de permanencia.

El equipo de analistas de CUALQUIER EJECUCIÓN Me encontré con la versión más reciente del malware y no pude rechazar la oportunidad de desmontarlo para examinar las configuraciones mecánicas de XWorm. Así es como lo hicieron y qué encontraron.

La fuente de la muestra XWorm

La muestra en cuestión fue descubierta en ANY. La base de datos de malware de RUN, un repositorio que contiene informes de análisis detallados de todos los archivos y enlaces que han subido los usuarios del sandbox en modo público.

Un vistazo rápido a los resultados del análisis reveló que la muestra se distribuyó inicialmente a través de MediaFire, un servicio de alojamiento de archivos. El malware estaba empaquetado en un archivo RAR y protegido con contraseña.

Figura 1: La página de MediaFire que contiene el enlace de descarga del archivo.

Tras la ejecución, la amenaza fue detectada instantáneamente por las reglas de Suricata y identificada como XWorm.

Figura 2: Tráfico de XWorm marcado como malicioso por el sandbox.

Tácticas, técnicas y procedimientos (TTP) de XWorm

El informe de la zona de pruebas destacó varias técnicas utilizadas por la muestra:

Figura 3: Actividades de XWorm en el sistema infectado.

MITRE T1547.001: XWorm agregó su acceso directo al directorio de Inicio.

MITRE T1053.005: Utilizaba el programador de tareas para reiniciarse con privilegios elevados, como lo indica el parámetro «/RL HIGHEST».

MITRE T1074.001: El software se instaló en el directorio Público.

MITRE T1571: El malware intentó conectarse a un servidor remoto, pero no recibió respuesta.

El intento fallido de XWorm de evadir el análisis del sandbox

Dado que el informe de análisis inicial tenía varios días, el equipo decidió ejecutar la muestra en el entorno de pruebas una vez más para comprobar si había nuevas actividades.

Sin embargo, después del lanzamiento, el malware falló casi de inmediato. Una breve investigación hizo evidente que la muestra ahora consultaba un servicio especial para determinar si se estaba ejecutando en un entorno limitado virtual.

Básicamente, los desarrolladores de XWorm implementaron una técnica de evasión que provocaba que el software malicioso se cerrara tan pronto como detectaba un entorno virtualizado.

Para superar esto, el equipo habilitó el proxy residencial en la configuración de la zona de pruebas. Esta característica reemplaza la dirección IP del centro de datos de la máquina virtual con una de un ISP real, lo que hace que el malware piense que se está ejecutando en la máquina de un usuario real.

Figura 4: El proxy residencial proporciona direcciones IP de numerosos

Después de volver a ejecutar la muestra con el proxy residencial habilitado, XWorm se ejecutó exitosamente y comenzó su actividad.

Además de eso, con la ayuda de la función de proxy MITM, fue posible extraer la información transmitida por XWorm a Telegram (MITRE T1102). Los datos incluían: la versión del malware (XWorm V3.1), el nombre de usuario de la máquina, la versión del sistema operativo y probablemente el hash de la víctima.

Figura 5: Información del sistema recopilada por XWorm (MITRE T1082).

Análisis estático de la nueva variante XWorm

Después de recopilar toda la información crucial proporcionada por el sandbox, los analistas comenzaron la fase de análisis estático de su investigación. El primer paso fue cargar la muestra en Detect it Easy (DIE), un estándar de la industria para el análisis inicial de malware. El programa determinó rápidamente que se trataba de una variación .NET de XWorm.

Figura 6: DIE proporcionó información sobre el compilador del malware.

A partir de ahí, el único paso lógico para el equipo fue abrir el archivo en dnSpy, un depurador de .NET, que rápidamente reveló que el binario estaba sujeto a una gran ofuscación. Sin embargo, DIE no pudo reconocer el empaquetador ni siquiera utilizando el escaneo heurístico.

Figura 7: El código del XWorm resultó estar ofuscado (MITRE T1027).

El empleo de de4dot, un desofuscador y desempaquetador de .NET, tampoco tuvo ningún efecto.

Más técnicas de evasión y persistencia de XWorm

Una investigación más profunda del binario malicioso permitió al equipo descubrir piezas adicionales del rompecabezas. En concreto, se encontraron una serie de mecánicas adicionales utilizadas por el malware:

Detección de virtualización: XWorm utilizó la consulta WMI «Seleccionar * de Win32_ComputerSystem» para comprobar los entornos VmWare o VirtualBox.

Figura 8: El malware aprovechó el Instrumental de administración de Windows (MITRE T1047).

Detección del depurador: También ejecutó la función API CheckRemoteDebuggerPresent para ver si se estaba depurando.

Figura 9: Xworm intentó evadir el análisis del depurador.

Detección de espacio aislado: El binario escaneó el sistema para ver si la biblioteca SbieDll.dll estaba cargada.

Figura 10: SbieDll.dll está asociado con Sandboxie, un programa de aislamiento basado en sandbox.

Verificación de IP del centro de datos: Xworm consultó la máquina para determinar si estaba alojada en un centro de datos.

Figura 11: El escaneo de IP del malware explica el motivo de su falla inicial.

Persistencia: XWorm utilizó el registro y el programador de tareas para establecer una presencia persistente en el sistema.

Figura 12: El código reveló la capacidad del malware para modificar el registro.

Extracción de la configuración de XWorm.

A continuación, los analistas encontraron un constructor que parecía un bloque que contenía configuraciones. Usaron una función para reasignar algunos de sus campos. El malware primero calculó un hash MD5 a partir de un valor en la sección de configuración supuesta.

Luego copió el valor obtenido dos veces en una matriz temporal, pero debido a un error de uno por uno, el MD5 no se copió por completo dos veces. El equipo utilizó la matriz obtenida como clave para descifrar las cadenas base64 entrantes utilizando AES en modo ECB.

También descubrieron que el campo utilizado era un mutex. Todo el proceso se describe en detalle en el artículo del blog de ANY.RUN «XWorm: Análisis técnico de una nueva versión de malware«.

Configuración de XWorm

La configuración completa de la nueva variante de XWorm es la siguiente:

Conclusión

Obtener configuraciones del malware más reciente es crucial pero requiere mucho tiempo. Para hacerlo más eficiente, puede ejecutar sus muestras a través del entorno limitado de ANY.RUN para acceder a la información necesaria en segundos.

Compruébalo tú mismo usando XWorm muestra. Además, ANY.RUN ofrece una prueba gratuita de 14 días de su plan superior a los equipos de seguridad para ayudarlos a probar las capacidades del servicio.