Rhadamanthys 0.9.x altera formatos `XS`, configuração e controle de execução

A linhagem de stealer passou a usar novos formatos internos XS1_B e XS2_B, configuração comprimida com marcador 0xBEEF, mutex derivado de seed e múltiplos endereços de comando e controle por amostra.

Componente	Rhadamanthys 0.9.x, com análise centrada na cadeia iniciada pelo carregador nativo para Windows e nos módulos proprietários XS.
Vetor	Execução de um carregador inicial distribuído em variantes .NET ou nativas de 32 e 64 bits, seguido por shellcode em memória e carregamento de módulos de segundo estágio.
Impacto	Roubo de dados por stealer modular, com mudanças que dificultam análise estática, reconstrução de módulos, parsers anteriores, detecção por artefatos antigos e vacinas baseadas em mutex previsível.
Prioridade	Atualizar parsers, regras de hunting e procedimentos de resposta para reconhecer XS1_B, XS2_B, marcador 0xBEEF, configuração comprimida, mutex derivado de seed e múltiplos C2 por amostra.
Versões	A série 0.9 foi anunciada em fevereiro de 2025, seguida por 0.9.1 e 0.9.2; a versão 0.9.2 já circula mesmo sem constar na listagem pública do operador.
Artefatos	Formatos XS1_B e XS2_B, magic 0xBEEF, magic de mutex XRHY, função MessageBoxW, charset Base64 customizado 4NOPQRSTUVWXY567DdeEqrstuvwxyz-ABC1fghop23Fijkbc|lmnGHIJKLMZ089a, flags 0x40 e 0x20 relacionadas à propagação de handle de mutex.

Resumo técnico

Rhadamanthys 0.9.x representa uma atualização material de uma família de malware modular vendida no mercado clandestino desde 2022. A arquitetura geral permanece baseada em um carregador inicial, execução em memória e módulos internos em formatos proprietários, mas a série 0.9 altera pontos que costumavam sustentar análise, conversão e detecção. A amostra analisada na série 0.9.2 mantém o primeiro estágio como executável Windows convencional, em variante .NET ou nativa de 32 ou 64 bits, e usa esse componente para preparar a execução de shellcode e carregar um segundo estágio composto por módulos empacotados em formatos próprios. A mudança não é apenas cosmética: ela afeta a forma como importações são resolvidas, como a configuração é identificada e descomprimida, como execuções duplicadas são bloqueadas e como processos injetados podem ser correlacionados por handle de mutex.

O aspecto mais importante para defesa é que Rhadamanthys 0.9.x quebra pressupostos de ferramentas e regras criadas para versões anteriores. Os formatos internos XS1 e XS2 foram modificados para XS1_B e XS2_B; a configuração deixa de usar o marcador histórico 0x59485221 associado a !RHY e passa a usar 0xBEEF; o conteúdo da configuração aparece em forma comprimida antes da expansão por LZO; e a amostra passa a aceitar múltiplas opções de comando e controle. Ao mesmo tempo, o mecanismo antigo de registro em chaves SibCode, usado para registrar horário da última execução e impor atraso de reexecução, foi removido do stub de construção na série 0.9.1. Isso reduz a utilidade de um indicador simples que era visível no registro do Windows em versões anteriores e força hunting mais orientado a comportamento, memória, empacotamento e relações entre processos.

Fluxo técnico

A cadeia observada começa no carregador inicial. Embora esse primeiro componente possa variar entre .NET e executáveis nativos, os estágios posteriores convergem. Na variante nativa, o executável inicial dispara shellcode em memória, e esse shellcode carrega o conjunto de módulos de segundo estágio. Os módulos principais não são arquivos PE padrão; eles usam formatos personalizados que preservam informações essenciais de executáveis, como relocations, tabelas de importação e seções com permissões, mas armazenam esses dados em cabeçalhos reinventados. Como o sistema operacional não carrega esses formatos diretamente, Rhadamanthys inclui loaders proprietários. A consequência defensiva é dupla: ferramentas comuns de análise PE não interpretam o conteúdo de forma nativa, e dumps de memória exigem reconstrução específica para recuperar estrutura, importações e limites de seção com precisão.

Na série 0.9.x, o subtipo de primeiro nível XS1 foi atualizado para uma variante identificada aqui como XS1_B. O cabeçalho estendido continua tendo campo de versão, agora observado como versão 4, mas um campo WORD que existia antes do tamanho do cabeçalho foi removido. Esse campo estava relacionado à chave usada na desofuscação de nomes de DLLs na tabela de importação customizada. A família ainda usa uma chave de desofuscação de importação, mas a lógica foi redesenhada: a nova chave imp_key tem apenas um byte e participa do cálculo de checksums que são mapeados para nomes de funções. A mudança invalida conversores e desofuscadores que dependiam da estrutura anterior e exige que ferramentas internas passem a tratar a resolução de importações por checksum com o novo layout.

O subtipo XS2_B sofreu uma alteração menor, mas igualmente relevante para parsers. Um campo da estrutura de importação customizada foi expandido de WORD para DWORD e carrega o nome da DLL. Em versões anteriores esse valor podia aparecer ofuscado; na variante nova ele passa a ser usado como está. Embora a mudança não adicione uma capacidade ofensiva evidente, ela modifica o contrato binário que ferramentas de análise esperavam. Esse tipo de churn incremental não precisa mudar a funcionalidade final do stealer para ser eficaz: basta tornar mais lenta a conversão para PE, quebrar assinaturas estruturais antigas e aumentar o custo de engenharia reversa em pipelines de triagem automatizada.

Outro elemento visível após desempacotar a amostra 0.9.2 é uma caixa de mensagem exibida no início da execução do núcleo desembrulhado, com o texto Do you want to run a malware? (Crypt build to disable this message). O comportamento é acionado quando a amostra detecta que está sendo executada em forma crua, não protegida pela camada de empacotamento esperada. Em Rhadamanthys, a exibição usa MessageBoxW, sem o uso de syscalls diretas para essa rotina. A finalidade operacional é desencorajar distribuidores de espalhar o executável sem proteção, reduzir infecções acidentais do próprio cliente criminoso e tornar mais evidente quando analistas chegaram ao núcleo executável. Para defesa, esse artefato pode ajudar na confirmação manual de amostras desembrulhadas, mas não deve ser tratado como requisito de detecção em endpoints de produção, porque ele aparece em uma condição específica de execução.

Superfície afetada

A superfície primária são estáções Windows nas quais o carregador inicial consiga executar código e preparar o segundo estágio em memória. O texto analisado não traz um vetor inicial de entrega, campanha específica, anexo, domínio, hash ou explorador associado; portanto, a exposição deve ser tratada no nível da execução pós-entrega. Ambientes com telemetria fraca de processo, memória e injeção tendem a perder a parte mais importante da cadeia, porque os módulos centrais não se apresentam como PE convencionais gravados em disco. A família também oferece múltiplas formas de empacotamento inicial, o que significa que controles focados exclusivamente em uma variante .NET ou em uma arquitetura nativa específica não cobrem todo o conjunto de amostras.

Na configuração, Rhadamanthys 0.9.2 troca o marcador antigo por 0xBEEF e armazena conteúdo ainda comprimido, que precisa ser expandido por LZO antes de expor os campos efetivos. Esses campos incluem endereço de C2, chaves de criptografia usadas no fluxo e flags que ativam ou desativam recursos. A mudança para múltiplas opções de C2 por amostra aumenta a resiliência operacional do malware, porque uma única ação de bloqueio de infraestrutura pode não encerrar a comunicação se a amostra tiver alternativas configuradas. A configuração continua embutida como string Base64 com alfabeto customizado, usando o charset 4NOPQRSTUVWXY567DdeEqrstuvwxyz-ABC1fghop23Fijkbc|lmnGHIJKLMZ089a, o que permite hunting em amostras e memória quando esse padrão aparece junto de outros sinais da família.

• Carregadores iniciais em .NET e executáveis nativos Windows de 32 e 64 bits devem ser considerados no escopo de análise.
• Módulos internos XS1_B e XS2_B exigem parsers atualizados; ferramentas dependentes de layouts XS1_A ou XS2 antigos podem falhar silenciosamente.
• A ausência de novas gravações em chaves SibCode na série 0.9.x reduz a cobertura de regras baseadas somente nesse artefato histórico.
• A configuração com 0xBEEF, compressão LZO e múltiplos C2 por amostra amplia a necessidade de extração confiável de configuração em laboratório.

Hunting e telemetria

O hunting deve começar pela correlação entre carregador, execução em memória e módulos não convencionais. Em endpoint, eventos de criação de processo isolados podem não revelar a cadeia completa; é necessário coletar telemetria de alocação de memória executável, criação de threads remotas, carregamento manual de módulos, duplicação de handles e processos que compartilham um mesmo objeto de mutex. A série 0.9 usa uma seed de 16 bytes na configuração para participar da geração do nome do mutex, combinada com o magic XRHY e hash posterior. Isso elimina a previsibilidade suficiente para a vacina universal usada contra versões anteriores, mas cria uma oportunidade de investigação: quando a duplicação do handle estiver habilitada, processos injetados podem carregar o mesmo handle de mutex e formar uma árvore de execução associada a uma amostra específica.

A análise estática e a análise de memória devem buscar a configuração em Base64 customizado, o marcador 0xBEEF após decodificação e a etapa de descompressão LZO. A presença isolada desses elementos não substitui validação, mas a combinação com módulos em formato XS, resolução de importações por checksum e cadeia de shellcode aumenta a confiança. Para laboratórios de malware, é importante atualizar ferramentas que convertiam módulos XS para PE e desofuscavam strings, porque a versão 0.9.x altera exatamente os pontos em que esses utilitários se apoiavam. Se um pipeline classifica amostras apenas quando a conversão para PE é bem-sucedida, a falha do parser deve virar evento de análise, não descarte automático.

Em hosts já investigados por possível infecção antiga, a presença de chaves SibCode ainda pode indicar versões anteriores, mas sua ausência não deve ser usada para excluir Rhadamanthys 0.9.x. O mesmo vale para mutex previsível: regras que esperam o padrão antigo tendem a perder amostras novas porque o nome agora depende de seed por configuração. Em rede, a atualização para múltiplos C2 por configuração exige extração de todos os endpoints configurados antes de bloqueio e retrocaça; registrar apenas o primeiro endereço encontrado pode deixar rotas de fallback ativas. Como o contexto não fornece domínios, IPs ou hashes, a resposta defensiva deve priorizar metodologia de extração e correlação, não lista fixa de IoCs.

• Amostras que, após desempacotamento, exibem Do you want to run a malware? (Crypt build to disable this message) via MessageBoxW em condição de execução crua.
• Módulos em memória ou em pacote interno com formatos XS1_B e XS2_B, incluindo alteração de campo de importação de WORD para DWORD no segundo subtipo.
• Configuração decodificável por Base64 customizado com charset 4NOPQRSTUVWXY567DdeEqrstuvwxyz-ABC1fghop23Fijkbc|lmnGHIJKLMZ089a, marcador 0xBEEF e conteúdo comprimido por LZO.
• Processos relacionados por handle de mutex quando a configuração não desabilita a duplicação por meio das flags 0x40 ou 0x20.
• Falhas novas em conversores, desofuscadores e parsers antes funcionais para Rhadamanthys 0.5 a 0.7, especialmente na etapa de importação customizada.

Mitigação

A mitigação deve tratar Rhadamanthys 0.9.x como uma atualização de família, não como uma família nova. O primeiro passo é revisar controles que dependem de artefatos removidos ou alterados, como chaves de registro SibCode, formato antigo de importação XS1_A e mutex derivado de valores hardcoded. Em seguida, pipelines de laboratório precisam ser ajustados para processar XS1_B e XS2_B, identificar a chave imp_key de um byte, resolver importações por checksum no novo esquema, decodificar a configuração com charset customizado, reconhecer 0xBEEF e executar a descompressão LZO antes de extrair C2, chaves e flags. Sem essa atualização, a organização pode continuar recebendo amostras mas perder os dados necessários para bloqueio, retrocaça e escopo de incidente.

Na contenção de um host suspeito, a ordem defensiva deve preservar evidências de memória antes de limpeza, porque os módulos principais podem não existir como PE comum no disco. Coletar dump de processo, lista de handles, árvore de processos, conexões de rede, artefatos de injeção e amostras do carregador inicial permite reconstruir a execução. Depois da coleta, o host deve ser isolado, credenciais usadas no endpoint devem ser tratadas como potencialmente expostas e sessões de navegador, carteiras, tokens locais e segredos de aplicações devem ser revistos conforme o perfil de uso da máquina. O contexto não lista famílias de dados específicas roubadas nessa versão, mas Rhadamanthys é um stealer; portanto, a resposta deve assumir risco de credenciais e segredos acessíveis ao usuário comprometido.

Em controles preventivos, reduza a janela de execução com bloqueio de binários não confiáveis, inspeção de anexos e downloads, EDR com visibilidade de injeção, política de execução restritiva e detecção de carregamento manual. Em controles de rede, a extração completa da configuração deve alimentar bloqueios de todos os C2 presentes, não apenas do primeiro. Em inteligência interna, mantenha versionamento das regras por família e por geração de formato, porque a série 0.9 mostra que os operadores alteram estruturas suficientes para quebrar automação sem alterar todos os comportamentos de alto nível. A validação final deve incluir amostras antigas e novas para confirmar que a cobertura não regrediu em versões anteriores enquanto passa a reconhecer as mudanças atuais.

• Atualizar ferramentas internas para interpretar XS1_B, XS2_B, 0xBEEF, Base64 customizado e descompressão LZO.
• Revisar regras que dependem de SibCode ou de mutex previsível e substituí-las por correlação de execução, memória, configuração e handles.
• Durante resposta a incidente, coletar memória, handles, árvore de processos, conexões e carregador inicial antes de remover artefatos do endpoint.
• Extrair todos os C2 presentes na configuração e aplicar bloqueio, retrocaça e busca em logs para cada endpoint identificado.
• Rotacionar credenciais, tokens e segredos acessíveis ao usuário comprometido quando houver confirmação de execução do stealer.