Operación XENOFISCAL: SideCopy despliega XenoRAT persistente dirigido contra el Ministerio de Finanzas de Afganistán.

Autores: Dixit Panchal y Vaibhav Krushna Billade

Índice:

• Introducción:
• Objetivos clave:
• Cadena de infección:
• Conclusiones iniciales sobre la campaña:
• Análisis de Decoy:
• Análisis técnico:
  • Etapa 1: Análisis del archivo LNK.
  • Etapa 2: Análisis de la carga útil HTA/JavaScript
  • Etapa 3: Análisis de la DLL del cargador de la etapa 1
  • Etapa 4: Análisis de la DLL del cargador de la etapa 2 y del código shell.
  • Etapa 5: Análisis de XenoRAT.
• Artefactos de infraestructura y atribuciones de los actores de amenazas.
• Conclusión: ¿Operación XENOFISCAL?
• Seqrite Cobertura:
• COI:
• MITRE ATT&CK:

Introducción:

Seqrite Labs ha estado monitoreando activamente las campañas de spear phishing en todo el mundo y cuenta con un historial bien establecido de seguimiento del clúster APT SideCopy, un grupo de amenazas vinculado a Pakistán que opera bajo el paraguas más amplio de Transparent Tribe/APT36. Como continuación de este esfuerzo de seguimiento, identificamos una campaña dirigida al Ministerio de Finanzas de Afganistán, con tácticas, técnicas y procedimientos (TTP) que coinciden con los de SideCopy con un nivel de confianza medio a alto.

La campaña comienza con un ataque de spear phishing: un archivo ZIP que contiene un archivo LNK malicioso con un nombre de archivo en idioma pastún cuidadosamente elaborado:

د_هغو_کارکوونکو_لېست_چې_د_فکري_او_رواني_جګړې_سیمینار_ته_ورپېژندل_شوي_وووو12.pdf.lnk (“Lista de empleados que conocieron el mundo intelectual y Seminario de Guerra Psicológica”)

La elección del pastún es deliberada. Es el idioma predominante en las instituciones gubernamentales de Afganistán y la lengua principal de los destinatarios previstos: funcionarios de finanzas provinciales que operan en los 34 Mustoufiats afganos. Al plantear el señuelo en torno a un seminario sobre guerra psicológica e intelectual, el actor demostró un conocimiento preciso del contexto operativo y administrativo de sus objetivos.

Lo que sigue en este informe es un análisis técnico completo de la campaña, desde la cadena de ejecución de LNK hasta la localización mediante implantes XenoRAT de la infraestructura europea a prueba de balas, junto con los cambios en la infraestructura, el análisis de documentos señuelo y la asignación de atribuciones en comparación con la línea base conocida de TTP de SideCopy.

Objetivos clave:

• Ministerio de Finanzas del Emirato Islámico de Afganistán.
• Direcciones Provinciales de Ingresos y Finanzas (Mustoufiats).
• Funcionarios gubernamentales de habla pastún.
• Empleados del gobierno provincial, no del ministerio central.

Cadena de infección:

Conclusiones iniciales sobre la campaña:

Durante nuestro análisis, observamos que el atacante inició el ataque a través de un archivo ZIP distribuido mediante spear phishing, que contenía un archivo LNK malicioso escrito en pastún, una elección deliberada que refleja un profundo conocimiento del entorno objetivo.

Una vez ejecutado, el LNK aprovecha silenciosamente mshta.exe para obtener una carga útil HTA remota de un dominio educativo afgano comprometido, que decodifica JavaScript ofuscado en memoria, establece persistencia basada en el Registro camuflada como una entrada de Microsoft Edge y, finalmente, implementa XenoRAT 1.8.7, enviando señales hacia una infraestructura de alojamiento europea a prueba de balas totalmente separada de la capa de entrega, lo que garantiza la resiliencia a largo plazo.

Análisis de Decoy:

El documento señuelo arrojado durante la ejecución es un directorio provincial del personal del Ministerio de Finanzas afgano que abarca las 34 provincias, y que incluye a directores de finanzas, jefes de ingresos, funcionarios financieros y secretarios, junto con sus números de teléfono móvil directos; todo ello escrito íntegramente en dari y pastún.

El nivel de detalle organizativo sugiere que el atacante realizó previamente una labor de inteligencia. Su función en el ataque es sencilla: mientras la víctima lee lo que parece ser un documento interno rutinario del gobierno, el malware ya ha completado su instalación silenciosamente en segundo plano.

Análisis técnico:

Etapa 1: Análisis del archivo LNK.

El archivo LNK actúa como vector de infección inicial y desencadenante de ejecución dentro de la cadena de ataque. Aunque está disfrazado con un icono de PDF y un nombre de archivo engañoso para parecer un documento legítimo, la inspección de las propiedades de su acceso directo revela que ejecuta la utilidad de Windows mshta.exe desde C:\Windows\System32. El comando incrustado en el acceso directo apunta a un recurso PHP malicioso remoto alojado a través de HTTPS ( hxxp[:]//< abimj.edu.af >/index.php ), lo que permite al atacante ejecutar contenido de script alojado externamente directamente en la memoria sin dejar un ejecutable en el disco. Al abusar de mshta.exe, un binario legítimo de Microsoft comúnmente asociado con la ejecución de aplicaciones HTML (HTA).

El atacante utiliza una técnica de secuestro de datos (LOLBIN) para evadir los mecanismos de detección tradicionales y sortear las sospechas del usuario. El uso excesivo de comas en la estructura de la URL indica, además, un intento de obstaculizar el análisis estático y la detección basada en firmas.

Etapa 2: Análisis de la carga útil HTA/JavaScript

La carga útil remota de PHP obtenida a través de mshta.exe contiene código JavaScript altamente ofuscado, diseñado para ejecutar lógica maliciosa dentro del contexto del motor HTA. La inspección inicial muestra la presencia de matrices de cadenas codificadas, como _$_f1bf=[“\x55\x33\x6…”], un método de ofuscación común utilizado para ocultar nombres de funciones, URL, comandos o cargas útiles secundarias a analistas y herramientas de seguridad. El script también define texto engañoso en la ventana, como “Error de archivo de Windows”, para imitar el comportamiento legítimo del sistema y potencialmente distraer a la víctima durante la ejecución. Esta etapa sirve como la capa principal de ejecución y entrega de la campaña, donde es probable que el JavaScript ofuscado se decodifique dinámicamente para realizar acciones posteriores, como la recuperación de la carga útil, la ejecución de comandos, el establecimiento de persistencia o la exfiltración de datos.

Analizando un JScript ofuscado

Tras el análisis, se identificó el archivo .js como un cargador de malware basado en JScript altamente ofuscado, diseñado para ejecutarse en entornos de Windows Script Host (WSH) o Internet Explorer antiguo con soporte para ActiveX habilitado. El script incorpora múltiples técnicas maliciosas, incluyendo la ejecución basada en ActiveX, la decodificación personalizada de la carga útil Base64, la deserialización de .NET BinaryFormatter y la ejecución de la carga útil en memoria.

La primera fase del malware comienza con una matriz JavaScript grande y ofuscada, definida normalmente como una variable como _$_f1bf, que contiene numerosos fragmentos de cadena codificados en hexadecimal que representan una carga útil incrustada. Estos fragmentos se concatenan posteriormente y se pasan a una función de decodificación personalizada. En lugar de utilizar las API nativas de decodificación Base64, el script implementa su propia rutina de decodificación Base64 para ocultar la carga útil y dificultar el análisis.

La función personalizada reconstruye dinámicamente el conjunto de caracteres Base64 estándar (A–Z, a–z, 0–9, +, /) utilizando String.fromCharCode, y luego procesa los datos codificados en fragmentos mientras reconstruye el flujo de bytes original mediante una serie de operaciones bit a bit. Al gestionar manualmente el proceso de decodificación, el malware evita indicadores sospechosos como atob() o bibliotecas de decodificación comunes, lo que dificulta considerablemente la detección estática y el análisis basado en firmas.

Reconstrucción de la carga útil mediante objetos COM de .NET

En la segunda etapa, el malware convierte la carga útil decodificada en un objeto ejecutable en memoria, aprovechando varias clases .NET instanciadas mediante ActiveXObject. El script crea System.Text.ASCIIEncoding para convertir la cadena decodificada en una matriz de bytes y, a continuación, utiliza System.Security.Cryptography.FromBase64Transform para realizar una transformación Base64 adicional sobre la carga útil. El flujo de bytes resultante se escribe en un objeto System.IO.MemoryStream, reconstruyendo así la carga útil serializada completamente en memoria sin acceder al disco. Este enfoque por etapas se utiliza habitualmente en malware sin archivos, ya que permite a los atacantes preparar objetos .NET maliciosos para su ejecución, minimizando los rastros forenses y reduciendo la probabilidad de detección por parte de los productos de seguridad tradicionales basados ​​en archivos.

Tras decodificar la carga útil incrustada, el script entra en su fase de ejecución creando un objeto ActiveX WScript.Shell , que permite el acceso a operaciones de registro, variables de entorno y otras funcionalidades del sistema. A continuación, el script comprueba si está instalada la versión 4.0.30319 de .NET Framework consultando la ruta del registro HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 . Si la versión más reciente no está disponible, recurre a .NET v2.0.50727. Posteriormente, el malware establece la variable de entorno COMPLUS_Version para forzar al proceso a cargar una versión específica del entorno de ejecución CLR, garantizando así la compatibilidad con la carga útil de la DLL de .NET incrustada.

Durante su ejecución, el malware abusa de componentes de deserialización .NET de confianza, incluidos los gadgets XAML de WPF como ObjectDataProvider y ResourceDictionary, junto con objetos de serialización de Windows Forms como AxHost y PropertyBagBinary. Estos componentes ayudan a mantener la cadena de gadgets de deserialización y activan la ejecución durante la reconstrucción de objetos.

Finalmente, el objeto serializado malicioso almacenado dentro del objeto MemoryStream se procesa a través de .NET BinaryFormatter.Deserialize_2() , lo que permite la ejecución sigilosa de DLL en memoria, minimizando los artefactos forenses y eludiendo los mecanismos de detección tradicionales basados ​​en archivos.

Etapa 3: Análisis de la DLL del cargador de la etapa 1 (cargador inicial)

Se trata de una DLL de carga .NET responsable de la ejecución de la carga útil de la siguiente etapa, la persistencia y la preparación en memoria de los siguientes componentes de la cadena de ataque.

Al inicio, la función `openthefile()` se encarga de descargar y abrir un documento PDF falso desde la URL `hxxp[:]//abimj.edu.af/institute/cloudiyaf/document.pdf`. La función primero extrae el nombre del archivo de la URL y guarda el archivo descargado en el directorio temporal de Windows mediante `WebClient.DownloadFile()`. Antes de iniciar la descarga, el malware habilita explícitamente la comunicación TLS 1.2 a través de `ServicePointManager.SecurityProtocol`, lo que garantiza la compatibilidad con conexiones HTTPS/TLS seguras. Tras descargar el documento, el malware pausa la ejecución durante cinco segundos y luego abre el archivo PDF descargado mediante una rutina de ejecución de comandos oculta.

La función RunProcessWithHiddenCmd() se utiliza para ejecutar archivos o comandos a través de cmd.exe. Esta función construye un argumento de línea de comandos usando /c, que indica a cmd.exe que ejecute el archivo especificado y finalice posteriormente. La función inicializa una nueva instancia de proceso, asigna cmd.exe como ejecutable y le pasa la cadena de argumentos generada. Una vez iniciado, el intérprete de comandos ejecuta el archivo o comando especificado y finaliza automáticamente al completarse.

Tras abrir el documento señuelo, el malware crea un directorio llamado USOShared-1de48789-1285 en C:\Users\Public\ para almacenar la carga útil HTA de la siguiente etapa (zuidrt.hta). A continuación, invoca la función RegWorkExePathFromPublic() , que contiene comandos de registro codificados en Base64 que se decodifican en tiempo de ejecución mediante la rutina de decodificación Base64 BSDSD94() . Una vez decodificado, el comando crea una nueva entrada en la clave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run con el nombre de valor Edgre. La entrada de registro ejecuta:

cmd /C start C:\Users\Public\USOShared-1de48789-1285\zuidrt.hta

Para garantizar aún más su sigilo y persistencia, el malware escribe el comando decodificado en un archivo por lotes llamado noway.bat en el directorio temporal del usuario y lo ejecuta mediante un proceso oculto. La ejecución está configurada para suprimir todas las ventanas visibles, impidiendo que aparezca cualquier símbolo del sistema. Esto asegura que la carga útil HTA se inicie automáticamente al iniciar sesión el usuario, manteniendo así su persistencia en el sistema.

La función CopyExeToUsersPublic() es responsable de recuperar y reconstruir la carga útil HTA de la siguiente etapa (zuidrt.hta) en el directorio C:\Users\Public\USOShared-1de48789-1285\. Primero verifica si el directorio de destino existe y lo crea si no existe usando Directory.CreateDirectory(), luego descarga la carga útil codificada desde:

hxxp[:]//abimj.edu.af/institute/cloudiya/

El archivo zuidrt.hta descargado se almacena en un formato comprimido y codificado en Base64 para evadir la detección. Posteriormente, el malware descomprime y decodifica los datos para reconstruir el archivo HTA final, que se ejecuta mediante RunProcessWithHiddenCmd(), el cual ejecuta internamente cmd.exe /c start C:\Users\Public\USOShared-1de48789-1285\zuidrt.hta , aprovechando la asociación de archivos de Windows para invocar mshta.exe y ejecutar el HTA.

Ejecución de la carga útil HTA (zuidrt.hta)

El archivo zuidrt.hta sigue una estructura similar a la carga útil HTA inicial, pero contiene componentes integrados modificados y una lógica de ejecución actualizada. Continúa la cadena de ataque reutilizando rutinas de ofuscación y decodificación para ocultar su funcionalidad y evadir el análisis. El script reinicializa las rutas de ejecución basadas en ActiveX para mantener la ejecución dentro del entorno HTA y reconstruye la carga útil serializada integrada en la memoria.

De forma similar a la fase inicial de HTA, la carga útil aprovecha los componentes de deserialización de .NET y las cadenas de gadgets para activar la ejecución en memoria de la DLL de carga de la fase 2 integrada. Esta fase actúa como una capa de ejecución secundaria dentro de la cadena de infección, asegurando la persistencia del flujo de trabajo del ataque y facilitando la transición hacia la DLL de la siguiente fase, responsable de la entrega y ejecución final de la carga útil.

Etapa 4: Análisis de la DLL del cargador de la etapa 2 y del código shell.

Tras el descifrado en tiempo de ejecución, el flujo de ejecución se transfiere a una DLL maliciosa.

La DLL es un cargador de shellcode basado en .NET responsable de recuperar, decodificar, descomprimir y ejecutar la carga útil de la siguiente etapa completamente en memoria. El malware utiliza múltiples capas de preparación y ejecución en tiempo real para eludir los mecanismos de seguridad tradicionales y reducir los artefactos en disco.

La DLL actúa como un cargador intermedio entre la etapa HTA basada en JavaScript y la carga útil final de Xeno RAT.

Configuración del entorno y recuperación de la carga útil

Al ejecutarse, la DLL inicializa un entorno de preparación diseñado para almacenar y procesar la carga útil de la siguiente etapa, minimizando así las sospechas. El malware primero decodifica una cadena codificada en Base64 ( ZmlyZWZ4LTFkZTg3ZWVjOC0xMjQx ) utilizando la rutina personalizada BSDSD94() , lo que da como resultado el nombre de directorio firefx-1de87eec8-1241. Luego crea un directorio de trabajo bajo la ruta de Windows de acceso público:

• C:\Usuarios\Público\firefx-1de87eec8-1241

El uso de C:\Users\Public\ permite al malware eludir las restricciones de escritura relacionadas con los privilegios, integrándose en la actividad legítima del sistema de archivos. La convención de nombres de directorio imita las carpetas de caché o de perfil generadas por la aplicación, lo que ayuda a reducir las sospechas del usuario y a evadir las detecciones básicas basadas en IOC. Además, el malware define nombres de archivo temporales para la carga útil, como ayui.vmxx y ayhui.vmxx , que se disfrazan intencionalmente con extensiones no estándar para evitar su identificación inmediata como contenido ejecutable.

Tras establecer el directorio de preparación, la DLL inicia la comunicación saliente con la infraestructura controlada por el atacante para recuperar la carga útil de la siguiente etapa. El malware contiene varias URL codificadas, entre ellas:

• hxxps[:]//abimj[.]edu[.]af/institute/10/
• hxxps[:]//abimj[.]edu[.]af/institute/7/

y selecciona dinámicamente el punto final de descarga en función de la versión del sistema operativo de la víctima. Los sistemas identificados como Windows 7 (versión 6.1) se redirigen a una ubicación de carga útil alternativa, lo que indica una entrega de carga útil que tiene en cuenta la compatibilidad.

Utilizando el método .NET WebClient.DownloadFile() junto con los protocolos TLS/TLS1.1/TLS1.2 habilitados explícitamente, el malware descarga la carga útil cifrada y la almacena localmente como ayui.vmxx . El contenido descargado no es directamente ejecutable; en su lugar, sirve como un bloque de preparación codificado y comprimido que se somete a una decodificación Base64 y una descompresión GZIP antes de que se inicie la ejecución del shellcode en la memoria.

Decodificación de la carga útil y reconstrucción del código shell

Tras descargar correctamente la carga útil de segunda etapa, la DLL almacena los datos recuperados en el directorio de preparación como un archivo disfrazado llamado ayui.vmxx. En lugar de desplegar un ejecutable portátil (PE) directamente en el disco, el malware utiliza mecanismos de codificación y compresión por capas para ocultar el contenido real de la carga útil y eludir los motores de detección estática. El archivo contiene datos codificados en Base64 y comprimidos con GZIP que, a simple vista, no parecen ejecutables. Esta técnica reduce significativamente la visibilidad de la firma para los antivirus y complica el análisis manual, ya que impide que los analistas identifiquen inmediatamente el formato de la carga útil. Posteriormente, el malware lee el archivo completo en la memoria mediante File.ReadAllBytes() y comienza a reconstruir la carga útil incrustada dinámicamente durante la ejecución.

El proceso de reconstrucción se gestiona mediante la función personalizada `decompressdata()` , que realiza múltiples operaciones de decodificación y descompresión completamente en memoria. La rutina primero decodifica el blob Base64, extrae el encabezado de tamaño descomprimido y utiliza la clase `GZipStream` de .NET para restaurar el búfer de carga útil original. Una vez completada la descompresión, los datos resultantes se pasan de nuevo a través de `Convert.FromBase64String()` para recuperar los bytes del shellcode sin procesar. La carga útil completamente reconstruida se escribe localmente como `ayhui.vmxx` , que sirve como contenedor intermedio del shellcode antes de la ejecución. Al combinar la decodificación por etapas, la compresión y la reconstrucción de la carga útil en tiempo de ejecución, el malware evita exponer el shellcode final en texto plano en el disco, eludiendo así los mecanismos convencionales de escaneo de archivos y detección basada en contenido mientras prepara la carga útil para la ejecución reflectiva en memoria.

Ejecución de código shell:

Tras la reconstrucción de la carga útil, la DLL pasa a la fase de ejecución final funcionando como un cargador de shellcode en memoria. En lugar de lanzar un ejecutable tradicional desde el disco, el malware asigna directamente memoria ejecutable dentro del proceso actual mediante la función VirtualAlloc() de la API de Windows . La solicitud de asignación utiliza la bandera MEM_COMMIT junto con los permisos de memoria PAGE_EXECUTE_READWRITE (RWX) , creando una región de memoria capaz de almacenar y ejecutar código arbitrario. Este patrón de asignación RWX es un indicador bien conocido de la ejecución de shellcode y la carga reflectiva de malware. Después de la asignación de memoria, el malware copia el búfer de shellcode reconstruido en la región asignada mediante Marshal.Copy() , lo que permite almacenar la carga útil completamente dentro de la memoria del proceso sin depender del cargador PE de Windows.

Una vez que el shellcode se asigna a la memoria ejecutable, el malware transfiere la ejecución al búfer inyectado mediante la API CreateThread() , utilizando la dirección base de la memoria asignada como punto de entrada del hilo. Esta técnica permite que el shellcode se ejecute directamente desde la memoria, evitando la monitorización de ejecución convencional basada en disco y reduciendo significativamente los artefactos forenses. A continuación, la DLL invoca WaitForSingleObject() con un valor de tiempo de espera infinito para mantener la sincronización del hilo y garantizar la ejecución ininterrumpida del shellcode. Esta metodología de ejecución se alinea con las técnicas modernas de malware sin archivos, donde las cargas útiles se descifran y se lanzan dinámicamente en la memoria para evadir los motores antivirus basados ​​en firmas, los mecanismos de control de aplicaciones y las tecnologías de escaneo estático. Posteriormente, el shellcode actúa como cargador para la carga útil final de Xeno RAT, lo que permite la persistencia, la comunicación de comando y control y el acceso remoto del atacante al sistema comprometido.

El código malicioso funciona como un cargador en memoria responsable de preparar y lanzar la carga útil final del troyano Xeno RAT.

Durante su ejecución, suele realizar validaciones del entorno, resolución dinámica de API y modificaciones de permisos de memoria mediante API como VirtualProtect() y GetProcAddress() . En los cargadores Donut, el código malicioso elude los mecanismos de seguridad modificando funciones como AmsiScanBuffer() para deshabilitar el escaneo AMSI y reducir la visibilidad del contenido cargado dinámicamente.

Dado que la carga útil final es un ensamblado .NET administrado, el shellcode inicializa el Common Language Runtime (CLR) de .NET cargando componentes como clr.dll y mscoree.dll. La carga útil incrustada se descifra y se carga directamente desde la memoria mediante técnicas de reflexión como Assembly.Load(byte[]) , evitando por completo la implementación en disco. Una vez cargada, la carga útil del RAT Xeno se ejecuta en memoria, lo que permite la comunicación de comando y control, la persistencia y el acceso remoto del atacante al sistema comprometido.

Etapa 5: Análisis de XenoRAT.

La última carga útil identificada en la cadena de infección es Xeno RAT , un troyano de acceso remoto (RAT) de código abierto disponible públicamente en GitHub y comúnmente utilizado por los ciberdelincuentes para el acceso remoto persistente, la vigilancia y las actividades posteriores a la explotación.

Tras su ejecución, inicializa un canal de comunicación seguro de comando y control (C2) mediante una dirección IP (185.235.137.106) y una configuración de puerto predefinidas , lo que permite la conexión directa a la infraestructura controlada por el atacante. Para mantener la ejecución de una única instancia y evitar múltiples lanzamientos, el malware también emplea un mutex ("clouda") , asegurando que solo se ejecute una instancia del cliente en el sistema infectado a la vez. Estos pasos de inicialización van seguidos de una lógica de persistencia y reconexión continua para mantener el acceso a largo plazo al host comprometido.

Ahora, vamos a examinar algunas funciones interesantes y analizar sus funcionalidades.

La función ConnectAndSetupAsync se encarga de establecer e inicializar una conexión de comando y control (C2) basada en TCP entre el cliente y el servidor remoto. Crea una nueva instancia de Node utilizando un SocketHandler configurado con el socket y la clave de cifrado proporcionados, lo que permite la comunicación cifrada a través de la conexión. Tras la inicialización, la función realiza un protocolo de autenticación asíncrono mediante AuthenticateAsync para validar la conexión según los valores de tipo e ID suministrados. Si la autenticación falla o se produce una excepción durante la configuración, la función devuelve null, lo que indica que no se pudo establecer correctamente el canal de comunicación C2. En caso contrario, devuelve un objeto Node completamente inicializado y autenticado, listo para el intercambio seguro de datos.

La función DllNodeHandler gestiona la carga y ejecución dinámica de módulos DLL externos recibidos a través de una conexión remota de Node. Primero, recibe el nombre de la DLL del cliente conectado y comprueba si el ensamblado ya está cargado en memoria. Si la DLL no existe, solicita los datos binarios al servidor remoto, los carga dinámicamente mediante Assembly.Load y los almacena en el diccionario Assemblies para su reutilización; de lo contrario, informa al cliente de que la DLL ya existe. Tras la carga, la función crea una instancia de una clase específica a partir del ensamblado mediante reflexión e invoca su método público Run de forma asíncrona, pasando la conexión activa de Node como argumento.

El método SendAsync envía datos de forma asíncrona a través del controlador de socket y verifica si la transmisión fue exitosa, desconectando el nodo si la operación de envío falla. De igual manera, el método ReceiveAsync recupera datos cifrados y formateados del controlador de socket subyacente y devuelve el flujo de bytes procesado al llamador; si la operación falla o devuelve null, el nodo se desconecta automáticamente para mantener un estado de conexión válido. En conjunto, estos métodos proporcionan una comunicación C2 confiable basada en TCP con gestión de conexión integrada y limpieza automática durante errores de transmisión.

Además, los datos de la carga útil se comprimen utilizando las API de compresión RTL nativas de Windows (RtlCompressBuffer) antes de la transmisión y se descomprimen utilizando RtlDecompressBuffer al recibirlos, basándose en el encabezado de tamaño original, lo que mejora la eficiencia de la transferencia a la vez que se preserva la integridad de los datos. La seguridad de los datos se garantiza mediante el cifrado AES, donde los datos sin procesar se cifran con una clave compartida y un vector de inicialización fijo a través de CryptoStream, lo que garantiza una comunicación segura durante la transmisión.

Los métodos adicionales dentro de la clase gestionan otras operaciones de red, incluida la desconexión de sockets (Disconnect), el establecimiento de subconexiones secundarias (ConnectSubSockAsync), la validación del estado de conexión activa (Connected) y el mantenimiento de las relaciones de nodos secundarios (AddSubNode).

La función AddToStartupAdmin crea una tarea programada de Windows llamada " XenoUpdateManager " que ejecuta automáticamente el archivo ejecutable especificado cada vez que un usuario inicia sesión en el sistema con los privilegios de administrador más altos disponibles. Crea una definición de tarea XML, la escribe en un archivo temporal y utiliza schtasks.exe para registrar la tarea en el Programador de tareas de Windows. Tras ejecutar el comando, comprueba la salida para determinar si la tarea se creó correctamente y, a continuación, devuelve el resultado.

 

La función AddToStartupNonAdmin agrega el archivo ejecutable al inicio de Windows del usuario actual escribiéndolo en la clave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run , de modo que se ejecuta automáticamente al iniciar sesión sin derechos de administrador, e indica si la operación se realizó correctamente.

La función GetAntivirus recupera información antivirus del sistema mediante la Instrumentalización de administración de Windows (WMI), consultando la clase AntivirusProduct en root\SecurityCenter2. Recopila los valores displayName devueltos por esta consulta, que representan los productos antivirus instalados y se utilizan para la identificación del sistema.

La función RemoveStartup elimina una aplicación del inicio de Windows borrando las entradas correspondientes tanto de Tareas programadas (mediante schtasks.exe) como de la clave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Run. Primero, comprueba si el usuario tiene permisos de administrador para eliminar tareas programadas, luego busca y elimina cualquier tarea que apunte a la ruta del ejecutable especificada. Finalmente, elimina la entrada de inicio del registro correspondiente para el usuario actual.

La función de desinstalación elimina los mecanismos de persistencia de la aplicación y, a continuación, finaliza el programa automáticamente. Primero, llama a RemoveStartup para eliminar cualquier entrada de inicio (tarea programada o registro) asociada al ejecutable actual.

Inicia un proceso cmd.exe oculto con un comando decodificado en Base64 (/C elección /CY /N /DY /T 3 & Del) que espera unos segundos y luego elimina el archivo ejecutable en ejecución del disco. Finalmente, la función finaliza el proceso actual de forma forzada, asegurando que la aplicación se cierre inmediatamente después de la limpieza.

CAPACIDADES DE Xeno-RAT

Xeno RAT revela información valiosa sobre su comportamiento operativo y sus capacidades posteriores a la explotación. Basándose en el código analizado, la actividad observada y la funcionalidad disponible en su proyecto de código abierto en GitHub, el malware demuestra una amplia gama de características comúnmente asociadas con troyanos de acceso remoto (RAT) avanzados.

• Supervisa la actividad de las víctimas y recopila información de reconocimiento del anfitrión.
• Establece una comunicación de comando y control (C2) cifrada basada en TCP.
• Admite la tunelización de red basada en proxy SOCKS5.
• Carga dinámicamente ensamblados externos en memoria mediante Assembly.Load.
• Ejecuta de forma remota comandos arbitrarios emitidos por el atacante.
• Proporciona funcionalidades de gestión de archivos, incluyendo carga, descarga y eliminación.
• Realiza registro de pulsaciones de teclas, captura de pantalla, monitorización del portapapeles y vigilancia de la cámara web y el micrófono.
• Envía actualizaciones periódicas de estado y de latido al servidor C2.
• Utiliza tráfico de red cifrado y comprimido para dificultar el análisis.
• Mantiene la persistencia mediante tareas programadas y claves de ejecución del registro.
• Puede agregarse o eliminarse de las ubicaciones de inicio de Windows.
• Opera de forma encubierta para mantener un acceso no autorizado a largo plazo.
• Incluye funciones de autodesinstalación y autoeliminación para la limpieza posterior a la ejecución.

Artefactos de infraestructura y atribuciones de actores de amenazas:

Basándonos en nuestro análisis y el historial de seguimiento de esta cadena y TPP con todas esas pruebas, hemos atribuido esta campaña al clúster de SideCopy con un nivel de confianza medio-alto como se mencionó anteriormente. Durante el análisis de la infraestructura, el dominio de entrega abimj[.]edu[.]af se resolvió en dos direcciones IP: 103.132.98.224 y 103.132.98.226, ambas ubicadas dentro del bloque 103.132.98.0/23 atribuido a AS58469, el Ministerio de Comunicación y Tecnología de la Información de Afganistán.

El análisis pasivo del DNS en este bloque de direcciones IP reveló más de 200 dominios legítimos del gobierno y la educación afganos alojados en la misma infraestructura, lo que confirma que el actor de la amenaza instaló deliberadamente su capa de distribución dentro de la propia infraestructura de internet soberana de Afganistán, una medida calculada para mezclar el tráfico malicioso con las comunicaciones gubernamentales legítimas y evadir la detección a nivel de red.

Al profundizar en el servidor C2 del RAT, la dirección IP 185.235.137.106, se descubrió un host Windows que ejecutaba HTTP, HTTPS y un puerto RDP no estándar, lo que concuerda con un servidor C2 dedicado administrado por un operador.

El servidor está alojado en AS59711 (HZ Hosting Ltd), un proveedor registrado en Bulgaria con presencia física en Frankfurt, documentado previamente en los informes de infraestructura de SideCopy por Seqrite.

En el momento del análisis, tres grupos de dominios apuntaban a esta IP, incluidos dominios desechables registrados por el atacante en las extensiones .xyz, .live y .online, junto con un dominio de infraestructura de correo totalmente configurado, lo que indica que el mismo servidor estaba gestionando simultáneamente comunicaciones de RAT y operaciones de entrega de phishing.

La cadena de ataque —LNK ejecutando mshta.exe para obtener un HTA remoto a través de un endpoint index.php— es una TTP característica de SideCopy documentada de forma consistente desde 2019 y sigue siendo uno de los identificadores más fiables del grupo. El uso de XenoRAT refuerza específicamente esta atribución, ya que Seqrite En diciembre de 2024, Labs confirmó que SideCopy había adoptado formalmente variantes personalizadas de XenoRAT como parte de su conjunto de herramientas actualizado, siguiendo un patrón similar de adopción de RAT de código abierto observado anteriormente con AsyncRAT. La persistencia basada en el registro a través de una clave Run con un nombre de proceso que suplanta la identidad de una aplicación legítima de Windows es igualmente coherente con el comportamiento documentado de SideCopy tras la explotación.

A nivel de infraestructura, el dominio de entrega se registró a través de AFGNIC y se alojó en el mismo bloque de IP que la infraestructura legítima del gobierno afgano, una técnica de mezcla deliberada consistente con el patrón documentado de SideCopy. El RAT C2 en HZ Hosting (AS59711) corrobora aún más esto, ya que el mismo proveedor ha aparecido en clústeres de infraestructura de SideCopy anteriores rastreados por SeqriteCabe destacar que la coherencia en la nomenclatura entre la ruta de entrega (cloudiyaf) y el nombre de inicio predefinido del RAT (clouda) sugiere que un único operador gestiona ambos niveles de infraestructura, vinculando las capas de entrega y post-explotación al mismo actor.

Conclusión: ¿Por qué la Operación XENOFISCAL?

El nombre deriva directamente de las dos características que definen esta campaña: XenoRAT, la herramienta de acceso remoto de código abierto desplegada como carga útil final, y Fiscal, que refleja el objetivo preciso: la red provincial del Ministerio de Finanzas de Afganistán. Juntas forman un nombre en clave que resume tanto el arma como la víctima en una sola palabra. La decisión deliberada del atacante de utilizar un señuelo con temática financiera contra un ministerio de finanzas, combinada con una herramienta de acceso remoto capaz de realizar vigilancia silenciosa a largo plazo, hizo que esta combinación fuera inevitable. XENOFISCAL no es solo un nombre, sino un resumen de toda la operación en ocho letras.

Seqrite Cobertura:

• Enlace.Descargador.50744.GC
• Script.Netloader.50745.GC
• Trojan.LoaderCiR
• Troyano.YakbeexMSIL.ZZ4
• cld.script.troyano.1779477414

COI:

Nombre de archivo	SHA256
Código postal	194B912C242604D6F9A79369F22338C58A13CE0CC2ED280CE505075808BC2F14
LNK	3B4194BDFE40D94031A94B30397FFD8A4B09D0A4057668E897B8BDCD1703DD01
PDF señuelo	DF9173A28C0B0B878C10A53D35CD7CE6F6ED66D207B6B7C4FF723721F1C027AB
ugayt.hta	A63E90EE57A1F213A8FE76EF1A6CFF5AE9ED7EBCEDA258431533825E648C0C67
de ninguna manera.bat	5833917BD137804F5A021D2CB37ADFE5C4B7B67DBB06D59C3B9C5CF393835E45
zuidrt.hta	99127C8C67D90E2776BEEB85281F9C68399BF4567B07A6B638D68B760212E88D
WayBroad.dll	8F2D979EF33B2900351C94C7335275A9342C75189E1A901998E90A539E944A1A
Aotestpass.dll	0019212F25EB04BBB33BB194879C095265DB7855D6003BDD777CF0CBB90EB772
XenoRata	9AE3D785486022AF82EA92E51B26E3F55C1BBA88A7BE2AD9790F4240E8499D14

 

MITRE ATT&CK:

Táctica	Nombre de la técnica	Identificación de la técnica
Acceso inicial	Archivo adjunto de phishing selectivo	T1566.001
Ejecución	Ejecución de proxy de utilidades de desarrollador de confianza: mshta	T1218.005
	Intérprete de comandos y secuencias de comandos: Shell de comandos de Windows	T1059.003
	Intérprete de comandos y secuencias de comandos: JavaScript	T1059.007
	Módulos compartidos	T1129
	API nativa	T1106
Persistencia	Claves de ejecución del registro / Carpeta de inicio	T1547.001
	Tarea programada	T1053.005
Escalada de privilegios	Tarea programada
Evasión de defensa	Archivos o información ofuscados	T1053.005
	Desofuscar / decodificar archivos o información	T1027
	Almacenamiento/ejecución sin archivos	T1140
	Carga de código reflectante	T1027.011
	Sistemas binarios y guiones para vivir de la tierra (LOLBAS)	T1620
	Archivos y directorios ocultos	T1218
	Inyección de procesos / Ejecución en memoria	T1564.001
	Bypass AMSI	T1055
	Eliminación del indicador en el host: Eliminación de archivos	T1562.001
Descubrimiento:	Registro de consultas	T1070.004
	Descubrimiento de información del sistema	T1012
	Descubrimiento de software	T1082
	Descubrimiento de software de seguridad	T1518
Colección	Keylogging	T1518.001
	Captura de pantalla	T1056.001
	Datos del portapapeles	T1113
	Captura de audio	T1115
	Captura de vídeo	T1123
Comando y control	Protocolo de capa de aplicación: protocolos web	T1125
	Protocolo de capa de no aplicación	T1071.001
	Canal encriptado	T1095
	Proxy: Proxy externo	T1573
	Resolución dinámica	T1090.002
Desarrollo de recursos	Adquirir infraestructura: dominios	T1568
	Infraestructura de compromiso	T1583.001