Pacchetto npm malevolo nascondeva malware nel codice di runtime
Un pacchetto npm malevolo chiamato indexed-btree trasportava il suo malware all'interno di normale codice di libreria che viene eseguito mentre un'applicazione è in funzione, invece che negli hook al momento dell'installazione che i team di sicurezza hanno imparato a monitorare. Il pacchetto è stato identificato da Checkmarx, una società di sicurezza della supply chain del software, che ha dichiarato che il codice imitava sorted-btree, una legittima utility di indicizzazione costruita attorno a un B-tree, una struttura dati ordinata che le applicazioni usano per memorizzare e cercare rapidamente informazioni ordinate. Il pacchetto e il suo repository GitHub associato non sono più disponibili per il download da npm.
npm è il principale registro pubblico da cui i progetti JavaScript e Node.js scaricano codice già pronto scritto da altre persone. Per anni, uno dei modi più semplici per attaccare quell'ecosistema è stato uno script del ciclo di vita, una breve istruzione come preinstall o postinstall che viene eseguita automaticamente quando un pacchetto viene installato. Checkmarx ha osservato che questi hook hanno usi onesti, come compilare codice, popolare un database con valori iniziali o impostare file di configurazione, ma che gli attaccanti li hanno spesso abusati per eseguire codice malevolo su una macchina senza che l'utente fosse d'accordo. La versione 12 di npm ha introdotto un cambiamento di sicurezza per impedire l'esecuzione automatica di script del ciclo di vita come preinstall e postinstall. La campagna indexed-btree sembra essere una risposta diretta a quel cambiamento: il pacchetto non si affida affatto a quegli hook e invece viene eseguito interamente dal codice dell'applicazione a runtime.
Il loader è nascosto all'interno di un metodo chiamato BTree.prototype.set(), una funzione dall'aspetto normale che l'applicazione di uno sviluppatore chiama quando memorizza un valore nella struttura dati. Quando quella funzione viene eseguita, attiva un secondo file, sharedLoad.min.js, un payload JavaScript che incorpora il primo stadio offuscato (volutamente rimescolato in modo che sia difficile da leggere) del malware. Secondo Checkmarx, quello stadio prende le impronte della macchina su cui è in esecuzione, segnala ciò che trova a un canale Slack e a un bot Telegram codificati in modo fisso, quindi usa una tecnica chiamata EtherHiding per recuperare blob crittografati di codice da uno smart contract distribuito sulla testnet Sepolia, una blockchain di test Ethereum. I blob vengono uniti per costruire il payload di secondo stadio. Una volta fatto ciò, il malware elimina i propri artefatti e rimuove il trigger dal codice del pacchetto, così la traccia è più difficile da seguire.
Le statistiche citate da Checkmarx mostrano che indexed-btree è stato caricato per la prima volta nel registro npm il 18 giugno 2026 da un utente npm chiamato charlessadler25, e che ha accumulato milioni di download in un breve arco di tempo. La campagna potrebbe anche aver fruttato denaro all'operatore: Checkmarx ha dichiarato che ha generato circa 230.933,57 EUR in criptovaluta, equivalenti a 109 ETH.
Checkmarx ha dichiarato che indexed-btree è uno dei tanti pacchetti npm legati alla stessa operazione, tutti rimossi da npm: ordered-kv-index, btree-leaderboard, priority-slot-queue, btree-range-store, btree-core, btree-time-index, btree-lru-cache, neighbor-key-map, sliding-score-window e mutex-forge.
Per contrastare la minaccia, Checkmarx raccomanda agli sviluppatori di non affidarsi solo alla scansione al momento dell'installazione e al blocco degli script del ciclo di vita, ma di usare anche l'analisi del comportamento a runtime, cioè strumenti che osservano ciò che il software fa effettivamente mentre è in esecuzione. Ensar Seker, chief information security officer di SOCRadar, ha dichiarato in una nota condivisa con The Hacker News che la campagna mostra gli attaccanti adattarsi quasi immediatamente a difese più forti della supply chain del software: npm ha migliorato la sicurezza al momento dell'installazione limitando gli script del ciclo di vita delle dipendenze, e questa operazione ha spostato l'esecuzione malevola in funzionalità di runtime dall'aspetto legittimo. Il punto più ampio di Seker è che i controlli di sicurezza cambiano il comportamento degli attaccanti piuttosto che eliminare la minaccia sottostante. Bloccare gli script del ciclo di vita è un miglioramento importante, ha sostenuto, ma gli attaccanti continueranno a cercare percorsi di esecuzione alternativi, quindi i difensori hanno bisogno di controlli a strati in grado di rilevare comportamenti malevoli prima dell'installazione, durante l'esecuzione e dopo il deployment.
Separatamente, la società di sicurezza Socket ha dichiarato di aver eliminato codice malevolo nella versione dev-main di visanduma/nova-two-factor, un pacchetto su Packagist, il principale registro pubblico per il codice PHP, con più di 700.000 download cumulativi. Socket ha collegato quell'intrusione a una campagna in corso che chiama PolinRider, che secondo lei è associata alla Corea del Nord. Un tratto distintivo della campagna è che gli operatori compromettono account di sviluppatori e iniettano contenuti malevoli nei repository del codice sorgente, poi usano azioni di routine degli sviluppatori come clonare un repository o aprirlo in un ambiente di sviluppo integrato (IDE, il programma in cui il codice viene scritto ed eseguito) come trigger che avvia la catena di infezione. Secondo Socket, questo spesso comporta la riscrittura della cronologia Git, l'occultamento di payload all'interno di file di configurazione o di font, l'impostazione di attività VS Code malevole che si eseguono da sole e l'affidamento a una distribuzione resistente alla rimozione come EtherHiding e il suo successore orientato alla furtività NullReceiver per recuperare payload a stadi attraverso una blockchain.
Il ricercatore di sicurezza di Socket Karlo Zanki ha dichiarato che l'analisi dell'organizzazione GitHub Visanduma indica che i suoi repository sono stati compromessi da metà giugno 2026, con le modifiche malevole introdotte tramite l'account sviluppatore LaHiRu. Un cambiamento notevole in questa iterazione, secondo Socket, è l'inserimento diretto di JavaScript pesantemente offuscato in index.php e la sua esecuzione tramite la funzione shell_exec() di PHP. Questo approccio consente a un punto di ingresso PHP di avviare la catena di infezione JavaScript, e Socket lo legge come un segno che gli operatori adattano il loro metodo di esecuzione al progetto che hanno compromesso invece di usare un unico percorso di distribuzione fisso.
Socket ha anche tratto una conclusione più ampia: la compromissione del registro dei pacchetti è spesso una conseguenza di un'intrusione più ampia basata su Git piuttosto che l'obiettivo principale della campagna. Gli operatori usano la normale collaborazione sul codice sorgente per raggiungere gli ambienti degli sviluppatori, diffondersi in repository aggiuntivi e mantenere l'accesso nel tempo. Un repository sorgente compromesso dà loro la possibilità di infettare i collaboratori, raggiungere progetti privati e muoversi attraverso i normali flussi di lavoro di sviluppo, e pubblicare un pacchetto diventa solo un ulteriore percorso di distribuzione quando quel repository produce una nuova release.
Per i proprietari di siti web e i team IT la lezione pratica è che i siti moderni sono assemblati da dozzine, a volte centinaia, di componenti di terze parti, e entrambi questi casi mostrano che un'installazione pulita non è prova di sicurezza. Gli scanner che guardano il codice solo quando viene installato possono perdere malware che aspetta che l'applicazione sia effettivamente in esecuzione, e un repository sorgente può essere compromesso molto prima che qualsiasi pacchetto venga pubblicato. I team dovrebbero tenere un inventario di ciò da cui dipendono i loro siti e applicazioni, osservare comportamenti inattesi dai loro server come traffico in uscita verso servizi che nessuno ha configurato, e proteggere gli account degli sviluppatori, le chiavi dei sistemi di rilascio e deployment, con la stessa cura dei login di produzione, inclusa l'autenticazione a due fattori. Per le organizzazioni che preferiscono non rivedere interamente da sole come costruiscono ed eseguono il software, AEU-I è il nostro servizio di IT, infrastruttura e consulenza orientato alla sicurezza, e le sue pagine pubbliche illustrano le aree che copre.