A atribuição como armadilha: um ataque a npm e a fragilidade da cadeia de fornecimento de software

A recente reelaboração da autoria do sequestro de pacotes npm – que agora a Amazon Threat Intelligence associa com a Coreia do Norte – volta a colocar sobre a mesa uma lição conhecida, mas insuficientemente resolvida: as atribuições tardias e fragmentadas complicam a defesa e a remediação na cadeia de fornecimento de software.

Em setembro de 2025 foi detectado um ataque que comprometeu pacotes muito populares como debug e chalk, e que se mostrou ao público inicialmente como fraude criptográfica: um mantenedor foi vítima de um phishing em um domínio que imitava npm e uma atualização maliciosa incluía código para reescrever endereços de carteiras no navegador. Desde então foram identificadas outras peças potencialmente relacionadas — como uma implantação em axios em março de 2026 e um pequeno pacote chamado typo-crypto em março de 2025 — e a Amazon argumenta que as três campanhas compartilham grupo autoral e padrão táctico. No entanto, a evidência que a Amazon publica é parcial: descreve coincidências no tradecraft, reutilização de código, ganchos pós-instalação e alguns indicadores de comando e controle, mas não traça publicamente uma cadeia clara que vincule cada incidente com esses mesmos indicadores.

Esse vazio importa. Para debug e chalk documentou-se código que operava exclusivamente no lado do navegador, interceptando fetch, XMLHttpRequest e APIs de carteiras para reescrever endereços antes de assinar transações; esse código não persistiu em disco e não dependia de hooks post-install como sim o payload de axios. Em typo-crypto, o comportamento observado — um trigger em espera e um segundo estádio baixado de um C2 — sugere um teste de conceito pequeno com poucos downloads, não uma campanha massiva desde o primeiro dia. Além disso, no caso de typo-crypto há inconsistências nos metadados do registro: uma única versão publicada imediatamente por uma conta que não coincide com o autor declarado e arquivos que aparentam impessoar a livrarias legítimas, o que coloca a possibilidade de que fosse publicada maliciosamente desde o início, não filhackeada mediante atualização. A Amazon também traz hashes e nomes de arquivo que, segundo a análise pública, não emparelham exatamente com o conteúdo disponível no tarball do registro, o que torna ainda mais difícil verificar publicamente a relação entre os artefatos descritos e os pacotes apontados.

A atribuição técnica e a atribuição política não são o mesmo. Enquanto o Google e a Microsoft atribuíram rapidamente o compromisso de axios a atores que suas assinaturas rastreiam como UNC1069 / WAVESHAPER e Sapphire Sleet (com a terminologia variando entre fornecedores), a Amazon estende essa leitura a campanhas mais antigas e menos claras. A diferença em tempos — atribuções quase imediatas para axios frente a reatribuções aos dez ou dezesseis meses para debug, chalk e typo-crypto — ressalta por que as organizações devem exigir transparência na evidência e conservar telemetria para permitir reconstruções forenses posteriores.

Do lado defensivo, algumas medidas recentes de npm ajudam, mas não eliminam o risco de comprometer um pacote via engenharia social. A versão v12, lançada em julho, veio com os programas de ciclo de vida desativados por defeito, o que reduz a via de exploração baseada em post-install scripts que explodiu axios. Além disso, o npm começou a digitalizar novos pacotes no momento da publicação. São passos na direção certa, mas não fecham a porta a ataques que aproveitam a confiança do mantenedor, contas mal geridas, ou pacotes publicados maliciosamente a partir de zero.

Para desenvolvedores e equipamentos responsáveis por dependências, há recomendações imediatas e práticas que reduzem a exposição: usar arquivos de bloqueio e realizar instalações reprodutíveis com 'npm ci' em ambientes controlados; revisar cuidadosamente pacotes pequenos ou com poucos mantenedores antes de adicioná-los; aplicar autenticação multifator e rotação de tokens de publicação; minimizar privilégios das contas que publicam e fazê-lo desde CI com credenciais efímeras; auditar as dependências transitórias e não instalar pacotes em ambientes de usuário com menos restrições. A nível organizacional, convém gerar e manter SBOMs, integrar digitalizações automáticas na cadeia CI/CD, adotar mecanismos de assinatura de artefatos (por exemplo, projetos do ecossistema Sigstore) e aplicar controles de admissão que verifiquem integridade e procedência antes de incluir dependência em produção. Recursos que orientam essas práticas são úteis, por exemplo, a iniciativa SLSA ( https://slsa.dev) e a assessoria de agências como CISA sobre segurança da cadeia de fornecimento ( https://www.cisa.gov/supply-chain).

Para os operadores de registries e fornecedores de ecossistemas A lição é dupla: melhorar a detecção automatizada não basta; a usabilidade e as políticas devem empurrar os mantenedores para práticas seguras sem aumentar o atrito operacional desnecessário. Isso implica oferecer opções de publicação mais seguras desde a CI, visibilizar mudanças de propriedade de pacotes, detectar padrões anormais de publicação ou de coincidências entre metadados e objetos binários, e facilitar processos rápidos e transparentes para mitigar e retirar pacotes comprometidos quando houver evidência sólida.

Finalmente, o episódio sublinha uma realidade política: atribuir uma campanha a um Estado-nação tem consequências amplas que vão além do técnico. Requer um padrão de teste público e reprodutível quando a atribuição influenciará decisões políticas, sanções ou resposta internacional. Enquanto isso, aqueles que desenvolvem e desdobram software devem operar sob o pressuposto de que o risco existe e aplicar princípio de menor privilégio, defesa em profundidade e práticas de higiene na cadeia de fornecimento para limitar o impacto de incidentes que, por vezes, apenas se compreendem semanas, meses ou mesmo anos depois.