Google atribui ataque à cadeia npm do Axios ao grupo norte-coreano UNC1069

Versões adulteradas do pacote Axios introduziram a dependência plain-crypto-js, acionaram execução por postinstall e entregaram backdoors para Windows, macOS e Linux.

Componente	Pacote Axios no npm, com versões trojanizadas 1.14.1 e 0.30.4, e dependência maliciosa plain-crypto-js.
Vetor	Controle indevido da conta npm do mantenedor e abuso de um gancho postinstall no package.json da dependência maliciosa, acionado automaticamente durante a instalação.
Impacto	Entrega de um dropper JavaScript ofuscado chamado SILKBELL, seguido por variantes de backdoor compatíveis com Windows, macOS e Linux.
Prioridade	Auditar árvores de dependência, lockfiles e diretórios node_modules em busca das versões comprometidas e de plain-crypto-js, isolar sistemas afetados e rotacionar credenciais expostas em ambientes de build.
Artefatos	setup.js, SILKBELL, WAVESHAPER.V2, variantes associadas a ZshBucket e comunicação C2 em intervalos de 60 segundos.
IoCs	Domínio C2 defangado sfrclak[.]com e endereço IP defangado 142.11.206[.]73.

Resumo técnico

O comprometimento do Axios no npm foi atribuído pelo Google a UNC1069, um agrupamento de atividade norte-coreano descrito como financeiramente motivado. O ataque atingiu a cadeia de suprimentos de software ao inserir versões trojanizadas de um pacote amplamente utilizado por aplicações JavaScript, sem depender de uma alteração funcional direta no código principal do Axios. A operação se apoiou na confiança transitiva criada por dependências de terceiros: quando a versão adulterada era resolvida e instalada, a execução maliciosa ocorria por meio de uma dependência adicionada ao pacote, reduzindo a visibilidade para revisões superficiais de diff no projeto principal.

As versões comprometidas identificadas foram 1.14.1 e 0.30.4. Elas introduziram a dependência plain-crypto-js, usada como veículo de entrega para um dropper JavaScript ofuscado chamado SILKBELL, associado ao arquivo setup.js. O ponto técnico central é o gancho postinstall dentro do package.json da dependência maliciosa. Em ecossistemas npm, esse tipo de gancho pode ser executado automaticamente durante a instalação do pacote, o que transforma uma simples resolução de dependência em uma oportunidade de execução de código no ambiente do desenvolvedor, do pipeline de CI/CD ou do sistema de build.

A cadeia foi construída para operar em múltiplos sistemas. O dropper selecionava a próxima etapa de acordo com o sistema operacional observado: malware baseado em PowerShell para Windows, um binário C++ no formato Mach-O para macOS e uma backdoor em Python para Linux. Após a execução inicial, o dropper também tentava remover evidências diretas, apagando a si próprio e substituindo o package.json da dependência por uma versão limpa, sem o gancho postinstall. Esse comportamento não elimina a necessidade de investigação, mas reduz a chance de detecção por inspeção tardia de arquivos já modificados no diretório de dependências.

Fluxo técnico

O fluxo começa com a publicação de versões adulteradas do Axios após o controle indevido da conta npm do mantenedor. Em vez de modificar diretamente a lógica do Axios, os operadores adicionaram plain-crypto-js como dependência. Essa escolha é relevante para engenharia e AppSec porque desloca o ponto de execução para um pacote auxiliar, onde revisões automatizadas focadas apenas no pacote principal podem deixar de identificar o comportamento. Quando uma aplicação, um ambiente de desenvolvimento ou uma esteira de build instalava a versão comprometida, o npm processava o ciclo de instalação e acionava o postinstall da dependência maliciosa.

SILKBELL funcionava como camada inicial de decisão e entrega. O código ofuscado buscava a próxima etapa em um servidor remoto e selecionava o artefato compatível com Windows, macOS ou Linux. A backdoor resultante foi identificada como WAVESHAPER.V2, descrita como evolução de WAVESHAPER, implante C++ anteriormente observado em operações de UNC1069 contra o setor de criptomoedas. A versão atualizada passou a usar comunicação baseada em JSON, coleta adicional de informações do sistema e suporte a mais comandos de backdoor, mantendo características como URL de C2 recebida dinamicamente por argumentos, comportamento de polling semelhante e uso de diretórios temporários compatíveis com os artefatos anteriores.

As variantes de WAVESHAPER.V2 consultavam o C2 em intervalos de 60 segundos e suportavam quatro comandos. Entre as capacidades citadas estão enumeração de diretórios, caminhos de arquivos, tamanhos e timestamps de criação ou modificação, além de execução remota de scripts conforme o sistema operacional. Para fins defensivos, o ponto importante não é reproduzir os comandos, mas entender que a intrusão dava ao operador capacidade de inventariar o sistema e acionar execução arbitrária dentro do contexto da máquina comprometida. Esse nível de acesso é especialmente crítico quando ocorre em estáções de desenvolvimento ou runners de CI, onde tokens, variáveis de ambiente, chaves de assinatura, credenciais de publicação e caches de dependência podem existir em memória, disco ou configuração.

A atribuição técnica também foi reforçada por sobreposições com malware anterior. A análise apontou semelhanças entre WAVESHAPER.V2 e WAVESHAPER, além de referências em binário macOS a caminhos de build como Jain_DEV/client_mac/macWebT/macWebT. O componente macWebT foi relacionado ao módulo webT usado por BlueNoroff em campanhas RustBucket e Hidden Risk em 2023 e 2024. Outro conjunto de análise vinculou o incidente a Stardust Chollima com confiança moderada, citando uma variante atualizada de ZshBucket para macOS, reutilização extensa de código e funções, perfilamento de usuário e host, além de envio de informações coletadas de forma semelhante a amostras anteriores.

Superfície afetada

A exposição recai sobre ambientes que resolveram ou instalaram as versões 1.14.1 ou 0.30.4 do Axios enquanto elas estavam comprometidas, incluindo máquinas de desenvolvedores, contêineres de build, runners de integração contínua, imagens intermediárias e caches de dependência. Como o Axios é uma biblioteca comum em aplicações JavaScript, a superfície não se limita ao projeto que declarou a dependência diretamente. Aplicações que a recebem de forma transitiva também precisam ser avaliadas por meio de lockfiles, manifests e artefatos de build gerados no período de exposição.

A existência de um pacote espelhado chamado @depup/axios, que republicou a versão comprometida 1.14.1 cerca de 17 minutos após sua liberação, amplia o problema operacional. Mesmo ataques de curta duração podem persistir quando sistemas automatizados copiam versões recém-publicadas para espelhos, caches internos ou pacotes derivados. Isso exige que a investigação vá além do registro npm principal e alcance proxies corporativos, registries privados, imagens de base, snapshots de dependências e repositórios que armazenam artefatos de terceiros.

• Projetos com package-lock.json ou outros lockfiles apontando para Axios 1.14.1 ou 0.30.4 durante a janela do incidente.
• Diretórios node_modules contendo plain-crypto-js, especialmente quando associados a execução de scripts de instalação.
• Ambientes Windows, macOS e Linux usados para desenvolvimento, build, teste ou empacotamento de software JavaScript.
• Registries internos, caches de proxy e pacotes espelhados que possam ter preservado versões comprometidas após remoção no ecossistema público.
• Runners de CI/CD e máquinas com segredos de publicação, credenciais de nuvem, tokens de repositório ou chaves usadas por pipelines.

Hunting e telemetria

A investigação deve começar pela cadeia de dependências e avançar para execução em endpoint. Em repositórios, procure referências às versões comprometidas do Axios, alterações inesperadas em lockfiles e presença de plain-crypto-js. Em endpoints e runners, correlacione instalações npm com criação ou execução de setup.js, processos filhos iniciados durante a fase de instalação e conexões de saída para infraestrutura C2. A limpeza automática do dropper reduz a confiabilidade de uma busca pontual no disco, por isso logs de processo, telemetry EDR, histórico de build e snapshots de contêiner são mais úteis do que uma simples inspeção manual posterior.

No macOS e Linux, a análise deve considerar diretórios temporários e de cache mencionados nos artefatos, incluindo caminhos similares a /Library/Caches/com.apple.act.mond. Em Windows, a execução de PowerShell vinculada a instalação de dependências JavaScript é um sinal forte, principalmente quando surge como processo descendente de npm, node, gerenciadores de pacote, agentes de CI ou shells não interativos. No nível de rede, conexões periódicas em torno de 60 segundos para domínio C2 defangado sfrclak[.]com ou IP defangado 142.11.206[.]73 devem ser tratadas como evidência relevante, respeitando a janela temporal do incidente e a possibilidade de infraestrutura já indisponível.

A telemetria de identidade e segredos também precisa entrar no escopo. Embora o contexto não confirme roubo específico de credenciais neste incidente, o local de execução torna plausível que variáveis de ambiente, tokens de pacote, credenciais de nuvem e chaves de repositório tenham ficado acessíveis ao código malicioso em sistemas afetados. A resposta deve revisar uso anômalo de tokens após a instalação, novas publicações em registries, operações incomuns em repositórios, criação de chaves, alteração de permissões e chamadas de API fora do padrão normal do pipeline.

• Instalações npm que resolveram Axios 1.14.1 ou 0.30.4 e executaram scripts de ciclo de vida durante o build.
• Presença de plain-crypto-js, setup.js ou alterações no package.json de dependências após instalação.
• Processos PowerShell, binários Mach-O ou Python iniciados por npm, node, agentes de CI ou shells de build.
• Conexões periódicas para sfrclak[.]com ou 142.11.206[.]73, ambos defangados, especialmente próximas à instalação de dependências.
• Acesso incomum a diretórios de cache, enumeração de arquivos e execução de scripts associada a processos de instalação de pacotes.

Mitigação

A primeira medida é identificar onde as versões comprometidas foram resolvidas. Equipes devem auditar manifests, lockfiles, caches, imagens e artefatos de build para localizar Axios 1.14.1 e 0.30.4. Quando encontradas, as dependências devem ser revertidas para uma versão conhecida como segura e fixadas em lockfiles para impedir reinstalação acidental. A verificação precisa incluir dependências transitivas e pacotes espelhados, pois a cópia automatizada para @depup/axios mostra que o risco pode continuar fora do pacote original.

Sistemas que executaram a cadeia comprometida devem ser tratados como potencialmente afetados, com isolamento quando houver evidência de execução do dropper, comunicação C2 ou processos suspeitos. A contenção deve remover dependências maliciosas, encerrar processos associados, bloquear a infraestrutura C2 defangada no controle de rede e preservar evidências antes de limpar artefatos. Em ambientes de CI/CD, a resposta deve incluir reconstrução de runners efêmeros, invalidação de caches e revisão de imagens que possam ter incorporado a dependência comprometida.

A rotação de credenciais é uma etapa defensiva importante para ambientes onde a instalação ocorreu com acesso a segredos. Tokens npm, credenciais de repositório, chaves de cloud, segredos de assinatura, variáveis de pipeline e contas de serviço devem ser avaliados conforme escopo de exposição. A mitigação estrutural deve reforçar autenticação de mantenedores, reduzir permissões de publicação, exigir revisão de mudanças em lockfiles, restringir scripts de instalação quando possível e monitorar pacotes recém-adicionados que introduzem ganchos de ciclo de vida. O incidente demonstra que controles de supply chain precisam cobrir npm, espelhos, PyPI, NuGet e qualquer registro que alimente pipelines corporativos.

• Auditar package-lock.json, manifests, caches internos e imagens para Axios 1.14.1, Axios 0.30.4 e plain-crypto-js.
• Fixar Axios em versão segura conhecida e reconstruir artefatos afetados a partir de dependências verificadas.
• Isolar hosts ou runners com sinais de execução de SILKBELL, WAVESHAPER.V2 ou variantes relacionadas a ZshBucket.
• Bloquear sfrclak[.]com e 142.11.206[.]73 em formato defangado nas ferramentas de defesa e investigar tentativas históricas de conexão.
• Rotacionar credenciais acessíveis aos ambientes que instalaram as versões comprometidas e revisar uso anômalo após a janela do incidente.
• Revisar políticas de execução de scripts de instalação, permissões de publicação em registries e monitoramento de dependências transitivas em CI/CD.