Rhadamanthys v0.5.0 amplia cadeia modular e técnicas de evasão no Windows

A versão analisada do ladrão de informações usa carregamento em múltiplos estágios, módulos XS1, TLS, chamadas de sistema indiretas e carga esteganográfica para dificultar análise e monitoramento.

Componente	Rhadamanthys v0.5.0, com carregador Windows PE de 32 bits, módulos em formato customizado XS1, módulos netclient e proto, e pacotes internos identificados como package #1 e package #2.
Vetor	Execução de um binário Windows que contém configuração embutida e componentes adicionais; a cadeia pode reiniciar em outro processo, injetar o módulo principal, apagar o arquivo original conforme configuração e buscar módulos de roubo no C2.
Impacto	Preparação e execução de componentes de roubo de informações, com evasão de sandbox, ofuscação de strings, redução de artefatos em memória, comunicação com C2 e download de carga anexada a arquivo JPG ou WAV.
Prioridade	Priorizar detecção de carregamento modular em memória, uso anômalo de TLS, chamadas de sistema indiretas, injeção em processo recém-criado e download de conteúdo com dados adicionais anexados a mídia.
Artefatos	Marcador de configuração !RHY, seção .textbss preenchida em tempo de execução, módulos netclient e proto, lista ua.txt, uso de RC4 para restaurar o módulo principal e formato customizado XS1.
Mitigação	Bloquear a execução inicial por controles de endpoint, revisar telemetria de criação de processos e memória, inspecionar tráfego para C2 configurado e conter hosts com sinais de carregamento de módulos Rhadamanthys.

Resumo técnico

Rhadamanthys v0.5.0 mantém a proposta de ladrão de informações, mas a versão analisada mostra uma cadeia mais refinada para preparar o ambiente antes de carregar os módulos finais de coleta. O executável inicial é um PE Windows de 32 bits que carrega uma configuração embutida, contém um pacote com componentes adicionais e conduz a transição para estágios posteriores. A amostra avaliada inclui lógica para detectar nomes de arquivo com aparência de hash hexadecimal nos tamanhos 16, 32, 40 ou 64 caracteres. Essa condição é relevante porque amostras enviadas a sandboxes costumam ser renomeadas dessa forma; quando o padrão é encontrado, o malware encerra a execução e evita expor seu fluxo completo ao ambiente automatizado.

A cadeia usa um desenho em camadas. O carregador inicial prepara uma seção .textbss, vazia no arquivo em disco, para receber em tempo de execução um shellcode responsável por desempacotar e carregar o primeiro módulo. O estágio seguinte aparece no formato customizado XS1, já observado em versões anteriores, e recebe a configuração decodificada do nível anterior. Essa configuração começa com o marcador !RHY e inclui, entre outros campos, o endereço do C2 usado posteriormente. A versão v0.5.0 também introduz ofuscação de strings, uso de TLS para buffers temporários, chamadas de sistema indiretas e um fluxo em que netclient e proto cooperam para baixar e validar o pacote que contém os componentes de roubo.

Fluxo técnico

O primeiro desvio defensivo ocorre antes do carregamento principal: o binário verifica o próprio nome e encerra caso ele pareça ter sido renomeado para um hash. Superada essa condição, o conteúdo necessário ao próximo estágio é expandido na seção .textbss. Em versões anteriores, código com função semelhante era colocado em uma região recém-alocada; nesta versão, a seção presente no PE serve como destino para o conteúdo carregado em tempo de execução. O papel técnico continua sendo desempacotar e executar o primeiro módulo do pacote interno. Esse módulo XS1 faz a ponte entre o executável inicial e os componentes que preparam a comunicação com infraestrutura externa.

Depois que o módulo XS1 é convertido internamente para execução, ele usa a configuração recebida da camada anterior. A versão analisada dificulta a leitura estática porque as strings deixam de aparecer de forma direta em extrações convencionais. Para isso, o malware usa TLS como área temporária. A rotina inicial aloca um índice com TlsAlloc, cria uma estrutura com buffer próprio e associa esse buffer ao armazenamento local da thread. Em chamadas posteriores, a mesma área é recuperada para deofuscar dados, incluindo strings. O algoritmo descrito para esse estágio usa uma chave de 16 bytes no início do bloco e dados terminados por zero. Para defesa, o ponto importante não é reproduzir a rotina, mas reconhecer que strings sensíveis podem existir apenas de forma transitória em memória.

Outra característica relevante é o uso de chamadas de sistema brutas e indiretas. O malware evita depender diretamente de APIs exportadas por bibliotecas como NTDLL e WIN32U, que frequentemente são monitoradas por produtos de segurança. Em vez de chamar a entrada instrumentada, a amostra prepara a chamada e transfere a execução para uma região da NTDLL próxima ao final da função, de modo que a transição para o núcleo ocorra a partir de um módulo do sistema. O desenho reduz a visibilidade de hooks tradicionais e tenta diminuir a suspeita causada por syscalls emitidas diretamente de módulos não pertencentes ao sistema. Em processos WoW64, a amostra também contempla a diferença entre 32 e 64 bits e implementa sua própria passagem usando a técnica Heaven’s Gate.

A etapa de obtenção dos módulos finais depende de netclient e proto. Ambos são carregados na mesma região de memória, com proto posicionado após netclient. O componente principal chama netclient com o endereço do C2 extraído da configuração e um User-Agent selecionado de ua.txt; se essa lista não estiver disponível, um valor embutido é usado. No início da execução de netclient, o módulo principal XS1 é criptografado e só volta a ser decifrado antes do retorno. A segunda chamada a proto restaura esse módulo com RC4 e uma chave gerada anteriormente. Depois que o payload é baixado, a integridade é verificada por comparação de hash calculado contra o hash esperado no cabeçalho do bloco. Na amostra descrita, a carga estava anexada a um arquivo WAV; o mesmo desenho também admite conteúdo anexado a JPG.

Superfície afetada

A superfície exposta é composta por estáções Windows onde o executável inicial consiga rodar e avançar pela cadeia de carregamento. O fluxo observado começa em um processo de 32 bits, mas considera a arquitetura do sistema para decidir se os próximos estágios continuam no processo atual ou passam para um novo processo de 64 bits. Quando a configuração habilita o comportamento de reinicialização, o módulo principal roda em dois caminhos: no primeiro, injeta a si mesmo em um processo recém-criado; no segundo, já dentro do novo processo, pode apagar o arquivo original e carregar módulos adicionais do package #1, incluindo netclient.

O risco operacional está no conjunto de condições que reduzem a visibilidade da execução. A amostra tenta escapar de sandboxes por nome de arquivo, oculta conteúdo na seção .textbss, usa formato XS1, mantém strings ofuscadas, armazena buffers temporários em TLS, criptografa o módulo principal durante a comunicação e apaga regiões de memória usadas por netclient e proto após o download. Esses comportamentos não provam por si só uma infecção por Rhadamanthys, mas formam uma combinação forte quando aparecem junto de conexão a C2 configurado, mídia com dados anexados e transição entre processos.

• Endpoints Windows que executem o PE inicial de 32 bits com configuração embutida e pacote interno de módulos.
• Ambientes de análise automatizada podem perder o fluxo completo se a amostra for renomeada para um padrão hexadecimal compatível com hash.
• Processos recém-criados usados como alvo de injeção devem ser tratados como superfície crítica quando houver cópia do módulo principal para memória.
• Hosts com tráfego para C2 e recebimento de arquivos WAV ou JPG contendo dados adicionais anexados exigem investigação de memória e endpoint.

Hunting e telemetria

A busca deve combinar sinais de endpoint, memória e rede. No endpoint, um ponto de partida é a execução de binários que encerram rapidamente quando o nome do arquivo possui apenas caracteres hexadecimais e tamanhos típicos de hash. Outro sinal é a presença de uma seção .textbss vazia no arquivo, mas preenchida em tempo de execução com código executável ou shellcode. A defesa também deve observar módulos não convencionais carregados em memória, ausência de strings úteis em análise estática, buffers transitórios associados a TLS e sequências de alocação, escrita e execução que antecedem a chamada de componentes internos.

Na memória, sinais mais específicos incluem conteúdo compatível com o marcador !RHY, artefatos do formato XS1, regiões que hospedam netclient e proto de forma contígua, e criptografia temporária do módulo principal durante a comunicação de rede. Como a cadeia destrói a região onde netclient e proto foram carregados após o retorno, coletas tardias podem não conter os artefatos mais úteis. Por isso, alertas de criação de processo, injeção, chamadas de sistema indiretas e conexão externa devem acionar aquisição rápida de memória e preservação de eventos de EDR.

Na rede, o tráfego relevante envolve contato com C2 definido na configuração e download de uma carga validada por hash. O conteúdo pode estar anexado a mídia JPG ou WAV, o que exige inspeção voltada a tamanho, estrutura e dados excedentes, não apenas ao tipo declarado do arquivo. A presença de User-Agent selecionado de uma lista ua.txt ou de valor embutido também pode auxiliar correlação quando combinada com telemetria de processo. A ausência de um domínio ou IP específico no material analisado impede criar bloqueios por indicador único; a abordagem defensiva deve privilegiar comportamento, sequência de estágios e anomalias de arquivo.

• Processo que inicia, valida o próprio nome como possível hash hexadecimal e encerra antes de expor atividade adicional.
• Seção .textbss sem conteúdo bruto no arquivo, mas usada em tempo de execução para código desempacotado.
• Uso de TlsAlloc seguido de buffers temporários reaproveitados para deofuscação de strings em módulos suspeitos.
• Chamadas de sistema indiretas que evitam o início instrumentado de funções em NTDLL ou WIN32U.
• Criação de novo processo seguida de injeção do módulo principal, execução no processo destino e possível remoção do arquivo original.
• Download de WAV ou JPG com dados anexados e validação de integridade antes de carregar o próximo pacote.

Mitigação

A resposta deve começar pela contenção do host que executou o carregador, porque a cadeia foi desenhada para reduzir artefatos após cada transição. O isolamento de rede limita a obtenção do package #2 e impede que os módulos finais recebam ou enviem dados ao C2. Em seguida, a equipe deve preservar eventos de criação de processo, carregamento de imagem, alocação de memória, chamadas nativas, conexões externas e arquivos recebidos. Quando houver evidência de injeção em processo recém-criado, a análise precisa incluir o processo original e o destino, pois o arquivo em disco pode ter sido apagado conforme a configuração.

A correção prática depende de impedir a execução inicial e detectar a cadeia antes do carregamento dos módulos de roubo. Controles de aplicação, reputação de arquivos, bloqueio de executáveis não autorizados em diretórios de usuário e inspeção comportamental são mais úteis do que bloqueios baseados apenas em IoC. No EDR, regras de correlação devem aproximar eventos que isoladamente podem parecer ruído: nome de arquivo com padrão de hash, seção preenchida em memória, deofuscação via TLS, chamadas de sistema indiretas, comunicação externa e mídia com conteúdo anexado. Em ambientes com proxy ou inspeção de tráfego, arquivos WAV e JPG recebidos por processos incomuns devem ser verificados quanto a dados extras além da estrutura normal.

Após a contenção, é necessário validar se houve execução dos módulos finais de stealer. A informação disponível confirma a preparação e o download dos componentes de roubo, mas não fornece uma lista de dados coletados nessa amostra. Assim, a investigação deve priorizar navegadores, carteiras, clientes de autenticação, armazenamentos locais de credenciais, sessões e tokens apenas como classes de ativos comumente visadas por ladrões de informações, sem presumir exfiltração quando a telemetria não confirmar. Se houver sinais de acesso a credenciais ou sessões, a rotação deve ser conduzida por escopo: contas usadas no host, segredos acessíveis ao usuário, tokens de desenvolvimento e credenciais presentes em navegadores ou aplicações locais.

• Isolar o endpoint com sinais de execução para impedir contato com C2 e download do pacote posterior.
• Coletar memória e eventos do processo original e do processo recém-criado antes que regiões temporárias sejam destruídas.
• Criar detecções comportamentais para .textbss preenchida em execução, módulos XS1, buffers TLS anômalos e chamadas de sistema indiretas.
• Inspecionar arquivos WAV e JPG recebidos por processos suspeitos em busca de dados anexados e discrepâncias de tamanho.
• Revisar credenciais e sessões acessíveis pelo usuário afetado somente quando a telemetria indicar avanço para módulos de roubo ou acesso a armazenamentos sensíveis.