Sapphire Sleet compromette 140 pacchetti npm Mastra con un attacco supply chain

Un nuovo attacco supply chain contro l’ecosistema npm conferma come le dipendenze software siano diventate uno dei principali bersagli delle operazioni cyber sponsorizzate dagli Stati. L’attore nordcoreano Sapphire Sleet ha compromesso oltre 140 pacchetti appartenenti agli scope mastra e @mastra, sfruttando il controllo di un account maintainer per distribuire una dipendenza malevola chiamata easy-day-js. L’operazione ha trasformato normali aggiornamenti software in una catena di infezione capace di compromettere workstation di sviluppatori, pipeline CI/CD, ambienti di build e sistemi aziendali. Una volta installato, il pacchetto eseguiva automaticamente uno script postinstall che disabilitava le verifiche TLS, contattava infrastrutture di comando e controllo e scaricava ulteriori componenti malevoli. La campagna è stata individuata il 17 giugno 2026 da Microsoft Threat Intelligence, che ha collaborato con il team di sicurezza npm per bloccare i pacchetti compromessi e revocare i privilegi dell’attaccante.

Come Sapphire Sleet ha compromesso l’ecosistema Mastra

L’attacco è iniziato con la compromissione dell’account npm ehindero, un maintainer che disponeva dei privilegi necessari per pubblicare aggiornamenti su tutto lo scope @mastra. Una volta ottenuto il controllo dell’account, gli aggressori hanno creato il pacchetto easy-day-js, progettato per imitare la popolare libreria dayjs attraverso una tecnica di typosquatting. Utilizzando l’account compromesso, Sapphire Sleet ha pubblicato nuove versioni di oltre 140 pacchetti Mastra, aggiungendo la dipendenza malevola come componente ufficiale. Da quel momento qualsiasi sviluppatore o pipeline automatizzata che eseguiva npm install o npm update riceveva automaticamente la versione avvelenata. L’attacco sfrutta uno dei meccanismi più insidiosi dell’ecosistema JavaScript: la fiducia implicita nelle dipendenze pubblicate da maintainer considerati affidabili. In questo caso la compromissione non ha richiesto vulnerabilità nei sistemi delle vittime, ma ha sfruttato il normale processo di aggiornamento del software.

Il takeover dell’account ehindero ha tradito la catena di pubblicazione

Le anomalie che hanno portato alla scoperta dell’incidente sono emerse analizzando il modo in cui venivano pubblicate le nuove versioni dei pacchetti. Tutte le release precedenti di mastra erano state distribuite attraverso workflow automatizzati basati su GitHub Actions e autenticazione OpenID Connect. La versione compromessa [email protected], invece, è stata pubblicata manualmente utilizzando l’account ehindero e un indirizzo email anonimo fornito da Tutamail.

Gli analisti hanno osservato che l’unica differenza significativa rispetto alla release precedente consisteva nell’aggiunta della dipendenza easy-day-js. Nessuna modifica equivalente risultava presente nel repository GitHub ufficiale del progetto. Questo dettaglio ha permesso di collegare rapidamente la compromissione alla catena di distribuzione npm anziché al codice sorgente originale. Lo stesso provider di posta anonima è stato utilizzato per pubblicare il pacchetto typosquat, rafforzando ulteriormente l’attribuzione dell’attività malevola.

Easy-day-js nascondeva una seconda fase malevola

Il pacchetto easy-day-js è stato progettato per apparire inizialmente innocuo. La prima versione pubblicata dagli aggressori conteneva esclusivamente il codice legittimo della libreria dayjs, senza alcun comportamento sospetto. Questa strategia ha consentito al pacchetto di acquisire credibilità e di superare eventuali controlli preliminari. Solo nella release successiva è stato introdotto il file setup.cjs insieme a uno script postinstall eseguito automaticamente durante l’installazione.

Il pacchetto easy-day-js è una deliberata imitazione della legittima libreria dayjs :

Tale approccio a più fasi rappresenta una tecnica sempre più utilizzata nelle campagne supply chain moderne. Gli aggressori distribuiscono inizialmente codice apparentemente pulito per ridurre le probabilità di rilevamento e introducono successivamente i componenti malevoli quando il pacchetto è già presente nelle dipendenze delle vittime. Il meccanismo sfrutta il fatto che molti ambienti di sviluppo e sistemi CI/CD eseguono automaticamente gli hook postinstall senza ulteriori verifiche.

Lo script setup.cjs agiva come dropper avanzato

L’elemento centrale della compromissione è rappresentato dal file setup.cjs, uno script fortemente offuscato progettato per agire come dropper. Attraverso tecniche di offuscamento basate su rotazione di array e decoder personalizzati, il codice nascondeva le proprie funzionalità reali fino all’esecuzione. Una volta attivato, il payload modificava la variabile NODE_TLS_REJECT_UNAUTHORIZED impostandola a zero, disabilitando di fatto la verifica dei certificati TLS. Questa operazione consentiva di stabilire connessioni sicure apparenti anche verso server che presentavano certificati non validi. Successivamente il malware creava file marker nelle directory temporanee del sistema, contattava l’infrastruttura di comando e controllo e scaricava il payload di secondo stadio. Questa fase rappresentava il vero punto di compromissione, trasformando una semplice dipendenza npm in un veicolo di accesso remoto e raccolta informazioni.

Il secondo stadio installava persistenza e raccolta dati

Dopo il download, il secondo stadio distribuiva un client Node.js multipiattaforma capace di operare su Windows, macOS e Linux. Il malware installava meccanismi di persistenza specifici per ciascun sistema operativo e iniziava immediatamente la raccolta di informazioni sull’host compromesso. Tra i dati acquisiti figuravano inventari di wallet di criptovalute, cronologie dei browser, informazioni di sistema e dettagli sugli ambienti di sviluppo. Tutte le informazioni venivano inviate all’infrastruttura di comando e controllo utilizzata dagli operatori di Sapphire Sleet. Una delle caratteristiche più avanzate del payload riguarda la capacità di eseguire iniezione riflessiva di assembly .NET direttamente in memoria sui sistemi Windows. Questa tecnica fileless consente di eseguire codice malevolo senza creare file permanenti sul disco, riducendo significativamente la probabilità di rilevamento da parte delle soluzioni di sicurezza tradizionali.

Backdoor PowerShell e privilegi elevati sui sistemi Windows

Nelle fasi successive dell’operazione, Sapphire Sleet distribuiva un ulteriore backdoor PowerShell indipendente dal payload Node.js iniziale. Questo componente cancellava la cronologia dei comandi, generava un identificatore univoco della vittima e raccoglieva informazioni dettagliate sull’ambiente compromesso. Il malware comunicava regolarmente con il proprio server di comando e controllo attraverso richieste periodiche effettuate ogni dieci secondi. Per garantire la persistenza, installava chiavi Run nel registro di Windows e creava file batch nascosti utilizzati per il riavvio automatico del codice malevolo. Le attività più avanzate includevano l’aggiunta di esclusioni per Microsoft Defender, la creazione di servizi persistenti e il caricamento di DLL malevole all’avvio del sistema. In alcuni casi gli aggressori riuscivano a ottenere privilegi equivalenti a SYSTEM, acquisendo il massimo livello di controllo disponibile sul sistema operativo.

Microsoft attribuisce l’attacco a Sapphire Sleet

Il 19 giugno 2026 Microsoft ha attribuito con elevata confidenza la campagna all’attore nordcoreano Sapphire Sleet. L’attribuzione si basa sull’analisi dell’infrastruttura utilizzata, delle tecniche operative osservate e delle modalità di persistenza implementate nei sistemi compromessi. Sapphire Sleet è noto da anni per operazioni mirate contro il settore finanziario, le piattaforme blockchain, gli exchange di criptovalute e le società di venture capital. Negli ultimi mesi il gruppo ha mostrato un crescente interesse verso gli attacchi supply chain, considerati particolarmente efficaci per raggiungere un elevato numero di vittime attraverso un singolo punto di compromissione. La campagna contro Mastra segue infatti un precedente incidente che aveva coinvolto il pacchetto Axios nell’aprile 2026, evidenziando una strategia sempre più focalizzata sulla compromissione delle dipendenze software utilizzate dagli sviluppatori.

Gli ambienti CI/CD diventano il bersaglio principale

Uno degli aspetti più preoccupanti dell’operazione riguarda l’impatto potenziale sulle pipeline CI/CD. A differenza di molti malware tradizionali, questa campagna non prende di mira esclusivamente gli utenti finali ma cerca di compromettere direttamente gli ambienti utilizzati per sviluppare, testare e distribuire software. Se una pipeline automatizzata installa una dipendenza compromessa, gli aggressori possono ottenere accesso a credenziali, token di autenticazione, chiavi di firma e segreti utilizzati durante il processo di build. Questo scenario apre la possibilità di ulteriori compromissioni a cascata, nelle quali software legittimo viene distribuito con componenti alterati senza che gli sviluppatori ne siano immediatamente consapevoli. Il rischio riguarda quindi non solo le organizzazioni che utilizzano Mastra ma anche eventuali clienti e progetti downstream che dipendono dagli stessi ambienti di sviluppo.

Indicatori di compromissione e misure di mitigazione

Microsoft raccomanda di verificare immediatamente la presenza della dipendenza easy-day-js nei file package-lock.json, nelle pipeline di build e negli alberi delle dipendenze utilizzati dagli ambienti di sviluppo. Le organizzazioni esposte dovrebbero considerare compromesse tutte le credenziali presenti sui sistemi che hanno eseguito le versioni avvelenate dei pacchetti. Tra gli indicatori di compromissione figurano gli indirizzi IP 23.254.164.92 e 23.254.164.123, il dominio teams.onweblive.org e la presenza di file marker nelle directory temporanee utilizzate dal malware. Microsoft Defender rileva i componenti principali della campagna attraverso le firme Trojan:JS/NpmStealz.Z!MTB e Trojan:JS/NpmSteal.DB!MTB, mentre Microsoft Defender for Endpoint identifica comportamenti associati all’iniezione di assembly .NET e alle connessioni verso infrastrutture malevole. Gli ambienti particolarmente sensibili dovrebbero adottare procedure di installazione come npm install –ignore-scripts per impedire l’esecuzione automatica degli hook postinstall.

L’attacco Mastra conferma la crisi della fiducia nell’ecosistema npm

La compromissione di oltre 140 pacchetti Mastra rappresenta uno degli episodi più significativi del 2026 nel panorama della sicurezza open source. L’operazione dimostra come il controllo di un singolo account maintainer possa trasformarsi rapidamente in un attacco capace di colpire migliaia di sviluppatori e organizzazioni in tutto il mondo. L’utilizzo di typosquatting, hook postinstall, payload multipiattaforma e tecniche fileless evidenzia inoltre un livello di sofisticazione tipico delle operazioni condotte da attori statali. Per l’ecosistema npm il caso Sapphire Sleet conferma una tendenza ormai evidente: la fiducia implicita nelle dipendenze software rappresenta uno dei punti più vulnerabili dell’intera filiera di sviluppo. Con la crescita degli attacchi supply chain, la verifica delle dipendenze, il controllo degli script automatici e la protezione degli account maintainer diventano elementi essenziali per garantire l’integrità del software moderno.