CanisterWorm um verme autodesplegável que redefine a segurança de npm com canisters da Internet Computer

Nos últimos dias, a comunidade de desenvolvedores recebeu um alerta sério: uma cadeia de compromisso iniciada no popular scanner Trivy parece ter derivado em uma onda de pacotes npm manipulados que albergam um verme autorreplicante nunca antes documentado, batizado pelos pesquisadores como CanisterWorm. Longe de ser uma infecção clássica, este ataque combina técnicas tradicionais de malware com uma peça inovadora: o uso de um canister da rede de blocos Internet Computer (ICP) como um "dead drop" descentralizado para gerenciar o comando e controle.

De acordo com a análise publicada pela equipe de pesquisa da Aikido Security, a intrusão inicial aproveitou credenciais comprometidas para publicar versões maliciosas de projetos relacionados a Trivy (entre eles trivy, trivy-action e setup-trivy) que continham um credential stealer. A partir daí os atacantes, atribuídos de forma provisória à operação conhecida como TeamPCP por assinaturas de inteligência como Cyble, começaram a propagar código capaz de instalar um backdoor em Python, estabelecer persistência e contactar periodicamente o canister de ICP para baixar a próxima etapa do ataque.

A mecânica técnica é inquietante por sua robustez: durante a instalação o pacote malicioso executa um hook de pós-install que lança um carregador. Este carregador deixa um backdoor em Python que, além de se manter ativo graças a um serviço de systemd configurado com Restart=always, consulta a cada 50 minutos ao canister de ICP usando um User-Agent falsificado. O canister responde com um URL em texto plano que aponta para o binário para baixar e executar. O controle através do canister é especialmente problemático porque, ao ser infraestrutura descentralizada, é resistente às ações de mitigação clássicas: o controlador do canister pode mudar o URL para colocar novas cargas sem voltar a tocar os equipamentos infectados.

Os pesquisadores também notaram um “interruptor” curioso usado pelos atacantes: se o URL que devolve o canister contém YouTube[.]com, o dropper ignora e não descarrega nada, funcionando bem como estado de latência. Nos momentos que a análise foi relatada, a URL ativa era um vídeo de brincadeira (um típico “rickroll”), mas o canister conta com métodos que permitem atualizar a ligação e servir um binário real em qualquer momento. O tabuleiro público do canister e os métodos expostos por ele (como get_latest_link e update_link) foram verificados pelos analistas e confirmam a capacidade de modificar o comportamento sobre a marcha.

A dimensão da contaminação do ecossistema npm é significativa: foram detectadas dezenas de pacotes afetados, incluindo 28 pacotes sob o escore @EmilGroup e 16 baixo @ opengov, além de nomes concretos como @teale.io/eslint- config, @airtm/uuid-base32 e @pypestream/floating-ui-dom. Em uma primeira versão da campanha, o atacante usava uma ferramenta chamada "deploy.js" executada manualmente com tokens npm roubados para publicar versões comprometidas de múltiplos pacotes e ampliar seu raio de impacto. Esta variante já era perigosa: um operador com tokens válidos pode, programáticamente e em grande escala, publicar pacotes infectados e comprometer a cadeia de fornecimento de projetos que dependem deles.

O que aumenta ainda mais a gravidade do incidente é que se observou uma evolução do verme para um comportamento completamente autônomo. Em versões maliciosas recentes (por exemplo, em @teale.io/eslint- config v1.8.11 e v1.8.12) a lógica de propagação foi incorporada diretamente em index.js. Ali existe uma função que busca tokens npm no ambiente do desenvolvedor durante o pós-install e lança a própria rotina de implantação em segundo plano, transformando assim a infecção em um verdadeiro worm que já não requer a execução manual do atacante para escalar: qualquer máquina de desenvolvimento ou canal CI que instale o pacote e tenha um token acessível pode se tornar um novo vetor de publicação para mais pacotes infectados.

Os detalhes de persistência e camuflagem são práticos e pouco sofisticados ao mesmo tempo: o serviço de systemd é feito passar por uma ferramenta de PostgreSQL chamada "pgmon" para evitar levantar suspeitas, e o backdoor não mata processos antigos quando adota um novo URL, o que significa que versões anteriores permanecem em execução. Aikido também relata que o autor provou o fluxo de propagação com uma cadeia de teste ("hello123") antes de colocar um binário real, estratégia habitual para garantir que toda a cadeia de infecção funciona antes de ativar a carga maliciosa real.

Diante desta ameaça, a resposta para desenvolvedores e equipes de segurança deve ser rápida e multifacetada. É imprescindível revogar e rotar tokens npm comprometidos imediatamente e revisar as integrações dos pipelines de CI para garantir que não armazenam tokens com permissões desnecessárias. As contas e credenciais usadas para publicar pacotes devem ser submetidas a uma auditoria, e convém inspeccionar os ambientes de desenvolvimento e runners por sinais de persistência: serviços de systemd com nomes suspeitos no espaço de usuário, arquivos como deploy.js, index.js com lógica de captura de tokens, e processos Python que realizam conexões periódicas a domínios ou endpoints incomuns. Para entender e mitigar o risco de tokens em npm, a documentação oficial sobre tokens pode servir de guia, por exemplo a página de Tokens do npm.

Convém também recordar que este ataque combina elementos de comunicação remota com infra-estruturas pouco convencionais; por isso é útil conhecer o conceito de "dead drop resolver" no âmbito do MITRE ATT&CK ( T1102.001) e como os canisters da Internet Computer estão sendo utilizados aqui como esse tipo de canal resistente à tomada abaixo. A própria documentação dos canisters ajuda a compreender por que seu tamper-proof e descentralização os tornam atraentes para abusos deste tipo: documentação do ICP.

Para equipamentos de resposta e infra-estruturas críticas, medidas práticas incluem bloquear versões afectadas ao nível de registro ou feed interno, purgar dependências comprometidas dos caches e lockfiles, auditar cadeias de fornecimento com ferramentas de análise de dependências e aplicar políticas que minimizem a exposição de credenciais em runners e imagens de build. GitHub e outros fornecedores têm guias sobre como proteger tokens e segredos em pipelines; revisar e aplicar boas práticas de gestão de segredos é chave para limitar a blast radius deste tipo de ataques ( Guia do GitHub sobre tokens e segredos).

A campanha CanisterWorm mostra várias tendências preocupantes: a sofisticação crescente das operações criminosas na cadeia de fornecimento do software, a reutilização de infra-estruturas descentralizadas para tornar mais resiliente o controle remoto do malware, e a facilidade com que os tokens e o acesso de publicação podem transformar uma conta comprometida em um multiplicador de danos. Análises públicas — como o relatório técnico da Aikido Security que documenta estes achados — são recursos valiosos para compreender a telemetria e os indicadores de compromisso e podem ser consultados para obter informações técnicas detalhadas ( Aikido).

Estamos perante um desenvolvimento ativo: as defesas devem mover-se rapidamente para neutralizar publicações maliciosas, retirar pacotes infectados do registro público e cortar o acesso dos atacantes. Entretanto, a comunidade de desenvolvedores deve assumir que qualquer pacote comprometido pode ser uma porta de entrada para uma propagação automática e agir em conformidade: auditar dependências, rotar credenciais expostas e endurecer pipelines. A combinação de vigilância, rotação de credenciais e políticas de menor privilégio continua a ser a melhor defesa contra este tipo de ameaças que se aproveitam da confiança inerente no ecossistema open source.