RONINGLOADER: O Novo Caminho do DragonBreath para o Abuso de PPL

Introdução

A Elastic Security Labs identificou uma campanha recente de distribuição de uma variante modificada do RAT gh0st, atribuída ao grupo APT Dragon Breath (APT-Q-27), por meio de instaladores NSIS infectados por trojans, disfarçados de softwares legítimos como o Google Chrome e o Microsoft Teams. A cadeia de infecção emprega um mecanismo de distribuição em múltiplos estágios que utiliza diversas técnicas de evasão, com muitas redundâncias destinadas a neutralizar produtos de segurança de endpoints populares no mercado chinês. Essas práticas incluem o uso de um driver assinado legitimamente, a implementação de políticas WDAC personalizadas e a adulteração do binário do Microsoft Defender por meio de abuso da Licença de Proteção de Plataforma (PPL).

Esta campanha tem como alvo principal os usuários de língua chinesa e demonstra uma clara evolução em termos de adaptabilidade em comparação com as campanhas anteriores relacionadas ao DragonBreath documentadas em 2022-2023. Por meio deste relatório, esperamos aumentar a conscientização sobre as novas técnicas que este malware está começando a implementar e destacar um carregador exclusivo que denominamos RoningLoader.

Principais conclusões

• O malware explora uma vulnerabilidade do Protected Process Light (PPL) para desativar o Windows Defender.
• Os agentes maliciosos exploram um driver de kernel válido e assinado para encerrar processos.
• Política WDAC personalizada não assinada aplicada para bloquear executáveis do Total Security e do Huorong 360
• DLLs fantasmas e injeção de payload via pools de threads para posterior encerramento do processo antivírus
• A carga útil final apresenta pequenas atualizações e está associada ao DragonBreath.

Descoberta

Em agosto de 2025, foi publicada uma pesquisa detalhando um método para abusar da vulnerabilidade Protected Process Light (PPL) e desativar ferramentas de segurança de endpoints. Após essa divulgação, criamos uma regra comportamental, " Evasão Potencial via Execução do ClipUp", e, após alguma busca por ameaças em dados de telemetria, identificamos uma campanha ativa que empregava a técnica.

Análise de código RONINGLOADER

O vetor de infecção inicial é um instalador trojanizado criado usando o Nullsoft Scriptable Install System (NSIS). O NSIS é uma ferramenta legítima e de código aberto para criar instaladores do Windows, mas é frequentemente usado indevidamente por agentes maliciosos para empacotar e distribuir malware, como visto no GULOADER. Nesta campanha, observamos a distribuição de instaladores maliciosos sob diversos temas, disfarçados de softwares legítimos como o Google Chrome, o Microsoft Teams ou outros aplicativos confiáveis, com o objetivo de induzir os usuários a executá-los.

Após a execução, o instalador NSIS principal funciona como um instalador auxiliar, contendo dois instaladores NSIS adicionais incorporados. Um dos instaladores aninhados é benigno e instala o software legítimo, enquanto o segundo é malicioso e responsável por implantar a cadeia de ataque.

A cadeia de ataque utiliza um driver assinado chamado ollama.sys para encerrar o processo do antivírus. O motorista tem um nome de signatário de Kunming Wuqi E-commerce Co., Ltd., com um certificado válido de fevereiro 3, 2025, a fevereiro 3, 2026. A análise do VirusTotal revelou 71 binários assinados adicionais. Entre estes, identificamos droppers do AgentTesla disfarçados de 慕讯公益加速器 (MuXunAccelerator), um software VPN focado em jogos popular entre usuários chineses, com amostras que datam de abril de 2025. É importante destacar que as técnicas de assinatura variam entre as amostras. Algumas amostras anteriores, como inject.sys, contêm artefatos HookSignTool incluindo a string JemmyLoveJenny, enquanto a amostra de outubro 2025 ollama.sys não mostra tais artefatos e usa procedimentos de assinatura padrão, mas ambas compartilham o mesmo período de validade do certificado.

Comparando o artefato de string PDB D:\VS_Project\加解密\MyDriver1\x64\Release\MyDriver1.pdb de ollama.syscom outras amostras, descobrimos artefatos diferentes em relação às outras amostras 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

Devido à diversidade de binários e ao grande volume de submissões, suspeitamos que o certificado possa ter sido vazado, mas isso é mera especulação neste momento.

Estágio 1

Nossa análise começou com o binário inicial, identificado por seu hash SHA256: da2c58308e860e57df4c46465fd1cfc68d41e8699b4871e9a9be3c434283d50b. Ao extrair, revelam-se dois executáveis incorporados: um instalador benigno, letsvpnlatest.exe, e o instalador malicioso Snieoatwtregoable.exe.

O instalador malicioso, Snieoatwtregoable.exe, cria um novo diretório em C:\Program Files\Snieoatwtregoable\. Dentro desta pasta, ele coloca dois arquivos: uma DLL chamada Snieoatwtregoable.dll e um arquivo criptografado, tp.png.

O núcleo da atividade maliciosa reside em Snieoatwtregoable.dll, que exporta uma única função: DllRegisterServer. Quando invocada, esta função lê o conteúdo do arquivo tp.png do disco e, em seguida, descriptografa esses dados usando um algoritmo simples que envolve uma rotação à direita (ROR) e uma operação XOR.

O conteúdo descriptografado é um shellcode que carrega e executa, por meio de reflexão, um arquivo PE na memória. O malware primeiro aloca uma nova região de memória dentro de seu próprio processo usando a API NtAllocateVirtualMemory , depois cria uma nova thread para executar o shellcode chamando NtCreateThreadEx.

O malware tenta remover quaisquer ganchos de espaço do usuário carregando um novo ntdll.dll, e então usando GetProcAddress com o nome da API para resolver os endereços.

O malware tenta se conectar ao localhost na porta 5555 sem qualquer propósito real, já que o resultado não importa; especulando, é provável que seja código morto ou código residual de pré-produção.

Estágio 2 - tp.png

RONINGLOADER primeiro verifica se possui privilégios administrativos usando a API GetTokenInformation . Caso contrário, ele tenta elevar seus privilégios usando o comando runas para iniciar uma nova instância elevada de si mesmo antes de encerrar o processo original.

Curiosamente, o malware tenta comunicar com um URL codificado http://www.baidu.com/ com o agente de usuário “Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko”, mas este parece ser um código morto, provavelmente devido a um recurso removido ou código de espaço reservado para versões futuras. Ele foi projetado para extrair e registrar a data do cabeçalho de resposta HTTP da URL.

O malware então examina uma lista de processos em execução em busca de soluções antivírus específicas. A função verifica uma lista predefinida de nomes de processos e define um sinalizador booleano correspondente como "Verdadeiro" caso algum seja encontrado.

A seguir, encontra-se uma tabela com os processos e os respectivos produtos de segurança incorporados no binário:

Encerramento do processo AV por meio de processo remoto injetado

Em seguida, o malware encerra esses processos. Curiosamente, o produto Qihoo 360 Total Security adota uma abordagem diferente dos demais.

Primeiro, ele bloqueia toda a comunicação de rede alterando o firewall. Em seguida, chama uma função para injetar shellcode no processo (vssvc.exe) associado ao serviço de Cópia de Sombra de Volume (VSS).
Primeiro, ele concede a si mesmo o token de alta integridade SeDebugPrivilege .

Em seguida, inicia o VSS (Volume Shadow Copy Service) caso ainda não esteja em execução e obtém o PID do processo associado (vssvc.exe).

Em seguida, o malware usa NtCreateSection para criar duas seções de memória separadas. Em seguida, mapeia as visualizações dessas seções no espaço de memória do processo vssvc.exe. A primeira seção contém um arquivo executável portátil (PE) completo, que é um driver com o nome do dispositivo \\.\Ollama. A segunda seção contém código shell destinado à execução.

O RONINGLOADER adota uma abordagem diferente para essa injeção de processo em comparação com outros métodos de injeção usados em outras partes do malware. Essa técnica utiliza o pool de threads para executar código remotamente por meio de um gatilho de gravação de arquivo no processo remoto. Esta técnica foi documentada pela SafeBreach em 2023 com diferentes variantes.

Após a execução, o shellcode começa resolvendo dinamicamente os endereços das APIs do Windows necessárias para o seu funcionamento. Esta é a única parte do RONINGLOADER que emprega qualquer tipo de ofuscação, usando o algoritmo de hash Fowler-Noll-Vo (FNV) para buscar funções por hash em vez de por nome.

Primeiro, ele busca os endereços de CreateFileW, WriteFile e CloseHandle para gravar o driver no disco em um caminho fixo, C:\windows\system32\drivers\1912763.temp.

Em seguida, realiza as seguintes operações:

• Crie um serviço chamado xererre1 para carregar o driver gravado no disco.
• Para cada um dos seguintes processos (360Safe.exe, 360Tray.exe e ZhuDongFangYu.exe), todos associados ao software Qihoo 360 , são chamadas 2 funções: uma para encontrar o PID do processo pelo nome, seguida de uma função para encerrar o processo pelo PID.
• Em seguida, ele para e exclui o serviço. xererre1

Para encerrar um processo, o malware utiliza o driver. Uma análise do driver revela que ele registra apenas a funcionalidade 1 : ele lida com um ID IOCTL (0x222000) que recebe um PID como parâmetro e mata o processo primeiro abrindo-o com ZwOpenProcess, depois terminando-o com APIs do kernel ZwTerminateProcess .

encerramento do processo AV

Retornando ao fluxo de execução principal, o malware entra em um loop para confirmar o término de 360tray.exe, conforme tratado pelo shellcode injetado no serviço VSS. O processo só prossegue após verificar se ele não está mais em execução. Imediatamente após essa confirmação, o sistema restaura suas configurações de firewall. Essa ação provavelmente é uma medida defensiva destinada a interromper o canal de comunicação do software, impedindo-o de enviar registros de atividades finais ou alertas de segurança para seus serviços de backend.

Em seguida, ele encerra os outros processos de segurança diretamente a partir de seu processo principal. Notavelmente, não há qualquer tentativa de ocultar essas ações, abandonando a técnica anterior de hashing da API e chamando as funções necessárias diretamente.

RONINGLOADER segue um procedimento consistente e repetível para encerrar seus processos alvo:

• Primeiro, ele grava o driver malicioso no disco, desta vez no caminho temporário. C:\Users\analysis\AppData\Local\Temp\ollama.sys.
• Um serviço temporário (ollama) é criado para carregar ollama.sys no kernel.
• O malware então obtém o PID do processo alvo pelo nome e envia uma solicitação contendo o PID para o seu driver para realizar o encerramento.
• Imediatamente após o envio do comando de encerramento, o serviço é deletado.

Com relação ao Microsoft Defender, o malware tenta encerrar o processo MsMpEng.exe usando a mesma abordagem descrita acima. Detectamos um erro de código do autor: para o Microsoft Defender, o código não verifica se o Defender já está em execução, mas procede diretamente à busca do processo MsMpEng.exe . Isso significa que se o processo não estiver em execução, o malware enviará 0 como o PID para o driver.

O malware possui código redundante adicional para interromper os processos da solução de segurança. Ele também injeta outro shellcode no svchost.exe, semelhante ao que foi injetado em vssvc.exe, mas a lista de processos é diferente, como pode ser visto na captura de tela abaixo.

A técnica de injeção também utiliza pools de threads, mas o código injetado é acionado por um evento.

Após o término do processo, o malware cria 4 pastas.

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

Arquivos incorporados

O malware então grava três arquivos .txt em C:\Users\Public\Downloads\<current_date>. Apesar da extensão, estes não são arquivos de texto, mas sim contêineres construídos com um formato específico, provavelmente adaptado de outra base de código.
Essa estrutura de arquivos personalizada está organizada da seguinte forma:

• Bytes mágicos: O arquivo começa com a assinatura 4B 44 01 00 para identificação.
• Contagem de arquivos: Em seguida, é exibido um valor que indica o número de arquivos contidos no contêiner.
• Metadados do arquivo: Uma seção de cabeçalho descreve as informações de cada arquivo armazenado.
• Dados comprimidos: Por fim, cada arquivo incorporado é armazenado em um bloco de dados comprimido com ZLIB.

Aqui está um exemplo de formato de arquivo para hjk.txt archive, que contém 2 arquivos: 1.bat e fhq.bat.
Este formato de arquivo se aplica a outros 2 arquivos incorporados na etapa atual:

• agg.txt, que contém 3 arquivos - Enpug.bin, goldendays.dll e trustinstaller.bin
• kill.txt, que contém o arquivo 1 - 1.dll

Scripts em lote para contornar o UAC e o antivírus em redes.

1.bat É um script em lote simples que desativa o Controle de Conta de Usuário (UAC) definindo o valor de registro EnableLUA como 0.

fhq.bat é outro script em lote que tem como alvo o programa definido em C:\ProgramData\lnk\123.txt e o software de segurança Qihoo 360 (360Safe.exe) criando regras de firewall que bloqueiam as conexões de entrada e saída para eles. Isso também desativa as notificações do firewall em todos os perfis.

Encerramento do processo AV via Phantom DLL

A DLL implantada, 1.dll, é copiada para C:\Windows\System32\Wow64\Wow64Log.dll para ser carregada lateralmente por quaisquer processos WOW64, já que Wow64Log.dll é uma DLL fantasma que não está presente nas máquinas Windows por padrão. Sua tarefa é redundante, essencialmente tentando matar uma lista de processos usando APIs padrão do Windows (TerminateProcess).

ClipUp MS Defender killer

O malware tenta então usar uma técnica de abuso de PPL documentada pela Zero Salarium em agosto de 2025. A prova de conceito do artigo tem como alvo apenas o Microsoft Defender. Observe que todos os comandos do sistema executados são feitos por meio de cmd.exe com a API ShellExecuteW

• A busca pela pasta de instalação do Microsoft Defender em C:\ProgramData\Microsoft\Windows Defender\Platform\*, direcionando apenas para o diretório com a data de modificação mais recente, que indica a versão atualmente em uso.
• Crie uma pasta C:\ProgramData\roming e um link de diretório com mklink para apontar para o diretório encontrado com o seguinte comando: cmd.exe /c mklink /D "C:\ProgramData\roming" “C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.25050.5-0”
• Em seguida, executa C:\Windows\System32\ClipUp.exe com o seguinte parâmetro: -ppl C:\ProgramData\roming\MsMpEng.exe, que sobrescreve MsMpEng.exe com dados inválidos, desativando efetivamente o EDR mesmo após uma reinicialização.

O autor parece ter copiado código do EDR-Freeze para iniciar ClipUp.exe.

Políticas Ci

O malware tem como alvo direto o Controle de Aplicativos do Windows Defender (WDAC) escrevendo um arquivo de política no caminho C:\\Windows\\System32\\CodeIntegrity\\CiPolicies\\Active\\{31351756-3F24-4963-8380-4E7602335AAE}.cip.

A política maliciosa opera em modo de "lista de bloqueio", permitindo que a maioria dos aplicativos seja executada, enquanto bloqueia explicitamente dois fornecedores populares de antivírus chineses:

• Qihoo 360 Segurança Total bloqueando 360rp.exe e 360sd.exe
• Huorong Security bloqueando ARPProte.exe
• Todos os executáveis assinados pela Huorong Security (北京火绒网络科技有限公司) através do certificado TBS hash A229D2722BC6091D73B1D979B81088C977CB028A6F7CBF264BB81D5CC8F099F87D7C296E48BF09D7EBE275F5498661A4

Um componente crítico é a regra Enabled:Unsigned System Integrity Policy , que permite que a política seja carregada sem uma assinatura 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

Na etapa anterior, o RONINGLOADER cria um novo serviço chamado MicrosoftSoftware2ShadowCop4yProvider para executar a próxima etapa de execução com o seguinte comando: regsvr32.exe /S "C:\ProgramData\Roning\goldendays.dll.

O objetivo principal deste componente é injetar a próxima carga útil em um processo legítimo do sistema com altos privilégios, a fim de camuflar suas atividades.

Para atingir esse objetivo, o RONINGLOADER primeiro identifica um processo alvo adequado. Possui uma lista fixa de dois nomes de serviço que tenta iniciar sequencialmente:

1. TrustedInstaller (TrustedInstaller.exe)
2. MicrosoftEdgeElevationService (elevation_service.exe)

O malware percorre essa lista, tentando iniciar cada serviço. Assim que um serviço é iniciado com sucesso, ou se um já estiver em execução, o malware salva seu ID de processo (PID) para a fase de injeção.

Em seguida, o malware estabelece persistência criando um arquivo em lote com um nome aleatório dentro do diretório C:\Windows\ (por exemplo, C:\Windows\KPeYvogsPm.bat). O script dentro deste arquivo executa um loop contínuo com a seguinte lógica:

• Verifica se o PID capturado do serviço confiável (por exemplo, PID 4016 para TrustedInstaller.exe) ainda está em execução.
• Se o serviço não estiver em execução, o script reinicia o serviço malicioso previamente criado (MicrosoftSoftware2ShadowCop4yProvider) para garantir que os componentes do malware permaneçam ativos.
• Se o processo de serviço estiver em execução, o script aguarda 10 segundos antes de verificar novamente.

Finalmente, o malware lê o conteúdo de C:\ProgramData\Roning\trustinstaller.bin. Usando o PID do serviço confiável que adquiriu anteriormente, ele injeta essa carga útil no processo alvo (TrustedInstaller.exe ou elevation_service.exe). O método de injeção é simples: ele realiza uma alocação virtual remota com VirtualAllocEx, escreve nela com WriteProcessMemory e então cria um thread remoto para executá-la com CreateRemoteThread.

Etapa 3 - trustinstaller.bin

A terceira etapa, contida em trustinstaller.bin, é responsável por injetar a carga útil final em um processo legítimo. O processo começa por enumerar os processos em execução e procurar um alvo, comparando os nomes dos processos com uma lista predefinida de processos potenciais.

Quando encontrado, ele irá injetar o shellcode em C:\ProgramData\Roning\Enpug.bin, que é a carga útil final. Ele criará uma seção com NtCreateSection, mapeará uma visualização dela no processo remoto com NtMapViewOfSection e escreverá a carga útil nela. Em seguida, criará um thread remoto com CreateRemoteThread.

Etapa 4 - Carga útil final

A carga útil final não sofreu grandes alterações desde a descoberta de uma campanha DragonBreath pela Sophosem 2023 e o relatório de QianXin em meados de 2022. Ainda é uma versão modificada do RAT de código aberto gh0st .

Nas campanhas mais recentes, um mutex de valor Global\DHGGlobalMutex é criado logo no início da execução. Fora do loop principal de comunicação C2, observa-se código morto criando um mutex chamado MyUniqueMutexName e destruindo-o imediatamente depois.

O domínio e a porta C2 permanecem fixos no código, mas agora estão criptografados com XOR. O canal C2 opera sobre sockets TCP brutos com mensagens criptografadas em ambas as direções.

Dados do sinalizador da vítima

O implante verifica com o servidor C2 e envia sinais repetidamente para o C2 em intervalos aleatórios, implementados através de Sleep(<random_amount> * 1000). A seguir, apresentamos a estrutura dos dados que o implante retorna ao servidor C2 durante o intervalo de sinalização:

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

As mensagens de requisição enviadas do servidor C2 para o implante seguem a seguinte estrutura:

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

O implante decifra mensagens C2 através da seguinte fórmula:

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

A seguir, uma lista de comandos disponíveis que, em sua maioria, permanecem os mesmos de 2 anos atrás:

Nota do analista: Existem vários IDs de comando que apontam para o mesmo comando. Utilizamos reticências para identificar quando isso foi observado.

Registrador de sistema

Além dos comandos C2, o implante implementa um registrador de teclas, de área de transferência e de janela ativa. Os dados capturados são gravados em %ProgramData%\microsoft.dotnet.common.log e podem ser ativados ou desativados por meio de uma chave de registro em HKEY_CURRENT_USER\offlinekey\open (1 para ativar, 0 para desativar). O arquivo de log implementa rotação automática, excluindo-se quando excede 50 MB para evitar detecção por uso excessivo de disco.

O trecho de código abaixo demonstra a rotina de inicialização que implementa a rotação de logs e configura uma interface DirectInput8 para adquirir o dispositivo de teclado para captura de eventos, seguida pela lógica de recuperação de eventos do teclado.

O malware entra então em um ciclo de monitoramento para capturar três categorias de informações.

• Primeiro, ele monitora a área de transferência usando OpenClipboard e GetClipboardData, registrando quaisquer alterações no conteúdo do texto com o prefixo [剪切板:].
• Em segundo lugar, ele rastreia as mudanças de foco da janela por meio de GetForegroundWindow, registrando o título e o carimbo de data/hora da janela ativa com os prefixos [标题:] e [时间:], respectivamente, sempre que o usuário alterna entre aplicativos.
• Terceiro, ele recupera eventos de teclado armazenados em buffer do dispositivo DirectInput8 (até 60 eventos por pesquisa) e os traduz em texto legível por meio de uma tabela de mapeamento de caracteres, precedendo os resultados com um prefixo [内容:].

Sequestrador de área de transferência

O malware também implementa um sequestrador de área de transferência que é configurado remotamente através do comando C2 ID 243. Ele monitora as alterações na área de transferência e realiza operações de busca e substituição no texto capturado, substituindo as sequências definidas pelo atacante por valores alternativos. Os parâmetros de configuração são armazenados no registro em HKEY_CURRENT_USER\offlinekey com as chaves clipboard (ativar/desativar recurso), charac (string de pesquisa), characLen (comprimento da pesquisa) e newcharac (string de substituição).

Ele registra uma classe de janela chamada ClipboardListener_Class_Toggle e cria uma janela oculta intitulada ClipboardMonitor para receber notificações de alteração da área de transferência. O procedimento da janela lida com as mensagens WM_CLIPBOARDUPDATE (0x31D) verificando os números de sequência da área de transferência com GetClipboardSequenceNumber para detectar alterações genuínas e, em seguida, invocando a rotina de manipulação principal, que troca o conteúdo da área de transferência por meio de EmptyClipboard e SetClipboardData.

Malware e MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que ameaças persistentes avançadas usam contra redes corporativas.

Táticas

As táticas representam o porquê de uma técnica ou subtécnica. É o objetivo tático do adversário: a razão para executar uma ação.

• Execução
• Persistência
• Escalação de privilégios
• Defense Evasion
• Acesso a credenciais
• Descoberta
• Coleta
• Command and Control (Comando e controle)

Técnicas

Técnicas representam como um adversário atinge um objetivo tático executando uma ação.

• Interpretador de comando e script: Shell de comando do Windows
• Serviços do sistema: Execução de serviços
• Criar ou modificar processo do sistema: serviço do Windows
• Abuse do mecanismo de controle de elevação: ignore o controle de conta de usuário
• Access Token Manipulation
• Impair Defenses: Desabilitar ou modificar ferramentas
• Comprometer as defesas: Desativar ou modificar o firewall do sistema.
• Remoção do indicador: Limpar logs de eventos do Windows
• Fluxo de execução do Hijack: carregamento lateral de DLL
• Injeção de processo
• Mascaramento: corresponder a nome ou local legítimo
• Modify Registry
• Subverter controles de confiança: Modificação da política de assinatura de código
• Captura de entrada: Keylogging
• Dados da área de transferência
• Descoberta de Processos
• Descoberta de informações do sistema
• System Owner/User Discovery
• Descoberta de Software: Descoberta de Software de Segurança
• Non-Application Layer Protocol
• Canal Criptografado: Criptografia Simétrica

Mitigações

Detecção

• Possível evasão por meio da execução do ClipUp
• Alocação de memória remota suspeita
• Injeção de código de processo potencialmente suspenso
• Gravação remota de memória em processo de destino confiável
• Escrita remota na memória do processo por módulo de baixa reputação
• Escrita na memória do processo para um processo não filho
• Shellcode sem suporte do módulo não assinado
• Tentativa de burlar o UAC através do carregamento lateral da DLL do logger WOW64
• API Network Connect a partir de memória não suportada
• Rundll32 or Regsvr32 Loaded a DLL from Unbacked Memory
• Módulo de rede carregado de memória suspeita sem backup

YARA

A Elastic Security criou regras YARA para identificar essa atividade. Abaixo estão as regras YARA para identificar o RONINGLOADER e o implante final:

• Windows.Trojan.RoningLoader
• Windows.Trojan.Sopro de Dragão

Observações

Os seguintes observáveis foram discutidos nesta pesquisa.

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• https://nsis.sourceforge.io/Página_Principal
• 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.zerosalario.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