Como a conta do mantenedor do Axios foi sequestrada: dentro do ataque que envenenou o npm
O sequestro da conta do principal mantenedor do Axios, um dos clientes HTTP mais usados no ecossistema JavaScript, não foi um ataque oportunista. Foi uma operação cuidadosamente planejada de engenharia social que se desenrolou ao longo de semanas, culminando na publicação de duas versões maliciosas do pacote no repositório npm.
Os atacantes se passaram por uma empresa legítima, copiaram sua identidade visual, usaram nomes e fotos reais dos fundadores e montaram todo um cenário corporativo falso para ganhar a confiança de Jason Saayman, mantenedor líder do projeto.
—
Como começou: engenharia social de longo prazo
De acordo com a análise pós-incidente publicada pelos responsáveis pelo Axios, o ataque teve início com um contato aparentemente profissional. Os criminosos se apresentaram como representantes de uma empresa de integração contínua, com comunicação bem elaborada e coerente com a imagem pública da organização real.
Eles não se limitaram a um simples e-mail ou mensagem isolada. A abordagem foi progressiva: conversas iniciais, troca de informações, convite para colaboração e, por fim, integração em um suposto ambiente interno da empresa. O objetivo era criar um relacionamento plausível e um contexto em que um pedido para instalar software ou atualizar ferramentas parecesse algo absolutamente normal.
—
Slack falso: um ambiente corporativo encenado
O passo seguinte foi o convite para um espaço de trabalho no Slack. Não se tratava de um workspace genérico, mas de um ambiente minuciosamente preparado para imitar a estrutura da empresa real.
Segundo Saayman, o Slack fraudulento parecia autêntico em todos os detalhes:
– canais com nomes típicos de times de engenharia, produto e suporte;
– conversas aparentemente naturais entre “colegas de trabalho”;
– compartilhamento de postagens do LinkedIn da empresa verdadeira, reforçando a sensação de legitimidade;
– perfis com nomes e fotos que se passavam por funcionários e por outros mantenedores de projetos de código aberto.
A simulação era tão convincente que não se limitava a um canal vazio com poucos usuários. Havia atividade encenada, interações e até o que pareciam ser outros desenvolvedores de código aberto participando de discussões técnicas. Isso reduziu drasticamente a suspeita de que algo estivesse errado.
—
A reunião no Microsoft Teams e o “erro técnico” montado
Com a confiança estabelecida, os atacantes marcaram uma reunião em vídeo pelo Microsoft Teams. A chamada incluía, aparentemente, várias pessoas da suposta empresa, reforçando o teatro corporativo.
Durante a reunião, em determinado momento apareceu um erro técnico na tela, alegando que havia um componente desatualizado no sistema de Saayman, impedindo o correto funcionamento da chamada. A solução, segundo os “colegas”, seria instalar uma atualização do Teams para corrigir o problema.
Esse tipo de manobra é conhecido: a vítima, pressionada pelo contexto social (estar em uma reunião, não querer atrasar o time, não parecer “a pessoa que não entende de TI”), fica mais propensa a aceitar instruções que, em outra situação, talvez questionasse. O “erro” era simulado, e toda a encenação tinha um único objetivo: levar o mantenedor a baixar e executar um instalador malicioso.
—
A falsa atualização: um RAT disfarçado
A suposta atualização do Microsoft Teams não era um patch oficial, mas um cavalo de troia de acesso remoto (RAT – Remote Access Trojan). Uma vez instalado, o malware concedeu aos atacantes controle remoto sobre o dispositivo de Saayman.
Com esse nível de acesso, os agentes de ameaça conseguiram obter credenciais sensíveis, incluindo os tokens e senhas usados para publicar novas versões do Axios no registro npm. A partir daí, não precisavam mais enganar ninguém: com as credenciais em mãos, eram, para todos os efeitos, o próprio mantenedor.
—
Publicação das versões maliciosas no npm
De posse do acesso, os invasores publicaram duas versões comprometidas do Axios:
– 1.14.1
– 0.30.4
Essas versões continham uma dependência maliciosa chamada `plain-crypto-js`, que era instalada como se fosse apenas mais um pacote comum. Na prática, essa dependência embutia outro RAT, capaz de comprometer sistemas macOS, Windows e Linux.
Quem instalou essas versões durante a janela em que estavam disponíveis no npm, ao invés de obter apenas um cliente HTTP, acabou instalando também um backdoor com capacidade de controle remoto.
As versões adulteradas permaneceram públicas por cerca de três horas antes de serem identificadas e removidas. Embora o tempo pareça curto, ele é mais que suficiente em um ecossistema onde pipelines de CI/CD, aplicações e bibliotecas são atualizadas de forma automática ou sem muita revisão manual.
—
Impacto: sistemas potencialmente comprometidos
A orientação dos responsáveis pela análise do incidente é direta: qualquer sistema que tenha instalado as versões maliciosas do Axios nesse intervalo de tempo deve ser tratado como comprometido.
As recomendações incluem:
– rotacionar todas as credenciais de acesso utilizadas por esses sistemas (senhas, tokens de API, chaves SSH, chaves de autenticação em nuvem);
– revisar logs de auditoria em busca de acessos suspeitos;
– verificar a integridade de aplicações e servidores;
– considerar a reinstalação ou reprovisionamento de máquinas críticas.
Em ataques que envolvem RAT, o problema não é apenas o código malicioso inicial, mas o que pode ter sido feito depois que o atacante obteve acesso remoto: instalação de outras ferramentas, roubo de segredos, exfiltração de dados e movimentação lateral dentro da infraestrutura.
—
Atribuição: operadores ligados à Coreia do Norte
O Google Threat Intelligence Group atribuiu o ataque a agentes de ameaça norte-coreanos, rastreados sob o identificador UNC1069. A ligação se baseia no uso do WAVESHAPER.V2, uma versão atualizada de um malware anteriormente associado a esse grupo.
Grupos ligados à Coreia do Norte, historicamente, têm interesse em comprometer cadeias de fornecimento de software, tanto para fins de espionagem quanto para obtenção de vantagens financeiras ou estratégicas. Atacar projetos amplamente utilizados em ecossistemas como JavaScript e Node.js amplia exponencialmente o alcance de uma campanha maliciosa.
—
Não foi um caso isolado: outros mantenedores também foram alvo
O ataque contra o Axios não aconteceu em um vácuo. Outros desenvolvedores de alto perfil no universo de código aberto relataram abordagens semelhantes.
Pelle Wessman, mantenedor de vários projetos e contribuinte em ferramentas populares como o framework de testes Mocha, descreveu ter sido contatado pela mesma campanha. No caso dele, o roteiro foi parecido: contato profissional, convite para colaboração e, em determinado momento, a tentativa de induzi-lo a instalar um aplicativo suspeito.
Quando Wessman recusou a instalação, os atacantes mudaram a estratégia e passaram a pressioná-lo a executar um comando Curl diretamente no terminal – outro vetor comum de download de malware. Diante da resistência, simplesmente apagaram todas as conversas, tentando eliminar vestígios da interação.
—
Um padrão de campanha bem definido
Investigações posteriores mostraram que a mesma tática foi usada contra diversos outros desenvolvedores e mantenedores de projetos de alto impacto, incluindo contribuidores do próprio Node.js.
A empresa de segurança responsável por parte dessa análise descreveu uma sequência recorrente na campanha:
1. contato inicial via LinkedIn ou Slack, com perfis bem elaborados;
2. convite para espaços privados de Slack supostamente corporativos;
3. agendamento de chamadas de vídeo para aumentar a confiança;
4. apresentação de mensagens de erro falsas durante as reuniões;
5. tentativa de convencimento para instalar software ou executar comandos maliciosos.
Esse padrão demonstra que os atacantes não dependem apenas de vulnerabilidades técnicas, mas exploram de forma intensa aspectos humanos: confiança, pressa, boa-fé e o contexto social de colaboração entre desenvolvedores.
—
O que esse incidente ensina para desenvolvedores e empresas
O caso Axios é mais um exemplo de ataque à cadeia de fornecimento de software, mas com um foco claro no elo humano: o mantenedor. Alguns aprendizados práticos se destacam:
– Verificação de identidade corporativa: convites para workspaces privados, reuniões e colaborações devem ser checados por canais independentes, como sites oficiais e contatos públicos já conhecidos da empresa real.
– Desconfiança de instaladores fora das lojas oficiais: atualizações de ferramentas amplamente usadas (Teams, Zoom, Slack, IDEs) devem ser baixadas apenas de locais oficiais ou via mecanismos internos de atualização.
– Uso de 2FA e tokens de escopo limitado: mesmo que credenciais sejam comprometidas, autenticação de múltiplos fatores e tokens com permissões restritas podem reduzir o impacto do ataque.
– Segmentação de ambientes de desenvolvimento: usar máquinas dedicadas ou ambientes isolados (como VMs e containers) para publicação de pacotes críticos diminui a superfície de ataque.
—
Segurança em projetos de código aberto: um novo patamar de risco
Projetos como Axios, Mocha e muitos outros são mantidos, em grande parte, por poucas pessoas, muitas vezes voluntárias ou com recursos limitados. Esses indivíduos passaram a ser alvo direto de grupos de ameaça extremamente sofisticados, que antes focavam quase exclusivamente em grandes empresas e órgãos governamentais.
Isso coloca o ecossistema de código aberto diante de um desafio estrutural: como proteger uma infraestrutura crítica da internet – bibliotecas, frameworks e ferramentas usadas por milhões de aplicações – quando a responsabilidade está concentrada em poucos mantenedores, sem suporte formal de segurança?
Iniciativas como revisões de código automatizadas, análise de dependências, monitoramento de anomalias em repositórios e educação em segurança para mantenedores se tornam essenciais. Mas, acima de tudo, é necessário que empresas que dependem fortemente de OSS invistam também em fortalecer a segurança desses projetos, e não apenas em consumi-los.
—
Como reduzir a exposição a ataques semelhantes
Para desenvolvedores, equipes de DevOps e organizações que usam npm e outros gerenciadores de pacotes, algumas práticas adicionais ajudam a mitigar riscos:
– Fixar versões e usar lockfiles (como package-lock.json ou yarn.lock) para evitar atualizações automáticas não auditadas;
– Monitorar alertas de segurança dos pacotes mais críticos utilizados em projeto;
– Implementar repositórios espelho internos que façam verificação e caching dos pacotes antes de serem usados em produção;
– Auditar cadeias de dependências em busca de pacotes pouco conhecidos ou recém-adicionados, especialmente quando surgem de forma inesperada;
– Reagir rapidamente a incidentes de supply chain, estabelecendo processos formais de resposta (incidentes, rotação de credenciais, comunicação com clientes e usuários).
—
Conclusão: o elo mais visado passou a ser o mantenedor
O sequestro da conta do mantenedor do Axios mostra que, na atualidade, proteger apenas servidores, redes e aplicações não é suficiente. A identidade digital de desenvolvedores-chave se tornou um alvo estratégico para grupos de ameaça.
Ao explorar a confiança, a aparência de normalidade em ferramentas de colaboração e a rotina de trabalho remoto, atacantes conseguem contornar muitos dos controles técnicos tradicionais. Por isso, a segurança da cadeia de fornecimento de software precisa ser tratada como uma responsabilidade compartilhada entre mantenedores, empresas usuárias e toda a comunidade de desenvolvimento.
Enquanto a adoção de boas práticas técnicas avança, entender e mitigar os riscos de engenharia social de alto nível – como o que atingiu o Axios – será determinante para evitar que um único clique em uma “atualização” falsa se transforme em uma brecha global.