Um grupo, múltiplos alvos: a conexão que ninguém havia feito antes
A Amazon divulgou uma pesquisa inédita revelando que vários comprometimentos recentes de pacotes populares do Gerenciador de Pacotes Node (NPM — Node Package Manager) foram conduzidos pelo mesmo grupo de ameaças vinculado à Coreia do Norte — o país oficialmente conhecido como República Popular Democrática da Coreia (RPDC). A conexão entre esses incidentes não havia sido reportada publicamente até agora.
O grupo em questão é rastreado pela comunidade de segurança sob vários nomes: SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon e Alluring Pisces. Segundo a análise da Amazon Threat Intelligence, esse ator de ameaças está por trás dos comprometimentos das bibliotecas axios, debug, chalk e typo-crypto — pacotes amplamente utilizados no ecossistema JavaScript.
O relatório também aborda como a IA generativa já está mudando a aparência de pacotes maliciosos e como atores de ameaças estão começando a sondar sistemas de revisão de código baseados em IA.
A linha do tempo dos ataques
A sequência de comprometimentos documentada pela Amazon Threat Intelligence revela uma operação metódica e progressiva:
- Março de 2025: comprometimento do pacote
typo-crypto — considerado um teste inicial de técnicas.
- Setembro de 2025: o mesmo ator compromete os pacotes
debug e chalk.
- Março de 2026: o mesmo manual operacional reaparece no comprometimento do
axios, uma das bibliotecas JavaScript mais usadas no mundo, com mais de 100 milhões de downloads semanais.
Em todos os casos, o grupo obteve acesso por meio de engenharia social contra mantenedores confiáveis dos pacotes, publicando em seguida uma atualização contendo código malicioso. Qualquer organização que atualizasse automaticamente para a versão mais recente recebia o pacote comprometido.
Embora o comprometimento do axios já tivesse sido atribuído publicamente a esse ator, os incidentes com typo-crypto, debug e chalk nunca haviam sido conectados a ele. A Amazon Threat Intelligence identificou Táticas, Técnicas e Procedimentos (TTPs — Tactics, Techniques and Procedures) compartilhados entre as campanhas, incluindo pacotes NPM trojanizados, uso de hooks pós-instalação e reuso de código.
A motivação é financeira: ao comprometer um número pequeno de pacotes altamente populares, o grupo obtém acesso potencial a milhares de ambientes downstream simultaneamente — muito mais eficiente do que atacar organizações uma a uma. Segundo dados da Wiz Research citados no relatório, cerca de 1 em cada 10 ambientes de nuvem foram afetados pelo evento das bibliotecas debug e chalk em uma janela de apenas duas horas.
A campanha menor que veio antes
Durante a análise de indicadores relacionados ao caso do axios, a Amazon Threat Intelligence identificou uma conexão com um domínio registrado em 2025, o que levou a uma investigação mais ampla. Essa investigação revelou que o mesmo ator havia inserido um arquivo trojanizado no pacote typo-crypto em março de 2025.
O arquivo malicioso, chamado core.js, se disfarça como o legítimo pacote core-js dentro do repositório do typo-crypto. Dado o baixo volume de downloads observado, a Amazon Threat Intelligence avalia que essa campanha foi de pequena escala — provavelmente um campo de testes para as operações maiores que viriam depois.
O comportamento técnico do malware é detalhado no relatório:
- O arquivo trojanizado é executado quando recebe um hash iniciando com o valor
0098273.
- Quando ativado, baixa um payload de segundo estágio de um servidor de Comando e Controle (C2) hardcoded.
- Executa o payload de acordo com o sistema operacional da vítima: Windows, macOS ou Linux.
- Implementa persistência baseada em arquivos com rotação de payload.
- Usa ofuscação em múltiplas camadas, combinando texto codificado em base64 com cifra XOR com chave
01042025.
Os indicadores de comprometimento (IoCs) associados incluem:
- Domínio:
npmjs[.]store
- Endereço IP:
216[.]74[.]123[.]126
- Pacote NPM:
typo-crypto (SHA256: 24604384b0e748ada07923630b3d037489e696284a98c4409fb9b6763565571f)
- Arquivo trojanizado:
core.js (SHA256: 2014d09c7ded74d89c885b5f11693865224116f1b25df9330e61fe528f419d73)
O malware foi reportado ao banco de dados de Vulnerabilidades Open Source (Vulnerabilidades Open Source), onde é rastreado como MAL‑2026‑3400.
Como as técnicas de ataque estão evoluindo
A Amazon Threat Intelligence e o Amazon Inspector documentaram uma série de mudanças nas táticas usadas para atacar bibliotecas open source. Cada padrão foi projetado para explorar a lacuna entre o momento em que uma dependência é inspecionada e o momento em que ela efetivamente executa.
De ataques por pacote para ataques por fragmento
Antes, um pacote malicioso concentrava todo o comportamento suspeito em si mesmo. Agora, os atacantes estão dividindo um único fluxo malicioso em vários pacotes de aparência inofensiva: um armazena um blob criptografado disfarçado de configuração; outro contém a lógica de descriptografia; um terceiro, publicado depois, busca e executa o payload. Analisado individualmente, cada pacote parece benigno. O comportamento malicioso só emerge quando os componentes são usados juntos na sequência correta.
Campanhas de longo prazo que investem em confiança
Em vez de publicar malware óbvio, os atacantes publicam algo genuinamente útil e o mantêm por semanas ou meses — corrigindo bugs, adicionando funcionalidades, acumulando dependentes. Em alguns casos, o objetivo nem é lançar um novo pacote, mas se tornar um contribuidor de um projeto existente. Esse foi o fio condutor do backdoor do XZ Utils até os comprometimentos dos mantenedores do debug, chalk e axios: o adversário trata a legitimidade como um ativo a ser gasto uma única vez, no momento de acesso máximo.
Desacoplando o pacote do seu comportamento
Em muitos casos recentes, uma biblioteca está limpa no registro público, mas ainda é perigosa — porque seu comportamento real depende de recursos controlados pelo atacante em outro lugar: scripts buscados de repositórios externos em tempo de execução, arquivos de configuração que ativam certos comportamentos, ou endpoints remotos consultados na inicialização. Enquanto esses recursos externos permanecem benignos, revisões de código passam e varreduras automatizadas retornam resultados limpos. Quando o atacante “arma” o endpoint, cada cópia instalada pode se tornar maliciosa de uma vez, sem nenhuma nova versão do pacote.
Da ofuscação básica à criptografia real
Onde antes os atacantes usavam minificação ou base64 simples, hoje se observam payloads em múltiplos estágios com técnicas criptográficas mais robustas: blobs criptografados com AES‑GCM, arrays de strings no estilo RC4, XOR em camadas sobre base64, e loaders nativos que mantêm o próximo estágio como campo criptografado descriptografado apenas em memória. O design comum é que a chave de descriptografia nunca está armazenada no pacote — ela é derivada do contexto de execução, buscada de um servidor ou fornecida como uma chave de licença.
Payloads que evitam detonar em sandboxes
À medida que os defensores escalaram a análise automatizada em sandboxes de nuvem, os atacantes tornaram seu código mais consciente do ambiente. O payload verifica se está sendo analisado antes de agir: terminais interativos, nomes de usuário e hostnames realistas, participação em domínio, uptime plausível, histórico de arquivos locais, sistemas operacionais específicos e metadados de nuvem que distinguem infraestrutura de análise de cargas de trabalho normais. Alguns servidores de entrega também adaptam o que servem com base no cliente — um decoy benigno vai para requisições genéricas, enquanto o payload real só aparece para o user agent exato usado pelo malware.
Como a IA generativa está mudando o cenário
A IA generativa está alterando tanto o que os atacantes conseguem produzir quanto o que os defensores podem confiar como sinal de detecção.
Historicamente, muitos pacotes maliciosos eram detectados porque pareciam errados: linguagem quebrada, documentação rasa, cópia e cola óbvios, ou funções reutilizadas entre amostras. A IA generativa apaga muitos desses sinais. Atacantes podem agora produzir milhares de linhas de código coerente e idiomático, bem comentado, com documentação convincente, históricos de commits plausíveis e identidades sintéticas de mantenedores — tudo envolvendo um backdoor. Como cada variante pode ser mutada, renomeada, reestruturada e re-criptografada, não há assinatura estável para corresponder.
A IA também está criando novos vetores de acesso inicial. Uma técnica emergente é o slopsquatting: atacantes registram nomes de pacotes que existem apenas porque um assistente de codificação com IA os alucineu. Quando um desenvolvedor — ou um agente autônomo — pede ajuda e o modelo recomenda com confiança um pacote inexistente, o atacante pode ter pré-registrado esse nome e estar esperando. A próxima pessoa que seguir a recomendação pode receber malware, sem ter digitado nada errado ou visitado um site malicioso.
Mais significativamente: atacantes não estão mais apenas escrevendo malware para humanos deixarem passar. Estão escrevendo malware para sistemas de IA aprovarem. À medida que organizações dependem de IA para revisar código e triar pacotes, esses sistemas de IA se tornam parte da superfície de ataque. A Amazon espera que a injeção indireta de prompt — uma técnica onde instruções ocultas manipulam um sistema de IA a tomar ações não intencionais — seja cada vez mais incorporada em pacotes maliciosos para enganar scanners baseados em IA. Essas instruções podem estar escondidas em comentários de código, arquivos README, docstrings ou fixtures de teste.
O que a AWS está fazendo a respeito
A Amazon Web Services (AWS) afirma estar investindo em Amazon Threat Intelligence e Amazon Inspector para ajudar clientes a se adaptarem a esse cenário em constante mudança.
Após descobrir a campanha, a Amazon Threat Intelligence trabalhou com o Amazon Inspector para que o pacote malicioso fosse rastreado, mitigado e compartilhado com a comunidade pelo banco de dados OSV. Os indicadores observados também foram compartilhados com o Amazon GuardDuty para alertar clientes sobre essa atividade.
O Amazon Inspector usa esses insights para refinar a lógica de detecção, ampliar a cobertura em registros de pacotes e priorizar sinais que refletem as mudanças de técnica descritas no relatório. A empresa também está colaborando com parceiros do setor, como registros de pacotes e a Open Source Security Foundation (OpenSSF).
Em 2026, a AWS se juntou à Linux Foundation e outros líderes do setor para lançar o Akrites, uma iniciativa colaborativa para defender software open source crítico contra ameaças cibernéticas habilitadas por IA. A AWS também co-investiu US$ 12,5 milhões junto a outras organizações para defender o ecossistema open source de ataques impulsionados por IA.
O que isso significa para equipes de segurança
O relatório da Amazon deixa claro que a segurança da cadeia de suprimentos de software open source exige uma mudança de mentalidade. Não basta escanear pacotes individualmente: é preciso raciocinar sobre como eles interagem em um grafo de dependências real. Um pacote que não mostra comportamento malicioso hoje não é o mesmo que um pacote seguro por design.
A paciência dos atacantes — investindo meses em construir confiança antes de agir — e a capacidade de usar IA para gerar malware convincente tornam as abordagens tradicionais de detecção cada vez menos eficazes. O setor como um todo, e não apenas os provedores de nuvem, precisa adaptar suas defesas a esse novo cenário.
Fonte
Amazon identifies North Korean hacker group behind open-source supply chain attacks (https://aws.amazon.com/blogs/security/amazon-identifies-north-korean-hacker-group-behind-open-source-supply-chain-attacks/)
