Amazon aponta Coreia do Norte como responsável por ataque aos pacotes npm debug e chalk em 2025
A Amazon passou a atribuir oficialmente à Coreia do Norte o sequestro dos populares pacotes npm debug e chalk, comprometidos em setembro de 2025. Segundo a equipe de inteligência da empresa, o ataque foi conduzido por um grupo de hackers vinculado ao regime norte-coreano, ampliando o entendimento de um incidente que, até então, era tratado majoritariamente como uma simples campanha de roubo de criptomoedas, sem autoria claramente definida.
Em um relatório divulgado em 29 de julho, a Amazon afirma, com “confiança moderada”, que o mesmo grupo envolvido no comprometimento do pacote axios, em março de 2026, também teria articulado o ataque contra debug e chalk. Essa conexão consolida a visão de que não se trata de episódios isolados, mas de uma campanha continuada e estrategicamente planejada contra a cadeia de suprimentos de software.
Como ocorreu o ataque aos pacotes debug e chalk
O ponto de partida do incidente teria sido um ataque de phishing direcionado a um mantenedor legítimo. Os criminosos registraram um domínio falso semelhante ao do npm e o usaram para enganar o responsável pelo pacote, obtendo acesso à conta e, em seguida, publicando versões maliciosas.
Essas versões comprometidas não se limitaram a um único projeto. De acordo com as investigações, pelo menos 18 pacotes foram afetados, somando juntos mais de 2 bilhões de downloads semanais. A escala do impacto potencial é enorme: qualquer aplicação que dependesse dessas bibliotecas poderia, em tese, ter sido usada como vetor para roubo de ativos digitais dos usuários finais.
Análises conduzidas por empresas de segurança como Aikido e Wiz apontaram que o código injetado tinha um foco bem definido: interceptar transações de carteiras de criptomoedas executadas diretamente em navegadores. O malware alterava silenciosamente os endereços de destino de transferências antes que o usuário confirmasse a operação, desviando fundos para carteiras controladas pelos atacantes.
Conexão com os ataques envolvendo axios e typo-crypto
O relatório da Amazon não se limita ao incidente com debug e chalk. A empresa também relaciona o caso a duas outras campanhas: o comprometimento do pacote axios, em março de 2026, e a publicação do pacote typo-crypto, em março de 2025.
Segundo a análise, o typo-crypto teria funcionado como um “campo de provas” para técnicas e ferramentas que mais tarde seriam usadas contra projetos muito mais conhecidos. Nessa visão, os criminosos primeiro experimentaram táticas em um pacote menos popular, ajustaram o código e, somente depois, partiram para bibliotecas amplamente utilizadas como debug, chalk e axios.
Um elemento comum às três campanhas, segundo a Amazon, é o uso intenso de engenharia social contra mantenedores confiáveis, seguido da publicação de versões adulteradas, porém aparentemente legítimas, em registros oficiais de pacotes. Ou seja, em vez de atacar diretamente usuários finais ou grandes empresas, o grupo mirou na base da cadeia de suprimentos: os responsáveis por manter bibliotecas críticas usadas por milhões de desenvolvedores.
Diferenças técnicas entre os ataques
Embora a Amazon considere que os mesmos agentes possam estar por trás das três campanhas, há diferenças importantes na forma como os ataques foram executados.
No caso do axios, a técnica principal explorava scripts disparados durante a instalação do pacote (especialmente scripts de post-install). Assim, o código malicioso era executado no ambiente do desenvolvedor ou do servidor assim que a dependência era instalada, abrindo possibilidades de comprometimento mais profundo do sistema, inclusive com estabelecimento de persistência.
Já no incidente envolvendo debug e chalk, a abordagem foi distinta. O malware foi desenhado para atuar diretamente no contexto do navegador, sem necessidade de manter persistência no sistema operacional. O código interceptava chamadas das APIs fetch, XMLHttpRequest e integrações com carteiras de criptomoedas, manipulando o tráfego e os dados em tempo real. Essa estratégia tornava o ataque mais furtivo e altamente focado em roubo de ativos digitais.
Evidências e limitações da atribuição
Apesar de apontar a Coreia do Norte como origem das campanhas, a Amazon não divulgou publicamente o conjunto completo de evidências que fundamentam essa conclusão. O relatório menciona semelhanças em técnicas empregadas, reutilização de trechos de código, indicadores de infraestrutura de comando e controle (C2) e padrões em pacotes trojanizados, mas não detalha quais artefatos sustentam cada associação específica.
Ainda assim, a atribuição ganha força porque converge com análises independentes de outras empresas. No caso do ataque ao axios, o Google associou a campanha ao grupo UNC1069, enquanto a Microsoft vinculou a operação ao Sapphire Sleet – também conhecido na indústria por diversos outros nomes: BlueNoroff, STARDUST CHOLLIMA, CryptoCore, Alluring Pisces e CageyChameleon. Esses grupos já são historicamente apontados como braços de operações cibernéticas ligadas ao governo norte-coreano, com forte foco em roubo financeiro para financiar o regime.
A Aikido, responsável por detectar a adulteração dos pacotes debug e chalk em 2025, afirma que a conexão com a Coreia do Norte já vinha sendo feita internamente e discutida em círculos técnicos especializados há algum tempo. Segundo a empresa, a relação entre os casos teria sido exposta em materiais técnicos, palestras e análises aprofundadas, e seria considerada bem estabelecida entre pesquisadores de segurança da cadeia de suprimentos.
A controvérsia em torno do pacote typo-crypto
Um ponto que suscita dúvidas nas conclusões da Amazon diz respeito ao pacote typo-crypto. O relatório afirma que todas as campanhas analisadas teriam começado pela mesma forma: o comprometimento de contas de mantenedores legítimos. Entretanto, os registros do npm mostram que o typo-crypto possuía apenas uma versão publicada, criada e disponibilizada em um intervalo de cerca de 204 milissegundos.
Esse intervalo extremamente curto sugere que o pacote pode ter sido concebido desde o início como um clone malicioso, com o objetivo de se passar pelo popular crypto-js, explorando erros de digitação ou confusão por parte dos desenvolvedores (o chamado typosquatting). Nesse cenário, não se trataria do sequestro de um projeto existente, mas da criação deliberada de um pacote fraudulento, o que contradiz parcialmente a tese de que todos os ataques teriam começado com o comprometimento de mantenedores estabelecidos.
Reação do ecossistema npm e novas defesas
Em paralelo ao debate sobre atribuição e origem dos ataques, o ecossistema npm começou a adotar medidas de mitigação para reduzir a superfície de ataque da cadeia de suprimentos. Em julho, a plataforma passou a desabilitar, por padrão, a execução de scripts durante o processo de instalação de dependências na versão 12 do gerenciador de pacotes. A intenção é dificultar que um simples npm install execute automaticamente código potencialmente malicioso sem supervisão.
Outra medida importante foi a introdução de análises automáticas sobre novos pacotes publicados, antes que eles sejam disponibilizados de maneira ampla aos usuários. Esses mecanismos de triagem visam detectar comportamentos suspeitos, padrões de malware conhecidos ou estruturas de código associadas a campanhas maliciosas.
Especialistas, no entanto, alertam que tais mudanças, embora bem-vindas, não são suficientes para eliminar o risco. Ataques baseados no sequestro de contas de mantenedores – obtidas por phishing, roubo de credenciais ou falhas em autenticação – continuam sendo um vetor extremamente crítico. Enquanto o ecossistema não adotar amplamente práticas de segurança fortes, como autenticação multifator obrigatória, revisão de permissões e segregação de funções, o comprometimento de perfis legítimos continuará sendo um dos caminhos mais eficazes para atacantes sofisticados.
Por que a cadeia de suprimentos de software virou alvo prioritário
O caso envolvendo debug, chalk, axios e typo-crypto ilustra uma transformação importante no cenário de ameaças: em vez de atacar apenas empresas individuais, criminosos e grupos estatais têm se concentrado na cadeia de suprimentos de software – isto é, nos componentes e bibliotecas que servem de base para milhares de aplicações.
Quando um pacote amplamente utilizado é comprometido, o atacante ganha um “atalho” para alcançar inúmeros ambientes ao mesmo tempo, sem precisar invadir cada alvo de maneira isolada. No contexto do JavaScript e do npm, em que projetos frequentemente contam com dezenas ou centenas de dependências, muitas delas atualizadas de forma automática ou sem auditoria minuciosa, o efeito dominó pode ser devastador.
Para grupos ligados a Estados-nação, como aqueles atribuídos à Coreia do Norte, esse modelo é especialmente atraente. Em uma única campanha bem-sucedida, é possível atingir usuários de criptomoedas, empresas de tecnologia, provedores de serviços financeiros e outros alvos de alto valor, ampliando o potencial de lucro ilícito e de espionagem.
Boas práticas para desenvolvedores e empresas
Diante desse cenário, a responsabilidade não recai apenas sobre plataformas como o npm ou grandes empresas de tecnologia. Desenvolvedores individuais, equipes de engenharia e organizações que dependem intensivamente de software de terceiros também precisam revisar seus processos.
Algumas medidas consideradas essenciais incluem:
– Habilitar autenticação multifator obrigatória em contas de mantenedores e repositórios críticos.
– Restringir quem pode publicar novas versões de pacotes e configurar fluxos de revisão de código antes da publicação.
– Evitar instalar dependências automaticamente sem revisão, especialmente em ambientes sensíveis ou de produção.
– Utilizar ferramentas de análise de dependências, detecção de malware em código e monitoramento de integridade de pacotes.
– Manter inventários claros de todas as bibliotecas utilizadas, suas versões e origens, facilitando respostas rápidas em caso de incidentes.
Empresas que mantêm bibliotecas populares precisam, ainda, investir em processos de segurança equivalentes aos de produtos finais: gestão de chaves, monitoramento de acessos suspeitos, rotação frequente de credenciais e testes regulares de engenharia social para treinar mantenedores.
Impacto para o futuro da segurança de software
O episódio envolvendo debug, chalk e axios deverá permanecer como um caso de referência na discussão sobre segurança da cadeia de suprimentos. Ele demonstra não apenas a capacidade técnica de grupos apoiados por Estados para explorar brechas em ecossistemas abertos, mas também evidencia a fragilidade de modelos baseados em confiança implícita entre desenvolvedores e repositórios públicos.
A tendência, nos próximos anos, é que ataques dessa natureza se tornem mais frequentes e sofisticados. Ao mesmo tempo, a indústria caminha em direção a práticas de “segurança por padrão”, como verificação de assinaturas de pacotes, restrição de scripts de instalação, certificação de mantenedores e detecção mais robusta de comportamentos anômalos.
Para o usuário final, a grande lição é que a confiabilidade de um software não depende apenas do nome da empresa que o distribui, mas de toda a cadeia de componentes que o compõe. E, enquanto atores como a Coreia do Norte continuarem a investir em operações de cibercrime e espionagem digital, a proteção dessa cadeia seguirá no centro das discussões de cibersegurança global.