Formatos executáveis customizados conectam Rhadamanthys à linhagem Hidden Bee

A análise mostra semelhanças estruturais entre os formatos NS, RS e HS, incluindo carregamento manual, tratamento próprio de exceções e componentes comprimidos usados para dificultar análise e detecção em memória.

Componente	Rhadamanthys nas versões 0.4.1 e anteriores, com módulos nos formatos customizados RS e HS, comparados a formatos NE e NS associados ao Hidden Bee.
Vetor	O fluxo começa em um executável PE inicial distribuído em campanhas maliciosas, normalmente protegido por empacotador ou crypter externo, que revela shellcode e estágios posteriores em formato próprio.
Impacto	Os formatos customizados dificultam varredura de memória e engenharia reversa, removem ou minimizam partes do PE e mantêm mecanismos próprios para importações, relocação e tratamento de exceções.
Prioridade	Priorizar análise de carregamento em memória, transições para regiões anônimas, alocações executáveis, manipulação de exceções e reconstrução defensiva dos módulos para entender a lógica central do stealer.
Artefatos	Magic values e estruturas citadas incluem NE, NS, RS, HS, identificador de arquitetura compatível com Machine ID, diretórios de dados minimizados e seções com RVA, tamanho, endereço bruto e características.
APIs e funções	Foram descritos usos de RtlAddFunctionTable, hook envolvendo KiUserExceptionDispatcher, redirecionamento em RtlDispatchException e instrumentação de chamada a ZwQueryInformationProcess.

Resumo técnico

Rhadamanthys apresenta uma cadeia de execução baseada em estágios que combina um executável PE inicial, camadas de empacotamento ou crypter e módulos internos em formatos executáveis customizados. A característica central não é apenas a presença de um loader manual, mas a adoção de estruturas que deixam de se parecer com um PE convencional em pontos importantes. Essa decisão técnica aumenta o custo de análise, reduz a eficácia de mecanismos simples de varredura em memória e obriga o analista a reconstruir metadados que normalmente estariam disponíveis em cabeçalhos, diretórios e tabelas padronizadas.

A comparação técnica com Hidden Bee indica continuidade de ideias e de implementação. Hidden Bee apareceu por volta de 2018, usava uma cadeia de múltiplos estágios e tinha como payload final um minerador implementado por scripts LUA. O canal de distribuição citado para essa família era o Underminer Exploit Kit. Amostras novas se tornaram raras com o tempo, com as últimas observadas em 2021, e o contexto técnico sugere como hipótese que parte do código ou da abordagem possa ter sido reaproveitada posteriormente. O ponto verificável mais relevante é a semelhança entre os formatos NE e NS do Hidden Bee e os formatos RS e HS observados em Rhadamanthys até a versão 0.4.1.

O uso de formatos próprios em malware não é uma novidade, mas o nível de personalização descrito é incomum porque vai além de um PE carregado manualmente com pequenas alterações. No formato NE, a substituição do cabeçalho DOS e a remoção do identificador PE ainda preservam grande parte da estrutura original, tornando a conversão defensiva relativamente direta quando os campos deslocados são restaurados. Já o formato NS remove o cabeçalho DOS e reduz o conjunto de informações do cabeçalho e dos diretórios de dados, aproximando-se mais de um formato executável alternativo. Essa segunda abordagem é a base mais próxima dos formatos vistos no Rhadamanthys.

Fluxo técnico

A cadeia de Rhadamanthys descrita começa em um módulo PE inicial, tratado como Stage 1. Antes de o analista chegar aos componentes próprios do malware, esse estágio pode estar encapsulado por uma camada externa de proteção. Como Rhadamanthys é vendido publicamente e usado por diferentes distribuidores, a camada de crypter ou packer pode variar entre campanhas. Depois que essa proteção externa é removida em ambiente de análise, o fluxo passa por redirecionamentos de execução para código sem nome claro, possivelmente shellcode, que realiza alocação, desempacotamento, remapeamento e transferência de controle para o próximo estágio.

O texto técnico aponta duas transições relevantes durante a execução observada: uma saída do módulo principal em um RVA específico e outra transferência em um deslocamento dentro do shellcode. O aspecto defensivo importante não é o valor isolado desses deslocamentos, que pode mudar entre amostras, mas o padrão de execução: código PE inicial transfere controle para uma região intermediária, essa região usa chamadas de alocação e manipulação de memória, descomprime um bloco interno e revela um módulo no formato RS. Para engenharia reversa e resposta a incidentes, esse padrão orienta a coleta de dumps de memória e a correlação entre regiões privadas executáveis e mudanças de permissão.

Nos formatos associados ao Hidden Bee, o NE mantém boa parte da estrutura PE, mas altera elementos suficientes para atrapalhar parsers e scanners que dependem de identificadores convencionais. O cabeçalho customizado substitui o cabeçalho DOS, enquanto os demais cabeçalhos permanecem próximos do PE, com a remoção do magic PE. Essa simplicidade relativa contrasta com o formato NS, no qual o cabeçalho DOS é removido e as informações do File Header e do Optional Header são condensadas em uma estrutura mínima. Mesmo assim, ainda há resquícios do PE, como o Machine ID, usado para distinguir módulos de 32 e 64 bits, além de diretórios de dados com pares de RVA e tamanho.

A cadeia também chama atenção pelo tratamento de exceções em módulos carregados manualmente. Em binários de 64 bits, a solução descrita usa RtlAddFunctionTable para registrar a tabela de exceções do módulo customizado, permitindo que handlers apropriados sejam encontrados quando exceções surgem dentro da região carregada. Em 32 bits, onde não há equivalente direto para essa API, a abordagem envolve hook no caminho de despacho de exceções, com alteração indireta do resultado de ZwQueryInformationProcess para habilitar comportamento compatível com imagem carregada. Essa técnica evita que exceções legítimas dentro do módulo provoquem crash imediato e também reduz sinais visíveis ao usuário ao configurar modos de erro que silenciam caixas de diálogo críticas.

Superfície afetada

A superfície de análise envolve sistemas Windows que executem o PE inicial da campanha e permitam que a cadeia alcance estágios em memória. O contexto não delimita versões específicas do Windows, tampouco lista campanhas, domínios ou hashes. Portanto, a exposição técnica deve ser tratada no nível de comportamento: processos que carregam código privado executável, executam shellcode intermediário, descomprimem módulos internos e usam formatos RS ou HS em vez de PE convencional. A superfície também inclui ferramentas de segurança que dependem de inspeção de cabeçalho PE, porque a ausência ou a minimização desses elementos pode prejudicar identificação baseada em estrutura.

No caso do Hidden Bee, a análise cobre formatos NE e NS, incluindo uma menção a carregamento de drivers em formato NS por um componente chamado kloader.bin. O contexto afirma que módulos em modo kernel não foram observados até então no Rhadamanthys, o que limita qualquer extrapolação. Ainda assim, a existência de um loader de drivers no histórico do Hidden Bee mostra que a família analisada já explorava customização de formato em diferentes níveis de privilégio. Para Rhadamanthys, a superfície confirmada no contexto permanece nos estágios de usuário e na lógica de loader associada aos formatos RS e HS.

Equipes de defesa devem considerar que a ausência de cabeçalhos PE completos não significa ausência de executável funcional. O malware pode preservar apenas o necessário para resolver arquitetura, diretórios essenciais, importações, seções e relocação, deixando de lado elementos esperados por ferramentas genéricas. Isso afeta triagem automatizada, carving de memória e enriquecimento de amostras. Quando um dump bruto não é reconhecido como PE, a análise ainda pode avançar por comparação de estruturas, identificação de diretórios minimizados, observação de chamadas de loader e reconstrução controlada do formato para fins defensivos.

• Processos com PE inicial que transfere execução para shellcode ou região anônima após camada externa de empacotamento.
• Módulos internos comprimidos que, após descompressão, revelam estruturas com magic RS, HS, NS ou NE.
• Regiões MEM_PRIVATE com comportamento de imagem, tabelas de exceção tratadas manualmente e execução fora de módulos nomeados.
• Ferramentas de análise que falham ao interpretar dumps por dependerem estritamente de magic MZ e PE.

Hunting e telemetria

A caça deve focar a transição entre um executável inicial reconhecível e módulos carregados manualmente. Em endpoint, sinais úteis incluem alocação de memória com posterior execução, mudança de permissões, transferência de controle para regiões sem imagem mapeada e presença de conteúdo comprimido que se transforma em estrutura executável própria. A observação de chamadas como VirtualAlloc é útil como parte de uma sequência, mas não deve ser tratada isoladamente como indicador de comprometimento, porque a API é comum em software legítimo. O valor defensivo surge quando a chamada aparece perto de descompressão, remapeamento e salto para offset interno.

Outra área de telemetria relevante é o tratamento de exceções. O uso de RtlAddFunctionTable por si só pode existir em aplicações legítimas, mas em conjunto com módulo privado executável, tabelas vindas de estrutura customizada e ausência de PE completo, torna-se um pivô de investigação. Em 32 bits, alterações no caminho de KiUserExceptionDispatcher, RtlDispatchException ou instrumentação de ZwQueryInformationProcess merecem análise quando associadas a código carregado manualmente. A configuração de modo de erro para suprimir falhas visíveis também pode compor uma linha temporal de furtividade operacional.

Em engenharia reversa, o hunting deve procurar marcas estruturais, não apenas assinaturas textuais. No formato NS, elementos descritos incluem Machine ID logo após o identificador, diretório de dados reduzido para seis registros e lista de seções com quatro campos principais: RVA, tamanho, endereço bruto e características. Nos formatos RS e HS, a semelhança estrutural com NS permite usar heurísticas de reconstrução para recuperar o contorno do módulo. Essa abordagem ajuda a chegar à lógica central do stealer sem depender de execução completa da cadeia em ambiente vivo.

• Transferência de execução do PE inicial para região privada ou shellcode intermediário.
• Descompressão de bloco interno seguida de remapeamento e execução de módulo em formato customizado.
• Uso de RtlAddFunctionTable associado a memória privada executável e tabela de exceções não originada de PE mapeado normalmente.
• Hook ou redirecionamento no fluxo de exceções envolvendo KiUserExceptionDispatcher, RtlDispatchException e ZwQueryInformationProcess.
• Dumps com ausência de MZ ou PE, mas com diretórios, seções e campos compatíveis com executável minimizado.

Mitigação

A resposta defensiva deve começar pela contenção do host suspeito e pela preservação de memória antes de encerrar processos, porque os estágios mais importantes podem existir apenas como regiões privadas carregadas manualmente. Como a cadeia depende de descompressão e remapeamento, dumps coletados no momento correto podem revelar os formatos RS ou HS mesmo quando o arquivo inicial em disco não contém diretamente a lógica final. A análise deve separar a camada externa de crypter do comportamento próprio de Rhadamanthys, já que diferentes distribuidores podem usar proteções externas distintas sem alterar necessariamente a estrutura interna do malware.

Na engenharia reversa, a mitigação operacional passa por reconstrução controlada e não por execução ampla. Quando um módulo customizado é identificado, a prioridade é recuperar cabeçalhos, diretórios, importações, relocação e tratamento de exceções o suficiente para permitir análise estática e extração de comportamento. A reconstrução de PE para fins defensivos reduz dependência de depuração prolongada e facilita comparação entre amostras. Para ambientes de produção, os resultados dessa análise devem alimentar detecções comportamentais, regras internas de triagem de memória e alertas sobre padrões de loader, em vez de depender apenas de hashes de amostras.

Controles preventivos devem reduzir a chance de execução do estágio inicial e aumentar a visibilidade sobre carregamento anômalo. Isso inclui bloqueio de executáveis não confiáveis, inspeção de cadeias com múltiplos estágios, endurecimento de políticas de execução, registro detalhado de eventos de processo e memória, e correlação entre telemetria de endpoint e sandbox. Como o contexto não fornece domínios, endereços IP, hashes ou nomes de campanhas específicas, a mitigação não deve ser baseada em IoCs ausentes. A ação mais concreta é transformar os detalhes estruturais descritos em detecções de comportamento e em procedimentos de análise de memória.

Também é importante registrar o limite de atribuição: a semelhança entre Hidden Bee e Rhadamanthys sustenta uma hipótese técnica de continuidade ou reaproveitamento, mas não substitui evidência operacional de autoria. A defesa deve usar essa relação para guiar pesquisa, comparação de amostras e criação de parsers internos, sem presumir automaticamente o mesmo operador, a mesma infraestrutura ou o mesmo objetivo final em todas as campanhas. Para o SOC, o valor prático está em reconhecer rapidamente uma família de técnicas de loader customizado e preservar artefatos antes que a cadeia seja perdida por término de processo ou limpeza automática.

• Isolar sistemas suspeitos e coletar memória antes de finalizar processos relacionados ao PE inicial.
• Priorizar análise de regiões privadas executáveis e dumps que não sejam reconhecidos como PE convencional.
• Criar detecções para carregamento manual, descompressão de estágios, remapeamento e transferência de controle para regiões anônimas.
• Correlacionar manipulação de exceções com módulos sem imagem mapeada normalmente.
• Evitar conclusões baseadas em IoCs não fornecidos; focar comportamento, estrutura de formato e cadeia de execução observável.