Attacco alla supply chain di Mastra: 145 pacchetti npm compromessi da Sapphire Sleet

Due giorni dopo, Microsoft ha attribuito l'operazione con elevata confidenza a Sapphire Sleet, gruppo sponsorizzato dalla Corea del Nord e noto anche come BlueNoroff e APT38 .

Come si è svolto l'attacco

La campagna, denominata easy-day-js, ha seguito una catena relativamente semplice ma molto efficace: prendere il controllo di un'identità considerata affidabile, pubblicare rapidamente versioni alterate e lasciare che fosse il normale processo di installazione a eseguire il codice malevolo.

1. L'account del maintainer viene sottratto

Gli aggressori hanno colpito tramite tecniche di ingegneria sociale un contributore legittimo di Mastra, riuscendo a ottenere le credenziali del suo account npm . L'account, identificato come ehindero, disponeva dei permessi di pubblicazione sull'intero ambito @mastra .

Questo passaggio è stato decisivo: invece di dover convincere gli sviluppatori a installare un pacchetto sconosciuto, gli aggressori hanno potuto aggiornare pacchetti già associati a un progetto legittimo.

2. Pubblicazione automatizzata su larga scala

Utilizzando l'account violato, gli attaccanti hanno ripubblicato tutti i pacchetti della famiglia @mastra/* nell'arco di circa 88 minuti. Alcuni resoconti collocano il picco della pubblicazione in appena 19 minuti . La velocità dell'operazione fa pensare all'impiego di uno script automatizzato, non a un caricamento manuale dei pacchetti.

3. La dipendenza contraffatta

Ogni versione compromessa includeva easy-day-js, un typosquat della libreria legittima e molto utilizzata dayjs . Il nome è studiato per sembrare plausibile a un controllo superficiale e per inserirsi nella catena delle dipendenze senza attirare immediatamente l'attenzione.

4. Il payload parte durante npm install

Il codice malevolo era collegato allo script npm postinstall. Di conseguenza, l'esecuzione poteva avvenire non appena uno sviluppatore installava un pacchetto interessato con npm install, senza che fosse necessario avviare l'applicazione o utilizzare una specifica funzione di Mastra .

5. Furto di credenziali e risorse crypto

Dopo l'esecuzione, il payload cercava chiavi di portafogli di criptovalute, credenziali cloud e segreti presenti sulle workstation degli sviluppatori e nei sistemi CI/CD, cioè gli ambienti automatizzati che compilano, testano e pubblicano il software . Il codice disabilitava inoltre la verifica TLS e scaricava un infostealer di seconda fase da un'infrastruttura controllata dagli aggressori .

Perché l'attacco è stato così efficace

L'incidente mostra il rischio di concentrare poteri di pubblicazione molto ampi in un unico account protetto da credenziali che possono essere rubate. Una volta ottenuto l'accesso al maintainer, gli aggressori non hanno dovuto compromettere singolarmente 145 progetti: hanno sfruttato i permessi già assegnati all'intero spazio dei nomi.

La fiducia nella provenienza del pacchetto ha inoltre giocato a favore dell'attacco. Un aggiornamento pubblicato sotto un namespace noto può essere installato automaticamente da pipeline e progetti che aggiornano le dipendenze senza una revisione puntuale di ogni nuova versione.

L'attribuzione a Sapphire Sleet

Il 19 giugno 2026 Microsoft ha valutato con elevata confidenza che l'attività fosse riconducibile a Sapphire Sleet, un attore statale nordcoreano che prende principalmente di mira il settore finanziario e quello delle criptovalute . L'azienda ha citato l'infrastruttura e le tattiche, tecniche e procedure — le cosiddette TTP — osservate nella campagna, ritenute coerenti con operazioni precedentemente attribuite al gruppo .

Amazon Threat Intelligence ha inoltre collegato Sapphire Sleet a precedenti campagne contro pacchetti npm come axios, debug, chalk e typo-crypto .

La risposta di Microsoft: chiavi NuGet più brevi

Sebbene l'incidente abbia colpito npm, Microsoft ha accelerato misure più ampie per proteggere gli ecosistemi di pacchetti, compreso NuGet.org, il repository utilizzato dagli sviluppatori .NET.

A partire dal 17 agosto 2026, la durata massima delle nuove chiavi API di NuGet.org passa da 365 a 30 giorni . Tutte le chiavi create prima di quella data verranno invece fatte scadere il 1° novembre 2026 .

L'obiettivo è ridurre il periodo in cui una chiave rubata può essere utilizzata per pubblicare pacchetti alterati. Come ha spiegato Microsoft, le chiavi di lunga durata sono stringhe facili da perdere o esporre e possono diventare un vettore privilegiato per gli attacchi alla supply chain .

Trusted Publishing: l'alternativa ai segreti permanenti

Microsoft raccomanda ai maintainer di passare a Trusted Publishing, un modello introdotto nel settembre 2025 che utilizza l'autenticazione OpenID Connect (OIDC) al posto di chiavi API conservate a lungo nei repository o nei sistemi CI/CD .

Il funzionamento è basato sull'identità del workflow, non sulla semplice disponibilità di un segreto:

• il workflow CI/CD, per esempio in GitHub Actions, richiede un token OIDC firmato crittograficamente;
• NuGet.org verifica che il token corrisponda al repository, al workflow e, se previsto, all'ambiente registrato nella policy;
• il servizio rilascia una chiave temporanea e monouso, normalmente valida per circa un'ora, limitata a quella sessione di pubblicazione .

I principali vantaggi sono :

• nessun segreto permanente da archiviare nel repository o nella pipeline;
• credenziali a breve durata, emesse solo quando serve pubblicare;
• verifica dell'identità del workload e della provenienza della richiesta;
• nessuna rotazione manuale delle chiavi di lunga durata;
• un impatto potenzialmente molto più limitato in caso di esposizione delle credenziali.

Trusted Publishing è disponibile anche nell'ecosistema npm e in altri repository di pacchetti, tra cui PyPI . Tuttavia, l'adozione di questo modello non elimina da sola ogni rischio: anche un workflow legittimo deve essere protetto da modifiche non autorizzate e da compromissioni dell'ambiente di build.

Le altre barriere introdotte nell'ecosistema npm

La risposta all'attacco Mastra si inserisce in una stretta più ampia sulle credenziali di pubblicazione:

• Token classic revocati: npm ha revocato definitivamente tutti i token classic a lunga durata nel dicembre 2025. Il comando npm login ora rilascia sessioni valide per due ore .
• Token granulari con scadenza: i nuovi token granulari abilitati alla scrittura hanno una durata predefinita di sette giorni e un limite massimo di 90 giorni .
• Staged publishing: disponibile in generale da maggio 2026, richiede a un maintainer di approvare esplicitamente una release con una verifica a due fattori prima che la versione diventi installabile pubblicamente .

Nel loro insieme, queste misure cercano di impedire lo scenario sfruttato da Sapphire Sleet: un unico token di pubblicazione a lunga durata, poco sorvegliato e dotato di accesso a un'intera famiglia di pacchetti.

Cosa devono fare sviluppatori e maintainer

L'incidente offre indicazioni concrete per ridurre il rischio:

1. Controllare le installazioni effettuate nella finestra dell'attacco. Chi ha installato versioni interessate il 17 giugno dovrebbe verificare i sistemi coinvolti, le pipeline e i log di pubblicazione.
2. Revocare e sostituire le credenziali potenzialmente esposte. La verifica dovrebbe includere chiavi cloud, token CI/CD, credenziali npm, accessi ai repository e chiavi di portafogli di criptovalute.
3. Migrare a Trusted Publishing. Per NuGet, le chiavi preesistenti alla modifica del 17 agosto 2026 devono essere sostituite o abbandonate prima della scadenza generale del 1° novembre 2026 .
4. Bloccare le versioni delle dipendenze. Per i componenti critici, usare versioni note e verificate invece di consentire aggiornamenti automatici non controllati .
5. Valutare la disattivazione degli script di installazione. npm install --ignore-scripts, oppure l'impostazione globale ignore-scripts = true, può impedire l'esecuzione automatica di script preinstall e postinstall; Microsoft indica impostazioni equivalenti anche per pnpm e Yarn .
6. Aggiungere approvazioni e autenticazione a più fattori alla pubblicazione. Staged publishing e 2FA introducono un controllo umano prima che una nuova versione raggiunga il registro pubblico .

La lezione centrale è semplice: nella supply chain del software non basta verificare il nome del pacchetto. Bisogna proteggere anche l'identità che lo pubblica, il processo di build e ogni credenziale che quel processo può raggiungere.