Campanha de malware em Go é distribuído por módulos Go e fornecedores de Terraform

Pesquisadores de segurança descobriram uma campanha que distribui um malware escrito em Go através de módulos de Go e, pela primeira vez documentada publicamente, mediante fornecedores publicados no registro de Terraform de HashiCorp. O que está confirmado por análise técnica de diferentes equipamentos (Aikido, JFrog, SafeDep e outros) é que pacotes legítimos foram troceados ou publicados com dependências maliciosas que, ao se incorporar em projetos, implantam um binário em Go que compartilha infraestrutura de comando e controle com versões prévias observadas em npm e PyPI.

A amostra foi encontrada em pelo menos dois módulos de Go e dois fornecedores de Terraform, que permitem aos atacantes chegar tanto a desenvolvedores como a ambientes de infraestrutura, e a amostra reutiliza mecanismos sofisticados: dois canais de C2 simultâneos (um baseado em uma cadeia de blocos de testenet e outro sobre a API do Slack), criptografia assimétrica para proteger o payload e controles de execução que só ativam a carga útil em condições concretas. O registo de fornecedores de HashiCorp pode ser consultado aqui: https://registry.terraform.io/.

Como funciona tecnicamente (confirmado pela análise): ao executar, o malware coleta informações do sistema (hardware, SO, hostname, disponibilidade de nó) e envia-a para um canal controlado pelo atacante no Slack usando a API (a técnica aproveita chamadas repetidas ao endpoint conversations.history): https://api.slack.com/methods/conversations.history. Depois gera uma chave efímera e combina essa chave com duas chaves públicas dos atacantes para derivar chaves compartilhadas que protegem a comunicação entre cliente e operador. Paralelamente, o agente consulta a cada poucos segundos um contrato inteligente na rede de testes Ethereum (Arbitrum Sepolia, segundo os relatórios) procurando comandos criptografados que possam decifrar e executar como código Go ou JavaScript. A consulta ao testenet pode ser verificada a partir de exploradores como o de Sepolia: https://sepolia.etherscan.io/.

Características que complicam a análise: Parte do payload está cifrada com chave assimétrica e só é decifrada sob condições específicas (por exemplo, a resolução de um sistema linear concreto ou a realização de uma operação criptográfica determinada), sugerindo design para operações direcionadas ou para dificultar os pesquisadores que encontram a parte frontal sem os elementos contextuais que ativam a carga útil. Os relatórios indicam ainda que os atacantes usam mecanismos para inflacionar contadores de downloads através de workers do GitHub Actions, buscando aparência de legitimidade.

Os vetores de entrada documentados incluem técnicas de engenharia social: ofertas de trabalho falsas, entrevistas remotas e tarefas de programação que obrigam a vítima a incluir uma dependência que introduz a porta traseira. Equipamentos de segurança observaram a mesma tática aplicada a repositórios e pacotes em npm, PyPI e agora Terraform/Go, o que mostra um padrão de reuso da cadeia de fornecimento do software.

Quem afeta e por que importa: desenvolvedores que incorporam dependências de terceiros sem auditoria suficiente, equipamentos que usam fornecedores de Terraform de terceiros e organizações com runners de CI/CD (GitHub Actions, etc.) são os mais expostos. Um fornecedor de Terraform malicioso tem potencial para alcançar segredos de produção (por exemplo, estados, credenciais e fornecedores cloud) de forma mais direta do que uma livraria de usuário final, pelo que o surgimento de fornecedores manipulados aumenta o risco operacional.

Impactos reais plausível (confirmados vs. estimados): confirmado: exfiltração de inventário do sistema e estabelecimento de canais de C2 duales; estimado: execução de módulos entregues dinâmicamente pelos operadores (os pesquisadores recuperaram o implant mas nem sempre o código posterior, pelo que as ações finais que executaram os atacantes em máquinas comprometidas ainda são incertas). A combinação de um dead drop em blockchain e uma segunda canalização pelo Slack reduz o risco para o operador, porque as ordens podem ser cifradas de forma que apenas certos clientes as interpretem, limitando também a capacidade de interferência de terceiros.

Vários equipamentos destacaram coincidências com campanhas atribuídas a atores vinculados à RPDC, como Graphalgo ou PolinRider. Isto é uma atribuição sugerida por analistas externos(ReversingLabs, Aikido e outros a mencionaram) mas, como sempre em relatórios de ciberameaças, a atribuição técnica não é uma certificação absoluta e deve ser tratada com cautela até que se reúnam mais evidências operacionais públicas e verificáveis.

O que o leitor deve fazer agora (medidas concretas e imediatas): Audite e reduza a superfície de dependência e de CI de forma pragmática: 1) Em projetos críticos, evite aceitar mudanças de dependências sem revisão humana: faça SCA (software composition analysis) e compare assinaturas e hashes; 2) Revoque e rote tokens e credenciais que possam ter sido expostos em repositórios ou actions, e limite o alcance dos runners de CI; 3) Active MFA e preferencialmente chaves de segurança em contas de manutenção e repositórios; 4) Bloqueie ou monitorize conexões invulgares salientes a partir de build runners e ambientes de execução para IPs e domínios suspeitos (por exemplo, o IP citado em algumas análises), e limite o acesso a APIs como o Slack para bots não verificados; 5) Audite e restrinja fornecedores de Terraform: trate os providers externos como código de infraestrutura crítica e aplique revisão de terceiros antes de seu uso; 6) Implemente políticas SLSA/firmado de artefatos e exigência de builds reprodutíveis para evitar que Actions ou credenciais comprometidas injetem artefatos maliciosos.

Além disso, os mantenedores de pacotes devem rever o histórico de acessos às suas contas, verificar se houve commits não autorizados, e rodar qualquer credencial com acesso a vários repositórios. Os equipamentos de segurança devem implantar detecção de anomalias (assinais de comportamento, egress inesperados, acessos a APIs de mensagens e chamadas a testesnets com padrões de polling frequentes) e preparar playbooks para desligar canais de C2 (revocar tokens, bloquear contratos ou endereços envolvidos em comunicações maliciosas).

Informações ainda incertas ou pendentes de confirmação: As funções exactas das cargas úteis subsequentes ao implant recuperado não foram completamente recuperadas pelos pesquisadores - cifradas e só são decifradas em contexto - e a relação definitiva entre todas as campanhas mencionadas e uma atribuição geopolítica firme continua a ser matéria de análise. Também é incerto até que escala operam os atacantes com fornecedores de Terraform: os achados atuais mostram casos concretos, mas não há ainda evidência pública de abuso maciço e sustentado em larga escala.

Este episódio reforça uma lição chave: a cadeia de fornecimento do software já não é apenas um código de livraria; inclui fornecedores de infra-estruturas, runners da CI e contas de manutenção. A mitigação efetiva exige controles técnicos, higiene de contas e vigilância contínua sobre dependências e artefatos de infraestrutura.