Plataformas afetadas: Windows
Usuários afetados: Usuários do Windows
Impacto: Coleta informações confidenciais e executa módulos maliciosos adicionais
Nível de gravidade: Crítico

Um relatório de ameaças publicado por especialistas em outubro de 2021 chamou nossa atenção recentemente. Ele discute um agente de ameaças desconhecido conduzindo uma campanha de espionagem no Sudeste Asiático usando um novo arsenal de malware personalizado. O que mais despertou nossa curiosidade foi a menção de uma carga útil DLL carregada do registro que ainda não havia sido descoberta.

A razão pela qual o módulo era difícil de encontrar ficou aparente depois de analisar seu carregador. O módulo é armazenado como um blob compactado com um cabeçalho personalizado no registro. Ele nunca é gravado em disco, tornando improvável que apareça em conjuntos de dados como o VirusTotal.

E assim, embarcamos em uma jornada para caçar o módulo perdido. Descobrimos agora uma amostra do módulo e uma infinidade de componentes e variantes que datam de 2017. A engenharia reversa das amostras nos permitiu observar a progressão do desenvolvimento desse malware ao longo dos anos. Com o tempo, o código personalizado foi adicionado, os componentes foram atualizados, os recursos foram expandidos, o código ficou mais organizado e a modularidade aumentou.

Este blog examinará os diferentes componentes desse malware e sua progressão ao longo do tempo, mapeando assim a evolução da estrutura do malware Soul.

Teoria da evolução

Na fase inicial, os invasores usaram um backdoor que incorporava código das ferramentas de código aberto Gh0st RAT e NetBot Attacker, embora com modificações consideráveis. O backdoor é incorporado como um blob compactado em seu executável dropper, que o grava no disco e o executa.

Dentro de um ano, o código do backdoor foi refatorado e teve código personalizado adicionado a ele, completando sua transformação no que chamamos de módulo Soul. Seu carregador, que apelidamos de SoulSearcher, também mudou. Em vez de descartar a carga no disco, o módulo compactado é armazenado no registro e carregado na memória.

Desde o início de 2020, detectamos variantes do SoulSearcher cada vez mais complexas, algumas das quais suportam o carregamento de vários módulos do registro. Eles se transformaram significativamente ao longo do tempo e seus artefatos de configuração lançam luz sobre os possíveis recursos do módulo Soul.

Além dos backdoors, ferramentas adicionais foram usadas, como keyloggers e uma ferramenta 7zr compilada de forma personalizada (7-zip autônomo reduzido).

Uma linha do tempo completa dos vários componentes é descrita abaixo, começando em 2017 com o primeiro keylogger e backdoor e terminando com as recentes variantes do SoulSearcher encontradas em novembro de 2021.

Timeline of the Soul malware framework — Figura 1: Cronograma da estrutura de malware Soul

Nota: Esta linha do tempo é baseada em carimbos de data e hora de compilação e, embora possam ser adulterados, no caso desta estrutura de malware, consideramos que eles são autênticos. Isso ocorre em parte porque a distribuição de tempo das amostras coletadas se correlaciona com nossa compreensão das capacidades dos componentes e seus avistamentos na natureza. Além disso, amostras relacionadas, como carregadores e suas cargas úteis, foram compiladas em segundos umas das outras.

Várias características são comuns em todos os componentes que encontramos:

Ofuscação de importação do DynamiCall do código-fonte vazado do notório Hacking Team’s
Backdoor RCS
Empilhar strings
Semelhança de estrutura de dados, como a estrutura de configuração
Algoritmos de criptografia e compressão
Nomes de mutexes, eventos e mapeamentos de arquivos
Timestamps de compilação adjacentes

Funcionamento do Backdoor

Este é o backdoor usado na fase inicial pelo agente da ameaça. Ele foi compilado em outubro de 2017 e usou código revisado de repositórios públicos e outros malwares vazados online, como:

DynamiCall
Gh0st RATO
Funções de manipulação de arquivos
Código de shell CMD
Mensagens e estruturas de comunicação
HTran (uma ferramenta de segurança de conexão de código aberto)
7zip

O backdoor é uma DLL colocada no disco por um simples conta-gotas. O dropper LZMA descompacta o backdoor e uma configuração que ambos compartilham. O dropper grava o backdoor em um caminho especificado pela configuração e anexa a configuração a ele como uma sobreposição. Dependendo do argumento de linha de comando passado para o dropper, o backdoor é executado com LoadLibrary ou rundll32.exe. Finalmente, o conta-gotas se exclui do disco.

Configuração

O backdoor lê sua configuração de sua sobreposição de arquivo e a descriptografa subtraindo e fazendo XOR de cada byte com 0x13.

A configuração começa com uma sequência de bytes cujo significado é desconhecido, mas é idêntico em todas as amostras que encontramos. Outros campos são o nome do arquivo backdoor ou caminho completo, o endereço C2 e a porta em little-endian. A configuração também contém um nome de serviço e uma descrição, ambos não utilizados. Em uma amostra, a string “NetBot” é definida como o nome do arquivo.

Figure 2: Configuration for the backdoor — Figura 2: Configuração para o backdoor

Dois outros campos, uma matriz de DWORDs e um sinalizador (destacado no deslocamento 0x1f0), controlam se e quando o backdoor deve suprimir a comunicação relacionada ao comando.

Os valores do array determinam os dias e horas para aceitar comandos. Nesta amostra, todos os valores são 2. Cada índice representa um determinado dia da semana e a hora do dia. Se o valor em um determinado índice for 0, as solicitações de comandos serão retidas no dia e hora correspondentes.

O sinalizador determina se o recebimento de comandos deve ser suprimido enquanto houver atividade na máquina, de acordo com as seguintes condições:

Além da sessão atual, há uma sessão de console ativa no sistema
Além da sessão atual, há uma sessão RDP ativa ou conectada no sistema

As sessões são monitoradas usando as APIs WTSRegisterSessionNotification e WTSEnumerateSessions.

Dependendo da configuração, o backdoor pode receber comandos em modo ativo (como cliente) ou passivo (como servidor). Existem dois números de porta, um para cada modo.

Se a porta do servidor não for 0, o backdoor entrará em contato com o servidor para receber comandos.
Se a porta de escuta não for 0, o backdoor escuta nessa porta e aguarda os comandos das conexões de entrada (apenas uma conexão pode estar ativa por vez).

Comunicação

As mensagens para o servidor C2, incluindo solicitações de comandos, têm uma estrutura fixa. Cada solicitação ao servidor é composta de cabeçalhos HTTP codificados que representam o tráfego de rede legítimo para taboola[.]com.

Constant HTTP headers sent in requests to the server — Figura 3: Cabeçalhos HTTP constantes enviados em solicitações para o servidor

A estrutura do corpo HTTP enviado ao servidor é mostrada abaixo. CompressedBuffer são dados deflacionados por zlib.

Figure 4: Format of message body sent by the backdoor

O recebimento de comandos começa quando o backdoor envia informações sobre a máquina para o servidor com um MessageType de 0x11000000:

Hostname
IP address(es)
CPU architecture
RAM size

A estrutura de resposta do servidor é semelhante à da solicitação:

Figura 5: Formato do corpo da mensagem de resposta do servidor para solicitações de backdoor

Em um segmento separado, o backdoor pode sinalizar o servidor se a supressão de recebimento de comando estiver em vigor no momento com MessageType 0x1100000B.

Comandos

Quando o servidor envia um comando, ele é um dos valores de CommandType na tabela abaixo e o campo CompressedBuffer está vazio. O backdoor envia uma solicitação adicional para os parâmetros do comando, com um valor MessageType especificado de acordo com o comando específico.

O mesmo acontece quando o backdoor funciona no modo passivo, exceto que é limitado a manipulação de arquivos, CMD e comandos de fechamento de soquete.

Os carregadores do SoulSearcher

O SoulSearcher é um tipo de carregador de segundo estágio visto na natureza desde novembro de 2018. Todas as amostras que encontramos são DLLs com um fluxo de operação semelhante. Eles são responsáveis por executar a carga útil do módulo Soul e analisar sua configuração.

As principais diferenças entre as variantes do SoulSearcher são o tipo de configuração passado para a carga e o local onde a configuração e a carga são armazenadas.

Figura 7: Tabela de tipos de SoulSearcher

SoulSearcher Binário

Estas são as primeiras amostras de SoulSearcher em nossa posse. Uma dessas amostras tem sua carga útil – um módulo Soul – embutido nela. Cada amostra exporta duas funções: DumpAnalyze e DumpAnalyzeEx.

Primeiro, o SoulSearcher procura o módulo e a configuração, seja em seus dados de sobreposição ou arquivos no disco. Se forem encontrados, ele salva o módulo no registro. Independentemente disso, o SoulSearcher busca a carga útil do registro, carrega-a reflexivamente e passa a configuração para ela como um argumento.

A configuração está localizada no final da sobreposição e é descriptografada usando SUB-XOR 0x13. Ele tem o mesmo formato do backdoor original do Soul, com um campo adicional que determina o tamanho do módulo Soul compactado na sobreposição. Outra parte da configuração é recuperada do valor de registro HKCU\Software\OIfkO2i1 e descriptografada com SUB-XOR 0x79. Se não existir, esse caminho também será consultado nas seções de registro de outros usuários.

Se o argumento “-h ” foi passado para a exportação do SoulSearcher, a configuração e a carga útil são extraídas de sdc-integrity.dat em vez da sobreposição. Eles são extraídos exatamente da mesma maneira que antes. O argumento fornecido é um identificador para uma DLL usada para recuperar o caminho do diretório no qual reside o arquivo .dat.

De qualquer forma, o módulo é salvo no registro em HKCU\Software\kuhO6Ba0kT.

XML SoulSearcher

Todo XML SoulSearcher começa com a obtenção da configuração anteriormente descartada por um componente desconhecido. A maioria dos exemplos o recupera do registro e alguns têm a opção de recuperá-lo de um objeto de mapeamento de arquivo ou de um arquivo no disco.

Por exemplo, uma amostra recupera a configuração de um dos seguintes, dependendo de estar sendo executado como um serviço:

Um nome de valor no formato de um GUID nos parâmetros de serviço em HKLM\SYSTEM\CurrentControlSet\Services\\Parameters
Um objeto de mapeamento de arquivo chamado Global\CacheDataMapping

Os dados binários recuperados têm a seguinte estrutura:

Figura 8: Estrutura da configuração obtida do registro

A estrutura é processada da seguinte maneira para recuperar a configuração XML:

Verifique se o tamanho de CompressedConfig é igual a CompressedConfigSize
Verifique se CompressedConfigSize e ConfigSize não são 0
Verifique se ambas as somas de verificação MD5 não são 0
Certifique-se de que Magic contém a sequência de bytes 86 AE 00 00
Execute a validação da soma de verificação MD5 da configuração compactada
LZMA-descompacte a configuração
Execute a validação da soma de verificação MD5 da configuração descompactada

Em uma variante, uma etapa extra é executada no início para descriptografar os dados do registro usando o AES-256 CBC. A chave é recuperada de um dos dois caminhos codificados.

As amostras mais antigas desserializam a string resultante com a API CreateXmlReader, enquanto as amostras mais recentes usam a biblioteca de código aberto TinyXML. Os nomes de atributos XML esclarecem os módulos Soul carregados do registro.

Semicolon SoulSearcher

A partir de agosto de 2021, as variantes do SoulSearcher começaram a usar uma configuração separada por ponto e vírgula codificada em vez de uma XML do registro. A primeira variante desse tipo foi compilada pouco mais de um mês antes do lançamento do relatório da Symantec.

Example of a semicolon-separated configuration

Essa configuração não possui os nomes de atributos XML indicativos, como aqueles nas configurações XML, resultando em uma ferramenta mais obscura. No entanto, aqui está o que podemos dizer sobre alguns desses campos:

Acreditamos que o primeiro campo, do5Kc1diLHgq5f6, representa o tipo de configuração. Nas configurações XML, o tipo é representado pela string X6bmLMbAL29AlxB.
Um dos valores indica se o SoulSearcher foi instalado como um serviço. Nesse caso, a configuração inclui campos para detalhes sobre o serviço, como seu nome.
Alguns dos valores determinam quais módulos Soul devem ser carregados.
Um campo pode conter um caminho de registro do qual carregar um módulo Soul (enquanto outros módulos são carregados de caminhos codificados).

Quando o Soul é encontrado

Variantes mais antigas do SoulSearcher carregam um único módulo Soul, enquanto alguns XML e Semicolon SoulSearchers mais recentes podem carregar até quatro, dependendo de sua configuração.

Figura 10: Estrutura do payload obtido do registro

Cada módulo é buscado no registro de maneira semelhante à configuração:

Verifique se o tamanho de CompressedModule é igual a CompressedModuleSize
LZMA-descompacte o módulo
Execute a validação da soma de verificação MD5 do módulo descompactado
Certifique-se de que a arquitetura do módulo corresponda à arquitetura do SoulSearcher

Este procedimento é idêntico em todas as amostras do SoulSearcher, exceto nos SoulSearchers binários, cuja estrutura difere ligeiramente.

O SoulSearcher carrega reflexivamente o módulo na memória e chama sua exportação Construct. Algumas variantes anteriores também chamam exportações adicionais do módulo.

Soul Backdoor

Descobrimos que uma amostra do Binary SoulSearcher de novembro de 2018 tinha uma carga útil incorporada.

Este módulo Soul se assemelha ao backdoor original em termos de funcionalidade, embora seu código seja muito mais organizado. Um exame minucioso revelou que o código do backdoor original foi reorganizado como várias exportações. Por exemplo, o código responsável por enviar e receber mensagens HTTP foi dividido nas exportações SendMsg e RecvMsg.

Soul backdoor module exported functions — Figura 11: Funções exportadas do módulo backdoor Soul