IronWorm compromette npm e GitHub con Rust, rootkit eBPF e furto di credenziali

IronWorm emerge come una delle minacce supply chain più sofisticate osservate nell’ecosistema degli sviluppatori open source, con una combinazione di Rust, pacchetti npm malevoli, compromissione di repository GitHub, furto esteso di credenziali e un rootkit kernel basato su eBPF. La scoperta di JFrog Security Research descrive il malware come un cugino più arrugginito di Shai-Hulud, perché ne riprende la logica di propagazione attraverso flussi di sviluppo fidati, ma la potenzia con tecniche di stealth avanzate e capacità di adattamento ai repository bersaglio. Il campione analizzato, collegato a [email protected], esegue durante l’installazione un binario Linux ELF da 976 KB senza intervento dell’utente, trasformando un normale comando npm install in un vettore di compromissione dell’ambiente di lavoro. L’attacco prende di mira sviluppatori attivi in ecosistemi crypto, AI, cloud e infrastrutture open source, sfruttando account e repository legati ad Arweave e WeaveDB. Il ricercatore individua 57 commit malevoli distribuiti su nove organizzazioni GitHub, con backdating artificiale e attribuzioni ingannevoli a bot apparentemente fidati. IronWorm non si limita a rubare segreti: modifica repository, inserisce dropper, replica pacchetti e usa Tor per il comando e controllo. L’errore dell’operatore, che lascia nel codice una recovery phrase BIP-39 associata a un wallet Ethereum, aggiunge un elemento raro in un’operazione tecnicamente complessa e dimostra quanto anche campagne avanzate possano tradirsi attraverso dettagli operativi trascurati.

IronWorm nasce come worm Rust per colpire sviluppatori e supply chain

IronWorm viene presentato da JFrog Security Research come un malware scritto in Rust progettato per compromettere sviluppatori e infrastrutture software attraverso pacchetti apparentemente legittimi. La scelta di Rust non è casuale: il linguaggio produce binari complessi da analizzare, integra runtime e astrazioni che aumentano il rumore durante il reverse engineering e permette agli operatori di realizzare codice performante, portabile e resistente all’analisi superficiale. Il worm condivide con Shai-Hulud l’idea di sfruttare workflow fidati e credenziali degli sviluppatori, ma introduce un livello superiore di stealth grazie all’integrazione di un rootkit eBPF e a una catena di infezione che parte dai package manager per arrivare ai repository GitHub. IronWorm prende di mira account e organizzazioni inseriti in ecosistemi dove i segreti hanno valore immediato, in particolare progetti crypto, repository con workflow CI/CD e ambienti che usano chiavi cloud, token GitHub, credenziali AI e configurazioni Kubernetes. L’obiettivo non è una singola macchina, ma l’intera relazione di fiducia tra pacchetto, sviluppatore, repository e registry. Una volta eseguito, il malware tenta di rubare credenziali locali, usarle per accedere a GitHub, modificare repository e inserire nuovi dropper che possano infettare altri utenti. Questo modello rende IronWorm particolarmente pericoloso perché trasforma ogni sviluppatore compromesso in un possibile nodo di propagazione. La presenza di commit backdatati, messaggi apparentemente innocui e attribuzioni a bot fidati conferma una strategia pensata per nascondere l’attacco dentro la normale attività di manutenzione del codice.

L’attacco parte da pacchetti npm pubblicati dall’account asteroiddao

La catena di infezione osservata da JFrog parte da pacchetti npm pubblicati dall’account asteroiddao, collegato all’organizzazione GitHub asteroid-dao e all’ecosistema Arweave e WeaveDB. Il pacchetto principale analizzato è [email protected], che contiene un binario ELF da 976 KB nella directory tools/setup. Il file package.json include un hook preinstall che esegue automaticamente il binario durante l’installazione del pacchetto. Questo dettaglio è decisivo perché elimina la necessità di un’azione esplicita da parte della vittima: lo sviluppatore installa il pacchetto, il gestore npm avvia lo script e IronWorm ottiene esecuzione sul sistema. Il malware si mimetizza tra file apparentemente coerenti con la struttura del progetto, riducendo la probabilità che un controllo manuale superficiale individui l’anomalia.

Una volta attivo, IronWorm inizia la raccolta di credenziali, cerca token GitHub e prepara la fase successiva di propagazione. La pubblicazione dei pacchetti malevoli in un intervallo temporale ristretto indica una campagna coordinata, non una compromissione occasionale. L’utilizzo di npm come vettore riflette una tendenza ormai consolidata nelle campagne supply chain: colpire l’anello di fiducia più vicino allo sviluppatore, cioè il package manager, dove la dipendenza viene installata spesso senza audit approfondito. IronWorm sfrutta esattamente questa dinamica e trasforma un pacchetto di sviluppo in un dropper capace di compromettere l’intero ambiente locale.

Il binario Rust usa packing, cifratura stringhe e anti-analisi

Il binario di IronWorm risulta impacchettato con una variante modificata di UPX, nella quale il magic value UPX! viene sovrascritto per ostacolare gli strumenti di unpacking automatico. Dopo il ripristino del marker, il file può essere scompattato con UPX standard, ma l’analisi rivela comunque un binario Rust in release con migliaia di funzioni e un runtime async che rende il reverse engineering particolarmente impegnativo. Il malware adotta una cifratura stringhe avanzata, utilizzando chiavi differenti per ogni chiamata di decrittazione. Questa tecnica impedisce l’estrazione immediata di indicatori utili e costringe il ricercatore a recuperare manualmente endpoint, percorsi file, variabili d’ambiente e template di iniezione. Le stringhe decifrate mostrano riferimenti a GitHub API, credenziali locali, percorsi cloud, configurazioni CI/CD e template per ecosistemi come npm, PyPI, Cargo, Conan e vcpkg. La presenza di questi riferimenti dimostra che IronWorm non è limitato a npm, ma è progettato per adattarsi a diversi gestori di pacchetti e linguaggi. Il malware include inoltre un payload eBPF compilato con clang 22.1.5, accompagnato da informazioni debug complete nella sezione .BTF.ext. Questo errore tecnico aiuta i ricercatori a ricostruire il funzionamento del rootkit kernel, ma conferma anche la natura avanzata dell’impianto. IronWorm combina quindi tecniche anti-analisi tipiche del malware moderno con un design modulare orientato alla compromissione estesa degli ambienti di sviluppo.

GitHub diventa il motore della propagazione automatica

Dopo l’esecuzione locale, IronWorm tenta di trasformare le credenziali rubate in accesso operativo ai repository GitHub della vittima. Il malware sfrutta token e sessioni disponibili per spingere commit malevoli, inserire dropper e modificare workflow o script di installazione. JFrog traccia 14 commit iniziali attribuiti falsamente a [email protected], mentre l’autore reale risulta ocrybit, membro di asteroid-dao. I commit vengono backdatati di circa tredici anni, copiando timestamp da modifiche legittime precedenti per mimetizzarsi nella cronologia del progetto. Git consente questa manipolazione temporale senza validazioni stringenti, permettendo agli operatori di nascondere modifiche recenti dietro date apparentemente antiche. La campagna coinvolge nove organizzazioni GitHub: ocrybit, asteroid-dao, alisista, warashibe, kakedashi-hacker, weavedb, ArweaveOasis, arthursimao e mlebjerg. In totale vengono osservati 57 commit malevoli, spesso accompagnati da messaggi banali come fix: resolve lint warnings, scelti per confondersi con normali interventi di manutenzione. Questo comportamento trasforma GitHub non soltanto in bersaglio, ma anche in infrastruttura di distribuzione. Ogni repository modificato può diventare un nuovo punto di esposizione per sviluppatori, CI/CD, package manager e utenti downstream, ampliando l’impatto della compromissione iniziale.

I commit backdatati nascondono il malware nella cronologia dei repository

La tecnica dei commit backdatati è uno degli elementi più insidiosi della campagna IronWorm. Invece di inserire modifiche facilmente visibili come commit recenti, il malware assegna timestamp storici alle modifiche, facendole apparire come parte di una vecchia attività del repository. Questa manipolazione riduce la probabilità che un maintainer individui l’alterazione durante controlli rapidi basati sulla cronologia recente. I messaggi di commit sono costruiti per apparire innocui e coerenti con la manutenzione ordinaria, mentre i nomi di job, step e script richiamano pattern familiari dei workflow automatizzati. L’attribuzione a identità bot come claude, dependabot o github-actions rafforza ulteriormente l’illusione di legittimità. IronWorm sfrutta così un limite strutturale dei sistemi di versionamento: la fiducia nella cronologia non coincide con una garanzia di autenticità operativa. Anche quando alcuni commit vengono rimossi dopo la rilevazione, le tracce dimostrano che la campagna è stata capace di propagarsi su più organizzazioni e di inserire componenti malevoli in punti diversi della catena. Il backdating diventa quindi una tecnica di stealth supply chain, utile non per nascondere un processo su una macchina, ma per occultare una modifica malevola dentro il tempo storico del progetto. Per gli amministratori di repository, questo significa che i controlli non possono limitarsi agli ultimi commit visibili, ma devono includere audit comparativi, verifica delle firme, controllo dei file sensibili e analisi dei cambiamenti anomali anche se apparentemente datati.

IronWorm usa dropper binari e workflow GitHub Actions

Il malware prevede due meccanismi principali di consegna del payload nei repository compromessi. Il primo, osservato direttamente in natura, consiste nell’inserimento di un binario dropper in percorsi come tools/setup o .github/scripts/precheck, accompagnato da modifiche al sistema di build o agli script di installazione per eseguirlo automaticamente. Questo metodo si integra bene nei package manager perché sfrutta hook come preinstall, script di setup o comandi CI apparentemente legittimi. Il secondo meccanismo, presente nel codice ma non osservato come attivato nella stessa forma, riguarda la manipolazione dei workflow GitHub Actions. In questo scenario IronWorm può sovrascrivere file di workflow per serializzare i secrets tramite toJSON(secrets) e caricarli come artifact, esfiltrando informazioni sensibili senza necessità di un server C2 esterno esplicito. La possibilità di usare artifact GitHub come canale di raccolta è particolarmente pericolosa perché sfrutta una funzionalità nativa della piattaforma e può apparire come parte del normale output di pipeline. Il malware sceglie nomi realistici per job e step, attribuisce modifiche a bot fidati e si inserisce nei processi automatizzati che gli sviluppatori tendono a considerare affidabili. La combinazione tra dropper binari e workflow CI/CD mostra una comprensione profonda delle abitudini di sviluppo moderne. IronWorm non attacca soltanto il codice, ma i processi che producono, testano e pubblicano il codice.

Trusted Publishing npm consente la replicazione senza segreti persistenti

Uno degli aspetti più avanzati di IronWorm è il supporto alla replicazione autonoma tramite Trusted Publishing npm in ambienti CI. Il malware può richiedere un token OIDC dal provider di integrazione continua e scambiarlo con l’endpoint npm per ottenere un token di pubblicazione scoped. Questa tecnica permette di pubblicare versioni trojanizzate direttamente su registry.npmjs.org senza dover rubare o memorizzare credenziali npm persistenti. Il valore offensivo è enorme: il worm sfrutta il modello di fiducia progettato per rendere più sicura la pubblicazione automatizzata e lo trasforma in meccanismo di autopropagazione. Invece di cercare password statiche o token a lunga durata, IronWorm usa identità temporanee e flussi legittimi di autenticazione federata. Questo riduce la visibilità dell’attacco e rende più difficile interrompere la catena se i workflow compromessi restano attivi. Il supporto a Trusted Publishing dimostra che gli operatori conoscono bene le evoluzioni recenti della sicurezza dei package manager e adattano il malware ai modelli di sviluppo più moderni. Il rischio è che ambienti CI/CD configurati per pubblicare automaticamente pacchetti diventino acceleratori dell’infezione, distribuendo versioni malevole con la stessa fiducia normalmente riservata ai rilasci legittimi. Per questo la sicurezza dei workflow deve includere controllo dei trigger, revisione delle modifiche ai file di pubblicazione, separazione dei permessi e monitoraggio delle release anomale.

Il furto di credenziali copre cloud, AI, Docker, Kubernetes e wallet

La componente di credential theft di IronWorm è ampia e mirata. Il malware cerca segreti in 86 variabili d’ambiente relative a servizi cloud, storage, database, CI/CD, API AI e piattaforme di sviluppo. Scansiona oltre venti percorsi file, inclusi ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json, ~/.claude/.credentials.json e ~/Cursor/auth.json. Questa selezione rivela l’obiettivo reale della campagna: compromettere sviluppatori che lavorano con infrastrutture cloud, agenti AI, container, cluster Kubernetes e strumenti moderni di coding assistito. IronWorm mira anche a 14 API AI, tra cui Anthropic, OpenAI, Gemini, xAI e altri provider, confermando che le chiavi per modelli AI sono ormai considerate asset di valore al pari di token cloud e credenziali GitHub. Il malware usa Tor per esfiltrare le informazioni raccolte e include una skip list interna per evitare l’invio di dati specifici, probabilmente appartenenti all’operatore o usati in test. La raccolta include inoltre token service-account Kubernetes e informazioni sui backend Vault, aumentando il rischio di compromissione laterale in ambienti aziendali. IronWorm non è quindi un semplice infostealer generico, ma un malware progettato per colpire il profilo operativo dello sviluppatore moderno, dove chiavi AI, cloud, container e repository convivono spesso sulla stessa macchina.

Il modulo Exodus e Kubernetes colpisce crypto e infrastrutture cloud

IronWorm include moduli specializzati per due aree ad alto valore: wallet crypto e infrastrutture cloud-native. Nel caso di Exodus, il malware inietta JavaScript nell’app Electron, disabilita webSecurity, sandbox e contextIsolation, amplia le policy di rete e cattura password e mnemonic inviandole tramite POST locale sulla porta 8738. Questa tecnica mostra una conoscenza specifica del funzionamento delle app desktop basate su Electron e del modo in cui le configurazioni di sicurezza possono essere indebolite dall’interno. Per gli sviluppatori crypto, il rischio è particolarmente alto perché una mnemonic rubata equivale spesso alla perdita irreversibile degli asset associati. Il modulo Kubernetes legge token di service-account, enumera namespace e dumpa oggetti Secret, cercando anche backend Vault se presenti. Una compromissione di questo tipo può estendersi rapidamente da una workstation a cluster interni, ambienti staging, registry privati e pipeline di deploy. La combinazione tra wallet theft e cloud-native exploitation conferma che IronWorm prende di mira operatori con accessi privilegiati a infrastrutture e fondi digitali. Non si tratta di una campagna orientata a utenti generici, ma di un attacco contro figure tecniche capaci di fornire accesso diretto a repository, pacchetti, chiavi di produzione e asset crypto.

Il rootkit eBPF rende il malware invisibile agli strumenti comuni

La componente più avanzata di IronWorm è il rootkit kernel basato su eBPF, progettato per nascondere processi e ostacolare il monitoraggio locale. Il payload intercetta letture di /proc e rimuove dai risultati i PID associati ai processi nascosti, permettendo al malware di evadere comandi comuni come ps, top e ls. Durante execve, il rootkit può nascondere automaticamente processi presenti in una watchlist, riducendo ulteriormente la visibilità dell’attività malevola. L’uso di eBPF è significativo perché porta tecniche di rootkit a un livello compatibile con i moderni meccanismi del kernel Linux, senza necessariamente richiedere moduli kernel tradizionali più rumorosi. IronWorm integra anche meccanismi anti-debugging che possono terminare processi di analisi e rendere più difficile il lavoro dei ricercatori. La ricostruzione del rootkit è stata possibile grazie alla presenza di informazioni debug complete nel file BPF, un dettaglio che sembra frutto di errore operativo, ma che non riduce la gravità della tecnica. L’integrazione tra Rust ed eBPF segnala una nuova soglia nella sofisticazione dei worm supply chain: il malware non si limita a rubare credenziali e propagarsi, ma tenta di restare invisibile sulla macchina dello sviluppatore compromesso. Questo aumenta il tempo di permanenza, consente raccolte più ampie e rende più difficile capire quando l’ambiente è stato davvero bonificato.

La recovery phrase nel codice tradisce l’operatore

L’elemento più sorprendente dell’analisi riguarda la presenza nel codice di una frase di recovery BIP-39 inserita nella skip list del malware: bench crane defense corn wheel trial news abuse finish better paddle slush. IronWorm confronta lunghezza e byte della frase prima dell’esfiltrazione, evitando probabilmente di inviare all’infrastruttura C2 un wallet di test o una mnemonic appartenente all’operatore. La frase deriva all’indirizzo Ethereum 0x7e28D9889f414B06c19a22A9Bd316f0AC279a4d6, creando un collegamento operativo raro e diretto tra codice malevolo e ambiente dell’attaccante. L’errore è clamoroso perché introduce nel malware un artefatto personale o di test che i ricercatori possono usare per attribuzione tecnica, analisi comportamentale e ricostruzione della catena di sviluppo. In una campagna altrimenti sofisticata, questo dettaglio dimostra come l’operatore abbia tentato di proteggere un proprio segreto ma abbia finito per esporlo. La presenza della recovery phrase non neutralizza il malware, ma offre una finestra preziosa sul processo di sviluppo e sui possibili asset usati durante i test. Per gli analisti, è un indicatore forte di coinvolgimento diretto dell’autore nel codice e una conferma della natura crypto-oriented della campagna.

IronWorm dimostra la maturità dei worm supply chain moderni

IronWorm rappresenta un’evoluzione importante dei malware supply chain perché combina tecniche che fino a pochi anni fa sarebbero state considerate appartenenti a categorie separate. Usa un pacchetto npm come vettore iniziale, un binario Rust offuscato come loader, GitHub come infrastruttura di propagazione, Trusted Publishing come meccanismo di replica, Tor come canale C2, furto di segreti come obiettivo economico e eBPF come strato di stealth kernel. Questa convergenza rende la minaccia particolarmente difficile da rilevare con controlli tradizionali. Gli sviluppatori devono trattare gli hook di installazione, i cambiamenti ai workflow, i pacchetti pubblicati da account inattesi e i commit backdatati come segnali di rischio. Le organizzazioni devono rivedere la fiducia concessa a package manager, CI/CD, token OIDC, bot GitHub e workstation degli sviluppatori. L’adozione di privilegi minimi, isolamento dei segreti, verifica dei pacchetti, pinning delle dipendenze, audit dei workflow e monitoraggio degli artifact diventa essenziale. IronWorm dimostra che la supply chain non viene compromessa solo violando registry o account maintainer, ma anche sfruttando la routine quotidiana dello sviluppo software. Un singolo comando di installazione può bastare per avviare una catena che ruba credenziali, modifica repository, pubblica pacchetti trojanizzati e nasconde processi a livello kernel.