Você encontra um pacote npm que resolve exatamente o problema que precisava. Instala, importa a dependência e testa.
Funciona. E caros leitores(a) esse é justamente o problema.
Pesquisadores da TrendAI, divisão de segurança corporativa da Trend Micro, descobriram 14 pacotes npm adulterados que se apresentavam como utilitários legítimos relacionados a calendário, datas e métricas. As bibliotecas realmente entregavam as funções prometidas.
Por baixo delas, porém, existia algo bem menos amigável: um implante Linux associado ao RedC2 4.0, uma estrutura de comando e controle com recursos para pós exploração. A descoberta foi reportada nesta semana e também documentada pelo The Hacker News.
O caso chama atenção não apenas pela presença de inteligência artificial no RedC2, mas pela forma escolhida para distribuir o malware.
O desenvolvedor nem precisava chamar uma função suspeita. Bastava importar o pacote.
O pacote funcionava. E isso tornava tudo mais convincente
Uma das características interessantes da campanha é que os pacotes npm maliciosos não eram simplesmente arquivos quebrados usando nomes atraentes para enganar desenvolvedores.
Eles funcionavam como utilitários. Enquanto o código aparentemente legítimo cuidava das funções relacionadas a datas e cálculos, arquivos com nomes como math-core.bin, math-calc.bin, calc.bin e calc-cache.bin escondiam o componente malicioso.
Esses arquivos eram apresentados como componentes nativos relacionados aos cálculos do pacote.
Na realidade, continham o RedShell, beacon Linux utilizado pelo RedC2 4.0.
É uma diferença importante. Uma biblioteca completamente falsa pode levantar suspeitas rapidamente. Uma biblioteca que entrega exatamente aquilo que promete tem muito mais chances de continuar sendo utilizada.
A embalagem funciona já o presente entregue é que não estava no anúncio.
Bastava importar a dependência para executar o malware
A parte mais preocupante está no mecanismo de execução.
Segundo a análise dos pesquisadores, o arquivo de entrada dist/index.mjs atuava como loader. Quando o módulo era carregado, ele localizava o binário escondido, concedia permissão de execução e iniciava o processo em segundo plano.
Não era necessário executar manualmente uma função maliciosa.
Também não dependia de um tradicional script de instalação para iniciar a cadeia.
Um simples import dentro da árvore de dependências poderia ser suficiente, inclusive quando o pacote aparecesse como dependência transitiva.
Na prática, isso significa que o desenvolvedor poderia não ter escolhido conscientemente aquela biblioteca. Ela poderia chegar através de outra dependência utilizada pelo projeto.
É aí que um problema aparentemente pequeno no npm começa a ganhar dimensões bem maiores.
O que o RedC2 4.0 consegue fazer no Linux
Depois da execução, o RedShell estabelece comunicação com a infraestrutura de comando e controle e registra o equipamento infectado enviando informações básicas sobre o sistema.
A partir daí, entra em um ciclo aguardando instruções do operador.
No Linux, o backdoor oferece acesso interativo por /bin/sh e possui recursos para reconhecimento do sistema, manipulação de arquivos, coleta de dados, persistência e execução de código.
Entre os dados que podem ser procurados estão chaves SSH e credenciais armazenadas em navegadores.
O framework também possui recursos para proxy SOCKS5, movimentação pela rede, transferência de arquivos e execução de ELF diretamente na memória.
Não estamos falando, portanto, de um pacote npm fazendo alguma telemetria indesejada.
Estamos falando de uma porta para atividades posteriores dentro da máquina comprometida.
RedC2 não nasceu ontem
O RedC2 4.0 é apresentado como uma ferramenta multiplataforma compatível com Windows, Linux e macOS.
Segundo a pesquisa, versões anteriores já vinham sendo comercializadas desde 2025. A versão 3.0 apareceu no início de 2026 e a versão 4.0 foi anunciada em junho, trazendo o beacon RedShell para Linux.
O framework oferece recursos de terminal remoto, transferência de arquivos, coleta de informações, entrega de outros payloads, operação de múltiplos beacons, tunelamento entre hosts e execução de componentes diretamente na memória.
A versão para Windows possui ainda capacidades relacionadas a evasão, interferência em mecanismos de segurança, movimentação lateral e contorno de controles do sistema.
Curiosamente, o site público associado à ferramenta afirma que seu uso deve ocorrer apenas em atividades autorizadas de segurança ofensiva e proíbe invasões sem autorização.
O software pode até ter termos de serviço. O malware distribuído pelo npm aparentemente não ficou muito impressionado com eles.
E onde entra a inteligência artificial?
Aqui está a parte que diferencia o RedC2 de muitos outros frameworks de comando e controle.
O RedC2 possui um componente chamado Red Agent, que utiliza um modelo de linguagem para transformar instruções em linguagem natural em comandos que os beacons conseguem executar.
Em vez de o operador conhecer cada comando necessário para realizar determinadas ações, ele pode descrever sua intenção e deixar essa camada traduzir o pedido para operações suportadas pelo framework.
Isso pode ser usado para tarefas de pós exploração como reconhecimento de rede e coleta de credenciais.
A inteligência artificial, portanto, não é o componente que infecta a máquina e também não transforma o RedC2 magicamente em um atacante autônomo.
Ela funciona como uma camada de abstração entre o operador e as capacidades ofensivas da ferramenta. Bom e isso talvez seja mais relevante do que parece.
IA pode diminuir a barreira técnica para operar ferramentas ofensivas
Ferramentas ofensivas sofisticadas tradicionalmente exigem algum conhecimento sobre sistemas operacionais, redes, persistência e movimentação dentro de ambientes comprometidos.
Uma interface baseada em linguagem natural pode reduzir parte dessa complexidade operacional.
O operador descreve o objetivo. O modelo traduz a intenção em uma sequência de ações compreendida pelo framework.
Segundo os pesquisadores, isso permite que operadores com diferentes níveis de conhecimento consigam executar operações mais complexas.
Não significa que qualquer pessoa digitando “invada essa empresa” automaticamente se transforma em especialista.
Mas significa que algumas barreiras entre intenção e execução começam a diminuir.
E essa tendência merece mais atenção do que simplesmente colocar “malware com IA” no título e imaginar um robô hacker trabalhando sozinho.
O verdadeiro problema começa antes da IA
Apesar do Red Agent chamar atenção, existe uma parte dessa história que considero ainda mais importante. Que certamente é a cadeia de suprimentos.
Um desenvolvedor confia em dezenas ou centenas de dependências para construir uma aplicação moderna. Essas dependências confiam em outras dependências. E algumas delas podem executar código durante instalação, compilação ou carregamento.
Nesse caso, um pacote aparentemente banal relacionado a datas era suficiente para introduzir um backdoor Linux.
A própria TrendAI destacou recentemente que a cadeia de suprimentos de software e os ambientes de desenvolvimento continuam entre as superfícies que defensores precisam tratar como prioritárias. Em seu relatório sobre atividades APT no primeiro semestre de 2026, a empresa recomenda verificar e controlar dependências justamente porque uma única dependência comprometida pode alcançar múltiplas vítimas. E esse não foi um episódio isolado.
O npm não é o único ecossistema enfrentando esse problema
A descoberta ocorreu próxima de outro ataque contra a cadeia de suprimentos, desta vez envolvendo três crates legítimos do ecossistema Rust.
Versões comprometidas teriam recebido uma dependência maliciosa capaz de executar código durante builds do Cargo. O malware associado realizava reconhecimento do dispositivo, procurava navegadores baseados em Chromium, estabelecia persistência e se comunicava com infraestrutura controlada pelos atacantes para receber novas tarefas.
Isso reforça uma mudança importante de perspectiva. A dependência de software não é apenas uma conveniência de desenvolvimento.
Ela também faz parte da superfície de ataque. Quanto maior a árvore, mais importante se torna saber o que realmente entrou nela.
Os 14 pacotes npm identificados
Os pesquisadores relacionaram a campanha aos pacotes streak-metrics-math, kit-map-vim, streak-map-cache, streak-map-kit, map-streak-kit, streak-cache-map, streak-calc-metrics, streak-calc-math, streak-math-abz, streak-metricsaz, streak-math-metrics, streak-metricazbd, streak-metricsazb e streak-kit-map.
No caso de streak-metrics-math, foram identificadas as versões 1.0.0 e 1.0.1. Nos demais pacotes reportados, a versão identificada foi 1.0.0.
Organizações que tenham utilizado esses componentes precisam tratar a situação como possível comprometimento, e não simplesmente remover o pacote e considerar o assunto encerrado.
A execução do implante significa que a investigação deve considerar o que aconteceu no sistema depois do carregamento da dependência.
O pacote mais perigoso pode ser justamente aquele que funciona
Existe uma lição particularmente desconfortável nessa campanha.
Durante anos, uma recomendação comum foi desconfiar de pacotes estranhos, mal documentados ou que simplesmente não funcionam. Isso continua válido. Mas não é suficiente.
Os pacotes desta campanha entregavam a funcionalidade prometida enquanto executavam uma segunda função escondida.
Agora adicione uma ferramenta de comando e controle capaz de operar em Linux, Windows e macOS e uma camada de IA que transforma linguagem natural em ações ofensivas.
Temos então três tendências se encontrando no mesmo incidente: ataques à cadeia de suprimentos, ferramentas ofensivas multiplataforma e inteligência artificial diminuindo a complexidade de determinadas operações.
A parte mais preocupante, porém, continua sendo extremamente humana. Nós confiamos no pacote porque ele funciona. E às vezes é exatamente isso que o atacante espera.
