Grupo APT FamousSparrow retoma ataques com novas versões do SparrowDoor

Em julho de 2024, a equipe de pesquisa da ESET detectou atividade suspeita no sistema de um grupo comercial dos Estados Unidos que atua no setor financeiro. Enquanto estávamos ajudando a instituição afetada a remediar o incidente, fizemos uma descoberta inesperada na rede da vítima: ferramentas maliciosas pertencentes ao FamousSparrow, um grupo APT alinhado com a China.

Nenhuma atividade do FamousSparrow havia sido documentada publicamente desde 2022, levando à crença de que o grupo estava inativo. No entanto, descobrimos que não apenas continuava ativo durante esse período, como também vinha trabalhando para aprimorar seu conjunto de ferramentas. A rede comprometida revelou não uma, mas duas versões inéditas do SparrowDoor, o backdoor característico do FamousSparrow.

Ambas as versões do SparrowDoor representam um avanço significativo em relação às anteriores, especialmente em termos de qualidade do código e arquitetura. Uma delas se assemelha ao backdoor que a equipe de pesquisa da Trend Micro chamou de CrowDoor, atribuído ao grupo APT Earth Estries em novembro de 2024. A outra é modular e consideravelmente diferente de todas as versões anteriores. Além disso, essa campanha marca a primeira vez que o FamousSparrow foi documentado utilizando o ShadowPad, um backdoor comercial conhecido por ser fornecido exclusivamente a cibercriminosos alinhados com a China.

Também descobrimos que, como parte dessa campanha, o invasor conseguiu acessar um instituto de pesquisa no México apenas alguns dias antes do ataque nos Estados Unidos.

Ao monitorarmos as atividades do grupo com base nessas descobertas, identificamos ataques adicionais realizados entre 2022 e 2024, que ainda estão sob investigação. Entre os alvos, encontramos uma instituição governamental em Honduras.

Este post disponibiliza uma visão geral das ferramentas utilizadas na campanha de julho de 2024, com foco nas versões inéditas do backdoor SparrowDoor descobertas na vítima nos Estados Unidos.

Pontos principais deste post:

• A equipe de pesquisa da ESET descobriu que o FamousSparrow comprometeu um grupo comercial do setor financeiro nos Estados Unidos e um instituto de pesquisa no México.
• O FamousSparrow implantou duas versões previamente não documentadas do backdoor SparrowDoor, sendo uma delas modular.
• Ambas as versões representam um progresso considerável em relação às anteriores e implementam a paralelização de comandos.
• O grupo APT foi observado utilizando, pela primeira vez, o backdoor ShadowPad.
• Discutimos as alegações de atribuição da Microsoft Threat Intelligence que associam o FamousSparrow ao Salt Typhoon.

O FamousSparrow é um grupo de ciberespionagem com vínculos com a China, ativo desde pelo menos 2019. O grupo foi inicialmente documentado publicamente em um post de 2021, quando observamos que estava explorando a vulnerabilidade ProxyLogon. Originalmente, o grupo era conhecido por atacar hotéis ao redor do mundo, mas também atacou governos, organizações internacionais, empresas de engenharia e escritórios de advocacia. O FamousSparrow é o único conhecido usuário do backdoor SparrowDoor.

Embora o FamousSparrow parecesse inativo no momento da nossa descoberta, atribuímos essa atividade ao grupo com um alto grau de confiança. Os payloads implantados são novas versões do SparrowDoor, um backdoor que parece ser exclusivo desse grupo. Apesar das melhorias significativas em qualidade de código e arquitetura nessas novas versões, elas ainda podem ser rastreadas diretamente para versões anteriores, documentadas publicamente.

Os loaders usados nesses ataques também apresentam sobreposições substanciais de código com amostras anteriormente atribuídas ao FamousSparrow. Em particular, utilizam o mesmo reflective loader shellcode que a amostra do loader libhost.dll descrita em um relatório de fevereiro de 2022, publicado pelo Centro Nacional de Cibersegurança do Reino Unido (NCSC). A configuração também compartilha o mesmo formato específico, com exceção da chave de criptografia, que agora está hardcodeada no loader e no backdoor. A criptografia XOR foi substituída por RC4.

Além disso, as comunicações com o servidor de C&C utilizam um formato muito semelhante ao utilizado nas versões anteriores do SparrowDoor.

Em 2021, a equipe de pesquisa da Kaspersky escreveu sobre um grupo cibercriminoso rastreado como GhostEmperor. Apesar de algumas semelhanças de infraestrutura com o FamousSparrow, os rastreamos como grupos separados. Em agosto de 2023, a Trend Micro observou que algumas TTPs do FamousSparrow se sobrepõem com as do Earth Estries. Também observamos sobreposições de código entre o SparrowDoor e o HemiGate desse grupo. Acreditamos que os dois grupos se sobrepõem parcialmente, mas não temos dados suficientes para avaliar plenamente a natureza e o alcance da conexão entre eles.

FamousSparrow e Salt Typhoon

Antes de mergulharmos na análise do conjunto de ferramentas do FamousSparrow, gostaríamos de discutir nossa posição sobre os vínculos entre o FamousSparrow e o Salt Typhoon, conforme relatado pela Microsoft Threat Intelligence.

Em setembro de 2024, o Wall Street Journal publicou um artigo (com paywall) informando que os provedores de serviços de internet nos Estados Unidos haviam sido comprometidos por um grupo cibercriminoso chamado Salt Typhoon. O artigo ecoou as alegações da Microsoft de que esse grupo seria o mesmo que o FamousSparrow e o GhostEmperor. Este é o primeiro relatório público que confunde esses dois últimos grupos. No entanto, como já mencionamos, consideramos que GhostEmperor e FamousSparrow são grupos diferentes. Há poucas semelhanças entre eles, mas muitas discrepâncias. Ambos usaram o endereço 27.102.113[.]240 como servidor de downloads em 2021. Ambos os grupos também foram os primeiros a explorar a vulnerabilidade ProxyLogon (CVE-2021-26855) e usaram algumas das mesmas ferramentas públicas. No entanto, além dessas ferramentas públicas, cada grupo tem seu próprio conjunto de ferramentas personalizadas.

Desde essa publicação inicial, a equipe de pesquisa da Trend Micro adicionou o Earth Estries à lista de grupos vinculados ao Salt Typhoon. Até o momento da produção deste post, a Microsoft, que criou o cluster Salt Typhoon, ainda não publicou indicadores técnicos nem detalhes sobre as TTPs utilizadas pelo grupo, nem forneceu uma explicação para essa atribuição. Para evitar confundir ainda mais as informações, continuaremos rastreando o cluster de atividade que vemos diretamente vinculado ao SparrowDoor como FamousSparrow até que tenhamos as informações necessárias para avaliar de forma confiável essas alegações de atribuição.

Com base em nossos dados e na análise dos relatórios públicos disponíveis, o FamousSparrow parece atuar de forma independente, com vínculos pouco claros com os outros grupos mencionados neste post. Acreditamos que esses vínculos podem ser melhor explicados pela possível existência de um terceiro elemento em comum, como um "intendente digital", responsável por unificar essas atividades aparentemente divergentes sob um mesmo grupo.

Análise técnica

Para obter acesso inicial à rede afetada, o FamousSparrow implantou um webshell em um servidor IIS. Embora não tenha sido possível determinar o exploit exato usado para implantar os webshells, ambas as vítimas executavam versões desatualizadas do Windows Server e do Microsoft Exchange, para as quais existem vários exploits disponíveis publicamente.

Quanto ao conjunto de ferramentas utilizadas na campanha, o grupo empregou uma combinação de ferramentas e malware personalizados, junto com ferramentas compartilhadas por outros grupos APT alinhados com a China, além de fontes públicas. Os payloads finais implantados foram SparrowDoor e ShadowPad. A Imagem 1 oferece uma visão geral da cadeia de comprometimento utilizada nesses ataques.

O grupo inicialmente baixou um script em lotes via HTTP de um servidor de downloads, 43.254.216[.]195. Este script contém um webshell .NET codificado em base64 que escreve em C:\users\public\s.txt. Em seguida, o script o decodifica usando certutil.exe e salva a saída decodificada em C:\users\public\s.ashx. Um módulo ASHX é um tipo de manipulador HTTP para ASP.NET. Embora seja semelhante aos módulos ASPX, os módulos ASHX não incluem nenhum componente de interface de usuário. O script então percorre as unidades C: a I: e P: para encontrar o diretório de instalação do DotNetNuke; em seguida, copia o webshell ASHX para <Directory_DotNetNuke>\DesktopModules\DotNetNuke.ashx.

O webshell em si é bastante genérico e não usa nada específico para DotNetNuke. Todos os dados que recebe e envia estão criptografados em AES com a chave e2c99096bcecd1b5. Na primeira solicitação, espera um arquivo .NET PE. Este arquivo executável é carregado na memória e salvo em uma variável de sessão. Nas solicitações seguintes, cria-se uma instância da classe LY contida naquele assembly .NET e os dados recebidos são passados para o seu método Equals. Embora nenhum payload tenha sido coletado enviado para esse webshell, é evidente que o método Equals não segue o contrato típico.

Nos casos observados, esse método foi utilizado para gerar uma sessão PowerShell remota interativa. Uma vez estabelecida a sessão, os atacantes usaram ferramentas legítimas do Windows para obter informações sobre o host e os domínios de Active Directory aos quais estava vinculado. Em seguida, baixaram o PowerHub, um framework de exploração posterior de código aberto, de um servidor controlado pelo atacante e utilizaram a técnica de escalonamento de privilégios BadPotato para obter privilégios de SYSTEM. Esse exploit não está presente no framework, mas parece que o grupo adicionou o módulo de código aberto Invoke-BadPotato ao seu deployment do PowerHub. Por fim, o atacante usou o módulo Invoke-WebRequest integrado ao PowerShell para baixar três arquivos do mesmo servidor que compõem o loader tridente de SparrowDoor.

Em um processo muito similar ao descrito em 2022 pelo NCSC do Reino Unido, os arquivos mencionados utilizam um esquema de carregamento tridente para executar SparrowDoor. Neste caso, o executável usado para o carregamento lateral de DLL é uma versão legítima do K7AntiVirus Messenger Scanner denominada K7AVMScn.exe, enquanto os arquivos maliciosos DLL e de payload cifrado são chamados K7AVWScn.dll e K7AVWScn.doc, respectivamente. O arquivo de payload é criptografado usando uma chave RC4 que está codificada tanto no loader quanto no payload descifrado resultante, mas varia de acordo com as amostras.

O payload descifrado consiste em uma configuração personalizada e um shellcode de loader reflexivo quase idêntico ao descrito pelo NCSC do Reino Unido, com a única diferença de que o primeiro campo, que continha a chave XOR de quatro bytes, foi removido. Os últimos 202 bytes do arquivo são criptografados separadamente, mas utilizando a mesma chave RC4, e contêm a configuração do servidor de C&C.

SparrowDoor

Como mencionado, observamos duas novas versões do SparrowDoor utilizadas nesses ataques. A primeira é muito similar ao que a equipe de pesquisa da Trend Micro denominou de CrowDoor, em um artigo publicado em novembro de 2024 sobre o Earth Estries. Esse malware foi documentado pela primeira vez pela equipe de pesquisa da ITOCHU e Macnica em uma apresentação no VirusBulletin em 2023. Do nosso ponto de vista, trata-se de uma parte do esforço contínuo de desenvolvimento do SparrowDoor e não de uma família diferente. Podemos acompanhar a evolução desde a primeira versão que descrevemos em 2021, passando pelas versões chamadas CrowDoor, até a versão modular que analisamos na última parte deste post.

Ambas as versões do SparrowDoor utilizadas nesta campanha representam avanços consideráveis na qualidade do código e na arquitetura em comparação com as versões anteriores. A mudança mais significativa é a paralelização de comandos que consomem muito tempo, como a E/S de arquivos e o shell interativo. Isso permite que o backdoor continue gerenciando novos comandos enquanto essas tarefas estão sendo realizadas. Explicaremos o procedimento mais adiante neste post, quando falarmos sobre os comandos de forma detalhada.

Como nas versões anteriores, o comportamento do backdoor varia dependendo do argumento da linha de comando que é passado. Esses argumentos estão listados na Tabela 1.

Tabela 1. Argumentos da linha de comando para o SparrowDoor.

Quando executado sem argumentos, o malware estabelece a persistência. Primeiro, tenta fazer isso criando um serviço chamado K7Soft, que está configurado para ser executado automaticamente na inicialização. Se isso falhar, ele utiliza uma chave Run do registro com o mesmo nome. Em ambos os casos, o mecanismo de persistência é configurado para executar o backdoor com um argumento de linha de comando 11. Ele também é imediatamente executado com esse mesmo argumento usando a API StartServiceA ou ShellExecuteA.

Quando executado com o argumento 11, o backdoor lança a ferramenta de gerenciamento de cores do Windows (colorcpl.exe) com um argumento de linha de comando 22 e injeta seu loader no processo recém-criado.

Somente quando o argumento da linha de comando é definido como 22, o backdoor executa realmente seu payload principal.

Após o SparrowDoor ser executado nesse modo de backdoor, ele termina, de forma indireta, qualquer outra instância que já esteja em execução. O backdoor usa a API K32EnumProcesses para percorrer os IDs de processo (PID) de todos os processos em execução e tenta criar um mutex chamado Global\ID(<PID>). Os PIDs de 15 ou menos são omitidos, provavelmente como uma forma de evitar matar alguns processos essenciais do sistema. Se o mutex já existir, o processo é finalizado. Se não, o mutex é fechado imediatamente. Quando o SparrowDoor termina de percorrer os PIDs, ele cria um novo mutex usando o mesmo formato de nome e seu próprio PID.

A seguir, o backdoor lê os últimos 202 bytes do arquivo de carga criptografado e os decifra usando a mesma chave RC4 usada pelo loader. O texto plano resultante é a configuração do servidor de C&C, que consiste em três pares de endereços e portas, seguidos de quatro valores numéricos que representam, respectivamente, o número de dias, horas, minutos e segundos que o backdoor deve aguardar após testar todos os servidores de C&C configurados. Isso está relacionado com a funcionalidade que descreveremos mais adiante, ao falarmos sobre o comando que o backdoor usa para alterar a configuração do C&C.

Após carregar essa configuração, o backdoor tenta se conectar ao primeiro servidor. Se não conseguir se conectar ou se o servidor C&C emitir um comando que faça com que a execução saia do loop de comandos principal, o SparrowDoor tentará se conectar ao próximo servidor, e assim por diante. Após testar o último servidor na configuração, o backdoor ficará em espera pelo tempo definido (seis minutos na amostra que analisamos), recarregará a configuração e repetirá o processo. Observe que, durante esse tempo, o SparrowDoor não responde aos comandos. No entanto, os comandos paralelizados que já estavam sendo executados continuarão até serem concluídos, encontrarem um erro ou forem finalizados pelo servidor.

O backdoor usa duas classes para gerenciar suas conexões: a classe abstrata CBaseSocket e sua classe filha CTcpSocket. Estas são essencialmente envoltórios ao redor dos sockets TCP Winsock. Enquanto os nomes das classes são genéricos e seguem a mesma convenção de nomenclatura usada na Microsoft Foundation Class Library (MFC), o código que elas contêm parece ser personalizado.

O SparrowDoor usa um valor inteiro como identificador da vítima ou da sessão. Esse valor é enviado ao servidor C&C quando solicita informações sobre o host e sempre que um novo socket é criado. O valor é lido da chave de registro HKLM\Software\CLASSES\CLSID\ID, voltando à mesma rota na colmeia HKCU caso haja algum problema. Se não estiver presente, o identificador é obtido do contador de desempenho da máquina e escrito na chave de registro mencionada. Embora o valor em si seja benigno, o uso dessa chave de registro não padrão representa uma oportunidade de detecção. De fato, o nome de qualquer chave de registro sob *Software\Classes\CLSID* deve ser um CLSID válido, representado por um GUID cercado por chaves. Embora isso não seja necessariamente um indicador malicioso, a presença de chaves com nomes não padrão sob CLSID é incomum.

Comandos

A primeira versão do SparrowDoor utilizada nesta campanha suporta mais comandos, descritos em..., do que as versões previamente documentadas. Embora os IDs dos comandos sejam diferentes dos utilizados na versão analisada pela Trend Micro, a ordem e o deslocamento entre os IDs são os mesmos. Não tivemos acesso a essa amostra, portanto, não podemos afirmar se os comandos adicionais estavam ausentes ou simplesmente não estavam documentados publicamente pelos criadores da ameaça.

Como mencionado anteriormente, alguns dos comandos foram paralelizados. Quando o backdoor recebe um desses comandos, ele cria um thread que inicia uma nova conexão com o servidor de C&C. O identificador único da vítima é enviado através da rede. Esse identificador único da vítima é transmitido pela nova conexão junto com um identificador de comando que indica o comando que originou essa nova conexão. Isso permite que o servidor de C&C acompanhe quais conexões estão relacionadas à mesma vítima e quais são seus objetivos. Cada um desses threads pode então gerenciar um conjunto específico de subcomandos. Para limitar sua complexidade, não incluímos esses subcomandos aqui; os revisaremos separadamente.

Tabela 2. Principais comandos implementados pelo SparrowDoor.

Toda a comunicação entre o malware e seu servidor de C&C utiliza o mesmo formato de pacote base, definido na Figura 2. O formato da seção de dados depende do comando enviado, podendo estar vazio. Na maioria dos casos, as respostas utilizam o ID do comando ao qual o backdoor está respondendo. No entanto, existem algumas exceções; as descreveremos quando discutirmos em detalhes os comandos relevantes.

Shell Interativo

Ao receber o comando de shell interativo, o SparrowDoor cria um novo thread e socket, como descrito anteriormente, e realiza todas as ações subsequentes dentro desse thread utilizando o novo socket. Em primeiro lugar, o backdoor envia uma mensagem de confirmação com o ID de comando 0x32341125 e o ID único da vítima no campo de dados. Em seguida, ele gera um processo cmd.exe e utiliza um par de threads e pipes nomeados para retransmitir os comandos e sua saída entre o servidor C&C e o shell.

\.\pipe\id2<endereço> é utilizado para passar os comandos recebidos do servidor C&C para o shell.

\.\pipe\id1<endereço> é utilizado para a saída resultante em STDOUT e STDERR.

Em ambos os casos, <endereço> é o endereço de memória, em formato decimal, da instância CTcpSocket. Esses comandos utilizam o ID 0x32341126 e os dados são, respectivamente, a linha de comando a ser executada e a saída bruta.

Se o backdoor receber uma mensagem com o ID do comando configurado para qualquer outro valor, a sessão de shell interativo é finalizada.

Mudança de configuração do C&C

A configuração do servidor C&C é armazenada no arquivo de payload criptografado. Se o backdoor receber o comando para alterar essa configuração (0x3234112A), a estrutura recebida é criptografada com RC4, e depois os últimos 202 bytes do arquivo criptografado são sobrescritos com o resultado. Curiosamente, a configuração não é recarregada automaticamente. Como mencionado anteriormente, a configuração só é recarregada quando os três servidores configurados são testados.

Para forçar o recarregamento da configuração, o servidor pode emitir o comando 0x32341127 ou um comando inválido. Ambos os comandos farão com que o SparrowDoor saia do loop de comandos e passe para o próximo servidor. A configuração também será recarregada se o backdoor for reiniciado, por exemplo, utilizando o comando 0x3234112B.

Operações com arquivos

Assim como outros comandos processados em paralelo, aqui tudo é realizado em uma nova thread usando um novo socket. O SparrowDoor envia uma mensagem de confirmação com o mesmo ID do comando original. O corpo dessa mensagem contém o ID único da vítima e o ID de operação enviado pelo servidor C&C. Este ID de operação não parece ter nenhum significado, e provavelmente é utilizado pelo servidor apenas para vincular a conexão ao comando de operação de arquivo, caso vários comandos desse tipo sejam executados em paralelo. Os IDs de comando 0x3234112E e 0x3234112F são usados, respectivamente, para leituras e gravações de arquivos.

Para a leitura de um arquivo, o corpo da mensagem contém o deslocamento inicial, o tamanho a ser lido e o caminho para o arquivo. Se a leitura solicitada ultrapassar o final do arquivo, ocorre um erro e nenhuma resposta é enviada. Caso contrário, o malware lê o arquivo em blocos de 4kB, cada um dos quais é enviado no corpo de uma mensagem com o ID de comando 0x32341130.

O processo é similar para a gravação de arquivos. A mensagem inicial do C&C contém o tamanho total dos dados a serem gravados, seguido pelo caminho do arquivo de destino. Curiosamente, a gravação só ocorre se esse tamanho for maior que o tamanho atual do arquivo de destino. Os dados são então enviados pelo servidor C&C em blocos de 4kB, usando o mesmo ID de comando 0x32341130.

Listagem de arquivos

Quando o comando de listagem de arquivos é recebido, o backdoor primeiro envia uma mensagem de confirmação com o ID de comando 0x32341133. Em seguida, utiliza as funções da API FindFirstFileW e FindNextFileW para percorrer, de forma não recursiva, os arquivos do diretório de destino. Para cada arquivo, o SparrowDoor envia uma mensagem, com o mesmo ID de comando do comando de listar arquivo (0x32341132) e as informações descritas na Figura 3.

Observe que, embora o comprimento do nome do arquivo não seja especificado diretamente, ele pode ser obtido subtraindo o tamanho dos outros campos (0x16) do valor data_length do cabeçalho.

Uma vez finalizada a iteração, é enviada uma mensagem com o ID de comando 0x32341134 e sem dados para indicar que a operação de listagem de arquivos foi concluída com sucesso.

Proxy

Essa funcionalidade permite que o backdoor atue como um proxy TCP entre o servidor C&C e uma máquina arbitrária. Assim como outros comandos processados em paralelo, essa ação é realizada em um novo thread utilizando seu próprio socket. O SparrowDoor envia uma mensagem de confirmação com o mesmo ID do comando original, e o corpo dessa mensagem contém o ID único da vítima.

O comando com ID 0x32341139 é então enviado pelo servidor para iniciar efetivamente o proxy. A funcionalidade de proxy é alcançada criando dois novos sockets: um conectado ao servidor C&C e outro conectado a um endereço e porta fornecidos pelo servidor na nova conexão. O SparrowDoor então utiliza um par de estruturas Winsock e eventos para monitorar os pacotes de entrada e retransmiti-los entre as duas partes.

A adição da funcionalidade de proxy ao SparrowDoor pode ser um indicativo de que o grupo está seguindo a tendência de cibercriminosos alinhados com a China, que constroem e utilizam redes operacionais de retransmissão (ORB).

SparrowDoor Modular

A versão modular do SparrowDoor apresenta mudanças significativas em relação às anteriores. No que diz respeito à comunicação de rede, o cabeçalho do comando agora é transmitido separadamente do corpo, e os dados são criptografados com RC4 utilizando a chave codificada iotrh^%4CFGTj. As classes personalizadas empregadas para a comunicação de rede continuam utilizando sockets Winsock TCP e mantêm grande semelhança com as versões anteriores. No entanto, a principal diferença é que a classe filha recebe um nome enganoso: CShttps, em vez de CTcpSocket.

Como visto na Tabela 3, esta versão implementa apenas os comandos relacionados à gestão da configuração do servidor C&C e à desinstalação do backdoor. A informação sobre a máquina hospedeira é enviada automaticamente após a mensagem de conexão inicial e inclui uma lista de produtos de segurança instalados, além das informações que eram enviadas nas versões anteriores.

Todos os outros comandos estão relacionados ao gerenciamento de plugins. Acreditamos que a funcionalidade removida tenha sido transferida para um ou mais módulos. Embora ainda não tenhamos observado nenhum plugin desse tipo, podemos compartilhar ideias baseadas na análise do código que implementa essa funcionalidade.

Tabela 3. Comandos implementados na versão modular do SparrowDoor.

Plugins

Os plugins instalados são referenciados por meio de uma lista padrão de C++; cada entrada consiste em uma máscara de bits e um endereço de função manipuladora. A máscara de bits é usada para determinar qual ID de comando o plugin manipula e corresponde ao nibble inferior do terceiro byte do ID do comando (ou seja, CommandID & 0xF0000).

Esta versão do SparrowDoor pode usar cinco IDs de comando diferentes para invocar comandos de plugin. Desses, três (0x3A76, 0x3A77 e 0x3A7B) seguem quase exatamente o mesmo caminho no código — a única diferença é o ID de resposta da mensagem de reconhecimento. Existem algumas diferenças menores no processo de handshake entre esse conjunto de comandos e os outros dois. No entanto, em todos os casos, o comando é processado em paralelo usando o mesmo método descrito na seção de Comandos neste post. No novo socket, o backdoor envia o ID de resposta correspondente, o ID único da máquina hospedeira e os dados que foram inicialmente recebidos do servidor C&C. Esses dados parecem funcionar como o ID de operação mencionado na seção Operações de Arquivo.

Uma vez completado esse handshake, todos os cinco comandos chamam a mesma função para realmente manipular o comando do plugin. Essa função recebe o ID do comando e os dados do servidor C&C, depois percorre os plugins instalados para enviar o comando ao controlador correto. O processo se repete até que o backdoor receba uma mensagem de comando com um formato incorreto.

Por padrão, apenas um plugin é instalado, com uma máscara de bits de 0x10000. Esse plugin lida com a instalação de novos plugins enviados pelo servidor C&C. Os plugins são enviados pelo servidor como arquivos PE e nunca são armazenados no disco. Junto com o conjunto de funções reduzidas presentes no backdoor base, isso provavelmente é destinado a evitar a detecção. Após receber um plugin desse tipo, ele é mapeado manualmente na memória e sua exportação fmain é chamada. Essa função retorna um ponteiro para uma estrutura que contém o endereço de uma função que retorna a máscara de bits para o plugin e o endereço da função manipuladora. Se nenhum plugin instalado tiver a mesma máscara de bits, o plugin recém-recebido é adicionado à lista.

Links para versões anteriores

Também identificamos amostras anteriores que apresentam sobreposições significativas de código com esta versão modular, incluindo código similar para lidar com plugins. Essas amostras correspondem ao backdoor que a Trend Micro denominou de HemiGate em um artigo de agosto de 2023. Algumas das amostras até utilizam a mesma chave RC4 mencionada neste post. Em vez de serem enviadas pelo C&C, os plugins são implementados como classes C++ que herdam de uma classe abstrata chamada PluginInterface. Esses plugins seguem o mesmo padrão descrito no parágrafo anterior: possuem um método que retorna uma máscara de bits, utilizada para despachar comandos, e um segundo método para manipular os comandos.

Acreditamos que o HemiGate representa uma etapa anterior na evolução do backdoor modular. Portanto, é provável que os plugins que ele contém sejam representativos dos usados na versão modular mais recente. A tabela a seguir apresenta uma visão geral dos plugins e sua funcionalidade.

Tabela 4. Resumo dos plugins contidos no HemiGate.

Essas semelhanças são uma evidência de que o cluster que rastreamos como o FamousSparrow se sobrepõe, pelo menos parcialmente, com o Earth Estries. Dado que o HemiGate é anterior às duas versões do SparrowDoor detalhadas anteriormente neste relatório, isso também pode ser um indicativo de que as versões modular e paralelizada do SparrowDoor estão sendo desenvolvidas paralelamente.

ShadowPad

Una vez que o SparrowDoor foi detectado na rede da vítima dos Estados Unidos, foi utilizado para executar um loader baseado em MFC com semelhanças com os loaders ShadowPad previamente documentados pela Cisco Talos.

Este loader ShadowPad é uma DLL chamada imjpp14.dll, destinada a ser carregada por meio de DLL side-loading pela versão legítima e obsoleta de mais de 14 anos do executável do Microsoft Office IME, imecmnt.exe, renomeado para imjp14k.exe. O loader primeiro verifica se o processo atual é o host esperado para o carregamento lateral, realizando uma correspondência de padrões no offset 0.xE367 na memória. Após a validação bem-sucedida, a DLL maliciosa descriptografa o arquivo chamado imjpp14.dll.dat, que se encontra no mesmo diretório que a DLL e seu host de carregamento lateral. Finalmente, o payload descriptografado é injetado em um processo wmplayer.exe (Windows Media Player).

Embora não tenhamos recuperado o payload cifrado, uma detecção do ShadowPad foi registrada na memória de um processo wmplayer.exe, com imjpp14k.exe como o processo pai. Além disso, ele se conectava a um servidor C&C do ShadowPad (IP: 216.238.106[.]150). Embora não tenhamos observado nenhuma amostra do ShadowPad utilizando isso, um dos servidores C&C do SparrowDoor possuía um certificado TLS que coincidia com uma impressão digital conhecida do ShadowPad.

Além disso, detectamos loaders e o backdoor do ShadowPad na memória de várias máquinas na rede da vítima. É a primeira vez que observamos que o FamousSparrow utiliza o backdoor ShadowPad.

Outras ferramentas

Durante o ataque, além dos programas maliciosos mencionados anteriormente, também observamos o seguinte:

• Um script em lote básico que despeja o registro com os seguintes comandos:

1. reg save HKLM\SYSTEM C:\users\public\sys.hiv
2. reg save HKLM\SAM C:\users\public\sam.hiv
3. reg save HKLM\SECURITY C:\users\public\security.hiv

• Impacket ou NetExec, detectados pelo nosso firewall, mas não registramos nenhum dos comandos.
• Um loader para uma versão do RAT de código aberto Spark que foi modificado para incluir código de um loader de código Shell Go de código aberto.

Também observamos o uso de uma ferramenta para despejar a memória do LSASS com a função não documentada da API MiniDumpW. Essa ferramenta está dividida em duas DLLs armazenadas no disco como %HOME%\dph.dll e %WINDIR%\SysWOW64\msvc.dll. A última provavelmente foi projetada para se misturar com as bibliotecas legítimas do Microsoft Visual C++ (MSVC) que estão armazenadas no mesmo diretório. A primeira é carregada por uma versão legítima do gerador de cache do VLC (vlc-gen-cache.exe), renomeada para dph.exe, e importa funções da segunda. Como os plugins do VLC podem ser DLLs nativas, seu gerador de cache contém naturalmente código para carregar e executar tais bibliotecas.

Infraestrutura de rede

O servidor C&C do ShadowPad utiliza um certificado TLS autofirmado, com um hash SHA-1 de BAED2895C80EB6E827A6D47C3DD7B8EFB61ED70B, que tenta falsificar os usados pela Dell. Segue o formato descrito pela Hunt Intelligence em um artigo de fevereiro de 2024. Embora esse padrão possa ser utilizado para rastrear servidores ShadowPad, ele não está vinculado a nenhum grupo específico. Um dos servidores C&C usados pelo SparrowDoor (45.131.179[.]24:80) tinha um certificado TLS, na porta 443, com o mesmo Nome Comum (CN) que o certificado utilizado pelo servidor C&C do ShadowPad mencionado anteriormente. Esse servidor também é o único presente em ambas as versões do SparrowDoor.

Observamos três servidores C&C exclusivos do SparrowDoor nesta campanha, todos operando na porta 80. A versão modular estava configurada para utilizar amelicen[.]com como seu terceiro servidor C&C. Quando a amostra foi detectada pela primeira vez, esse domínio apontava para o endereço IP mencionado no parágrafo anterior.

Curiosamente, um dos servidores C&C configurados na versão modular (43.254.216[.]195:80) também foi utilizado pelo loader do SparrowDoor. Isso é incomum, pois o SparrowDoor emprega TCP puro, enquanto os arquivos foram baixados via HTTP. Além disso, há um intervalo de quase duas semanas entre os downloads (30 de junho de 2024) e a compilação do SparrowDoor modular (12 de julho de 2024). Ainda não sabemos se o serviço que escutava nessa porta foi modificado nesse período ou se o servidor C&C do SparrowDoor possui funcionalidade para servir arquivos via HTTP.

Conclusão

Entre 2022 e 2024, a ausência de atividade e de relatórios públicos levou à presunção de que o FamousSparrow estava inativo. No entanto, nossa análise de uma rede comprometida nos Estados Unidos em julho de 2024 revelou duas novas versões do SparrowDoor, confirmando que o grupo segue desenvolvendo seu principal backdoor. Uma dessas versões também foi identificada em uma máquina no México.

Durante nosso rastreamento baseado nas descobertas abordadas neste post, identificamos atividades adicionais do grupo nesse período, incluindo um ataque a uma instituição governamental em Honduras. Esses novos indícios não apenas demonstram que o FamousSparrow continua ativo, mas também que estava aprimorando o SparrowDoor ao longo desse tempo.

Seguiremos monitorando e reportando as atividades do FamousSparrow, além de acompanhar o debate sobre seus possíveis vínculos com o Salt Typhoon.

Indicadores de Comprometimento

Arquivos

Rede

Técnicas ATT&CK do MITRE

Esta tabela foi construída utilizando a versão 16 do framework MITRE ATT&CK.