Aparece una peligrosa nueva variante del malware XWorm

Aparece una peligrosa nueva variante del malware XWorm

En septiembre de 2024, desde Netskope se informó sobre el malware XWorm y su cadena de infección. En dicho informe se dieron a conocer nuevas instrucciones de comando y control (C2) y se analizaron sus características más destacadas.

Tras casi un año de seguimiento de este malware, Netskope Threat Labs ha descubierto una nueva versión (versión 6.0) en circulación que introduce nuevas características, como la protección de procesos y capacidades anti análisis mejoradas. De acuerdo con la cadena de infección descrita anteriormente, el XWorm sigue ejecutándose en memoria y sigue utilizando técnicas de evasión de la ejecución.

Entre las principales conclusiones relativas a la última versión de XWorm, se encuentran las siguientes:

•    La aparición de esta nueva variante del XWorm indica que el malware sigue en desarrollo activo y que probablemente se utilizará en un futuro próximo.

•    Esta última versión incluye funciones adicionales para mantener la persistencia y eludir el análisis.

•    El cargador incorpora una nueva funcionalidad para eludir la interfaz de análisis antimalware (AMSI), que utiliza la modificación en memoria de CLR.DLL para evitar la detección.

El XWorm 6.0 inicia su cadena de infección a través de un archivo VBScript, que probablemente se ha entregado mediante ingeniería social. Este incrusta y reconstruye otra carga útil VBScript ofuscada en tiempo de ejecución. El proceso comienza con una matriz variable de códigos de caracteres. Itera sobre la matriz en orden inverso utilizando UBound y convierte cada valor numérico en su correspondiente carácter Unicode utilizando la función ChrW de VBScript. A continuación, estos caracteres se concatenan para formar el VBScript malicioso real, que se ejecuta mediante la función eval. 

XWorm 6.0 consigue la persistencia almacenando el update.vbs en las carpetas TEMP y APPDATA y añadiendo estas rutas a la clave de ejecución del registro. Esto difiere de nuestra muestra anterior de XWorm, que dependía de tareas programadas para mantener el acceso.

El cliente de XWorm ofrece a los atacantes la flexibilidad de seleccionar métodos de persistencia, como la clave de ejecución del registro, las tareas programadas o la carpeta de inicio, lo que indica que seguiremos viendo variantes que utilicen cualquiera de estos métodos.

El script de PowerShell wolf-8372-4236-2751-hunter-978-ghost-9314.ps1 implementa primero un bypass de la interfaz de análisis antimalware (AMSI) modificando la instancia de la biblioteca Common Language Runtime (CLR.DLL) en memoria. 

Para ello, recupera la información de la memoria del sistema itinerando a través de todas las regiones de memoria del proceso actual mediante la función GetCurrentProcess(). Busca CLR.DLL dentro de estas regiones y busca la cadena «AmsiScanBuffer». Cuando la encuentra, la sustituye por bytes nulos, por lo que el CLR ya no puede resolver el método AmsiScanBuffer y le impide enviar contenido sospechoso de la memoria a AMSI para su inspección. El atacante copió el script de un repositorio público de GitHub y sustituyó algunos nombres de funciones.

A continuación, descarga el binario XWorm de un repositorio público de GitHub mediante la clase .NET HTTP.Client. El método Assembly.Load es el encargado de cargar el archivo en la memoria, y se activa en el punto de entrada.

XWorm6.0

Esta muestra de XWorm 6.0, denominada Microsoft.exe, conserva el mismo diseño operativo que la versión anterior, con algunas mejoras adicionales. En esta sección se analizan las principales diferencias.

La aplicación comienza recuperando su configuración a partir de una cadena codificada en base 64. El XWorm incluye un servidor de mando y control (C2) codificado. Aunque este comportamiento es común en otras muestras, difiere de la versión que Netskope Threat Labs reportó anteriormente, ya que esta recibe la dirección C2 a través de un argumento de línea de comandos de un script PowerShell.

Otra nueva característica que descubrimos es la capacidad del XWorm para impedir la finalización de procesos marcándose a sí mismo como proceso crítico. Para marcar un proceso como crítico se requieren privilegios elevados, por lo que primero comprueba si se está ejecutando con privilegios de administrador verificando si el usuario actual pertenece al grupo WindowsBuiltInRole.Administrator, que corresponde al valor 544.

Si XWorm se ejecuta con privilegios de administrador, invoca EnterDebugMode para activar SeDebugPrivilege, lo que le permite marcar el proceso XWorm como crítico. Los usuarios no pueden terminar un proceso crítico sin privilegios de administrador. Si un usuario con privilegios elevados lo detiene por la fuerza, el sistema se bloqueará y será necesario reiniciarlo; tras el reinicio, XWorm se iniciará de nuevo utilizando la clave de ejecución del registro.

XWorm incorpora varias técnicas anti análisis. Aunque las técnicas anteriores siguen vigentes, hemos identificado una nueva que no estaba presente en las muestras anteriores.

XWorm se termina a sí mismo cuando detecta su ejecución en Windows XP. Este cambio podría ser un intento de impedir que los investigadores o analistas ejecuten la carga útil en un entorno de análisis heredado o en un sandbox. Esta técnica de evasión del análisis también se observa en el AsyncRAT de código abierto.

Otra técnica antianálisis denominada «Anyrun» hace pensar que puede detectar el sandbox Any.Run. Sin embargo, en realidad utiliza el servicio IP-API para comprobar si la dirección IP del dispositivo está asociada a centros de datos o a proveedores de alojamiento. Si detecta que la IP pertenece a alguna de estas categorías, el proceso del XWorm se detendrá.

Conclusiones

La última versión del XWorm observada en la naturaleza incorpora nuevas características. En particular, marca su proceso como crítico para evitar que se termine, y mejora el antianálisis para evitar su ejecución en dispositivos con Windows XP. Además, el XWorm sigue ejecutándose directamente en memoria y elude el AMSI mediante el uso de parches en memoria de clr.dll.

Estos detalles pueden ayudar a los responsables de la seguridad a detectar el XWorm en sus entornos y a desarrollar estrategias de detección basadas en sus técnicas.