00:00:00Esta pode ser uma das maiores violações da cadeia de suprimentos NPM que já vimos,
00:00:03e não, isso não é uma pegadinha de 1º de abril, é apenas um momento ruim e as pessoas precisam estar cientes disso.
00:00:07Aconteceu no pacote Axios; o cliente HTTP foi instalado 101 milhões de vezes esta semana
00:00:13e tem mais de 174.000 dependentes. Por isso, já impactou pacotes como Datadog,
00:00:18OpenClaw e WordPress, e também foi associado a hackers norte-coreanos.
00:00:22Então, vamos direto ao assunto e ver o que aconteceu.
00:00:29Aqui está a história: em 31 de março de 2026, um invasor comprometeu a conta NPM
00:00:34do mantenedor principal do Axios e publicou duas versões com backdoor: a versão 1.14.1, que
00:00:39foi marcada como a versão mais recente, e também a versão 0.30.4, marcada como legado.
00:00:44Nesses pacotes, eles introduziram uma dependência fantasma chamada plaincryptojs,
00:00:48que era essencialmente o pacote crypto.js normal, mas com um pequeno ajuste:
00:00:52ele tinha um script de pós-instalação chamado setup.js. Isso significa que todos e cada CI instalando
00:00:58esses pacotes comprometidos também estavam executando esse script. O script em si continha
00:01:02código ofuscado que verificava qual sistema operacional você estava usando e se conectava a um servidor
00:01:07para baixar um segundo payload relevante para o seu sistema operacional. Portanto, ninguém
00:01:12estava a salvo desse ataque e eles chegaram ao ponto de garantir que o payload do Mac OS
00:01:16funcionasse tanto em Macs Intel quanto Apple. E é o segundo payload que é o realmente ruim;
00:01:20este é o RAT, ou cavalo de Troia de acesso remoto, e funciona basicamente da mesma forma em todos
00:01:25os sistemas operacionais. Primeiro, ele escaneava seus arquivos percorrendo suas pastas de documentos, área de trabalho
00:01:29e configurações, e a versão para Windows estava até escaneando seu OneDrive, AppData e cada
00:01:33letra de unidade que você tivesse no sistema, enviando então essa lista de arquivos de volta para o servidor,
00:01:38provavelmente para verificarem se havia algo que valesse a pena roubar. Depois disso, ele começava
00:01:42o beaconing: a cada 60 segundos, ele fazia contato com o nome do host, nome de usuário, sistema operacional,
00:01:47fuso horário, modelo de hardware e uma lista completa de todos os processos em execução para que o invasor pudesse ver
00:01:52qual software você está rodando e se o está usando ativamente. E se tudo isso não parece ruim
00:01:56o suficiente, a pior parte ainda está por vir, pois a qualquer momento o invasor poderia emitir remotamente quatro comandos
00:02:00que permitiriam navegar em qualquer diretório do seu sistema, executar comandos de shell ou scripts arbitrários,
00:02:05soltar e executar malware adicional ou até mesmo encerrar todo o processo para apagar seus rastros. Na verdade,
00:02:10eles até garantiram que o script de configuração original se deletasse, excluísse o package.json
00:02:15que continha a pós-instalação e o substituísse por uma versão limpa para tentar tornar isso o mais
00:02:19indetectável possível. Então, você pode ver que esse ataque foi realmente sério e projetado para
00:02:23visar estações de trabalho de desenvolvedores e executores de CI/CD em busca de todos os tipos de segredos, como arquivos .env,
00:02:28tokens NPM, chaves SSH e qualquer outra coisa; qualquer sistema que tenha executado esses payloads maliciosos
00:02:34deve ser tratado como um cenário de roubo total de credenciais. Além de tudo isso, há também
00:02:38o mistério de como a conta NPM foi comprometida. O mantenedor observou que possui autenticação de dois fatores ativada e
00:02:43seus pipelines do GitHub Actions também têm autenticação ativada. Portanto, o que parece ter acontecido é que
00:02:47os pacotes foram publicados usando o NPM CLI através de um token de acesso NPM de longa duração. Então, a próxima pergunta
00:02:53é como eles conseguiram acesso a esse token, e o mantenedor até pensa que alguém pode ter
00:02:56obtido seus códigos de recuperação de conta, mas como fizeram isso é um mistério completo por enquanto. Se você quiser
00:03:01verificar se foi afetado por algo disso, certifique-se de pesquisar em seus arquivos lock pelas versões impactadas do
00:03:04axios, bem como pelo pacote plaincryptojs, e também pesquise em seus node_modules pelo
00:03:09pacote em si. Se você vir algum deles, infelizmente, são más notícias. Você também pode verificar
00:03:14seu sistema em busca de artefatos de RAT, e deixarei relatórios completos sobre isso no link abaixo para que possa seguir
00:03:18os passos e saber o que fazer se tiver sido comprometido. No futuro, também há alguns
00:03:22passos que você pode tomar para tentar prevenir esses ataques, e o primeiro é sempre fazer o commit dos seus arquivos lock
00:03:26e garantir que está usando o comando npm ci em vez do comando npm install em seus pipelines.
00:03:31Você também deve garantir que tenha uma idade mínima definida no seu gerenciador de pacotes, garantindo que
00:03:35os pacotes tenham pelo menos 48 horas de vida antes de serem instalados, com a esperança de que qualquer um malicioso
00:03:39seja pego a tempo, já que este do axios foi descoberto e deletado três horas depois. Finalmente,
00:03:44se possível, apenas use a flag --ignore-scripts ao executar o npm install ou use um gerenciador de pacotes
00:03:48como o bun, que na verdade bloqueia todos os scripts de pós-instalação por padrão e só os executa em
00:03:53dependências que você listou especificamente como confiáveis. Espero que este seja o maior ataque que
00:03:57veremos este ano, mas definitivamente estamos vendo cada vez mais deles, então certifique-se de se manter seguro
00:04:01por aí e deixe-me saber o que você pensa de tudo isso nos comentários abaixo
00:04:04ou clique em se inscrever e, como sempre, vejo você no próximo.