Nova onda de ataques contra npm ameaça credenciais, pipelines e ambientes cloud

O ecossistema npm voltou a ser alvo de ataques contra a cadeia de suprimentos de software, desta vez envolvendo tanto pacotes maliciosos quanto versões adulteradas de pacotes legítimos. Segundo análises da JFrog, Endor Labs, StepSecurity, Microsoft, Red Hat e OX Security, os invasores comprometeram dezenas de pacotes para distribuir um ladrão de informações escrito em Rust e uma nova variante de worm capaz de se espalhar automaticamente entre projetos, repositórios e ambientes de desenvolvimento.

A primeira campanha foi associada a um malware chamado IronWorm, identificado pela JFrog. De acordo com a empresa, o malware foi projetado para coletar segredos armazenados nas máquinas dos desenvolvedores, ocultar sua atividade por meio de um rootkit de kernel baseado em eBPF e se comunicar com seus operadores pela rede Tor. A combinação de roubo de credenciais, ocultação em nível de sistema e propagação por pacotes npm torna a ameaça especialmente perigosa para ambientes de desenvolvimento e integração contínua.

O IronWorm foi distribuído por meio de versões trojanizadas de pacotes publicados no registro npm. A atividade foi rastreada até uma conta npm comprometida chamada “asteroiddao”, usada para publicar versões de pacotes contendo um binário ELF em Rust. Esse binário era executado por meio de um hook de preinstall, mecanismo que permite rodar código automaticamente durante a instalação de um pacote.

A cadeia de ataque segue um padrão típico de comprometimento de supply chain. Primeiro, os invasores obtêm acesso a uma conta legítima ou confiável dentro do ecossistema de desenvolvimento. Em seguida, publicam uma versão adulterada de um pacote npm. Quando outro desenvolvedor instala o pacote, o hook de instalação executa o binário malicioso. A partir daí, o malware coleta credenciais, modifica projetos, injeta código malicioso em repositórios acessíveis e tenta se propagar para novos pacotes e organizações no GitHub.

A JFrog afirmou que o IronWorm tem semelhanças com o worm Shai-Hulud, justamente pelo uso de credenciais roubadas como mecanismo de propagação. Na prática, isso significa que a ameaça não se limita a infectar uma única estação de trabalho. Ao capturar tokens e chaves de acesso, o malware pode alcançar repositórios, pipelines, pacotes e ambientes de publicação, ampliando o impacto para outros desenvolvedores e organizações que dependem desses componentes.

O malware mira 86 variáveis de ambiente e diversos arquivos que podem conter credenciais relacionadas a OpenAI Codex, Anthropic, Claude, Google Gemini, Cursor, Amazon Web Services, Docker, Kubernetes, npm, configurações de vault e arquivos da carteira de criptomoedas Exodus. Esse conjunto de alvos mostra que os invasores buscam não apenas credenciais tradicionais de infraestrutura e cloud, mas também configurações associadas a assistentes de programação baseados em inteligência artificial.

Um detalhe incomum observado pela JFrog é que o componente de roubo de carteira possui uma lógica para ignorar a própria carteira do invasor. Até o momento da análise, essa carteira estava vazia e não apresentava transações registradas.

A empresa descreveu o IronWorm como uma arma de cadeia de suprimentos criada para encontrar segredos, modificar projetos e injetar código malicioso com o objetivo de se autopropagar pelo GitHub. Os commits maliciosos foram identificados em nove organizações do GitHub e apareceram com o autor “claude”, usando o endereço “claude@users.noreply.github.com”, em uma tentativa de se passar pelo chatbot de inteligência artificial da Anthropic.

Segundo a JFrog, a conta npm “asteroiddao” está ligada à organização GitHub “asteroid-dao”. Um usuário identificado como “ocrybit” era membro dessa organização e também de organizações relacionadas ao Arweave. A análise indica que o malware roubou as credenciais desse usuário e as utilizou para enviar commits maliciosos em repositórios aos quais ele tinha acesso. Esses commits inseriam malware em outros pacotes, que poderiam ser publicados posteriormente e infectar novos desenvolvedores.

Além disso, o payload tinha capacidade de substituir workflows existentes do GitHub Actions por um novo fluxo capaz de coletar segredos, gravá-los em um arquivo aparentemente inofensivo e enviá-los como artefato de build. Essa técnica reduz a necessidade de um servidor externo de comando e controle, já que o próprio ambiente de CI/CD passa a ser usado como meio de exfiltração.

Em ambientes de integração contínua, o IronWorm também abusa do fluxo de Trusted Publishing do npm para obter tokens de curta duração e publicar versões contaminadas no registro. Esse ponto é relevante porque explora mecanismos legítimos criados para dar mais segurança e rastreabilidade à publicação de pacotes, transformando-os em parte da cadeia de propagação.

Outro componente técnico importante é o uso de eBPF como rootkit em nível de kernel. O eBPF é uma tecnologia legítima do Linux usada para observabilidade, rede e segurança, mas pode ser abusada por malware para ocultar processos, conexões e atividades. No caso do IronWorm, o payload tenta esconder processos e dificultar a análise. No entanto, em sistemas com kernel lockdown habilitado, as técnicas de ocultação falham e os processos e sockets passam a ficar visíveis novamente.

Paralelamente ao IronWorm, pesquisadores da Endor Labs e da StepSecurity revelaram uma campanha distinta envolvendo uma nova variante do worm Miasma. A campanha comprometeu 57 pacotes npm em mais de 286 versões maliciosas. Essa nova onda ocorre depois de uma atividade anterior do Miasma que infectou 32 pacotes em mais de 90 versões sob o namespace @redhat-cloud-services em apenas 72 segundos.

Entre os pacotes afetados citados estão ai-sdk-ollama, autotel, awaitly, effect-analyzer, eslint-plugin-awaitly, executable-stories-cypress, http-uploader-dev, mountly, node-env-resolver e node-env-resolver-aws. Os dados roubados pelo malware eram exfiltrados para uma conta do GitHub chamada “liuende501”, atualmente inacessível. Segundo as informações divulgadas, até 236 repositórios foram preparados nessa conta. Ainda não está claro se a conta foi removida pelo GitHub ou apagada pelo próprio invasor.

A StepSecurity destacou uma técnica chamada “Phantom Gyp”. Em vez de usar scripts tradicionais de ciclo de vida, como preinstall ou postinstall, que normalmente são monitorados por ferramentas de segurança, o invasor abusa de um arquivo binding.gyp de apenas 157 bytes para acionar a execução de código durante o npm install. Com isso, a campanha consegue contornar grande parte das verificações focadas em scripts de instalação.

A cadeia do Miasma foi projetada para baixar e instalar o runtime JavaScript Bun, usado para carregar um coletor abrangente de credenciais. O malware busca segredos relacionados a AWS, Google Cloud, Microsoft Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, RubyGems, PyPI, SSH, gerenciadores de senha e assistentes de IA.

Um dos aspectos mais preocupantes dessa variante é o foco em configurações de assistentes de programação com IA. Segundo os pesquisadores, o malware injeta arquivos persistentes de backdoor em repositórios de projetos, que são executados sempre que um desenvolvedor abre o projeto em uma IDE assistida por IA. Esse comportamento mostra uma mudança importante no cenário de ameaças: ferramentas de desenvolvimento baseadas em inteligência artificial estão se tornando parte da superfície de ataque.

A Red Hat informou que a causa provável do incidente envolvendo Miasma foi o comprometimento de uma conta do GitHub usada para enviar commits não autorizados a repositórios da organização RedHatInsights. A Microsoft acrescentou que o payload operava em Linux, macOS e Windows, baixando dinamicamente a versão correta do Bun para cada plataforma, embora runners Linux de CI/CD pareçam ter sido o alvo principal.

De acordo com a Microsoft, em máquinas de desenvolvedores o malware roubava chaves SSH, credenciais de linha de comando, dados de navegadores e carteiras. Em ambientes de CI/CD, o Miasma extraía segredos da memória de runners do GitHub Actions, escalava privilégios usando sudo sem senha e republicava pacotes adulterados com proveniência SLSA falsificada para continuar a propagação downstream.

A nova variante do Miasma é avaliada como derivada do worm Shai-Hulud, usado por TeamPCP em campanhas recentes. Embora tenha mudanças consideradas em grande parte cosméticas, a funcionalidade central permanece semelhante. Ainda assim, a atribuição dos ataques mais recentes continua incerta, já que o código do Shai-Hulud foi publicado publicamente pelo próprio TeamPCP.

A OX Security identificou estágios adicionais na cadeia de ataque do Miasma. Entre eles está a busca por commits no GitHub contendo a string “firedalazer”, usada para recuperar outro payload. Esse mecanismo substitui a string “FIRESCALE”, anteriormente sinalizada como dead drop. O novo payload é um arquivo JavaScript chamado “index.js”, que contém uma versão alternativa do worm Shai-Hulud e transforma a infecção em um ciclo contínuo.

Nesse caso, os dados roubados são exfiltrados para repositórios públicos do GitHub com descrições como “Miasma : The Spreading Blight” ou “Miasma - The Spreading Blight”. A diferença sutil na formatação da descrição, incluindo o espaço entre “Miasma” e os dois-pontos, foi citada como um detalhe relevante. Atualmente, existem 82 repositórios desse tipo criados nas contas “0tabek16” e “windy629”.

Pesquisadores da OX Security alertaram que o invasor pode alterar dinamicamente os commits “firedalazer” no GitHub, criando novas versões do malware de forma mais adaptável. Com isso, o GitHub deixa de funcionar apenas como um ponto morto de entrega de payload e passa a atuar como um comando e controle adaptativo, aproveitando uma plataforma confiável e amplamente permitida em ambientes corporativos. Essa abordagem dificulta a detecção em nível de rede, já que muitas ferramentas de segurança não tratam o tráfego para o GitHub como suspeito.

As recomendações para desenvolvedores que instalaram versões afetadas incluem rotação imediata de credenciais, desativação de scripts de instalação e rebuilds nativos por padrão, além da fixação de pacotes com hashes de integridade. Para empresas, o incidente reforça a necessidade de monitorar contas de publicação, revisar permissões em organizações GitHub, aplicar controles em pipelines de CI/CD, proteger tokens de curta duração e tratar ferramentas de IA e IDEs assistidas como parte da superfície de risco.

Os ataques envolvendo IronWorm e Miasma demonstram como o ecossistema de desenvolvimento se tornou um alvo estratégico para grupos de cibercrime e operadores de campanhas avançadas. Ao comprometer pacotes usados por desenvolvedores, os invasores conseguem transformar dependências legítimas em veículos de espionagem, roubo de credenciais e propagação automática. O impacto pode alcançar ambientes cloud, repositórios privados, pipelines de build, registros de pacotes e organizações inteiras que dependem de componentes open source.