Como a conta do mantenedor do Axios foi sequestrada: bastidores do ataque e lições para todo o ecossistema open source
O sequestro da conta do principal mantenedor do Axios, uma das bibliotecas HTTP mais usadas no ecossistema JavaScript, não foi um ataque oportunista. Foi o resultado de uma campanha de engenharia social longa, bem planejada e extremamente convincente, que terminou com a publicação de versões maliciosas do pacote no npm e a possível contaminação de milhares de projetos.
Um ataque preparado com semanas de antecedência
De acordo com a análise pós-incidente feita pelos mantenedores do Axios, o ataque começou semanas antes da publicação dos pacotes maliciosos. Os criminosos escolheram um alvo de alto valor: Jason Saayman, mantenedor líder do projeto.
Para ganhar sua confiança, os invasores se passaram por uma empresa legítima de tecnologia, copiando minuciosamente a marca, logotipos e até as fotos dos fundadores. O objetivo era criar um cenário crível o suficiente para que qualquer desenvolvedor acreditasse estar lidando com uma parceria real ou uma oportunidade profissional legítima.
Slack fraudulento com “vida própria”
O passo seguinte foi o convite de Saayman para um espaço de trabalho no Slack, supostamente pertencente à tal empresa. Esse workspace havia sido preparado com um nível de detalhe incomum:
– canais com nomes plausíveis para times de produto, engenharia e marketing
– interações encenadas entre perfis falsos
– compartilhamento de posts “reais” do LinkedIn
– contas que se passavam por funcionários e por outros mantenedores de projetos de código aberto
Saayman descreveu que o Slack parecia altamente autêntico. Os canais exibiam conteúdo que remetia às atividades reais da empresa clonada, incluindo reposts de publicações do LinkedIn que, ao que tudo indica, redirecionavam para a conta verdadeira da companhia. Havia ainda perfis que aparentavam ser membros da equipe, além de outros desenvolvedores de open source, reforçando a ilusão de uma comunidade técnica legítima.
A reunião no Teams que abriu a porta do ataque
Depois de construir esse ambiente de confiança, os atacantes marcaram uma reunião por Microsoft Teams. A chamada simulava a participação de várias pessoas, como seria comum em uma conversa de alinhamento técnico ou de parceria comercial.
Durante a reunião, surgiu então o elemento-chave do golpe: uma mensagem de erro informando que algo na máquina de Saayman estaria desatualizado e impedindo o funcionamento correto da sessão no Teams. A “solução” sugerida pelos invasores foi a instalação de uma suposta atualização do aplicativo.
À primeira vista, tudo parecia coerente com um problema técnico típico de videoconferência – ainda mais num contexto de trabalho colaborativo remoto, onde updates constantes são a norma. Foi exatamente essa normalização do cenário que os criminosos exploraram.
A falsa atualização que era, na verdade, um trojan de acesso remoto
O arquivo oferecido como “atualização do Teams” era, na realidade, um trojan de acesso remoto (RAT). Ao ser instalado, o malware concedeu aos atacantes controle sobre o dispositivo do mantenedor.
Com esse acesso, foi possível capturar credenciais sensíveis, incluindo os dados necessários para publicar novas versões do Axios no npm. O controle não era apenas pontual: uma vez implantado o RAT, qualquer ação realizada pelo mantenedor no dispositivo poderia potencialmente ser monitorada ou manipulada.
Publicação das versões maliciosas do Axios no npm
Munidos das credenciais de publicação, os criminosos lançaram duas versões comprometidas do Axios no registro npm:
– 1.14.1
– 0.30.4
Essas versões introduziam silenciosamente uma dependência adicional, chamada `plain-crypto-js`. Essa biblioteca, por sua vez, tinha a função específica de instalar um RAT em máquinas que utilizassem o pacote comprometido, mirando sistemas macOS, Windows e Linux.
As versões maliciosas permaneceram disponíveis por cerca de três horas antes de serem identificadas e removidas. Embora o tempo pareça curto, a popularidade do Axios faz com que qualquer janela, mesmo pequena, seja perigosa: pipelines de CI/CD automatizados e atualizações automáticas podem ter puxado essas versões sem qualquer intervenção humana direta.
Consequências: dispositivos comprometidos e rotação urgente de credenciais
Qualquer sistema que tenha instalado as versões maliciosas durante o período em que estiveram disponíveis no npm deve ser tratado como potencialmente comprometido. Isso inclui:
– estações de desenvolvimento
– servidores de build
– ambientes de teste e produção
– máquinas de CI em nuvem
A recomendação é clara: realizar uma rotação completa de credenciais e chaves de autenticação usadas nessas máquinas. Isso inclui tokens de acesso, chaves de API, chaves SSH, segredos de aplicações e qualquer outro dado sensível que possa ter sido acessado via RAT.
Além da rotação, é necessário revisar logs, analisar atividades suspeitas e, quando possível, reinstalar sistemas a partir de bases confiáveis, principalmente em infraestruturas críticas.
Atribuição: grupo norte-coreano e malware conhecido em nova versão
O Google Threat Intelligence Group atribuiu o ataque a um grupo de ameaças ligado à Coreia do Norte, rastreado sob o identificador UNC1069. A conexão foi feita com base no uso do WAVESHAPER.V2, uma variante atualizada de um malware já conhecido em operações anteriores do mesmo grupo.
Esse tipo de atribuição mostra que não se tratou de uma ação isolada de cibercriminosos genéricos, mas de uma campanha sofisticada, possivelmente ligada a objetivos estratégicos de longo prazo, como espionagem, roubo de propriedade intelectual ou infiltração em cadeias de suprimentos de software.
Outros mantenedores também foram alvo
O ataque não se limitou ao Axios. Pelle Wessman, mantenedor de diversos projetos de código aberto, incluindo o framework de testes Mocha, relatou ter sido abordado na mesma campanha.
No caso de Wessman, o roteiro foi semelhante: contato inicial, tentativa de convencê-lo a instalar um aplicativo suspeito e, após a recusa, mudança de tática. Os atacantes então tentaram levá-lo a executar um comando via Curl, outra forma de introduzir o malware na máquina. Diante da resistência, todos os registros de conversa foram apagados pelos criminosos, evidenciando a preocupação em apagar rastros.
Uma campanha estruturada contra o ecossistema de código aberto
Relatos adicionais analisados por empresas de segurança indicam que múltiplos desenvolvedores proeminentes foram abordados com variações do mesmo golpe. Entre os alvos, havia mantenedores de pacotes amplamente utilizados e até colaboradores do próprio projeto Node.js.
O padrão se repetia:
1. Primeiro contato por canais profissionais, como LinkedIn ou mensagens diretas em ferramentas de chat.
2. Convite para um espaço privado de colaboração (geralmente Slack), supostamente relacionado a uma empresa legítima ou a um projeto técnico de alto nível.
3. Agendamento de uma chamada de vídeo, em que um “erro técnico” surgia, exigindo a instalação de um software adicional ou a execução de um comando.
4. Tentativa de instalação de malware, geralmente disfarçado de ferramenta corporativa ou atualização de aplicativo.
Essa abordagem reforça que o objetivo não era um único projeto, mas a cadeia de suprimentos de software como um todo, explorando a confiança depositada na figura dos mantenedores.
—
Lições para desenvolvedores e equipes de segurança
A partir desse caso, é possível tirar uma série de aprendizados práticos para quem trabalha com desenvolvimento, DevOps, segurança e manutenção de projetos open source.
1. Engenharia social de alta qualidade é a regra, não a exceção
Os invasores investem tempo em construir narrativas convincentes: perfis completos, espaços de trabalho cheios de conteúdo, reuniões com múltiplos participantes e até uso de sinais do mundo real, como posts legítimos de empresas. A velha recomendação de “desconfiar de mensagens mal escritas” é insuficiente diante desse nível de profissionalismo.
Desenvolvedores experientes, bem informados e tecnicamente sólidos também são vulneráveis, principalmente quando o ataque se apóia em ferramentas usadas no dia a dia (Slack, Teams, e-mail corporativo) e em cenários comuns (entrevistas, convites para colaboração, propostas de parceria).
2. Nunca instale software a partir de prompts em chamadas de vídeo
Uma regra prática essencial: qualquer pedido para instalar aplicativos, plugins, atualizações ou executar comandos durante uma chamada de vídeo deve acender um alerta máximo.
Mesmo que o convite pareça vir de uma empresa respeitável, o ideal é:
– encerrar a chamada
– verificar o domínio, a legitimidade do e-mail e os contatos oficiais da organização
– baixar qualquer software somente de portais oficiais, lojas oficiais ou repositórios verificados
Se a atualização for realmente necessária, ela não dependerá de um arquivo enviado por chat ou de um link improvisado durante a reunião.
3. Credenciais de publicação são ativos críticos
Para projetos populares, as credenciais de publicação (como tokens do npm, PyPI, registries privados, etc.) devem ser tratadas como segredos de altíssima sensibilidade. Boas práticas incluem:
– uso de tokens de curta duração sempre que possível
– armazenamento de credenciais em cofres de segredos, não em arquivos locais desprotegidos
– exigência de autenticação multifator para ações de publicação
– revisão periódica de acessos e tokens ativos
Em projetos maiores, vale considerar fluxos de CI/CD em que o desenvolvedor não publica diretamente a partir de sua máquina, mas dispara pipelines em ambientes mais controlados e monitorados.
4. Detecção rápida reduz danos, mas não os elimina
No caso do Axios, as versões maliciosas permaneceram ativas por cerca de três horas. Apesar de breve, esse intervalo foi suficiente para exigir uma resposta ampla, com recomendações de rotação de credenciais e análise de possíveis comprometimentos.
Isso demonstra que:
– automação para detecção de anomalias em pacotes (comportamento atípico de dependências, por exemplo) pode fazer a diferença
– alertas automáticos de mudanças críticas em projetos de alto impacto devem ser levados a sério
– redundância e observabilidade nas cadeias de compilação e deploy são fundamentais para identificar ações suspeitas rapidamente
5. Mantenedores precisam de suporte, não apenas cobrança
O caso evidencia uma fragilidade crônica do ecossistema de código aberto: muitos dos componentes críticos usados globalmente são mantidos por poucas pessoas, muitas vezes de forma voluntária ou sem uma estrutura robusta de segurança.
Esses mantenedores:
– não têm, em geral, equipes dedicadas de segurança
– lidam simultaneamente com desenvolvimento, suporte e gestão da comunidade
– são alvo direto de atacantes porque representam um ponto único de falha
Organizações que dependem fortemente de software open source precisam considerar investimentos em segurança compartilhada, auditorias independentes, patrocínio a ferramentas de análise e programas formais de apoio aos projetos-chave em sua stack.
6. Proteção da cadeia de suprimentos passa por educação contínua
Casos como o do Axios devem ser usados como material de treinamento recorrente para times de desenvolvimento, segurança e operações. É fundamental trabalhar:
– conscientização sobre engenharia social sofisticada
– exercícios de simulação de ataques (tabletop exercises)
– políticas internas claras sobre o que fazer em abordagens suspeitas
– canais dedicados para que desenvolvedores reportem tentativas de fraude sem receio
Quanto mais os times reconhecerem padrões de ataque (como convites inesperados, pressa por instalar ferramentas, insistência em comandos manuais), menor a chance de cair em armadilhas bem produzidas.
7. Usuários de bibliotecas populares também têm responsabilidade
Não basta confiar cegamente em qualquer versão mais recente de um pacote, por mais famoso e consolidado que seja. Boas práticas para consumidores de bibliotecas incluem:
– fixar versões (pinning) e evitar atualizações automáticas sem testes
– usar ferramentas de análise de dependências para detectar comportamentos estranhos
– acompanhar canais oficiais dos principais projetos usados em produção
– manter um plano de resposta para incidentes em pacotes de terceiros
Em incidentes de supply chain, quem consome bibliotecas não é apenas vítima passiva: decisões de arquitetura, automação e governança de dependências podem mitigar ou amplificar o impacto de um ataque.
—
O sequestro da conta do mantenedor do Axios demonstra que a linha de frente da segurança não está apenas nos firewalls ou nos sistemas de detecção de intrusão, mas nas pessoas que mantêm o software que sustenta praticamente toda a infraestrutura digital atual. Ao mirar diretamente esses indivíduos, atacantes conseguem, com um único golpe bem-sucedido, alcançar milhares de empresas e usuários finais.
Reforçar a proteção da cadeia de suprimentos de software exige uma combinação de tecnologia, processos e, principalmente, cultura de segurança – tanto em grandes organizações quanto entre mantenedores independentes. O caso Axios não é um episódio isolado, mas um alerta sobre o que já é a realidade da nova geração de ataques: sofisticados, personalizados e focados em alvos que, até pouco tempo atrás, raramente eram vistos como o elo mais fraco.