Amazon liga axios, debug e chalk ao grupo e alvo final é seu package.json

Amazon Threat Intelligence ligou quatro ataques ao NPM a um único grupo da Coreia do Norte. Os pacotes atingidos foram axios, debug, chalk e typo crypto. O caso do axios já era público. As outras três conexões, no entanto, aparecem agora pela primeira vez.

O detalhe que interessa ao desenvolvedor está no método. Em todos os casos, o acesso veio de um mantenedor legítimo que foi enganado. Depois disso, uma versão nova saiu no registro com o nome de sempre. Portanto, quem rodava atualização automática recebeu o código malicioso sem clicar em nada.

O axios sozinho passa de 100 milhões de downloads por semana, segundo os dados da Amazon. Além disso, a Wiz Research estimou que cerca de um em cada dez ambientes de nuvem sentiu o incidente de debug e chalk em uma janela de duas horas. Ou seja, duas horas bastaram para transformar uma dependência em incidente global.

Amazon: Um ensaio silencioso aconteceu um ano antes do estrago

A investigação começou por um domínio registrado em 2025 que aparecia nos indicadores do axios. Em seguida, a equipe puxou o histórico daquele domínio. Foi assim que apareceu um arquivo com trojan dentro do pacote typo crypto, publicado em março de 2025.

O arquivo se passava por uma peça do core js. O volume de download continuou baixo o tempo todo. Por isso, a leitura da Amazon é de que a operação nunca teve intenção de escala. A hipótese de trabalho aponta para um teste, uma chance de ajustar a mecânica antes dos alvos grandes.

A ativação exigia uma condição específica. Primeiro, o código conferia se um hash começava com um valor determinado. Depois, buscava a segunda etapa em um servidor de comando fixo. Então rodava a carga adequada ao sistema, fosse Windows, macOS ou Linux. A persistência ficava no sistema de arquivos, com cargas que giravam ao longo do tempo. Duas camadas de ofuscação cobriam tudo, com base64 por cima de uma cifra XOR.

Se a hipótese estiver certa, o grupo passou mais de um ano lapidando a técnica. Enquanto isso, o ecossistema seguia instalando pacotes normalmente.

Três pacotes inofensivos que só viram malware quando se juntam

Existe uma tática que quebra a lógica dos scanners. O ataque chega dividido. Um pacote guarda um blob criptografado disfarçado de configuração. Outro carrega a lógica de decifrar. Um terceiro chega depois, quando os dois primeiros já estão instalados, e apenas junta as peças e executa.

Nenhum dos três levanta suspeita sozinho. Os ganchos de instalação parecem comuns. As chamadas de rede também parecem comuns. De fato, a análise isolada aprova todos.

O risco aparece quando os três convivem no mesmo grafo de dependências, na ordem certa. A maioria das ferramentas avalia pacote por pacote. Logo, o comportamento combinado escapa da revisão.

A paciência também mudou de patamar. Alguns agentes publicam algo útil e mantêm o projeto por meses, com correções e recursos reais, enquanto acumulam dependentes. Em outros casos, o objetivo é virar colaborador de um projeto que já existe. Esse foi o fio que ligou o backdoor do XZ Utils aos casos de debug, chalk e axios.

O pacote passa na revisão e vira arma depois, sem release novo

Um pacote pode estar limpo no seu lock file e ainda assim depender de recursos que o atacante controla. Scripts de licença buscados em tempo de execução entram nessa conta. Arquivos de configuração remotos também. Endpoints consultados na inicialização fecham o conjunto.

Enquanto esses recursos externos continuam benignos, a revisão passa e o scan volta limpo. No momento em que o conteúdo remoto muda, toda cópia instalada pode virar maliciosa ao mesmo tempo. Nenhuma versão nova precisa ser publicada para isso acontecer.

A criptografia dentro dos pacotes acompanhou essa evolução. Alguns usam blobs AES GCM que só abrem com a senha certa. Outros aplicam arrays de strings no estilo RC4, com chave diferente a cada chamada. Há ainda quem empilhe XOR sobre base64.

O ponto comum está no lugar da chave, que fica fora do pacote. Ela vem de um servidor, nasce do contexto da máquina ou chega como licença. Assim, ler o código inteiro não basta para decifrar a carga.

O payload também testa se você é um dev de verdade (Amazon)

A evasão de sandbox ficou mais criteriosa. Antes de agir, a carga procura sinais de ambiente real. Terminal interativo, nome de usuário plausível, hostname coerente, tempo de atividade da máquina, histórico de arquivos locais e metadados de nuvem entram na checagem.

Alguns servidores de entrega vão além e respondem de acordo com o cliente. Uma requisição parecida com navegador recebe um engodo. O payload real sai apenas para o user agent exato do malware. Por isso, uma análise rápida em ambiente limpo tende a voltar sem nada.

IA generativa apagou os sinais que denunciavam pacote falso

Durante anos, os indícios eram grosseiros. Texto quebrado, documentação rala, função repetida entre amostras, cópia evidente. Esses sinais sustentavam boa parte da triagem manual.

A Amazon relata que esse repertório acabou. Agora o código chega coerente e bem comentado. A documentação convence. O histórico de commits parece plausível. Além disso, identidades sintéticas de mantenedores completam a fachada.

Cada variante pode ser reescrita, renomeada e cifrada de novo. Portanto, a detecção por assinatura fica sem padrão estável para segurar.

Slopsquatting, o pacote que existe porque um modelo alucinou

Aqui está a rota nova que mais interessa a quem programa com assistente. Um modelo sugere com confiança um pacote que nunca existiu. O atacante registra esse nome antes. Depois, entrega malware a quem seguir a recomendação.

O caminho dispensa erro de digitação. Também dispensa link suspeito. A instalação veio de uma sugestão que parecia boa. Em pipelines com agentes autônomos, o risco cresce, já que a instalação acontece sem revisão humana no meio.

Quando o seu revisor de IA vira a superfície de ataque

A preocupação mais urgente da Amazon aparece quando a organização usa IA para revisar código e priorizar pacotes. Nesse cenário, o próprio revisor entra no alvo.

A técnica esperada é a injeção indireta de prompt. Instruções escondidas ficam em comentários no código, README, docstrings e arquivos de teste. Elas são escritas para convencer um scanner automatizado a aprovar o que deveria ser sinalizado. Também servem para fazer o scanner pular um arquivo que merecia inspeção.

O Amazon Inspector reportou o malware do typo crypto ao banco de vulnerabilidades de código aberto. Além disso, os indicadores foram compartilhados com o Amazon GuardDuty, para que os clientes conferissem os próprios ambientes.

O que dá para revisar no seu projeto ainda esta semana

• Trave versões e confie no lock file, evitando faixas abertas em dependências críticas.
• Desligue scripts de instalação por padrão no CI, liberando apenas o que for necessário.
• Segure atualização automática por alguns dias, já que a janela crítica costuma ser curta.
• Trate ambiente de build como alvo, sem credencial de publicação disponível ali.
• Revise pacotes novos em conjunto, olhando o grafo inteiro em vez de arquivos isolados.
• Confira sinais de rede em tempo de instalação, porque tráfego inesperado ali é anomalia.
• Valide toda sugestão de pacote vinda de assistente antes de instalar, sobretudo em fluxo automatizado.
• Trate saída de revisor automático como opinião, mantendo revisão humana em dependências sensíveis.

Amazon: O recado que fica

O caso mostra uma mudança de foco. O ataque mira a confiança do ecossistema, antes de mirar a máquina do desenvolvedor. Uma conta de mantenedor vale mais do que mil tentativas contra empresas isoladas.

Portanto, a defesa útil mora no processo. Menos automatismo cego na atualização, mais atenção ao grafo de dependências e ceticismo saudável com qualquer sugestão de instalar algo novo. Assim, o próximo incidente encontra um ambiente mais duro para trabalhar.

Acompanhe nosso perfil no Instagram!