ESET participa da Operação Endgame para desarticular o Amadey e o Stealc

Há um ano, a equipe de pesquisa da ESET participou de duas grandes operações que desarticularam algumas das principais operações cibercriminosas da época, o Lumma Stealer e o Danabot. Mais recentemente, nossa equipe voltou a colaborar com parceiros do setor privado e autoridades responsáveis pela aplicação da lei, desta vez tendo como alvo a botnet Amadey e o infostealer Stealc, ambos oferecidos no modelo de malware como serviço (MaaS).

A Operação Endgame, coordenada pela Microsoft Digital Crimes Unit (DCU), BitSight, Lumen, Mitsui Bussan Secure Directions (MBSD) e outros parceiros, teve como objetivo atingir toda a infraestrutura de rede conhecida utilizada pelos afiliados do Amadey e do Stealc, com o intuito de interromper suas operações cibercriminosas.

A ESET contribuiu para essa iniciativa fornecendo análises técnicas, informações estatísticas, servidores de comando e controle (C&C) conhecidos, chaves de criptografia, identificadores de campanhas e compilações, além de outras informações de inteligência sobre ameaças coletadas durante o monitoramento de longo prazo dessas duas famílias de malware.

Principais pontos desta publicação:

• A ESET participou da Operação Endgame, uma ação global coordenada para desarticular as ameaças Amadey e Stealc.
• A Operação Endgame afetou cerca de 50 domínios e quase 200 servidores ativos de comando e controle (C&C) baseados em IP associados ao Amadey e ao Stealc.
• A ESET forneceu análises técnicas, informações estatísticas, servidores C&C conhecidos, chaves de criptografia, identificadores de campanhas e outros dados de inteligência.
• Apresentamos uma visão geral do ecossistema de malware como serviço (MaaS) no nível dos afiliados de ambas as famílias de malware.
• Descrevemos como agrupamos as atividades relacionadas ao Amadey e ao Stealc.
• Resumimos as características técnicas mais relevantes para o rastreamento e a desarticulação dessas ameaças, incluindo comunicações C&C, identificadores incorporados e chaves de criptografia.
• Detalhamos as sobreposições entre as atividades do Amadey e dos afiliados do Lumma Stealer.

Contribuição para a operação de desarticulação

A equipe de pesquisa da ESET monitora a botnet Amadey e o infostealer Stealc há três anos. Para esta operação de desarticulação, compartilhamos estatísticas referentes ao quarto trimestre de 2025 até o primeiro semestre de 2026, além de indicadores técnicos e dados de configuração extraídos de amostras de malware processadas.

Nossos sistemas automatizados analisaram amostras do Amadey e do Stealc, identificando os campos mais relevantes para o rastreamento em larga escala. Entre eles estão servidores C&C, identificadores de compilação, chaves de criptografia, caminhos de URL, identificadores de campanhas e outros valores incorporados utilizados pelas famílias de malware durante a comunicação com a infraestrutura controlada pelos cibercriminosos.

Um dos principais focos do nosso trabalho foi encontrar métodos confiáveis para lidar com o grande volume de amostras processadas e agrupá-las. Essa abordagem foi especialmente útil porque tanto o Amadey quanto o Stealc são comercializados como serviços. Dessa forma, as amostras de malware são distribuídas e operadas por afiliados, que frequentemente utilizam sua própria infraestrutura, geram ou solicitam suas próprias compilações e coordenam suas próprias campanhas. A identificação de grupos de atividade nesses ecossistemas permite encontrar alvos prioritários para operações de desarticulação como esta.

O compartilhamento de análises técnicas, informações estatísticas e inteligência sobre ameaças, como listas de servidores C&C, identificadores de afiliados e chaves de criptografia, permite que as autoridades responsáveis pela aplicação da lei identifiquem, priorizem e atuem contra infraestruturas maliciosas com alto grau de confiança. Os IoCs também ajudam a diferenciar grupos individuais, infraestruturas compartilhadas e botnets de alto impacto, cuja interrupção provavelmente terá os maiores efeitos no cenário geral de ameaças.

Ao final, a operação afetou cerca de 50 domínios e quase 200 endereços IP ativos utilizados como servidores C&C do Amadey ou do Stealc.

Famílias de malware desarticuladas

O Amadey é um malware modular do tipo loader. Sua principal função é distribuir malwares adicionais para sistemas comprometidos, embora também ofereça módulos para exfiltração de dados e acesso remoto.

O Stealc, por outro lado, é um infostealer típico oferecido como serviço. Ele tem como alvo credenciais, cookies, carteiras de criptomoedas, extensões de navegadores e arquivos cujos nomes correspondem a padrões definidos pelos afiliados.

Ambas as famílias de malware são vendidas como serviços e anunciadas em fóruns da darknet. Para obter visibilidade sobre esses fóruns, utilizamos a Flare.io, uma plataforma de inteligência sobre ameaças que monitora comunidades clandestinas. Em ambos os ecossistemas, os afiliados recebem um painel de administração hospedado por eles mesmos, que deve ser implantado em sua própria infraestrutura de servidores. Isso exige um certo nível de conhecimento técnico dos afiliados e também lhes dá controle direto sobre os dados das vítimas e a distribuição de cargas maliciosas.

Esse modelo difere de outros ecossistemas MaaS. Por exemplo, os afiliados do Danabot podem optar por alugar uma infraestrutura C&C como serviço, enquanto o Lumma Stealer utilizava uma rede de exfiltração totalmente gerenciada por seus operadores. No caso do Amadey e do Stealc, os afiliados são responsáveis por implantar e operar sua própria infraestrutura, tornando os esforços de desarticulação mais difíceis. Por isso, a abordagem de agrupamento foi essencial.

Embora os métodos de distribuição dependam, em última instância, de cada afiliado, a telemetria da ESET mostrou consistentemente que ambas as famílias de malware foram distribuídas por uma ampla variedade de canais. Os métodos mais comuns incluíram falsas atualizações de software, instaladores de softwares pirateados e loaders de malware de terceiros.

O Amadey utilizava um modelo de pagamento por recompilação. Os afiliados adquiriam uma licença e pagavam uma taxa adicional sempre que precisavam gerar uma nova compilação, por exemplo, ao trocar para um novo servidor C&C. Em outras palavras, os operadores do Amadey não forneciam aos afiliados uma ferramenta de compilação; em vez disso, as amostras eram compiladas sob demanda para cada afiliado.

O Stealc adotou uma abordagem mais favorável aos afiliados, oferecendo geração ilimitada de compilações (Figura 1) como parte de sua assinatura. Isso reduziu o custo operacional da troca de infraestrutura C&C e facilitou a geração de novas amostras pelos afiliados sempre que necessário.

Na tentativa de evitar golpes de falsificação de identidade, os operadores de ambos os serviços orientavam explicitamente potenciais afiliados, nos fóruns da darknet, a entrar em contato com eles apenas por canais oficiais. O Amadey direcionava os compradores para mensagens privadas no fórum da darknet onde era anunciado, enquanto o Stealc utilizava mensagens privadas em fóruns da darknet ou no Telegram.

Amadey

O Amadey é um malware modular do tipo loader que tem sido anunciado em fóruns da darknet pela conta InCrease desde outubro de 2018. Ao longo do tempo, tornou-se uma das famílias de malware mais estáveis e ativamente mantidas, com suporte contínuo fornecido por meio de canais de fóruns da darknet.

Nossa taxa de detecção de telemetria, apresentada na Figura 2, indica que o Amadey foi observado globalmente, sem um foco regional específico, embora as maiores taxas de detecção tenham sido registradas na Índia, Turquia, Egito, México e Espanha.

A principal função do Amadey é distribuir malwares adicionais para as vítimas. Além disso, ele oferece três módulos para ampliar a exfiltração de dados e o acesso aos sistemas: monitoramento da área de transferência, roubo de credenciais e acesso remoto baseado em VNC.

O serviço tem o preço de US$ 600, pagos em Bitcoin, por uma única licença, com uma cobrança adicional de US$ 50 por recompilação. Isso significa que os afiliados têm um custo cada vez que geram uma nova compilação, por exemplo, ao trocar para um novo servidor C&C. Esse modelo de preços permaneceu praticamente inalterado desde as primeiras versões anunciadas, sugerindo uma base de clientes estável e consolidada.

Ao longo dos anos, observamos atualizações contínuas de versões (Figura 3) e o desenvolvimento ativo do Amadey. O marco mais significativo no desenvolvimento do Amadey ocorreu em agosto de 2020 (v1.99.5), quando toda a base de código foi completamente reescrita. A segunda grande evolução ocorreu com o lançamento da versão v5.03, em outubro de 2024, que trouxe uma série de novos recursos: hVNC com conexão reversa, suporte a instaladores silenciosos MSI, habilitação de RDP, execução do cmd.exe com privilégios de SISTEMA e suporte integrado para cargas maliciosas criptografadas.

De forma geral, a maioria das outras atualizações menores teve um objetivo implícito, porém constante: evitar as detecções de soluções antivírus à medida que elas surgiam.

Visão geral técnica

Cada amostra do Amadey contém pelo menos uma URL de servidor C&C incorporada ao código, com uma configuração que suporta até três entradas. As amostras também incluem uma chave RC4 utilizada para criptografar as comunicações com o servidor C&C.

Nossa análise mostrou que a chave RC4 extraída de cada amostra funciona como um identificador confiável de cluster, permitindo agrupar amostras em botnets individuais, como discutiremos com mais detalhes na seção Agrupamento (Clustering).

Um segundo valor incorporado ao código, denominado internamente como sd, é uma sequência hexadecimal de seis caracteres com aparência aleatória, seguindo o padrão [0-9a-f]{6}. Esse valor é transmitido durante o processo inicial de comunicação com o servidor C&C e, provavelmente, identifica uma compilação específica dentro da implantação de um afiliado. Embora às vezes seja chamado por pesquisadores de identificador de campanha ou ID do Amadey, o modelo de negócio do Amadey baseado em pagamento por compilação indica que o termo mais adequado é identificador de compilação.

Cada amostra também possui um número de versão. Nossa análise se concentra na versão v5.x, que tem sido a variante predominante observada na telemetria da ESET desde o início de 2025.

Esse bot também verifica o layout do teclado da vítima. Caso corresponda a um layout associado a um país da Comunidade dos Estados Independentes (CIS), toda a comunicação de rede é rejeitada silenciosamente. Atores de ameaças que operam a partir do Leste Europeu costumam utilizar esse tipo de mecanismo de proteção integrado para evitar afetar empresas e entidades governamentais da região, reduzindo o risco de chamar a atenção ou sofrer ações legais por parte das autoridades locais. Além disso, esses operadores frequentemente adotam essas práticas para evitar possíveis reações negativas de outros integrantes do ecossistema criminoso por atingir “seu próprio povo” ou por violar as regras dos fóruns da darknet onde seus serviços são anunciados.

Esta seção apresenta apenas uma visão geral do Amadey, pois uma análise técnica aprofundada já foi publicada no relatório da Swisscom.

Comunicações C&C

O Amadey se comunica com seu servidor de comando e controle (C&C) por meio de HTTP utilizando requisições POST. Em alto nível, essa comunicação segue um ciclo de vida composto por três etapas:

• Beacon inicial: o bot envia uma requisição HTTP POST mínima contendo st=s para o servidor C&C. O servidor responde com um intervalo de espera, por exemplo <c>10<d>, instruindo o bot a aguardar 10 minutos entre as comunicações subsequentes.
• Registro: o bot transmite informações do sistema criptografadas com RC4 e codificadas como uma sequência simples de chave-valor. Esses dados incluem a versão do sistema operacional, nome de usuário, nome do computador, produto antivírus instalado, privilégios administrativos, valor sd e outras informações do dispositivo. É importante destacar que a própria chave RC4 nunca é transmitida pela rede. Com base em nossa telemetria, nenhum servidor foi observado fornecendo tarefas para mais de uma chave RC4 ao mesmo tempo, sugerindo que cada amostra precisa se comunicar com um servidor C&C que já conhece e espera exatamente aquela chave RC4 específica. O servidor responde com uma lista de tarefas.
• Execução de tarefas: as tarefas são entregues como sequências de comandos estruturadas, delimitadas pelas tags <c> e <d>, com comandos individuais separados pelo caractere #, conforme apresentado na Figura 4. Cada tarefa contém um tipo de comando específico, como baixar e executar um arquivo EXE, iniciar uma sessão VNC ou executar um plugin de roubo de informações. As tarefas também incluem parâmetros como um indicador de escalonamento de privilégios, diretório de destino e URL da carga maliciosa.

Cada tarefa possui sua própria lógica de processamento, variando desde comandos simples de download e execução até a execução mais complexa de componentes hVNC ou de proxy. O funcionamento interno desses recursos já foi documentado em análises técnicas anteriores.

Agrupamento de atividades (Clustering)

Ao rastrear malwares comercializados como serviço (MaaS), um dos principais desafios é encontrar uma maneira confiável de agrupar amostras pertencentes ao mesmo agente de ameaça. Compreender o modelo de negócio e a distribuição da infraestrutura de rede é, portanto, essencial para uma desarticulação bem-sucedida, pois permite que equipes de defesa e autoridades responsáveis pela aplicação da lei identifiquem os pontos críticos onde uma ação terá maior impacto. Nesta seção, explicamos nossa metodologia.

As amostras do Amadey contêm três valores principais de configuração incorporados ao código:

• URLs dos servidores C&C;
• Chaves RC4 utilizadas nas comunicações C&C;
• O valor sd  transmitido durante o processo inicial de comunicação com o servidor C&C.

Durante nosso monitoramento, observamos que as URLs dos servidores C&C do Amadey seguem um padrão consistente:

http(s)?://<C&C>/<random_path>/index.php

Além disso, o mesmo componente <random_path> da URL foi utilizado com diferentes servidores C&C (veja a Figura 5). Como esse valor parece ser uma sequência aleatória, sua associação com múltiplos servidores C&C ao longo do tempo indicou fortemente que esses servidores fazem parte do mesmo cluster operacional. Por isso, dividimos a URL C&C em dois componentes: o endereço IP ou domínio e o caminho da URL <random_path>.

Utilizando os valores presentes na configuração das amostras, combinados com nosso entendimento sobre sua finalidade, aplicamos modelagem em grafos para obter informações sobre a estrutura do ecossistema do Amadey. Em uma primeira análise da Figura 6, observamos claramente que não existe uma infraestrutura compartilhada, mas sim diversos subgrupos de botnets menores, com um deles claramente dominante. Analisaremos esse maior cluster em mais detalhes na próxima seção.

Para concluir, os principais pontos são:

1. Identificamos um total de 53 clusters únicos dentro do ecossistema do Amadey.
2. Cada valor sd está associado a exatamente uma chave RC4.
3. As chaves RC4 provavelmente funcionam como identificadores úteis de afiliados, pois as recompilações mantêm a chave enquanto alteram o valor sd.
4. O componente <random_path> da URL C&C é ocasionalmente reutilizado durante a troca de servidores C&C, servindo como uma evidência confiável de que esses servidores pertencem ao mesmo cluster.

O maior cluster de botnet do Amadey

Um cluster se destaca como o maior, sendo responsável por quase 34% de todas as amostras do Amadey processadas. Esse cluster também foi o único que permaneceu ativo durante todo o período analisado, conforme apresentado na nossa linha do tempo na Figura 7.

A maior botnet também predominou em relação ao número médio de cargas maliciosas distribuídas às vítimas por execução. Com base em nossa metodologia de agrupamento, as amostras do Amadey pertencentes à maior botnet distribuíram, em média, cerca de 14 cargas maliciosas simultaneamente para cada vítima (Figura 8).

A variedade e a diversidade das famílias de malware distribuídas eram amplas, incluindo desde infostealers e RATs até malwares protegidos por mecanismos complexos de proteção de código. A Figura 9 apresenta uma visão geral das cargas maliciosas que identificamos sendo distribuídas durante o período de monitoramento.

Além disso, a equipe de pesquisa da ESET obteve evidências de que, em muitas ocasiões, múltiplas amostras do Lumma Stealer foram distribuídas para uma única vítima, cada uma atribuída a um afiliado diferente (consulte nossa pesquisa anterior sobre o Lumma Stealer). Como resultado, vários afiliados do Lumma Stealer acabavam tendo acesso aos mesmos dados roubados. Essa observação nos leva a concluir que os cibercriminosos responsáveis por controlar esse maior cluster provavelmente operavam seu próprio modelo de pay-per-install (PPI), monetizando ainda mais suas botnets.

Stealc

Diferentemente do Amadey, o Stealc é um representante típico de um infostealer. Ele tem como alvo uma ampla variedade de fontes de dados, incluindo credenciais armazenadas por navegadores, clientes de e-mail, clientes FTP, plataformas de jogos, arquivos de carteiras de criptomoedas e extensões de navegadores.

O Stealc foi apresentado em um fórum da darknet em fevereiro de 2023, e iniciamos seu monitoramento pouco depois. Nossa taxa de detecção de telemetria, apresentada na Figura 10, indica que o Stealc foi distribuído globalmente, sem um foco regional específico. As maiores taxas de detecção foram observadas nos Estados Unidos, na Polônia e na Itália.

O Stealc é anunciado por um agente de ameaça que utiliza o pseudônimo plymouth. Os operadores mantiveram o Stealc ativamente, divulgando notas de atualização em uma publicação de fórum da darknet sempre que uma nova versão era lançada. Nos últimos três anos, foram registradas 37 versões.

O Stealc é vendido como uma assinatura mensal, com preços que sofreram poucas alterações:

• US$ 300 por mês;
• US$ 700 por três meses;
• US$ 1.000 por seis meses.

Em março de 2025, o Stealc recebeu uma grande atualização arquitetural com a versão 2, introduzindo mudanças significativas no protocolo de rede e na estrutura de configuração. Desde então, essa versão passou a dominar nossa telemetria. Em junho de 2026, ela havia alcançado a versão 2.22.1, conforme apresentado na Figura 11.

Além de seus principais alvos, o Stealc inclui um coletor de arquivos (file grabber) configurável, que permite aos afiliados definir padrões personalizados para identificar arquivos que devem ser exfiltrados de máquinas comprometidas. Suas comunicações C&C e cadeias de texto incorporadas são protegidas por criptografia RC4 com chaves específicas para cada compilação.

O Stealc não depende de um único método padronizado de distribuição. Cada afiliado é responsável por seus próprios mecanismos de disseminação. No entanto, de forma semelhante ao Amadey, nossa telemetria indica que alguns vetores se destacam de maneira consistente, especialmente instaladores de software trojanizados e loaders de malware já estabelecidos, como o Amadey.

Visão geral técnica

Uma análise técnica detalhada do Stealc v2 já foi publicada pela Lumma-Labs. Nesta seção, focamos nas características que podem ser utilizadas para o agrupamento de atividades.

As versões atuais do Stealc incorporam duas chaves RC4 distintas por amostra:

• Uma para descriptografar cadeias de texto ofuscadas durante a execução;
• Uma segunda para criptografar as comunicações de rede C&C.

Além das duas chaves RC4, também extraímos o identificador de compilação (build identifier) das amostras do Stealc. Esse valor representa uma campanha individual do Stealc e, diferentemente de outras cadeias de texto, não é protegido no binário.

Esse valor é importante porque é transmitido como parte do processo inicial de comunicação com o servidor C&C (veja a Figura 12).

O endereço do servidor C&C e o caminho da URL utilizados nas comunicações são armazenados entre as cadeias criptografadas com RC4 e foram extraídos como parte do nosso processo automatizado de desempacotamento da configuração.

Comunicações C&C

O Stealc se comunica com seu servidor C&C por meio de HTTP utilizando objetos JSON criptografados com RC4.

A requisição inicial enviada ao servidor C&C contém três valores:

• Um identificador de compilação (build);
• Uma impressão digital da máquina comprometida (hwid));
• O tipo de requisição (essa requisição inicial utiliza o tipo create).

A impressão digital da máquina é derivada do número de série do volume do sistema e formatada como uma sequência UUIDv4. Um exemplo de objeto JSON dessa requisição inicial é apresentado na Figura 12.

O servidor C&C responde com um objeto JSON complexo que define quais funcionalidades o Stealc deve executar. Junto a essa resposta, é enviado um valor access_token gerado aleatoriamente, que funciona como uma chave de sessão e precisa ser utilizado em todas as requisições posteriores. Caso contrário, elas são rejeitadas pelo servidor. Além das definições detalhadas dos alvos, o objeto JSON também determina se o malware deve capturar uma tela, realizar autodestruição após a conclusão das atividades ou baixar e executar uma carga adicional posteriormente. Um exemplo do objeto JSON de resposta é apresentado na Figura 13.

Cada resposta do servidor também contém, logo no início, um par de chave-valor gerado aleatoriamente. Nenhuma das duas sequências hexadecimais é reutilizada em comunicações C&C posteriores. De acordo com uma pesquisa da Zscaler, esse mecanismo impede a criação de assinaturas de detecção estáticas para o tráfego criptografado com RC4, mesmo quando a mesma chave de criptografia é utilizada repetidamente. Na Figura 13, o nonce gerado aleatoriamente é: "bf66e52": "03030ac3e9a8cebf".

Após o registro inicial, o Stealc utiliza três tipos adicionais de operação, com nomes autoexplicativos, para executar suas funcionalidades:

• upload_file: exfiltrar os dados coletados;
• loader: obter e executar uma carga maliciosa adicional;
• done: sinalizar a conclusão da operação.

Agrupamento (Clustering)

Como mencionado, diferentemente do Lumma Stealer, os operadores do Stealc não oferecem infraestrutura compartilhada aos seus afiliados. De forma semelhante à nossa abordagem de agrupamento para o Amadey, aplicamos modelagem em grafos aos valores extraídos das configurações do Stealc, combinada com nosso entendimento sobre sua finalidade, para compreender melhor a estrutura do ecossistema do Stealc. O resultado foi um grafo que mostra que o Stealc é, de fato, fragmentado em muitos grupos pequenos (veja a Figura 14). Cada grupo está centralizado em torno de um pequeno número de servidores C&C, frequentemente apenas um, e normalmente associado a poucos identificadores de compilação (build IDs) ou caminhos de URL C&C. Desarticular esse tipo de infraestrutura é, portanto, uma tarefa desafiadora devido à ausência de um ponto fraco. No total, identificamos 73 grupos distintos (veja a Figura 14) operando o Stealc desde março de 2025.

Conclusão

Para operações globais de desarticulação, como a Operação Endgame contra o Amadey e o Stealc, é necessário realizar o rastreamento automatizado de longo prazo de malwares. Este artigo apresenta informações coletadas dessa forma, mas também fornece detalhes sobre o modelo de negócio específico de malware como serviço (MaaS) por trás de cada família e como isso se traduz em infraestruturas de rede frequentemente fragmentadas. Além disso, documenta seus principais identificadores estáticos e protocolos de comunicação C&C, e descreve como a equipe de pesquisa da ESET ajudou a identificar pontos críticos para a operação de desarticulação. A inteligência sobre ameaças da ESET relacionada ao Amadey e ao Stealc, combinada com os dados compartilhados por nossos parceiros, forneceu uma base sólida tanto para a operação de desarticulação quanto para os esforços das autoridades responsáveis pela aplicação da lei.

A Operação Endgame teve como objetivo apreender ou tornar inoperantes todos os servidores C&C conhecidos do Amadey e do Stealc, interrompendo diretamente a infraestrutura utilizada pelos afiliados de ambas as ofertas de MaaS. A ESET continuará monitorando ambas as famílias e acompanhando quaisquer tentativas de reconstrução da infraestrutura operacional após essa operação.

Indicadores de Comprometimento (IoCs)

Uma lista completa de indicadores de comprometimento (IoCs) e amostras pode ser encontrada em nosso repositório no GitHub.

Arquivos

Rede

Técnicas do MITRE ATT&CK

Esta tabela foi criada utilizando a versão 19 da estrutura MITRE ATT&CK.