RONINGLOADER: El nuevo camino de DragonBreath hacia el abuso de PPL

Introducción

Elastic Security Labs identificó una campaña reciente que distribuía una variante modificada del gh0st RAT, atribuida a Dragon Breath APT (APT-Q-27), a través de instaladores troyanizados de NSIS disfrazados de software legítimo como Google Chrome y Microsoft Teams. La cadena de infección emplea un mecanismo de entrega de varias etapas que aprovecha varias técnicas de evasión, con muchas redundancias destinadas a neutralizar los productos de seguridad de endpoints populares en el mercado chino. Estos incluyen traer un controlador firmado legítimamente, implementar directivas WDAC personalizadas y alterar el binario de Microsoft Defender a través del abuso de PPL.

Esta campaña se dirige principalmente a usuarios de habla china y demuestra una clara evolución en la adaptabilidad en comparación con campañas anteriores relacionadas con DragonBreath documentadas en 2022-2023. A través de este reporte, esperamos crear conciencia sobre las nuevas técnicas que este malware está comenzando a implementar y arrojar luz sobre un cargador único al que llamamos RoningLoader.

Conclusiones clave

• El malware emplea un abuso de Protected Process Light (PPL) para deshabilitar Windows Defender
• Los actores de amenazas aprovechan un controlador de kernel válido y firmado para eliminar procesos
• Directiva WDAC personalizada sin firmar aplicada para bloquear 360 ejecutables de Total Security y Huorong
• DLL fantasma e inyección de carga útil a través de grupos de subprocesos para una mayor finalización del proceso antivirus
• La carga útil final tiene actualizaciones menores y está asociada con DragonBreath

Descubrimiento

En agosto de 2025, se publicó una investigación que detalla un método para abusar de Protected Process Light (PPL) para deshabilitar las herramientas de seguridad de endpoints. Luego de esta divulgación, producimos una regla de comportamiento, Evasión potencial a través de la ejecución de ClipUp y, luego de buscar algunas amenazas de datos de telemetría, identificamos una campaña en tiempo real que empleaba la técnica.

Análisis de código de RONINGLOADER

El vector de infección inicial es un instalador troyanizado creado mediante el sistema de instalación de scripts de Nullsoft (NSIS). NSIS es una herramienta legítima de código abierto para crear instaladores de Windows, pero los actores de amenazas abusan con frecuencia de ella para empaquetar y entregar malware, como se ve en GULOADER. En esta campaña, observamos que los instaladores maliciosos se distribuyen bajo varios temas, hacer pasar por software legítimo como Google Chrome, Microsoft Teams u otras aplicaciones confiables para atraer a los usuarios a ejecutarlos.

Tras la ejecución, el instalador principal de NSIS funciona como un cuentagotas, que contiene dos instaladores de NSIS integrados adicionales. Uno de los instaladores anidados es benigno e instala el software legítimo, mientras que el segundo es malicioso y responsable de implementar la cadena de ataque.

La cadena de ataque aprovecha un controlador firmado denominado ollama.sys para la finalización del proceso antivirus. El conductor tiene un nombre de firmante de Kunming Wuqi E-commerce Co., Ltd., con un certificado válido desde el 3de febrero de 2025como 3de febrero de 2026. Al voltear sobre VirusTotal se revelaron 71 binarios firmados adicionales. Entre estos, identificamos los droppers de AgentTesla que se hacen pasar por 慕讯公益加速器 (MuXunAccelerator), un software VPN centrado en los juegos popular entre los usuarios chinos, con muestras que se remontan a abril de 2025. En individuo, las técnicas de firma varían entre las muestras. Algunos ejemplos anteriores, como inject.sys, contienen artefactos HookSignTool, incluida la cadena JemmyLoveJenny, mientras que el ejemplo de octubre de 2025 ollama.sys no muestra tales artefactos y usa procedimientos de firma estándar, pero ambos comparten el mismo periodo de validez del certificado.

Al comparar D:\VS_Project\加解密\MyDriver1\x64\Release\MyDriver1.pdb de artefactos de cadena PDB de ollama.syscon otras muestras, descubrimos diferentes artefactos de otras muestras enviadas:

• D:\cpp\origin\ConsoleApplication2\x64\Release\ConsoleApplication2.pdb
• D:\a_work\1\s\artifacts\obj\coreclr\windows.x86.Release\Corehost.Static\singlefilehost.pdb
• C:\Users\0\Desktop\EAMap\x64\Release\ttt.pdb
• h:\projects\netfilter3\bin\Release\Win32\nfregdrv.pdb

Debido a la diversidad de binarios y al gran volumen de envíos, sospechamos que el certificado puede haber filtrado, pero esto es especulación en este momento.

Etapa 1

Nuestro análisis comenzó con el binario inicial, identificado por su hash SHA256: da2c58308e860e57df4c46465fd1cfc68d41e8699b4871e9a9be3c434283d50b. Al extraerlo, se revelan dos ejecutables incrustados: un instalador benigno, letsvpnlatest.exe, y el instalador malicioso Snieoatwtregoable.exe.

El instalador malicioso, Snieoatwtregoable.exe, crea un nuevo directorio en C:\Program Files\Snieoatwtregoable\. Dentro de esta carpeta, coloca dos archivos: una DLL llamada Snieoatwtregoable.dll y un archivo cifrado, tp.png.

El núcleo de la actividad maliciosa reside en Snieoatwtregoable.dll, que exporta una única función: DllRegisterServer. Cuando se invoca, esta función lee el contenido del archivo tp.png del disco y, a continuación, descifra estos datos mediante un algoritmo simple que implica una operación de rotación a la derecha (ROR) y XOR.

El contenido descifrado es shellcode que carga y ejecuta reflexivamente un archivo PE en la memoria. El malware primero asigna una nueva región de memoria dentro de su propio proceso empleando la API de NtAllocateVirtualMemory , luego crea un nuevo subproceso para ejecutar el shellcode llamando a NtCreateThreadEx.

El malware intenta eliminar cualquier gancho de espacio de usuario cargando un nuevo ntdll.dlly luego usando GetProcAddress con el nombre de la API para resolver las direcciones.

El malware intenta conectarse a localhost en el puerto 5555 sin ningún propósito real, ya que el resultado no importará; Especulativamente, es probable que se trate de código muerto o código sobrante de preproducción

Etapa 2 - tp.png

RONINGLOADER primero verifica si tiene privilegios administrativos mediante la API de GetTokenInformation . De lo contrario, intenta elevar sus privilegios mediante el comando runas para iniciar una nueva instancia elevada de sí mismo antes de finalizar el proceso original.

Curiosamente, el malware intenta comunicar con una URL codificada http://www.baidu.com/ con el agente de usuario “Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko”, pero esto parece ser un código muerto, probablemente debido a una función eliminada o un código de marcador de posición para versiones futuras. Está diseñado para extraer y registrar la fecha del encabezado de respuesta HTTP de la URL.

Luego, el malware escanea una lista de procesos en ejecución en busca de soluciones antivirus específicas. Comprueba una lista codificada de nombres de procesos y establece una bandera booleana correspondiente en "True" si se encuentra alguna.

A continuación se muestra una tabla de procesos y los productos de seguridad asociados codificados de forma rígida en el binario:

Terminación del proceso AV a través de un proceso remoto inyectado

A continuación, el malware mata esos procesos. Curiosamente, el producto Qihoo 360 Total Security adopta un enfoque diferente al de los demás.

Primero, bloquea toda comunicación de red cambiando el firewall. A continuación, llama a una función para insertar shellcode en el proceso (vssvc.exe) asociado con el servicio de instantáneas de volumen (VSS).
Primero se otorga a sí mismo el alta integridad SeDebugPrivilege token.

A continuación, inicia el VSS (Servicio de instantáneas de volumen) si aún no se está ejecutando y recupera el PID de su proceso asociado (vssvc.exe).

A continuación, el malware emplea NtCreateSection para crear dos secciones de memoria separadas. A continuación, asigna vistas de estas secciones al espacio de memoria del proceso vssvc.exe. La primera sección contiene un archivo ejecutable portátil (PE) completo, que es un controlador con el nombre de dispositivo \\.\Ollama. La segunda sección contiene shellcode destinado a la ejecución.

RONINGLOADER adopta un enfoque diferente para esta inyección de procesos en comparación con otros métodos de inyección empleados en otras partes del malware. Esta técnica aprovecha el grupo de subprocesos para ejecutar código de forma remota a través de un desencadenador de escritura de archivos en el proceso remoto. Esta técnica fue documentada por SafeBreach en 2023 con diferentes variantes.

Una vez ejecutado, el shellcode comienza resolviendo dinámicamente las direcciones de las API de Windows que necesita para funcionar. Esta es la única parte de RONINGLOADER que emplea alguna ofuscación, empleando el algoritmo de hash Fowler-Noll-Vo (FNV) para buscar funciones por hash en lugar de por nombre.

Primero obtiene las direcciones de CreateFileW, WriteFiley CloseHandle para escribir el controlador en el disco en una ruta codificada de forma rígida, C:\windows\system32\drivers\1912763.temp.

A continuación, realiza las siguientes operaciones:

• Cree un servicio denominado xererre1 para cargar el controlador colocado en el disco
• Para cada uno de los siguientes procesos (360Safe.exe, 360Tray.exey ZhuDongFangYu.exe), que están asociados con el software 360 Qihoo, llama a 2 funciones: una para encontrar el PID del proceso por nombre, seguida de una función para matar el proceso por PID
• A continuación, se detiene y elimina el servicio xererre1

Para matar un proceso, el malware usa el controlador. Un análisis del controlador revela que solo registra 1 funcionalidad: maneja un ID de IOCTL (0x222000) que toma un PID como parámetro y mata el proceso abriéndolo primero con ZwOpenProcessy luego terminándolo con ZwTerminateProcess API del kernel.

Terminación del proceso AV

Volviendo al flujo de ejecución principal, el malware entra en un bucle para confirmar la finalización de 360tray.exe, tal como lo maneja el shellcode inyectado en el servicio VSS. Continúa solo luego de verificar que el proceso ya no se está ejecutando. Inmediatamente luego de esta confirmación, el sistema restaura su configuración de firewall. Es probable que esta acción sea una medida defensiva destinada a cortar el canal de comunicación del software, evitando que cargue registros de actividad finales o alertas de seguridad en sus servicios de backend.

A continuación, finaliza los demás procesos de seguridad directamente desde su proceso principal. En individuo, no intenta ocultar estas acciones, abandonando la técnica de hash de API anterior y llamando directamente a las funciones necesarias.

RONINGLOADER sigue un procedimiento coherente y repetible para terminar sus procesos de destino:

• Primero, escribe el controlador malicioso en el disco, esta vez en la ruta temporal C:\Users\analysis\AppData\Local\Temp\ollama.sys.
• Se crea un servicio temporal (ollama) para cargar ollama.sys en el kernel
• Luego, el malware obtiene el PID del proceso de destino por nombre y envía una solicitud que contiene el PID a su controlador para realizar la terminación.
• Inmediatamente luego de enviar el comando kill, se elimina el servicio.

Con respecto a Microsoft Defender, el malware intenta matar el proceso de MsMpEng.exe empleando el mismo enfoque descrito anteriormente. Notamos un error de código del autor: para Microsoft Defender, el código no verifica si Defender ya se está ejecutando, sino que procede directamente a buscar el proceso MsMpEng.exe . Esto significa que si el proceso no se está ejecutando, el malware enviará 0 como PID al controlador.

El malware tiene más código redundante para matar los procesos de la solución de seguridad. También inyecta otro shellcode en svchost.exe, similar a lo que se inyectó en vssvc.exe, pero la lista de procesos es diferente, como se ve en la captura de pantalla a continuación.

La técnica de inyección también usa grupos de subprocesos, pero el código inyectado se desencadena por un evento.

Luego de la finalización del proceso, el malware crea 4 carpetas

• C:\ProgramData\lnk
• C:\ProgramData\<current_date>
• C:\Users\Public\Downloads\<current_date>
• C:\ProgramData\Roning

Archivos incrustados

Luego, el malware escribe tres archivos .txt en C:\Users\Public\Downloads\<current_date>. A pesar de su extensión, estos no son archivos de texto, sino contenedores construidos con un formato específico, probablemente adaptado de otra base de código.
Esta estructura de archivos personalizada se organiza de la siguiente manera:

• Bytes mágicos: El archivo comienza con la firma 4B 44 01 00 para su identificación.
• Recuento de archivos: A esto le sigue inmediatamente un valor que indica el número de archivos encapsulados dentro del contenedor.
• Metadatos del archivo: A continuación, una sección de encabezado describe la información de cada archivo almacenado.
• Datos comprimidos: Finalmente, cada archivo incrustado se almacena en un bloque de datos comprimido con ZLIB.

Este es un formato de archivo de ejemplo para el hjk.txt archive, que contiene 2 archivos: 1.bat y fhq.bat.
Este formato de archivo se aplica a 2 otros archivos incrustados en la etapa actual:

• agg.txt, que contiene 3 archivos: Enpug.bin, goldendays.dlly trustinstaller.bin
• kill.txt, que contiene 1 archivo - 1.dll

Scripts por lotes para omitir las redes UAC y AV

1.bat es un script por lotes simple que deshabilita el Control de cuentas de usuario (UAC) estableciendo el valor del Registro EnableLUA en 0.

fhq.bat es otro script por lotes que se dirige al programa definido en C:\ProgramData\lnk\123.txt y al software de seguridad Qihoo 360 (360Safe.exe) creando reglas de firewall que bloquean las conexiones entrantes y salientes a ellos. También deshabilita las notificaciones de firewall en todos los perfiles.

Terminación del proceso AV a través de DLL fantasma

El archivo DLL implementado, 1.dll, se copia en C:\Windows\System32\Wow64\Wow64Log.dll para que cualquier proceso WOW64 lo cargue localmente, ya que Wow64Log.dll es un archivo DLL fantasma que no está presente en las máquinas Windows de forma predeterminada. Su tarea es redundante, esencialmente intenta eliminar una lista de procesos empleando las API estándar de Windows (TerminateProcess).

Asesino de ClipUp MS Defender

Luego, el malware intenta emplear una técnica de abuso de PPL documentada por Zero Salarium en agosto de 2025. La PoC del artículo solo tiene como destino Microsoft Defender. Tenga en cuenta que todos los comandos del sistema ejecutados se realizan a través de cmd.exe con la API de ShellExecuteW

• Busca la carpeta de instalación de Microsoft Defender en C:\ProgramData\Microsoft\Windows Defender\Platform\*, dirigir solo al directorio con la fecha de modificación más reciente, que indica la versión empleada actualmente
• Cree un C:\ProgramData\roming de carpeta y un vínculo de directorio con mklink para apuntar al directorio encontrado con el siguiente comando: cmd.exe /c mklink /D "C:\ProgramData\roming" “C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.25050.5-0”
• A continuación, se ejecuta C:\Windows\System32\ClipUp.exe con el siguiente parámetro: -ppl C:\ProgramData\roming\MsMpEng.exe, que sobreescribir MsMpEng.exe con datos basura, deshabilitando efectivamente el EDR incluso luego de un resetear

El autor parece copiar el código de EDR-Freeze para iniciar ClipUp.exe.

Políticas de Ci

El malware se dirige directamente al Control de aplicaciones de Windows Defender (WDAC) escribiendo un archivo de directiva en la ruta de acceso C:\\Windows\\System32\\CodeIntegrity\\CiPolicies\\Active\\{31351756-3F24-4963-8380-4E7602335AAE}.cip.

La política maliciosa opera en un modo de "lista de denegación", lo que permite que la mayoría de las aplicaciones se ejecuten mientras bloquea explícitamente a dos populares proveedores de antivirus chinos:

• Qihoo 360 total seguridad bloqueando 360rp.exe y 360sd.exe
• Seguridad de Huorong bloqueando ARPProte.exe
• Todos los ejecutables firmados por Huorong Security (北京火绒网络科技有限公司) a través del certificado TBS hash A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4

Un componente crítico es la regla Enabled:Unsigned System Integrity Policy , que permite que la directiva se cargue sin una firma digital válida.

Truncated...
    <Rule>
      <Option>Enabled:Inherit Default Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Unsigned System Integrity Policy</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Advanced Boot Options Menu</Option>
    </Rule>
    <Rule>
      <Option>Enabled:Update Policy No Reboot</Option>
    </Rule>
  </Rules>
  <EKUs />
  <FileRules>
    <Allow ID="ID_ALLOW_A_019A298478CE7BF4902DE08CA2D17630" FileName="*" />
    <Allow ID="ID_ALLOW_A_019A298478CE7AB089C369772F34B39B" FileName="*" />
    <Deny ID="ID_DENY_A_019A298478CE7DBA9913BFC227DACD14" FileName="360rp.exe" InternalName="360rp.exe" FileDescription="360杀毒 实时监控" ProductName="360杀毒" />
    <Deny ID="ID_DENY_A_019A298478CE763C85C9F42EC8669750" FileName="360sd.exe" InternalName="360sd.exe" FileDescription="360杀毒 主程序" ProductName="360杀毒" />
    <FileAttrib ID="ID_FILEATTRIB_A_019A298478CE766B9C39FB9CE6805A11" FileName="ARPProte.exe" MinimumFileVersion="6.0.0.0" />
  </FileRules>
  <Signers>
    <Signer ID="ID_SIGNER_A_019A298478CE7608908CAE58FD9C3D8E" Name="">
      <CertRoot Type="TBS" Value="A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4" />
      <CertPublisher Value="北京火绒网络科技有限公司" />
      <FileAttribRef RuleID="ID_FILEATTRIB_A_019A298478CE766B9C39FB9CE6805A11" />
    </Signer>
    <Signer ID="ID_SIGNER_A_019A298478CE77F7B523D1581F518639" Name="">
      <CertRoot Type="TBS" Value="A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4" />
      <CertPublisher Value="北京火绒网络科技有限公司" />
    </Signer>
  </Signers>
...Truncated

Etapa 3 - goldendays.dll

En la etapa anterior, RONINGLOADER crea un nuevo servicio denominado MicrosoftSoftware2ShadowCop4yProvider para ejecutar la siguiente etapa de ejecución con el siguiente comando: regsvr32.exe /S "C:\ProgramData\Roning\goldendays.dll.

El objetivo principal de este componente es inyectar la siguiente carga útil en un proceso legítimo del sistema de alto privilegio para camuflar sus actividades.

Para lograr esto, RONINGLOADER primero identifica un proceso objetivo adecuado. Tiene una lista codificada de dos nombres de servicio que intenta iniciar secuencialmente:

1. Instalador de confianza (TrustedInstaller.exe)
2. MicrosoftEdgeElevationService (elevation_service.exe)

El malware itera a través de esta lista, intentando iniciar cada servicio. Una vez que un servicio se inicia con éxito, o si se encuentra uno ya en ejecución, el malware almacena su ID de proceso (PID) para la fase de inyección.

A continuación, el malware establece persistencia creando un archivo por lotes con un nombre aleatorio dentro del directorio C:\Windows\ (por ejemplo, C:\Windows\KPeYvogsPm.bat). El script dentro de este archivo ejecuta un bucle continuo con la siguiente lógica:

• Comprueba si el PID capturado del servicio de confianza (por ejemplo, PID 4016 para TrustedInstaller.exe) sigue ejecutar
• Si el servicio no se está ejecutando, el script resetear el servicio malicioso creado anteriormente (MicrosoftSoftware2ShadowCop4yProvider) para garantizar que los componentes del malware permanezcan activos
• Si el proceso de servicio se está ejecutando, el script se suspende durante 10 segundos antes de volver a comprobarlo

Finalmente, el malware lee el contenido de C:\ProgramData\Roning\trustinstaller.bin. Empleando el PID del servicio de confianza que adquirió anteriormente, inyecta esta carga útil en el proceso de destino (TrustedInstaller.exe o elevation_service.exe). El método de inyección es sencillo: realiza una asignación virtual remota con VirtualAllocEx, escribe en ella con WriteProcessMemoryy luego crea un subproceso remoto para ejecutarla con CreateRemoteThread.

Etapa 3 - trustinstaller.bin

La tercera etapa, contenida dentro de trustinstaller.bin, es responsable de inyectar la carga útil final en un proceso legítimo. Comienza enumerando los procesos en ejecución y buscando un objetivo haciendo coincidir los nombres de los procesos con una lista codificada de procesos potenciales.

Cuando se encuentre, inyectará el shellcode en C:\ProgramData\Roning\Enpug.bin, que es la carga útil final. Creará una sección con NtCreateSection, mapeará una vista de la misma en el proceso remoto con NtMapViewOfSectiony escribirá la carga útil en ella. Luego creará un subproceso remoto con CreateRemoteThread.

Etapa 4 - Carga útil final

La carga útil final no sufrió cambios importantes desde el descubrimiento de Sophosde una campaña de DragonBreath en 2023 y el reporte de QianXin a mediados de 2022. Sigue siendo una versión modificada del código abierto gh0st RAT.

En las campañas más recientes, se crea un mutex de valor Global\DHGGlobalMutex al comienzo de la ejecución. Fuera del bucle de comunicación C2 principal, se observa que el código muerto crea una exclusión mutua llamada MyUniqueMutexName y la destruye inmediatamente después.

El dominio y el puerto C2 permanecen codificados, pero ahora están cifrados con XOR. El canal C2 funciona a través de sockets TCP sin procesar con mensajes cifrados en ambas direcciones.

Datos de balizas de víctimas

El implante se registra con el servidor C2 y se conecta repetidamente al C2 a intervalos aleatorios, implementado a través de Sleep(<random_amount> * 1000). A continuación se muestra la estructura de los datos que el implante devuelve al servidor C2 durante el intervalo de balizamiento:

struct BeaconData {
    // +0x000
    uint32_t message_type;           // Example Beacon ID - 0xC8 (200)
    
    // +0x004
    uint32_t local_ip;               // inet_addr() of victim's IP
    
    // +0x008
    char hostname[50];               // Computer name or registry "Remark"
    
    // +0x03A
    char windows_version[?];         // OS version info
    
    // +0x0D8
    char cpu_name[64];               // Processor name
    
    // +0x118
    uint32_t entry_rdx;              
    
    // +0x11C
    char time_value[64];             // Implant installed time or registry "Time" value
    
    // +0x15C
    char victim_tag[39];             // Command 6 buffer (Custom victim tag)
    
    // +0x183
    uint8_t is_wow64;                // 1 if 32-bit on 64-bit Windows
    
    // +0x184
    char av_processes_found[128];    // Antivirus processes found
    
    // +0x204
    char uptime[12];                 // System uptime

    char padding[52];                 
    
    // +0x244
    char crypto_wallet_track[64];    // "狐狸系列" (MetaMask) or registry "ZU" (crypto related tracking)
    
    // +0x284
    uint8_t is_admin;                // 1 if running with admin rights
    
    // +0x285
    char data[?];             
    
    // +0x305
    uint8_t telegram_installed;      // 1 if Telegram installed
    
    // +0x306
    uint8_t telegram_running;        // 1 if Telegram.exe running
    
    // +0x307
    // (padding to 0x308 bytes)
};

Comandos C2

Los mensajes de solicitud enviados desde el servidor C2 al implante siguen la estructura:

struct C2_to_implant_msg {
    uint32_t total_message_len;
    uint32_t RC4_key;
    char encrypted_command_id;
    uint8_t encrypted_command_args;
};

El implante descifra los mensajes C2 a través de la siguiente fórmula:

RC4_decrypt(ASCII(decimal(RC4_key)), encrypted_command_id || command)

A continuación se muestra una lista de comandos disponibles que, en su mayor parte, siguen siendo los mismos que hace 2 años:

Nota del analista: Hay varios ID de comando que apuntan al mismo comando. Usamos puntos suspensivos para identificar cuándo se observó esto.

Registrador del sistema

Además de los comandos C2, el implante implementa una pulsación de teclas, un portapapeles y un registrador de ventanas activas. Los datos capturados se escriben en %ProgramData%\microsoft.dotnet.common.log y se pueden habilitar o deshabilitar a través de una clave del Registro en HKEY_CURRENT_USER\offlinekey\open (1 para habilitar, 0 para deshabilitar). El archivo de registro implementa la rotación automática, eliminar a sí mismo cuando supera los 50 MB para evitar la detección por un uso excesivo del disco.

En el fragmento de código siguiente se muestra la rutina de inicialización que implementa la rotación de registros y configura una interfaz DirectInput8 para adquirir el dispositivo de teclado para la captura de eventos, seguido de la lógica de recuperación de eventos de teclado.

Luego, el malware ingresa a un ciclo de monitoreo para capturar tres categorías de información.

• Primero, monitorea el portapapeles usando OpenClipboard y GetClipboardData, registrando cualquier cambio en el contenido del texto con el prefijo [剪切板:].
• En segundo lugar, realiza un seguimiento de los cambios de enfoque de la ventana a través de GetForegroundWindow, registrando el título de la ventana activa y la marca de tiempo con los prefijos [标题:] y [时间:], respectivamente, cada vez que el usuario cambia de aplicación.
• En tercer lugar, recupera los eventos de teclado almacenados en búfer del dispositivo DirectInput8 (hasta 60 eventos por encuesta) y los traduce en texto legible a través de una tabla de mapeo de caracteres, anteponiendo los resultados con un prefijo [内容:].

Secuestrador del portapapeles

El malware también implementa un secuestrador de portapapeles que se configura de forma remota a través del ID de comando C2 243. Monitorear los cambios en el portapapeles y realiza operaciones de búsqueda y reemplazo en el texto capturado, sustituyendo las cadenas definidas por el atacante con valores de reemplazo. Los parámetros de configuración se almacenan en el Registro en HKEY_CURRENT_USER\offlinekey con las claves clipboard (habilitar o deshabilitar característica), charac (cadena de búsqueda), characLen (longitud de búsqueda) y newcharac (cadena de reemplazo).

Registra una clase de ventana denominada ClipboardListener_Class_Toggle y crea una ventana oculta titulada ClipboardMonitor para recibir notificaciones de cambio en el portapapeles. El procedimiento de ventana controla los mensajes de WM_CLIPBOARDUPDATE (0x31D) verificando los números de secuencia del portapapeles con GetClipboardSequenceNumber para detectar cambios genuinos y, a continuación, invocando la rutina de manipulación principal, que intercambia el contenido del portapapeles a través de EmptyClipboard y SetClipboardData.

Malware y MITRE ATT&CK

Elastic usa el framework MITRE ATT&CK para documentar tácticas, técnicas y procedimientos comunes que las amenazas persistentes avanzadas emplean contra las redes empresariales.

Táctica

La táctica representa el porqué de una técnica o subtécnica. Es el objetivo táctico del adversario: la razón para realizar una acción.

• Ejecución
• Persistencia
• Escalada de privilegios
• Evasión de defensa
• Acceso a credenciales
• Descubrimiento
• Colección
• Comando y control

Técnicas

Las técnicas representan cómo un adversario logra un objetivo táctico mediante la realización de una acción.

• Intérprete de comandos y scripting: Shell de comandos de Windows
• Servicios del sistema: Ejecución de servicios
• Crear o modificar proceso del sistema: Servicio de Windows
• Mecanismo de control de elevación de abuso: omitir el control de cuentas de usuario
• Access Token Manipulation
• Debilitar defensas: deshabilitar o modificar herramientas
• Perjudicar las defensas: deshabilitar o modificar el firewall del sistema
• Eliminación del indicador: Borrar registros de eventos de Windows
• Flujo de ejecución de secuestro: carga lateral de DLL
• Inyección de proceso
• Enmascaramiento: Coincidencia de nombre o ubicación legítimos
• Modify Registry
• Subvertir controles de confianza: modificación de la directiva de firma de código
• Captura de entrada: registro de teclas
• Datos del portapapeles
• Descubrimiento de procesos
• Detección de información del sistema
• System Owner/User Discovery
• Descubrimiento de software: Descubrimiento de software de seguridad
• Non-Application Layer Protocol
• Canal cifrado: criptografía simétrica

Mitigaciones

Detección

• Evasión potencial a través de la ejecución de ClipUp
• Asignación de memoria remota sospechosa
• Posible inyección de código de proceso suspendido
• Escritura de memoria remota en un proceso de destino de confianza
• Escritura de memoria de proceso remoto mediante módulo de baja reputación
• Memoria de proceso Escribir en un proceso no secundario
• Shellcode sin respaldo de un módulo sin firmar
• Intento de omisión de UAC a través de la carga lateral de DLL del registrador WOW64
• API de conexión de red desde memoria sin respaldo
• Rundll32 or Regsvr32 Loaded a DLL from Unbacked Memory
• Módulo de red cargado desde una memoria sospechosa sin respaldo

YARA

Elastic Security creó reglas de YARA para identificar esta actividad. A continuación se muestran las reglas de YARA para identificar RONINGLOADER y el implante final:

• Windows.Trojan.RoningLoader
• Windows.Trojan.DragonBreath

Observaciones

En esta investigación se discutieron los siguientes observables.

Referencias

A lo largo de la investigación anterior se hizo referencia a lo siguiente:

• https://nsis.sourceforge.io/main_page
• https://learn.microsoft.com/en-us/windows-server/storage/file-server/volume-shadow-copy-service
• https://github.com/jemmy1228/hooksigntool
• https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
• https://hijacklibs.net/entries/microsoft/built-in/wow64log.html
• https://en.wikipedia.org/wiki/fowler%E2%80%93Noll%E2%80%93Vo_hash_function
• https://www.zerosalarium.com/2025/08/countering-edrs-with-backing-of-ppl-protection.html
• https://github.com/twosevenonet/edr-freeze/blob/ceffd5ea7b813b356c77d469561dbb5ee45aeb24/pplhelp.cpp#L43
• https://news.sophos.com/en-us/2023/05/03/doubled-dll-sideloading-dragon-breath/
• https://ti.qianxin.com/blog/articles/operation-dragon-breath-%28apt-q-27%29-dimensionality-reduction-blow-to-the-gambling-industry/
• https://github.com/sin5678/gh0st