- Un utente malintenzionato ha compromesso l'account npm del principale manutentore di Axios e ha rilasciato le versioni 1.14.1 e 0.30.4 con una dipendenza fantasma, plain-crypto-js, che ha distribuito un RAT multipiattaforma durante l'installazione.
- Il malware ha contattato un server C2 (sfrclak[.]com) e ha scaricato payload specifici per Windows, macOS e Linux, eseguendo attività di ricognizione del sistema, mantenendo segnali periodici e, in alcuni casi, stabilendo la persistenza.
- L'attacco, attribuito da Google e da altri ricercatori all'attore nordcoreano UNC1069, ha combinato una finestra di vulnerabilità di circa tre ore con una sofisticata campagna di ingegneria sociale contro il gestore del sistema per rubarne le credenziali.
- Le organizzazioni che sono riuscite a installare le versioni interessate devono impegnarsi ad adottare misure correttive, ricercando artefatti RAT, ruotando le credenziali, bloccando le versioni sicure di Axios e rafforzando i controlli relativi alla catena di fornitura, alla CI/CD e alla gestione delle dipendenze.
La comunità di sviluppatori JavaScript ha appena vissuto uno di quegli episodi che ti fanno riconsiderare quanto ti fidi delle tue dipendenze, come dimostrato dai problemi di vulnerabilità delle librerie . Axios, una delle librerie HTTP più utilizzate nell'ecosistema, è stata manipolata su npm per distribuire un trojan di accesso remoto (RAT) attraverso versioni apparentemente legittime. L'incidente è durato solo poche ore, ma ha chiarito che la catena di fornitura del software è molto più fragile di quanto molti pensassero.
Il problema serio non è solo che gli aggressori siano riusciti a infiltrare del malware in un pacchetto scaricato decine o centinaia di milioni di volte a settimana. Il vero problema è che ci sono riusciti dirottando l'account npm del principale manutentore, pubblicando versioni "ufficiali" che sembravano normali e non avevano modificato una sola riga del codice sorgente di Axios . Tutto il comportamento malevolo risiedeva in una dipendenza fantasma creata appositamente per l'attacco.
Come è nato l'impegno di Axios nei confronti di npm
Per comprendere la portata dell'incidente, dobbiamo partire dal punto di ingresso. L'attaccante è riuscito a prendere il controllo dell'account npm di "jasonsaayman", il principale manutentore di Axios, e ha modificato l'indirizzo email associato con uno sotto il suo controllo , ospitato su Proton Mail. Da quel momento in poi, ha avuto mano libera per pubblicare nuove versioni del pacchetto come se ne fosse il manutentore.
Sfruttando tali credenziali, ha caricato due versioni dannose di Axios: la 1.14.1 e la 0.30.4 , che interessavano entrambi i rami principali del progetto. I caricamenti sono stati effettuati a soli 39 minuti di distanza l'uno dall'altro e, secondo l'analisi di StepSecurity, sono stati eseguiti direttamente da npm utilizzando un classico token a lunga durata, bypassando completamente la consueta pipeline CI/CD basata su GitHub Actions.
Diciotto ore prima dell'attacco finale, l'autore aveva già pubblicato una versione "pulita" relativa alla dipendenza dannosa nel registro npm . Questo passaggio preliminare è servito a creare una cronologia e a impedire che alcuni controlli automatici si attivassero quando un pacchetto completamente nuovo è apparso al momento dell'attacco.
Ciò che colpisce è che gli aggressori non hanno modificato il codice sorgente di Axios né apportato modifiche visibili al repository GitHub . Infatti, le versioni 1.14.1 e 0.30.4 non avevano commit o tag corrispondenti su GitHub; esistevano solo su npm. La differenza fondamentale risiedeva nel file delle dipendenze del pacchetto, che era stato pubblicato nel registro.
In circostanze normali, Axios dichiara solo tre dipendenze: follow-redirects, form-data e proxy-from-env . Tuttavia, nelle versioni compromesse, è apparsa una quarta dipendenza, precedentemente inesistente nel progetto: plain-crypto-js, versione 4.2.1. Questa libreria fantasma non veniva utilizzata in nessuna parte del codice sorgente di Axios, ma includeva uno script di post-installazione che veniva eseguito automaticamente durante l'installazione del pacchetto con npm, pnpm o strumenti simili.
plain-crypto-js: la dipendenza fantasma distribuita dal RAT
La chiave dell'attacco risiedeva in quella dipendenza aggiuntiva. Il pacchetto plain-crypto-js era stato pubblicato su npm da un utente di nome "nrwise", con un indirizzo email Proton Mail, e il suo unico scopo era quello di eseguire uno script di post-installazione offuscato in Node.js (setup.js) . Tale script fungeva da dropper, ovvero da programma di installazione iniziale per la seconda fase del malware.
Durante l'installazione di Axios in una delle sue versioni infette, il ciclo di vita post-installazione di npm ha attivato automaticamente il codice plain-crypto-js senza richiedere alcuna azione specifica da parte dello sviluppatore . Il dropper si è connesso a un server di comando e controllo (C2) attivo nel dominio sfrclakcom, in ascolto sulla porta 8000, e ha scaricato un payload specifico per il sistema operativo della macchina infetta; questo comportamento può essere identificato tramite l'analisi del traffico di rete.
I ricercatori di StepSecurity e altri team di analisi descrivono un comportamento molto cauto. Dopo aver eseguito il payload dannoso, il dropper eliminava le proprie tracce: cancellava lo script postinstall, sostituiva il file package.json con una versione "pulita" e lasciava un file node_modules che, a prima vista, sembrava innocuo . In questo modo, una successiva ispezione manuale non rilevava il codice dannoso direttamente all'interno di Axios.
Per identificare la manipolazione, l'unico indizio affidabile era rappresentato dai file di blocco (package-lock.json, pnpm-lock.yaml, yarn.lock) e dalla presenza di versioni specifiche: axios 1.14.1 o 0.30.4 e plain-crypto-js 4.2.1, oltre a due versioni di questo pacchetto con numeri intermedi (4.2.0, 4.2.2) collegate in alcune analisi. Socket, dal canto suo, ha successivamente rilevato che lo stesso malware veniva distribuito anche attraverso i pacchetti @shadanai/openclaw (varie versioni 2026.3.xx) e @qqbrowser/openclaw-qbot (0.0.130), e tecniche di sicurezza come gli honeypot possono contribuire a identificare campagne simili.
RAT multipiattaforma: Windows, macOS e Linux sotto i riflettori
Una volta eseguito, lo script setup.js fungeva da orchestratore in grado di rilevare il sistema operativo e seguire un percorso di attacco specifico per la piattaforma . La campagna era chiaramente pre-preparata: secondo StepSecurity, gli aggressori avevano precompilato tre payload distinti, uno per ciascun sistema.
Sui sistemi macOS, il processo di post-installazione avviava uno script AppleScript che scaricava un file binario infetto da Trojan dal server sfrclakcom:8000 . Questo file binario veniva salvato nel percorso /Library/Caches/com.apple.act.mond, i suoi permessi venivano modificati per renderlo eseguibile e, infine, veniva avviato in background tramite /bin/zsh. Una volta avviato il RAT, lo script AppleScript stesso veniva eliminato per complicare ulteriormente l'analisi forense.
Sui computer Windows, il malware individuava il file binario di PowerShell del sistema, lo copiava in %PROGRAMDATA%\wt.exe per mascherarlo da terminale Windows e generava uno script VBScript temporaneo . Questo script VBScript contattava quindi il server C2 per scaricare un ulteriore script PowerShell RAT, lo eseguiva e infine eliminava il file scaricato. Inoltre, la variante per Windows creava il file %PROGRAMDATA%\system.bat con una routine di download che consentiva al malware di ripristinarsi ad ogni accesso e aggiungeva una chiave di esecuzione al registro di sistema di Windows per garantirne la persistenza.
Su Linux e altri sistemi Unix-like oltre a macOS, il dropper utilizzava execSync di Node.js per avviare un comando shell che scaricava uno script Python da sfrclakcom, lo salvava come /tmp/ld.py e lo eseguiva con nohup per mantenerlo in esecuzione in background . A differenza di Windows, questa variante non presentava un robusto meccanismo di persistenza, il che suggerisce un approccio più orientato all'esfiltrazione rapida dei dati o l'occasionale implementazione della persistenza tramite comandi successivi.
SafeDep ed Elastic Security Labs hanno analizzato i payload di secondo livello e hanno concluso che i RAT per macOS (binario C++ Mach-O) e Linux (script Python) condividevano lo stesso set di comandi, protocollo C2, formato dei messaggi e comportamento operativo . Questo tipo di analisi si basa in genere su servizi di scansione come VirusTotal , che facilitano la correlazione di campioni e IOC.
In tutti i casi, ogni host compromesso ha eseguito immediatamente una ricognizione del sistema: directory utente, radici delle unità, processi attivi e altri metadati . Queste informazioni sono state inviate al server di comando e controllo e l'agente ha mantenuto un ciclo di beacon di circa 60 secondi, in attesa di nuove istruzioni, tra cui l'esecuzione di script aggiuntivi o l'iniezione di file binari in memoria.
Periodo di esposizione, obiettivi e attribuzione alla Corea del Nord
Le versioni dannose di Axios sono rimaste disponibili su npm per circa tre ore, durante un intervallo di tempo attentamente selezionato. I pacchetti compromessi sono stati pubblicati poco prima di mezzanotte di domenica (un momento che ha massimizzato il tempo di reazione dei difensori) e l'incidente è stato contenuto entro le prime ore di lunedì mattina , dopo che le società di sicurezza hanno allertato le autorità in merito al comportamento anomalo.
Durante quel periodo relativamente breve, Huntress ha rilevato almeno 135 sistemi connessi al server dell'attaccante . Dato che Axios registra più di 80-100 milioni di download a settimana (secondo diverse fonti, anche più di 300 milioni in alcuni periodi), questo numero rappresenta probabilmente solo la punta dell'iceberg, limitato ai sistemi che giungono all'attenzione delle società di analisi che hanno reso pubblici i propri dati.
Google, tramite il suo team di Threat Intelligence, ha attribuito l'attacco a un presunto attore nordcoreano identificato come UNC1069 . Elastic Security Labs ha rafforzato questa ipotesi riscontrando una forte somiglianza tra il RAT (Remote Access Trojan) diffuso su macOS e WAVESHAPER, una backdoor in C++ scoperta da Mandiant e anch'essa collegata allo stesso gruppo di minacce.
Gli analisti di Google hanno sottolineato che i gruppi legati alla Corea del Nord si specializzano da anni in attacchi alla catena di approvvigionamento e furti di criptovalute . Lo schema è sempre lo stesso: compromettere infrastrutture di sviluppo, librerie ampiamente utilizzate o software affidabili per poi spostarsi lateralmente verso obiettivi che gestiscono risorse di alto valore, chiavi private o credenziali.
Diversi report hanno inoltre evidenziato che la moderazione e la progettazione dell'attacco suggerivano un team ben coordinato : tre implementazioni parallele dello stesso RAT (PowerShell, C++ e Python), un protocollo C2 coerente, un comportamento pressoché identico in tutte le varianti e una chiara strategia di autopulizia per evitare di lasciare tracce. Elastic ha sottolineato che tale coerenza indica un singolo sviluppatore o un gruppo che lavorava a partire da un documento di progettazione condiviso, ben lontano dall'improvvisazione.
Al di là degli aspetti puramente tecnici, uno dei punti più inquietanti del caso è come l'account npm del principale responsabile sia stato violato. Lo stesso manager di Axios ha poi spiegato di aver attivato l'autenticazione a due fattori su quasi tutti i suoi servizi , eppure ha finito per concedere l'accesso senza rendersene conto.
Secondo l'analisi post-mortem condivisa dal team, gli hacker hanno messo in atto un'operazione di ingegneria sociale estremamente elaborata, supportata da strumenti basati sull'intelligenza artificiale, per guadagnarsi la fiducia delle vittime . Si sono spacciati per il fondatore di un'azienda, copiandone l'identità visiva, la fotografia e persino il marchio aziendale. Hanno creato un vero e proprio spazio Slack con il logo aziendale, canali con post apparentemente sincronizzati con LinkedIn e persino profili falsi di dipendenti e altri manutentori di software open source.
In tale contesto, hanno programmato una riunione tramite Microsoft Teams a cui sembrava partecipare un gruppo completo di professionisti . Durante la riunione, hanno simulato un problema tecnico e segnalato che un componente del loro sistema era obsoleto. Il tecnico della manutenzione, presumendo che si trattasse di un requisito legittimo relativo allo strumento di videoconferenza stesso, ha scaricato e installato il file suggerito.
Quel file era, di fatto, il Trojan di accesso remoto che ha permesso agli aggressori di impossessarsi delle credenziali della vittima e, in definitiva, di assumere il controllo dell'account npm utilizzato per pubblicare Axios . L'intero processo è stato orchestrato così bene, con così tanti dettagli credibili, che la vittima lo ha descritto come "perfettamente coordinato, professionale e assolutamente convincente".
Questo elemento umano dell'incidente chiarisce che persino misure tecniche come l'autenticazione a due fattori (2FA) sono insufficienti quando l'ingegneria sociale di alto livello si combina con l'impersonificazione visiva, i deepfake o la clonazione dettagliata di organizzazioni . L'anello debole, ancora una volta, è l'interazione umana.
Impatto sulle organizzazioni e sugli sviluppatori che utilizzano Axios
Da un punto di vista pratico, il problema principale è determinare chi è stato effettivamente colpito. Qualsiasi organizzazione che abbia installato [email protected] o [email protected] durante il periodo in cui erano disponibili dovrebbe presumere che la macchina o la pipeline che ha eseguito l'installazione possa essere compromessa.
Le raccomandazioni di aziende come StepSecurity, Aikido, Huntress ed Elastic sono inequivocabili. In caso di sospetto, è necessario un approccio proattivo, non limitarsi a "eliminare e reinstallare node_modules ". La procedura più prudente consiste nel ricostruire le macchine o gli ambienti interessati a partire da immagini affidabili e nell'analizzare attentamente i log CI/CD per identificare quali job o pipeline potrebbero aver eseguito le versioni compromesse.
Inoltre, è fondamentale ruotare tutte le credenziali e i segreti a cui il RAT potrebbe aver avuto accesso da quei nodi : token npm, chiavi del provider cloud, segreti della pipeline, credenziali del database, chiavi SSH, ecc. Lasciare queste credenziali in circolazione dopo un attacco di questo tipo apre la strada a movimenti laterali silenziosi.
A livello tecnico, i team dovrebbero esaminare i propri file di blocco (package-lock.json, pnpm-lock.yaml, yarn.lock) alla ricerca di riferimenti alle versioni compromesse di Axios e plain-crypto-js . Se questi elementi vengono rilevati, il passo successivo consiste nell'ispezionare i sistemi interessati alla ricerca di potenziali artefatti RAT: /Library/Caches/com.apple.act.mond su macOS, %PROGRAMDATA%\wt.exe e %PROGRAMDATA%\system.bat su Windows, oppure /tmp/ld.py su Linux.
Parallelamente, si raccomanda di impostare esplicitamente versioni sicure di Axios, come la 1.14.0 e la 0.30.3, e di utilizzare override o risoluzioni per impedire che le dipendenze transitive si risolvano in versioni indesiderate . Bloccare il traffico in uscita verso il dominio sfrclakcom è inoltre una misura di contenimento sensata, almeno durante l'analisi della portata completa dell'attacco.
Lezioni di sicurezza per la catena di fornitura del software
L'incidente di Axios non è un evento isolato, ma un altro anello di una catena di attacchi alla supply chain che include casi come SolarWinds, Kaseya, 3CX, Polyfill.io e le vulnerabilità sfruttate in Log4j. L'idea di base è sempre la stessa: compromettere un componente ampiamente utilizzato e affidabile per massimizzare la portata , piuttosto che tentare di attaccare una macchina alla volta.
Uno degli insegnamenti più frequentemente ripetuti dagli esperti è che la fiducia non può basarsi esclusivamente sulla popolarità di una libreria o sulla reputazione di chi la gestisce . Se il canale di rilascio (l'account npm, la pipeline CI/CD, l'infrastruttura di build) viene compromesso, tutto ciò che viene rilasciato attraverso di esso eredita tale rischio. Anche la revisione manuale del codice è insufficiente se il malware si nasconde nelle dipendenze transitive e si autoelimina dopo l'esecuzione.
È stato inoltre evidenziato che la "velocità predefinita" per gli aggiornamenti delle dipendenze ha un costo in termini di superficie di attacco . Adottare sempre automaticamente l'ultima versione è incredibilmente comodo, ma apre la porta alla diffusione di un aggiornamento dannoso in pochi minuti. Alcune organizzazioni stanno già valutando politiche come quella di richiedere che una nuova versione sia presente nell'ecosistema per un certo periodo prima di essere adottata, o di richiedere che le modifiche ai pacchetti critici siano sottoposte a un'ulteriore revisione manuale.
Per quanto riguarda l'infrastruttura di sviluppo, gli ambienti CI/CD devono essere trattati come risorse altamente sensibili . Qualsiasi RAT eseguito durante l'installazione delle dipendenze cercherà quasi certamente di accedere ai segreti della pipeline e di ottenere l'accesso ad altri ambienti. Segmentare questi nodi, monitorarli più attentamente e ruotare periodicamente i loro segreti non è più una raccomandazione "ideale", ma una necessità.
Infine, il rilevamento di questo tipo di attacchi richiede la combinazione di informazioni provenienti da più fonti: versioni installate, file di blocco, indicatori di compromissione del sistema operativo e telemetria di rete . Gli strumenti che generano e gestiscono le distinte base del software (SBOM) aiutano a tracciare rapidamente quali progetti utilizzano quali pacchetti, il che è fondamentale quando vengono attivati avvisi di massa come questo.
L'intera vicenda con Axios illustra quanto l'ecosistema delle dipendenze, per quanto maturo e consolidato possa sembrare, si basi ancora fortemente sulla fiducia e sulla costante vigilanza. Una libreria apparentemente innocua, gestita da una singola persona vittima di un attacco di ingegneria sociale ben orchestrato, può diventare, nel giro di poche ore, un vettore globale per la diffusione di RAT (Remote Access Trojan) multipiattaforma contro aziende, freelance e organizzazioni di ogni dimensione . Rafforzare i controlli sugli account di pubblicazione, sulle pipeline e sulle dipendenze critiche non è più una buona pratica opzionale, ma un prerequisito per lo sviluppo continuo in un ambiente in cui gli aggressori sono sempre più pazienti, ingegnosi e dotati di strumenti più sofisticati.
