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.
