Provedores falsos do Terraform distribuem malware em Go e ameaçam credenciais de produção
Pesquisadores de segurança identificaram uma campanha que usa provedores maliciosos do Terraform e módulos Go para instalar um programa capaz de coletar informações de máquinas e receber comandos remotamente. A estratégia chama atenção por explorar ferramentas comuns no desenvolvimento e, segundo os pesquisadores, representa o primeiro caso documentado de uso do registro da HashiCorp para distribuir código malicioso.
Entre os pacotes identificados estão os provedores `gocommunity-io/dockerd`, que somava 222 downloads, e `kreuzwenker/docker`, com 1.449. Também foram encontrados os módulos Go `gocommunity.io/orderedbtree` e `gogets.dev/btreex`. Os nomes e a aparência desses componentes imitam projetos legítimos, o que pode dificultar a identificação de um pacote suspeito durante a configuração de um ambiente.
A distribuição do malware não começa necessariamente nos registros de pacotes. Os operadores atraem desenvolvedores com ofertas e oportunidades de trabalho associadas a empresas Web3 fictícias. Depois, encaminham projetos que parecem inofensivos, mas cuja execução pode acionar dependências maliciosas de npm ou PyPI. Assim, um repositório aparentemente confiável funciona como porta de entrada para componentes nocivos.
Após ser executado, o programa, escrito em Go, coleta dados da máquina infectada. Entre as informações reunidas estão atributos de hardware, detalhes do sistema operacional, nome do host e disponibilidade do dispositivo. Esses dados são enviados à infraestrutura dos operadores, que pode então manter contato com o sistema comprometido.
A comunicação de comando e controle utiliza dois caminhos distintos. Um deles consulta um canal do Slack a cada dez segundos e procura mensagens que iniciam, alimentam ou encerram transferências de arquivos. O outro verifica, a cada três segundos, contratos implantados na testnet Sepolia do Ethereum em busca de instruções cifradas. Os comandos recebidos podem ser executados como código Go ou JavaScript.
Para separar as comunicações de cada vítima, o malware cria um par de chaves temporário em cada cliente e o combina com a chave pública controlada pelo operador. Com esse mecanismo, uma máquina infectada não consegue decifrar mensagens destinadas a outra. O uso de diferentes canais e de criptografia torna a operação mais difícil de detectar e acompanhar.
Os pesquisadores relacionam o código à campanha Graphalgo, documentada pela ReversingLabs em fevereiro de 2026 e atribuída, em abril do mesmo ano, a atores norte-coreanos. A associação indica que o malware identificado pode fazer parte de uma operação mais ampla, embora a semelhança de código, por si só, não permita concluir que todos os incidentes tenham a mesma origem.
Para reduzir o risco, equipes de desenvolvimento devem conferir com atenção o nome, o mantenedor e o histórico de cada provedor ou módulo antes de incluí-lo em um projeto. Pacotes com grafia muito parecida com a de ferramentas conhecidas merecem verificação adicional. Downloads, popularidade e descrição não são provas suficientes de legitimidade: componentes recém-publicados ou imitações podem parecer confiáveis à primeira vista.
Também é importante revisar os arquivos de configuração e os mecanismos de instalação. Dependências indiretas podem introduzir código que não aparece de forma evidente no projeto principal. A análise em um ambiente isolado, sem acesso a credenciais reais e com tráfego de rede monitorado, ajuda a observar comportamentos inesperados antes que o software seja usado em máquinas de trabalho.
Em ambientes automatizados, como pipelines de integração e entrega contínuas, convém limitar permissões e evitar que tarefas de instalação tenham acesso irrestrito a segredos. Tokens, chaves de nuvem e credenciais de produção devem ser disponibilizados apenas quando necessários e com escopo reduzido. Assim, mesmo que um componente malicioso seja executado, a exposição potencial pode ser menor.
Se houver suspeita de comprometimento, a resposta deve incluir a interrupção do uso do pacote, a análise dos registros de execução e de rede e a troca das credenciais que estavam acessíveis à máquina afetada. Como o malware pode receber comandos e transferir arquivos, a investigação também deve avaliar se houve extração de dados ou instalação de outros componentes.
O caso evidencia que a cadeia de suprimentos de software pode ser explorada antes mesmo de um pacote chegar ao registro oficial. A combinação de engenharia social, dependências aparentemente legítimas e comunicação por serviços conhecidos exige controles em várias etapas: verificar quem entrega o projeto, inspecionar o código e restringir os privilégios concedidos durante a execução.