IronWorm: worm em Rust com rootkit eBPF e C2 via Tor compromete 37 pacotes npm do ecossistema Arweave

A JFrog Security Research divulgou em 3 de junho a descoberta do IronWorm, um worm de supply-chain escrito em Rust que comprometeu 37 pacotes npm, infectou 57 commits em 9 organizações ligadas ao ecossistema Arweave e combina rootkit eBPF de kernel, comando e controle por Tor e auto-replicação via OIDC do npm. O malware é descrito pelos pesquisadores como uma evolução técnica direta do Shai-Hulud — “o primo enferrujado” — e marca uma nova etapa nos ataques contra cadeias de desenvolvimento.

O que aconteceu

A equipe da JFrog acompanhava os pacotes publicados pela conta npm asteroiddao, vinculada à organização GitHub asteroid-dao dentro do ecossistema de banco de dados descentralizado Arweave/WeaveDB, quando notou que todos os pacotes da conta haviam sido republicados na mesma janela curta de tempo. Cada nova versão trazia um binário nativo executado por hook de instalação. A investigação revelou um exemplar de 976 KB embarcado em tools/setup e disparado via preinstall definido no package.json — gatilho que roda antes mesmo de o npm começar a resolver dependências.

A OX Security, que também rastreou a campanha, contabilizou pelo menos 36 pacotes npm únicos com mais de 32 mil downloads mensais combinados. Os commits maliciosos foram atribuídos publicamente ao desenvolvedor ocrybit, membro das organizações Arweave comprometidas, cujas credenciais foram roubadas e usadas para empurrar código em todos os repositórios ao alcance da conta.

Pouco depois da publicação da pesquisa, parte das versões maliciosas foi marcada como deprecada no npm e vários dos commits sumiram do GitHub — mas a JFrog adverte que a conta comprometida tinha cerca de 4.500 contribuições privadas no mês, sugerindo que o impacto real pode ser bem maior do que a parte visível.

Como o ataque funciona

O binário é um ELF Linux empacotado com um stub UPX modificado: o atacante sobrescreveu o magic UPX! para enganar a detecção do unpacker padrão, mas restaurar o marcador permite desempacotar normalmente — um truque anti-análise de baixo custo. Por dentro, é uma build de release em Rust com runtime async, milhares de funções e strings criptografadas individualmente: não há uma chave única que desbloqueie tudo, cada call site usa parâmetros próprios, exigindo trabalho de engenharia reversa manual e demorado.

Decifradas, as strings entregaram o arsenal completo: endpoints da API do GitHub, listas longas de variáveis de ambiente associadas a credenciais de provedores cloud e de IA, caminhos de arquivos de credenciais no disco, identidades de bots vinculadas a IDs reais do GitHub, e templates de injeção de código para múltiplos ecossistemas de pacotes (npm, PyPI, Cargo, Conan e vcpkg).

“Esta é uma arma de supply-chain construída para encontrar segredos, modificar projetos e injetar código malicioso para se autopropagar pelo GitHub”, afirmam os pesquisadores da JFrog no relatório.

Dois payloads, dois disfarces

O malware adapta a carga ao alvo. Se o repositório distribui um pacote, o IronWorm derruba um binário em um caminho aparentemente inocente — tools/setup ou .github/scripts/precheck — e modifica o sistema de build para executá-lo: preinstall no npm, subprocess no setup.py do PyPI, build-script hook no Cargo. Esses commits chegam assinados pelo autor claude <claude@users.noreply.github.com>, imitando um assistente de IA para que o novo hook de build pareça automação de rotina.

Se o repositório já usa GitHub Actions, o caminho é mais sujo: o malware não cria um arquivo novo, ele substitui um workflow existente por um job de exfiltração de segredos. A engenharia social do ataque está em reaproveitar funcionalidades legítimas do Actions — a expressão ${{ toJSON(secrets) }} serializa todos os segredos do run em um único valor, despejados em um arquivo com nome banal (“format-results.txt”) e enviados como artefato de build. Sem C2 externo. Os commits dessa variante adotam identidades de bots familiares (dependabot, renovate, github-actions), porque um ajuste rotineiro de CI vindo de um desses é justamente o tipo de mudança que ninguém olha.

Os commits ainda chegam com datas forjadas: o malware copia o timestamp do último commit legítimo do repositório, fazendo a injeção parecer ter quatro, sete ou até treze anos de idade. Apenas o log do GitHub Actions revela a verdade.

Rootkit eBPF, C2 por Tor e auto-publicação no npm

O implante carrega um objeto BPF compilado com clang 22.1.5 que opera como rootkit de kernel. Ele reescreve o conteúdo de /proc em tempo real para esconder processos da lista de ps, top e ls; intercepta cada execve para esconder automaticamente processos cujo nome bate com uma watchlist; bloqueia ptrace contra processos protegidos com SIGKILL (rodar strace contra o malware pode matar o próprio shell que executou o comando); e filtra /proc/net/tcp e o netlink para remover conexões ocultas das ferramentas de rede. Em sistemas com kernel lockdown habilitado, parte desses truques falha silenciosamente — mas em servidores stock rodando como root o conjunto funciona inteiro.

O canal de comando e controle baixa o Tor expert bundle, escreve um torrc próprio, sobe o daemon e bate em /api/agent. Os comandos disponíveis incluem upload de segredos extraídos, drop de arquivos do servidor controlado pelo atacante e execução de shell remota. Há ainda um caminho de fallback que usa o serviço público temp.sh tunelado pelo Tor.

A capacidade de auto-replicação no npm é elegante e perigosa: quando rodando em ambiente CI, o malware solicita um token OIDC do CI, troca esse token no endpoint /-/npm/v1/oidc/token/exchange/package/<pkg> e recebe um token automation de curta duração escopado ao pacote. Com isso publica versão trojanizada — sem nunca tocar em credencial armazenada do npm.

Quem é afetado

• Desenvolvedores Web3 e do ecossistema Arweave/WeaveDB — alvo primário. Nove organizações já confirmadas: ocrybit, asteroid-dao, alisista, warashibe, kakedashi-hacker, weavedb, ArweaveOasis, arthursimao e mlebjerg.
• 86 variáveis de ambiente alvo do scanner, cobrindo provedores cloud (AWS, GCP, Azure), object storage, bancos de dados, tokens de source-control e package-registry, sistemas CI/CD, Vault e Kubernetes.
• 14 chaves de API de IA — Anthropic, OpenAI, Gemini, Cohere, Mistral, Groq, Perplexity, xAI e outras — sinal claro de adaptação ao stack típico de um desenvolvedor em 2026.
• Mais de 20 caminhos de arquivos de credenciais, incluindo ~/.claude/.credentials.json, ~/.codex/auth.json, ~/Cursor/auth.json, ~/.gemini/settings.json, além dos clássicos ~/.aws/credentials, ~/.kube/config e ~/.docker/config.json.
• Carteiras Exodus via módulo dedicado que injeta hook JavaScript no Electron e enfraquece proteções (webSecurity, sandbox, contextIsolation, nodeIntegration) para capturar senha e seed mnemonic.
• Clusters Kubernetes — outro módulo lê o token de service-account dentro do pod, enumera namespaces, dumpeia Secrets e, se houver Vault, faz login com o mesmo token e enumera os backends.

Análise

O IronWorm é a confirmação de uma tese que vinha se desenhando desde o Shai-Hulud em 2025: ataques de supply-chain estão deixando de ser scripts em JavaScript baratos e curtos para se tornarem implantes nativos completos, com runtime moderno, criptografia, persistência em kernel e canais ocultos. A escolha de Rust não é estética — é defensiva. Binários Rust são notoriamente difíceis de fazer engenharia reversa: trazem runtime async, milhares de funções de framework e padrões de chamada que afogam a lógica do próprio malware. Combinar isso com criptografia de string por call site, UPX modificado e rootkit eBPF eleva o custo de análise em ordens de magnitude — exatamente o ponto onde a maioria das equipes de SOC desiste.

A comparação direta com o Shai-Hulud é proposital. Os dois compartilham a ideia central: comprometer desenvolvedores, roubar credenciais e usar workflows confiáveis da cadeia de software para se espalhar — inclusive reaproveitando as mesmas mensagens de commit. Mas o IronWorm leva o conceito ao próximo nível em sofisticação, e essa elevação técnica é o que importa para a defesa. O modelo está se profissionalizando.

Há, porém, sinais claros de que o operador ainda está em rodada de testes. O objeto BPF foi compilado com clang 22.1.5 sem strip — sobraram 214 linhas verbatim de código-fonte e metadados que permitiram à JFrog reconstruir q2.bpf.c e entender a mecânica do rootkit. Pior ainda, o operador codificou no binário uma seed BIP-39 inteira para que o stealer não roubasse a própria carteira de teste durante desenvolvimento — uma pista de atribuição que reverte ao endereço Ethereum 0x7e28D9889f414B06c19a22A9Bd316f0AC279a4d6. A carteira está quase vazia, mas o erro operacional é significativo: indica que esta provavelmente não é a forma final da campanha, é o ensaio.

Para quem defende, o recado é simples: o tempo em que se podia confiar que um commit assinado por dependabot ou github-actions era seguro acabou. As identidades de bot viraram vetor. E o caminho de exfiltração via artefato de Actions, que não foi observado em produção mas está no código, é tecnicamente a parte mais perigosa do implante porque elimina a necessidade de C2 externo — segredos do CI viram um arquivo baixável por quem tem acesso ao repositório.

Recomendações práticas

• Auditar imediatamente repositórios em que a conta comprometida tenha tido acesso de escrita. Procurar commits com datas retroativas, branches inesperados, hooks de build novos e mudanças atribuídas a claude, dependabot[bot], renovate[bot], github-actions[bot] e outras identidades de automação fora do contexto normal de uso.
• Para pacotes npm afetados, deprecar ou despublicar versões maliciosas onde possível e publicar versão limpa com advisory de segurança claro.
• Rotacionar TODAS as chaves e segredos acessíveis pela conta comprometida, em todos os 86 contextos varridos pelo malware — cloud, AI, Vault, Kubernetes, registries e CI/CD.
• Habilitar kernel lockdown em hosts de build e em CI runners para neutralizar parte das capacidades do rootkit eBPF.
• Bloquear o uso de Trusted Publishing do npm via OIDC sem aprovação humana adicional em projetos sensíveis; considerar exigir review obrigatório para todo workflow do GitHub Actions modificado.
• Implementar varreduras de pacotes em pipeline com cobertura para os 37 IoCs publicados pela JFrog (lista em XRAY-989492 até XRAY-989790) e monitorar novos pacotes do ator asteroiddao e organizações relacionadas.
• Para desenvolvedores Web3: revisar carteiras Exodus instaladas em máquinas de desenvolvimento e rotacionar seeds; tratar máquinas de dev que rodaram qualquer pacote suspeito como comprometidas até prova em contrário.
• Monitorar conexões de saída para nós Tor a partir de hosts de desenvolvimento e build — não é tráfego esperado em CI/CD legítimo.

Fonte: JFrog Security Research