Engenharia social contra Axios mostra como um maintainer pode virar vetor para 100 milhões de downloads

O que aconteceu

Uma operação atribuída ao cluster UNC1069 usou engenharia social de alto nível para comprometer o maintainer do Axios, uma das bibliotecas mais usadas no ecossistema JavaScript. Em vez de explorar uma falha técnica, o grupo montou um cenário corporativo falso e induziu a vítima a instalar um suposto “update” durante uma chamada no Microsoft Teams. O update era, na prática, um RAT.

Como o golpe funcionou (engenharia social nível APT)

Clonagem de identidade de um fundador real para dar credibilidade ao contato.
Workspace no Slack com branding, perfis falsos e canais “corporativos”.
Reunião no Teams com o que parecia ser um time completo.
Alerta de “atualização necessária” durante a call, levando o maintainer a instalar o malware.
O RAT se autoapagou após execução para reduzir rastros forenses.

Linha do tempo (resumo)

18 horas antes: um pacote “limpo” foi publicado para criar histórico de registry.
12:21 UTC (domingo): versões maliciosas publicadas no npm.
+39 minutos: releases nas branches latest e legacy.
~3 horas depois: npm removeu as versões comprometidas.

Impacto direto

Axios tem cerca de 100 milhões de downloads por semana e é presença comum em ambientes de cloud. Em poucas horas, versões maliciosas ficaram disponíveis tempo suficiente para:

Exfiltrar credenciais de npm e acesso de publicação.
Acessar chaves e segredos em pipelines (AWS, SSH, CI/CD e .env).
Disparar conexões para C2 em diferentes sistemas (Windows, macOS e Linux).

Por que isso assusta (mesmo com MFA)

O maintainer relatou ter MFA habilitado “praticamente em tudo”. Ainda assim, a engenharia social venceu. Ou seja: o problema não foi senha fraca, mas um playbook desenhado para quebrar a confiança humana. É um ataque que trata a vítima como interface — e isso ignora a maior parte dos controles técnicos tradicionais.

O que fazer agora (checklist curto)

Rotacionar credenciais: npm tokens, AWS keys, SSH, secrets de CI/CD e variáveis em .env.
Identificar se versões comprometidas foram instaladas em build/CI nas últimas semanas.
Travar releases críticas com revisão de co-maintainers e chaves segregadas.
Adotar SBOM e allowlist de versões para pacotes críticos.
Monitorar releases “fora do padrão” (horário, tamanho do diff, branch inesperada).

O padrão que está se repetindo

O mesmo cluster já foi ligado a compromissos recentes envolvendo Trivy, KICS, LiteLLM e até GitHub Actions. A mensagem é clara: o supply chain open source está virando alvo prioritário de operações persistentes — com impacto que escala muito além do maintainer atacado.

Como saber se você foi afetado (Axios/npm)

1) Verifique versões instaladas (builds e lockfiles):

Procure se houve instalação de versões publicadas no intervalo do incidente
package-lock.json, yarn.lock, pnpm-lock.yaml
I logs e caches de build
Se achar versões suspeitas, trate como comprometimento potencial.

2) Procure indícios de execução do pacote malicioso:

Conexões de saída inesperadas logo após npm install / npm ci
Processos desconhecidos durante build (especialmente em runners de CI)
Alterações repentinas em ~/.npmrc, tokens de npm ou secrets de CI
Criação/uso de arquivos temporários estranhos no runner

3) Rotacione credenciais se houver qualquer dúvida:

npm tokens, chaves de cloud (AWS/GCP/Azure), SSH keys, secrets de CI/CD e variáveis .env.

4) Proteja próximos releases:

Fixar versões (allowlist)
Adotar SBOM e policy de dependências
Revisão por co-maintainers em releases críticos

Conclusão

Um único maintainer, uma call fake, e 100 milhões de downloads viraram vetor em questão de horas. A moral da história é simples e cruel: se o ecossistema depende de confiança individual, ele precisa começar a tratar maintainers como ativos críticos — não como hobby.

Fonte: https://x.com/aakashgupta/status/2040171739926393151