FamousSparrow concentra suas operações na América Latina e implementa o novo backdoor SparroWocky

O monitoramento contínuo do FamousSparrow pela equipe de pesquisa da ESET voltou a dar frutos. Nosso relatório público anterior sobre o FamousSparrow revelou que esse grupo APT ligado à China havia desenvolvido duas novas versões de seu backdoor personalizado, chamado SparrowDoor. Desta vez, descobrimos que o FamousSparrow passou a usar um novo backdoor, o SparroWocky, e vem implantando-o em vários países da América Latina desde pelo menos agosto de 2025.

No que parece ser uma reação da China ao crescente interesse dos Estados Unidos na América Latina, o FamousSparrow intensificou sua atividade na região, concentrando suas operações quase exclusivamente nela em julho de 2025. Um mês depois, observamos que o grupo havia começado a utilizar o novo backdoor SparroWocky, que rapidamente substituiu o SparrowDoor como principal implante do FamousSparrow.

O SparroWocky é um backdoor modular desenvolvido em C++. Sua arquitetura e as técnicas utilizadas por seus autores indicam um sólido conhecimento de técnicas de evasão de análise e dos mecanismos internos do Windows. Escolhemos o nome SparroWocky porque as primeiras amostras que coletamos contêm a primeira estrofe de Jabberwocky, um poema nonsense de Lewis Carroll. Felizmente, embora seja avançada, a forma como o SparroWocky funciona é muito menos enigmática do que seu nome pode sugerir. Por isso, uma análise minuciosa de sua vorpal blade nos permitiu elaborar uma análise detalhada desse backdoor.

Principais pontos deste artigo:

• O FamousSparrow está intensificando seus ataques contra órgãos governamentais na América Latina.
• Desde agosto de 2025, o grupo parece estar substituindo o SparrowDoor pelo SparroWocky, um novo backdoor personalizado desenvolvido em C++.
• Com a adoção do SparroWocky, o FamousSparrow começou a incorporar diretamente em seu malware códigos de projetos de código aberto.
• O SparroWocky é um backdoor com amplos recursos, que manipula estruturas de baixo nível na memória e modifica códigos em tempo de execução para evitar a detecção.
• O SparroWocky é capaz de carregar e executar Beacon Object Files (BOF), um tipo especial de arquivo executável compatível com diversas ferramentas de red team e testes de intrusão.

O FamousSparrow é um grupo de ciberespionagem ligado à China que, acredita-se, esteja ativo desde pelo menos 2019. Documentamos publicamente o grupo pela primeira vez em uma publicação de setembro de 2021, quando observamos que ele explorava a vulnerabilidade ProxyLogon. Inicialmente, o grupo era conhecido por atacar hotéis em diferentes partes do mundo, embora também tenha direcionado suas operações contra governos, organizações internacionais, associações comerciais, empresas de engenharia e escritórios de advocacia. O FamousSparrow é o único usuário conhecido do backdoor SparrowDoor.

Analisamos duas versões do SparrowDoor em uma publicação de 2025, na qual também abordamos as atribuições relacionadas ao grupo. Como apontou a Trend Micro, o FamousSparrow está ligado ao Earth Estries. No entanto, a natureza exata dessa relação ainda não é totalmente conhecida. O grupo também foi publicamente associado ao Salt Typhoon, mas, devido à falta de indicadores técnicos que confirmem essa relação, continuamos monitorando os dois como grupos independentes.

Com base em nossa investigação, atribuímos com alto grau de confiança a campanha mais recente e o backdoor SparroWocky ao FamousSparrow. Isso se deve ao fato de que, em alguns dos primeiros ataques nos quais esse backdoor foi utilizado, o SparroWocky foi implantado por meio do SparrowDoor, uma ferramenta exclusiva do FamousSparrow. Além disso, não apenas o perfil das vítimas coincide com os alvos históricos do grupo, como também registramos tentativas de implantação do SparroWocky contra muitas das mesmas organizações que haviam sido anteriormente atacadas com o SparrowDoor.

América Latina na mira

Como mencionamos anteriormente, o FamousSparrow parece estar atualmente focado em alvos de alto perfil na América Latina. Essa tendência começou, no mínimo, em julho de 2025 e se manteve com a chegada do SparroWocky. De fato, entre meados de 2025 e 2026, 90% dos alvos do grupo registrados em nossa telemetria estavam localizados na região. Como mostra a Figura 1, observamos a implantação do novo backdoor contra entidades governamentais da Argentina, Equador, Guatemala, Honduras, Panamá, Peru, Porto Rico e Venezuela. Trata-se de um caso incomum entre os grupos APT ligados à China que monitoramos atualmente, já que, normalmente, suas operações se distribuem entre diferentes regiões do mundo durante períodos prolongados.

Acreditamos que esse foco não seja casual e provavelmente reflita a resposta da China a diversas iniciativas recentes dos Estados Unidos na região. De fato, o segundo mandato presidencial de Donald Trump representou uma reafirmação agressiva dos interesses dos Estados Unidos na América Latina, algo que coloca em risco diversos investimentos estratégicos que a China desenvolveu no continente ao longo da última década em setores como energia, mineração e telecomunicações. Suspeitamos que as atividades do FamousSparrow tenham como objetivo ajudar a China a monitorar melhor e antecipar as reações dos governos locais diante das atuais pressões dos Estados Unidos.

Em alguns casos, observamos indícios que parecem respaldar claramente essa hipótese. Por exemplo, uma das entidades panamenhas que identificamos entre os alvos está diretamente envolvida na disputa comercial em torno de dois importantes portos localizados na região do canal, que até pouco tempo atrás eram operados por uma empresa sediada na China. Como a concessão concedida a essa companhia foi contestada judicialmente pelo governo panamenho no início de 2025, parece muito provável que a operação do FamousSparrow buscasse obter informações antecipadas e privilegiadas sobre as intenções das autoridades locais em relação a esse assunto.

Ainda não está claro se o aparente foco do grupo na América Latina responde a um mandato geográfico formal ou se trata de uma prioridade temporária impulsionada pelas atuais circunstâncias geopolíticas.

Análise do SparroWocky

O SparroWocky é um backdoor modular desenvolvido em C++ e projetado com forte ênfase em modularidade e furtividade. Ele surgiu pouco depois de o FamousSparrow começar a se concentrar na América Latina e rapidamente se tornou o principal implante do grupo, substituindo o SparrowDoor. É importante destacar que o SparroWocky não é uma variante do SparrowDoor, mas uma família de malware completamente diferente. A transição para esse novo backdoor também veio acompanhada de uma maior integração de ferramentas de código aberto ao fluxo de trabalho do FamousSparrow. Enquanto anteriormente essas ferramentas eram implantadas como componentes independentes junto ao SparrowDoor, com o SparroWocky, algumas delas foram incorporadas diretamente ao malware.

Entre os principais recursos do SparroWocky estão a execução de arquivos arbitrários, a capacidade de atuar como proxy TCP e a execução de comandos. O backdoor também coleta informações gerais sobre o computador comprometido, como nome do computador, nome de usuário, domínio, versão do Windows e endereços IP de suas interfaces de rede.

Além disso, o SparroWocky pode exfiltrar arquivos e capturar telas periodicamente. As informações exfiltradas são criptografadas usando RC4 e transmitidas por meio do protocolo TLS. Dependendo de sua configuração, o SparroWocky pode estabelecer persistência por meio da criação de um serviço dedicado ou de uma entrada em uma chave Run do Registro do Windows.

Loader

O SparroWocky é implantado por meio do esquema habitual de loader tridente, que consiste em um executável legítimo, uma DLL maliciosa que se passa por uma DLL exigida por esse executável e um arquivo que contém um payload criptografado (veja a Figura 2). O loader está localizado na DLL mencionada e é executado por meio de DLL side-loading. Observamos que o FamousSparrow utiliza uma ampla variedade de alvos para realizar o side-loading. Na maioria dos casos, trata-se de uma versão modificada da DLL legítima que o executável normalmente deveria carregar. Embora a maior parte do arquivo permaneça intacta, uma parte arbitrária da seção .text é substituída por código malicioso, e o cabeçalho do ponto de entrada (entry point) é modificado para apontar para essa região alterada.

Essa técnica oferece determinados recursos de evasão de mecanismos de defesa. Ao manter os mesmos metadados e a mesma lista de funções exportadas da DLL legítima, a DLL maliciosa pode passar mais despercebida. Além disso, como o código inserido na região modificada não corresponde às funções exportadas nem às chamadas presentes na parte não alterada do arquivo, as ferramentas automatizadas de análise podem ter dificuldade para identificar corretamente os limites entre as funções.

A principal função do loader é extrair e descriptografar seu payload a partir de um arquivo. Esses arquivos, que normalmente têm o mesmo nome do executável, mas com a extensão .dat, apresentam uma estrutura específica detalhada na Figura 3.

O arquivo contém um cabeçalho personalizado que começa com um valor mágico de quatro bytes (0x11328712), seguido pelo tamanho dos dados de configuração, pelo tamanho do payload e por uma chave RC4 de 16 bytes. Essa chave RC4 é usada para descriptografar o restante do arquivo, que contém tanto a configuração do SparroWocky (descrita na seção Configuração) quanto o próprio backdoor. Disponibilizamos um script para descriptografar arquivos de payload do SparroWocky em nosso repositório no GitHub.

O payload do backdoor em texto simples tem o formato de um arquivo executável portátil (PE) do qual os valores mágicos MZ e PE foram removidos. Esse payload executável é carregado de forma reflexiva diretamente na memória, sem ser gravado no disco. Por isso, acreditamos que a remoção desses valores mágicos seja possivelmente uma tentativa de evitar mecanismos de defesa em memória que utilizam reconhecimento simples de padrões para identificar ou extrair seções suspeitas da memória.

SparroWocky

Nossa análise do SparroWocky baseia-se principalmente em uma amostra compilada em 17 de novembro de 2025, de acordo com o timestamp de seu PE (SHA-1: 44F0A22B143B79FA760BF31E14C8FFF714C8A2A1). A versão desse backdoor parece ser a 1.8, de acordo com as informações coletadas por seu comando de fingerprinting, explicado na Tabela 3.

Como mencionamos anteriormente, escolhemos o nome SparroWocky porque encontramos a primeira estrofe de Jabberwocky, de Lewis Carroll, em várias das amostras que coletamos. Acreditamos que essa estrofe seja proveniente dos vetores de teste da RFC 7539, que define o algoritmo de criptografia ChaCha20-Poly1305. As amostras do SparroWocky também contêm outras strings utilizadas como vetores de teste nessa RFC. No entanto, o SparroWocky não utiliza ChaCha20-Poly1305. Embora não saibamos qual versão exata do Mbed TLS é utilizada pelo backdoor, esses vetores de teste estavam presentes nessa biblioteca antes da versão 4.0.0.

Vale destacar que o SparroWocky depende de pelo menos os seguintes projetos públicos:

• Mbed TLS, uma biblioteca em C que utiliza para estabelecer um canal de comunicação seguro com seu servidor C&C.
• MinHook, uma biblioteca de hooking da API do Windows que utiliza para ocultar dos produtos de segurança o endereço de início de threads recém-criadas.
• COFF Loader (ou um projeto semelhante), que utiliza para permitir o carregamento e a execução dinâmica de plugins na memória na forma de objetos COFF.

Além disso, nossa análise revelou que os desenvolvedores implementaram diversas técnicas para evitar ferramentas de monitoramento. Entre elas está uma variante de uma técnica chamada SilentMoonwalk (ou StackMoonwalk), que permite ao SparroWocky falsificar as call stacks originadas nas rotinas do MinHook. O backdoor também utiliza um algoritmo personalizado de API hashing para resolver dinamicamente as funções da API do Windows. Essas técnicas são explicadas em maior detalhe na seção Técnicas antianálise.

Configuração

O loader do SparroWocky extrai e descriptografa sua configuração do arquivo de payload.dat localizado no mesmo diretório, conforme explicado na seção Loader. A chave RC4 armazenada no cabeçalho do payload é usada para descriptografar a configuração, que se apresenta na forma de uma string de texto com campos separados por tabulações. Posteriormente, essas informações são processadas e armazenadas em uma estrutura interna. Os diferentes campos de configuração e seus valores são descritos na Tabela 1, seguindo a ordem em que aparecem na configuração.

Tabela 1. Configuração do SparroWocky.

Recursos

Comportamento controlado por argumentos

Após processar sua configuração, o backdoor analisa a linha de comando do processo no qual está sendo executado e adota diferentes comportamentos de acordo com a quantidade e o valor dos argumentos recebidos. Se nenhum argumento for fornecido, o SparroWocky simplesmente estabelece persistência e executa a lógica principal do backdoor. Por outro lado, se receber argumentos, o valor do primeiro determina qual ação o malware deve realizar, conforme descrito na Tabela 2.

Tabela 2. Argumentos da linha de comando do SparroWocky e seus significados.

* Explicado na seção «Comandos do backdoor».

Quando o SparroWocky é executado com a opção c, ele lê da entrada padrão (stdin) uma lista adicional de parâmetros separados por vírgulas:

• Uma string de comando;
• Um tempo limite (timeout) em segundos;
• Opcionalmente, o conteúdo de um arquivo PE.

Se esse último parâmetro não estiver presente, o backdoor lê de C:\Windows\System32\ o executável especificado na string de comando e carrega o arquivo MUI (Multilingual User Interface) associado de C:\Windows\System32\en-US\. Esse processo é descrito na seção Camuflagem do processo host para PE carregados dinamicamente. Caso contrário, o arquivo PE é executado pelo reflective loader do SparroWocky, e a string de comando é passada como linha de comando. É provável que essa funcionalidade tenha sido projetada para permitir que o backdoor execute facilmente utilitários do sistema.

O SparroWocky carrega o executável especificado na memória e o executa com o comando fornecido. Ao mesmo tempo, o backdoor cria uma nova thread que chama ExitProcess para finalizar o processo quando o tempo limite definido expirar. O processo de carregamento envolve a instalação de hooks e a falsificação de estruturas na memória para camuflar o processo host antes da execução do executável-alvo. Essas técnicas de evasão de análise são explicadas em maior detalhe na seção dedicada à Camuflagem do processo host para PE carregados dinamicamente.

Além disso, quando o malware é executado sem argumentos ou com a opção p, é iniciado um mecanismo de sincronização de instâncias. Esse recurso impede que várias instâncias do backdoor sejam executadas simultaneamente por meio de um mecanismo personalizado de comunicação entre processos (IPC, Inter-Process Communication).

Quando uma nova instância é iniciada, a instância que já está em execução é encerrada e, se a nova instância estiver sendo executada a partir de um local diferente, os arquivos e as configurações de persistência estabelecidos pela instância anterior são removidos.

Isso é realizado por meio do uso de três tipos de objetos globais: um mutex, um evento (event) e um bloco de memória compartilhada (shared memory block), denominados, respectivamente, MyMutexName, MyEventName e MySharedMemName.

Comandos do backdoor

O backdoor primeiro estabelece comunicação com seu servidor de Comando e Controle (C&C) e, em seguida, executa sua lógica principal dentro de um loop infinito, no qual processa os comandos recebidos. Esses comandos são gerenciados por uma classe personalizada chamada WinHandler (derivada de outra classe personalizada chamada ServerHandler), de acordo com as informações de tipos em tempo de execução (RTTI, Runtime Type Information) presentes no malware. Os manipuladores de um conjunto mínimo de comandos são codificados diretamente (hardcoded) no próprio loop de processamento de comandos. Por sua vez, ServerHandler conta com um método virtual específico para gerenciar comandos adicionais. Esse método é implementado em WinHandler. Embora não tenhamos observado outras implementações desse método, essa arquitetura facilitaria aos desenvolvedores modificar o conjunto de comandos que o backdoor pode processar. A lista de comandos compatíveis é apresentada na Tabela 3.

Tabela 3. Comandos do SparroWocky.

*Comando hardcoded.

O comando 0x14 utiliza uma versão ligeiramente modificada do RunCOFF, pertencente ao projeto de código aberto COFF Loader, para carregar e executar um Beacon Object File (BOF). Um BOF é um executável no formato Common Object File Format (COFF) independente de posição na memória, projetado para ser executado diretamente na memória de um implante. Os BOFs foram introduzidos originalmente no Cobalt Strike e, posteriormente, adotados por outros frameworks populares de red team, como Brute Ratel, Metasploit e Sliver. A modificação realizada no RunCOFF está no processo de resolução dos símbolos importados. O SparroWocky redireciona as chamadas para bibliotecas externas realizadas pelo BOF para uma sub-rotina de stack spoofing. Dessa forma, as chamadas realizadas pelo objeto BOF ficam ocultas e são encaminhadas por meio dessa rotina. Depois que o objeto é carregado, o loader de BOF localiza e executa function_name, passando como parâmetros os valores incluídos em function_arguments. A capacidade de carregar BOFs permite que o FamousSparrow aproveite módulos e ferramentas já existentes desenvolvidos para esse tipo de arquivo.

Autodeleção

Conforme descrito na seção Comportamento controlado por argumentos, o SparroWocky pode ser completamente removido do sistema. Isso pode ser realizado pelo servidor de Comando e Controle (C&C) por meio do comando 0x13. Primeiro, o mecanismo de persistência configurado anteriormente é removido. Em seguida, o arquivo em lotes (batch) mostrado na Figura 4 é criado e executado.

@echo off
timeout /t 2
del "<legitimate_executable>" /f /q
del "<loader_library>" /f /q
del "<payload_filepath>" /f /q
del "%%0" /f /q\n

Figura 4. Arquivo em lotes para autodeleção.

Esse processo remove todos os componentes utilizados pelo backdoor: o executável legítimo, a biblioteca utilizada para o side-loading e o arquivo de payload. Ao final, o próprio script também é excluído.

Técnicas antianálise

O SparroWocky emprega diversas técnicas destinadas a dificultar sua análise e evitar soluções de segurança presentes no sistema comprometido. Uma técnica comum utilizada pelo backdoor é a resolução dinâmica de APIs por meio de API hashing, mas ele também implementa mecanismos mais sofisticados, descritos a seguir.

SilentMoonwalk

A primeira técnica de destaque é chamada SilentMoonwalk e, essencialmente, fornece um mecanismo para falsificar call stacks. Seu objetivo é impedir que ferramentas e produtos de análise identifiquem a verdadeira origem de determinadas funções que normalmente são monitoradas, como as APIs do Windows. Esse método requer várias etapas de inicialização:

• Localizar o deslocamento (offset) de RtlUserThreadStart e BaseThreadInitThunk, duas funções que geralmente aparecem no início (ou no final) de qualquer call stack.
• Localizar um gadget JOP (jump-oriented programming) e um gadget ROP (return-oriented programming) dentro da biblioteca legítima kernel32.dll, que serão utilizados para restaurar a call stack original.

Depois que esses requisitos são atendidos, quando o SparroWocky realiza uma chamada ofuscada para uma função da API do Windows, ele primeiro salva o contexto atual do processo (os registradores). Em seguida, cria uma call stack falsa usando os gadgets identificados anteriormente e insere o endereço de uma rotina responsável por restaurar tanto a call stack quanto o contexto originais. Como resultado, parece que as chamadas para as APIs do Windows se originam em RtlUserThreadStart e BaseThreadInitThunk, ocultando a verdadeira origem da execução. A Figura 5 mostra a visualização da call stack obtida durante uma sessão de depuração com o WinDbg.

No caso do SparroWocky, essa técnica é utilizada para ofuscar as chamadas realizadas por plugins no formato BOF (comando 0x14) ou pela biblioteca de hooking MinHook, vinculada estaticamente.

Ocultação do endereço de início das threads

O SparroWocky utiliza a biblioteca MinHook para aplicar um hook sobre a função CreateThread, com o objetivo de ocultar das soluções de segurança o valor original do parâmetro lpStartAddress. Em essência, qualquer thread criada pelo SparroWocky terá como endereço de início a função AnimateWindow, algo que provavelmente seria considerado legítimo por um produto de segurança. O patch aplicado a AnimateWindow a transforma em um trampoline que simplesmente executa o endereço de início original, conforme mostrado na Figura 6.

Camuflagem do processo host para PE carregados dinamicamente

O último componente de código de destaque do SparroWocky é seu PE loader personalizado, utilizado quando ele é executado com a opção c. Embora a implementação de PE loaders seja uma prática bastante comum entre desenvolvedores de malware, os autores do SparroWocky foram além e integraram mecanismos de camuflagem do processo host.

Conforme descrito na Tabela 2, quando o SparroWocky é executado com a opção c, ele carrega um arquivo PE na memória e o executa. Se o arquivo não for fornecido como argumento, o PE loader analisa a linha de comando especificada para extrair o nome do arquivo. Em seguida, procura esse arquivo no diretório C:\Windows\System32\ e, mais importante, recupera o arquivo de localização MUI (Multilingual User Interface) em inglês associado ao PE-alvo (armazenado como C:\Windows\System32\en-US\<exe_name>.mui).

Nesse caso, o arquivo PE é carregado na memória e vários hooks são configurados para garantir que qualquer chamada realizada pelo PE carregado para recuperar dados de recursos, como RtlLoadString ou RtlFindMessage, seja redirecionada para os dados do arquivo .mui. Esse processo replica o comportamento normal do Windows ao carregar arquivos PE e reduz o risco de erros inesperados.

A linha de comando obtida do Stdin é analisada, e o SparroWocky aplica hooks às seguintes funções, utilizadas para recuperar informações sobre os argumentos da linha de comando, para que apontem para essa linha de comando:

• GetCommandline[AW]
• __(w}getmainargs
• __p___argc
• __p___{w}argv

O PE loader também é capaz de registrar os manipuladores de exceções (exception handlers) do executável recém-carregado, uma implementação incomum, mas crítica, pois permite que as exceções sejam tratadas corretamente.

Por fim, antes de chamar o entry point do arquivo PE carregado, o SparroWocky falsifica e insere uma estrutura LDR_DATA_TABLE_ENTRY falsa na lista duplamente encadeada da estrutura PEB_LDR_DATA. Essa lista duplamente encadeada é utilizada pelo Windows para acompanhar os módulos carregados e costuma ser monitorada por produtos de segurança. A Figura 7 mostra um trecho do código utilizado para configurar alguns de seus campos.

Essa última técnica demonstra que os desenvolvedores do SparroWocky possuem profundo conhecimento do mecanismo de carregamento de arquivos PE do Windows e estão dispostos a ir além para camuflar o processo host e confundir os softwares de monitoramento.

Protocolo de rede

Para se comunicar com seu servidor de Comando e Controle (C&C), o SparroWocky utiliza o protocolo de criptografia TLS. Internamente, o backdoor emprega a biblioteca Mbed TLS, e o único detalhe de destaque é que utiliza a string de personalização acdbenus ao inicializar o gerador determinístico de bits aleatórios, conforme mostrado na Figura 8.

Antes do handshake inicial do TLS, uma conexão TCP é estabelecida com o servidor C&C usando um dos três modos de conexão.

O modo de conexão 0 indica que o SparroWocky utiliza o proxy atualmente configurado no computador ou uma conexão TCP direta caso não exista um proxy do sistema configurado. Essa configuração é obtida consultando o valor de registro ProxyServer, localizado na chave HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. Se a conexão com o servidor proxy falhar, o SparroWocky tenta se conectar usando o modo 1 e, posteriormente, o modo 2.

O modo de conexão 1 corresponde a uma conexão por meio de um proxy HTTP. Essa conexão utiliza autenticação Negotiate (Kerberos ou NTLM) ou Basic, usando o nome de usuário e a senha definidos na configuração. Ambos os métodos utilizam cabeçalhos HTTP genéricos, com a string User-Agent configurada como Mozilla/5.0.

O modo de conexão 2 utiliza um proxy SOCKS5, sem autenticação (campo AUTH configurado como 0x00) ou com autenticação por nome de usuário e senha (campo AUTH configurado como 0x02). Os valores utilizados neste último caso são obtidos da configuração do malware.

Mensagens de comando

Depois que o handshake TLS é concluído, o SparroWocky envia os bytes 0x11223344 (big-endian) para indicar que está pronto para receber comandos na sessão principal. O backdoor utiliza um formato simples para receber comandos e enviar resultados, conforme ilustrado na Figura 9.

Se o campo command_arg_size for diferente de 0, significa que dados adicionais serão enviados ou recebidos após o cabeçalho. Nesse caso, os dados, sejam argumentos de comandos ou resultados, são criptografados usando RC4, e cada mensagem utiliza uma nova chave de oito bytes gerada dinamicamente, incluída no cabeçalho.

Infraestrutura de rede

O SparroWocky utiliza diretamente o endereço IP de seus servidores C&C para estabelecer as conexões, geralmente pela porta 443. Em alguns casos, também o observamos operando pela porta 8080. Embora tenhamos detectado certificados autoassinados reutilizados em vários servidores, não contamos com um fingerprint confiável que possa ser utilizado como indicador genérico.

Conclusão

Durante o segundo semestre de 2025 e o primeiro semestre de 2026, o FamousSparrow concentrou suas operações em alvos localizados na América Latina. Essa mudança representa uma alteração em relação à sua estratégia anterior, de alcance global. Como parte dessa evolução, o grupo desenvolveu o SparroWocky, que substituiu o SparrowDoor como seu principal implante. Embora não pareça ser baseado no mesmo código-fonte, observamos que o SparroWocky mantém diversas funcionalidades e conceitos presentes no backdoor anterior do grupo, que analisamos em uma publicação anterior. No entanto, incorpora técnicas de evasão mais sofisticadas para passar despercebido.

O FamousSparrow continua recorrendo a ferramentas ofensivas de código aberto para fins maliciosos. Anteriormente, essas ferramentas costumavam ser implantadas junto ao backdoor do grupo como componentes independentes. Com o SparroWocky, observamos também que o grupo possui os recursos de desenvolvimento necessários para integrar diretamente códigos de projetos de código aberto ao seu próprio backdoor personalizado.

Indicadores de Comprometimento

Em nosso repositório no GitHub é possível encontrar uma lista completa de indicadores de comprometimento (IoCs) e amostras.

Arquivos

Rede

Técnicas do MITRE ATT&CK

Esta tabela foi elaborada utilizando a versão 19 do framework MITRE ATT&CK.