Preâmbulo
Na noite da última segunda-feira, eu estava trabalhando até tarde quando recebi um alerta do Slack de uma ferramenta de monitoramento que eu havia criado três dias antes. Axios foi comprometido; um dos pacotes npm mais populares do mundo.
Meu coração começou a acelerar, eu sabia que cada segundo era crucial para reagir e minimizar os danos. Mas, sinceramente, foi tão absurdo que pensei que devia ser um falso positivo. Verifiquei e revisei tudo algumas vezes, embora parecesse obviamente malicioso.
Não foi um falso positivo. Foi uma das maiores violações da cadeia de suprimentos já registradas no npm, presumivelmente atribuída a agentes estatais da Coreia do Norte. Conseguimos detectar o problema com uma prova de conceito que eu desenvolvi às pressas numa sexta-feira à tarde, rodando no meu laptop e usando inteligência artificial para ler as diferenças entre as versões.
Quero compartilhar a história toda. Como chegamos até aqui, o que eu construí e por que acredito que compartilhar isso abertamente torna todos um pouco mais seguros.
Estou preocupado com a cadeia de suprimentos há algum tempo.
Alguns incidentes recentes na cadeia de suprimentos realmente me tiraram o sono. O compromisso na cadeia de suprimentos é um problema complexo. Na Elastic, temos muitos desenvolvedores, e nossos clientes de segurança confiam em nós para protegê-los. Ficou claro que o status quo foi rompido e precisamos de novas tecnologias ou procedimentos para ajudar. Tive algumas ideias para um ecossistema mais confiável e validado por IA, baseado em princípios de controle de aplicativos, mas que limitasse custos e atritos.
Mas foi no acordo com Trivy que realmente me chamou a atenção. No dia 19 de março, um grupo chamado TeamPCP comprometeu a ação do GitHub aquasecurity/trivy-action (a mesma do popular scanner de segurança Trivy, sim, uma ferramenta de segurança). Eles injetaram um programa que roubava credenciais e coletava segredos de pipelines de CI/CD. Uma quantidade enorme de credenciais foi roubada.
Isso se espalhou rapidamente. Em 24 de março, o LiteLLM foi atingido. A TeamPCP roubou as credenciais de publicação do LiteLLM no PyPI através do pipeline Trivy comprometido e as usou para distribuir versões maliciosas que roubavam credenciais de forma agressiva. Chaves SSH, credenciais da nuvem, chaves de API, dados da carteira, tudo.
LiteLLM é um pacote que eu mesmo já utilizei. Então, pode-se dizer que naquele momento eu estava completamente "acordado à noite".
Eu sabia que, com todas as credenciais vazadas na violação de segurança da Trivy, certamente haveria mais. Precisávamos fazer algo para nos mantermos à frente disso. Tanto para o bem dos nossos clientes quanto para proteger a Elastic.
Sexta-feira, depois do voo noturno
Eu tinha acabado de voltar da RSAC 2026 em São Francisco. Voo noturno na quinta-feira à noite. Se você já fez um voo noturno depois de quatro dias de conferência, sabe no estado em que eu estava. No entanto, eu estava tão animado como sempre para um novo projeto, então sentei e desenvolvi a versão 0.0.1.
A ideia: monitorar as alterações à medida que são enviadas para os repositórios de pacotes. Execute um diff para ver o que mudou. Utilize IA/LLM para determinar se as alterações são maliciosas. Basicamente é isso.
O pipeline tem a seguinte aparência:
- Consulte a API de changelog do PyPI e o feed do
_changesdo npm para novas versões. - Filtre com base em uma lista de observação dos 15.000 pacotes mais populares por número de downloads.
- Baixe as versões antigas e novas diretamente do registro (sem pip install, sem npm install, sem execução de código).
- Compare-os em um relatório Markdown.
- Envie a diferença para um LLM: "isso é malicioso?"
- Em caso afirmativo, avise o Slack.
Eu queria me concentrar principalmente nos pacotes mais populares, já que é muito provável que os atacantes busquem esses pacotes de qualquer maneira, e isso seria muito menos custoso em termos de tokens e poder computacional. Foi perfeitamente possível executar o programa no meu laptop.
Por que o cursor?
Existem muitos sistemas de segurança para agentes disponíveis no mercado. Eu escrevi as minhas próprias para projetos como engenharia reversa de malware de IA. Mas eu estava com pouco tempo, então optei por usar o Cursor, já que é uma das minhas principais ferramentas de desenvolvimento. A CLI do agente permite invocá-lo programaticamente: basta passar um espaço de trabalho, uma instrução e um modelo. Eu o executo no modo ask (somente leitura), então ele só pode ler as diferenças, nunca modificar nada. Toda a etapa de análise consiste em uma única chamada de subprocesso.
A instrução é simples. Eu digo a ele o que procurar (código ofuscado, base64, exec/eval, chamadas de rede inesperadas, esteganografia, mecanismos de persistência, abuso de script de ciclo de vida) e peço que ele responda com Verdict: malicious ou Verdict: benign. Analise o veredicto e aja de acordo com ele.
Sobre a seleção do modelo
Normalmente uso Opus 4.6 ou GPT 5.4 para a maioria das coisas. Opus especialmente desenvolvido para tarefas focadas em cibersegurança. Mas eu queria manter os custos baixos para algo que precisa analisar dezenas de versões por hora.
Ultimamente, a equipe do Cursor publicou alguns posts muito bons no blog, um sobre busca rápida por expressões regulares para ferramentas de agentes e outro sobre sua abordagem de aprendizado por reforço em tempo real, na qual eles usam tokens de inferência de produção reais como sinais de treinamento e implementam pontos de verificação aprimorados aproximadamente a cada cinco horas. Engenharia verdadeiramente impressionante.
Então eu quis experimentar o Composer 2 . Usei o modo rápido, que é realmente muito rápido. Ideal para uso em tempo real. Baixo custo, rápido e eficaz (nos meus testes).
Testando no Telnyx
É preciso testar essas coisas para saber se elas realmente funcionam. Normalmente, isso significa ajustar bastante os prompts.
Tive sorte (ou azar) com o timing. Na mesma sexta-feira em que eu estava desenvolvendo isso, o pacote telnyx do PyPI foi comprometido pelo TeamPCP. Eles injetaram 74 linhas de código malicioso em _client.py: payloads ocultos dentro de arquivos de áudio WAV (esteganografia), ofuscação base64, um implante de persistência do Windows disfarçado de msbuild.exe e exfiltração para um C2 codificado.
Usei a diferença entre o pacote telnyx legítimo e o malicioso para construir o prompt inicial. O modelo se mostrou muito eficiente na identificação de alterações maliciosas como essa. Eu também queria saber imediatamente quando uma violação de segurança fosse detectada, então adicionei alertas do Slack.
Segunda à noite
Deixei rodando durante o fim de semana. O sistema processava várias versões, e todas retornavam sem problemas.
Nunca tive um único falso positivo, o que é realmente estranho para quem já trabalhou com detecção em cibersegurança. Normalmente estamos afogados em FPs. Instruí intencionalmente o LLM a alertar apenas sobre comprometimentos da cadeia de suprimentos de "alta confiança", já que eles geralmente são muito propensos a disparar alertas assim que configurados. Ainda estou processando o caso de teste da Telnyx, sem falsos positivos. Pode ser que esteja ocorrendo sobreajuste com um tamanho de amostra tão pequeno, mas não há tempo para construir algo mais robusto.
Então, na noite de segunda-feira, enquanto trabalhava até tarde, chegou o alerta do Slack.
🚨 Supply Chain Alert: axios 0.30.4
Verdict: MALICIOUS
npm: https://www.npmjs.com/package/axios/v/0.30.4Será que realmente acabou de descobrir uma das maiores falhas na cadeia de suprimentos da história recente?
Verifiquei a análise. Verifiquei novamente. Verifiquei novamente. Os atacantes comprometeram a conta npm de um mantenedor, alteraram o endereço de e-mail para uma conta ProtonMail que controlavam e publicaram duas versões maliciosas (1.14.1 e 0.30.4). Eles não injetaram código diretamente no Axios. Em vez disso, adicionaram uma dependência fantasma chamada plain-crypto-js que executava um gancho pós-instalação implantando malware multiplataforma. Obviamente foi malicioso.
A resposta
Entrei em contato imediatamente com nossa equipe de segurança da informação e com a equipe de pesquisa da Elastic para que elas pudessem começar a trabalhar imediatamente. Eu sabia que cada segundo importava. Descobri que, quando entrei em contato com eles, já haviam recebido alertas do Elastic Defend sobre um host que tinha instalado o pacote malicioso e estavam respondendo ativamente. Mas naquele momento ninguém havia percebido a dimensão do problema ou compreendido a causa raiz de como a máquina foi infectada. A ferramenta de monitoramento forneceu o contexto que faltava.
Tentei enviar um e-mail para security@npmjs e recebi uma mensagem de erro. Tentei enviar o documento pelo portal de segurança deles e recebi um erro. Eu postei um tweet em desespero, tentando conseguir falar com um ser humano. Rapidamente também abri uma ocorrência de segurança no próprio repositório do Axios.
Mais tarde, vi um tweet de outro pesquisador que havia observado a falha de segurança e percebi que estava lidando com isso mais como uma vulnerabilidade do que como um incidente na cadeia de suprimentos. Com uma vulnerabilidade, você se coordena discretamente. Com uma infecção ativa que está instalando malware nos computadores das pessoas neste exato momento, adotar medidas de segurança amplas e transparentes é a decisão correta. Então, imediatamente compartilhei todos os detalhes que havia compilado com X.
Começamos até a receber alertas de nossa telemetria mostrando organizações afetadas em atividade. O aparelho estava em pleno funcionamento.
Felizmente, a equipe da Axios agiu rapidamente e removeu os pacotes. Além disso, o servidor C2 do atacante estava recebendo tantas solicitações que estava entrando em colapso. Poderia ter sido muito pior.
Nossa equipe da Elastic Security Labs publicou relatórios técnicos completos sobre a violação de segurança. A primeira parte aborda a cadeia de ataque de ponta a ponta, o malware multiplataforma e o protocolo C2: Por dentro da violação da cadeia de suprimentos da Axios - um RAT para governar todos. A segunda aborda as regras de busca e detecção em Linux, Windows e macOS: a Elastic divulga detecções para a violação da cadeia de suprimentos da Axios.
Para onde vamos a partir daqui?
O estado atual das coisas não é bom e precisamos melhorar como um todo o ecossistema de software, sem falar da indústria de segurança.
Daqui a duas semanas, em março:
- O Trivy (um scanner de segurança) foi comprometido para roubar segredos de CI/CD.
- O LiteLLM foi comprometido usando esses segredos roubados.
- A Telnyx foi comprometida na mesma campanha.
- O Axios, um dos pacotes mais utilizados no npm, foi comprometido por um suposto agente da Coreia do Norte.
- E muito mais
Os registros de pacotes são infraestrutura crítica. As equipes responsáveis pelo PyPI e pelo npm estão fazendo um ótimo trabalho, mas a ameaça já ultrapassou a capacidade dos modelos de confiança atuais. Precisamos de um monitoramento automatizado melhor para as alterações nos pacotes. Não se trata apenas de escanear assinaturas, mas sim de entender o que o código faz. Os mestres em Direito (LLM) são realmente bons nisso, como este projeto demonstra. E precisamos que a rotação de credenciais após violações de segurança aconteça mais rapidamente. A cascata de Trivy para Litellm e para Telnyx aconteceu porque as credenciais roubadas não foram rotacionadas com rapidez suficiente.
Uma medida prática que você pode tomar agora mesmo: não instale atualizações de pacotes imediatamente. Adicione um tempo de imersão. Deixe as novas versões em repouso por um período antes de suas compilações as incorporarem. Fazemos isso com nossos sistemas de CI/CD na Elastic em resposta ao shai-hulud. Isso não vai impedir tudo, mas dá à comunidade tempo para detectar vulnerabilidades antes que elas afetem seus pipelines de CI/CD e máquinas de desenvolvedores. A boa notícia é que muitos gerenciadores de pacotes adicionaram suporte nativo para isso. Por exemplo, para impor um atraso de 7 dias:
npm config set min-release-age 7
pnpm config set minimum-release-age 10080
yarn config set npmMinimumReleaseAge 10080
uv --exclude-newer "7 days ago"Estamos disponibilizando isso como código aberto.
Estamos lançando a ferramenta: monitor de cadeia de suprimentos
Quero ser sincero. É uma prova de conceito. Eu o construí em uma tarde, sem dormir. Não espero que ninguém o execute em nível de produção. É necessária uma assinatura do Cursor para a análise do LLM, os lançamentos são processados sequencialmente e as listas de monitoramento são estáticas.
Mas a abordagem funciona. A comparação em tempo real das versões de pacotes e o uso de IA para classificar as alterações detectaram um ataque à cadeia de suprimentos de um dos pacotes mais populares do npm.
Estou compartilhando isso porque é melhor para a comunidade aprender com nossas experiências. Se alguém pegar essa ideia e construir algo melhor, ótimo. Se a equipe do registro de pacotes incorporar isso ao seu fluxo de trabalho, melhor ainda. Se isso significar que outra pessoa terá uma grande chance de se defender na próxima vez, então valeu a pena.
Como funciona (para os curiosos)
Monitoramento: Duas threads consultam o PyPI (via changelog_since_serial() XML-RPC) e o npm (via feed CouchDB _changes ). Novos lançamentos que correspondem à lista de observação dos N itens mais populares são colocados em fila. O estado persiste em last_serial.yaml então ele continua de onde parou.
Comparação de diferenças: versões antigas e novas baixadas diretamente das APIs do registro. Sem pip/npm install, não há execução de código. Arquivos extraídos, hashes calculados e relatório de diferenças unificado gerado em Markdown.
Análise: O relatório de diferenças é enviado para a CLI do Cursor Agent em modo somente leitura. O prompt pede para procurar indicadores da cadeia de suprimentos. A saída foi analisada para obter o veredicto.
Alerta: Veredicto malicioso envia uma mensagem para o Slack com o nome do pacote, classificação, link do registro e resumo da análise.
Inteligência artificial na segurança, além deste projeto
A segurança da cadeia de suprimentos é uma questão importante, mas não estamos impotentes. A IA nos fornece novas ferramentas para defesa em larga escala e na velocidade das máquinas. Este projeto é um exemplo de como usar IA para ajudar a resolver um problema de segurança, mas temos feito muitos trabalhos interessantes com IA em toda a Elastic Security. Um ponto que eu gostaria de destacar: nossa equipe publicou recentemente um artigo sobre como usar o Attack Discovery, Workflows e Agent Builder para detectar e confirmar automaticamente ataques do tipo APT. Isso demonstra o poder da Plataforma Elástica, que oferece segurança orientada a agentes para melhorar significativamente a eficiência e a eficácia do seu SOC em um momento em que estamos coletivamente sobrecarregados por ataques.
O projeto supply-chain-monitor está disponível em github.com/elastic/supply-chain-monitor.
Agradecemos à equipe da Elastic Infosec pela rápida resposta ao incidente, aos mantenedores do Axios pela rápida remoção do malware e à comunidade de segurança pelo esforço coletivo que limitou o impacto.