La Corea del Nord dietro gli attacchi npm a debug, chalk e axios: l’attribuzione di Amazon

Introduzione

Il 29 luglio 2026 Amazon Threat Intelligence ha attribuito con media confidenza al gruppo nordcoreano Sapphire Sleet (tracciato anche come UNC1069 o BlueNoroff) la compromissione di alcuni tra i pacchetti npm più diffusi al mondo. L’indagine lega per la prima volta in un’unica regia tre campagne che, nell’arco di dodici mesi, hanno colpito debug e chalk a settembre 2025, axios a marzo 2026 e la pubblicazione malevola del pacchetto typo‑crypto nel marzo 2025.
Le precedenti analisi di Aikido e Wiz non avevano identificato un attore specifico: ora il quadro si completa, delineando una minaccia persistente e finanziariamente motivata alla supply chain del software open‑source.

Analisi tecnica

Le tre campagne a confronto

Le operazioni mostrano tecniche d’attacco differenti, sintomo di un avversario capace di adattarsi ai controlli di sicurezza.

• debug e chalk (settembre 2025): gli attaccanti hanno compromesso gli account dei maintainer tramite ingegneria sociale e rilasciato aggiornamenti infetti. Il codice malevolo iniettato – uno script eseguito lato browser – non sfruttava hook di npm come postinstall, ma si attivava direttamente quando le applicazioni web caricavano i pacchetti. Agganciando fetch, XMLHttpRequest e le API dei wallet di criptovalute, lo script modificava silenziosamente gli indirizzi delle transazioni (wallet drainer), senza installare alcuna persistenza sul dispositivo.
• typo‑crypto (31 marzo 2025): un falso pacchetto che imitava crypto‑js (typosquatting) pubblicato come pacchetto originale, non frutto di un maintainer compromesso. Conteneva un trigger offuscato (XOR con chiave 01042025) che si attivava solo a condizioni specifiche, probabilmente un banco di prova per affinare le tecniche.
• axios e Mastra (marzo 2026): l’accesso ai maintainer ha permesso di inserire script di ciclo vita (postinstall) che distribuivano una backdoor (WAVESHAPER.V2) per furto di credenziali e movimento laterale negli ambienti di sviluppo.

Le prove e le discrepanze

Le evidenze pubbliche fornite da Amazon – riuso di codice e infrastrutture C2 condivise (npmjs[.]store, IP 216.74.123.126) – non dettagliano però l’esatto collante fra le campagne. Emergono alcune discrepanze: l’hash SHA256 indicato per core.js non corrisponde ad alcun file nell’archivio di typo‑crypto e il pacchetto appare un’operazione di typosquatting originale, non un maintainer compromesso.
Google e Microsoft avevano già attribuito l’attacco a axios allo stesso attore, ma nessun altro vendor ha pubblicamente confermato il collegamento anche per debug, chalk e typo‑crypto. Aikido sostiene di aver legato gli incidenti da tempo grazie a sovrapposizioni delle C2 fra axios e Mastra.

La risposta della piattaforma

npm v12 (rilasciato l’8 luglio 2026) disabilita di default gli script di ciclo vita delle dipendenze, rimuovendo il vettore postinstall sfruttato da axios. Tuttavia, non protegge da attacchi come quello a debug e chalk, dove il codice malevolo veniva distribuito direttamente nel pacchetto ed eseguito dalle applicazioni senza bisogno di hook d’installazione.

Impatto

I pacchetti coinvolti totalizzavano oltre 2 miliardi di download settimanali. Il guadagno immediato documentato è di soli 600 USD (fonte Socket), ma il rischio sistemico è enorme e ancora attuale.

• Utenti finali: lo script in debug/chalk intercettava transazioni crypto nel browser, reindirizzando i fondi senza lasciare tracce sul dispositivo.
• Sviluppatori: la backdoor in axios consentiva accesso a credenziali e ambienti aziendali, esponendo reti e repository interni.
• Ecosistema: la compromissione di maintainer fidati e l’uso di un falso pacchetto come test dimostrano una pianificazione sofisticata e una minaccia concreta alla catena di fornitura, che sfrutta la fiducia riposta nei manutentori open‑source.

Mitigazione

• Aggiornare npm all’ultima release (v12) per bloccare gli script di ciclo vita; purtroppo ciò non basta per attacchi in‑code come quelli visti.
• Proteggere gli account maintainer: imporre autenticazione a due fattori (2FA), monitorare accessi anomali e revisionare ogni aggiornamento sospetto sono contromisure irrinunciabili.
• Rilevare indicatori di compromissione: cercare nei propri ambienti il dominio npmjs[.]store, l’IP 216.74.123.126 e il file core.js. Nelle applicazioni web, verificare eventuali hook anomali su fetch, XMLHttpRequest e API wallet.
• Verificare l’integrità dei pacchetti: confrontare gli hash con quelli dichiarati e diffidare di pacchetti in cui l’autore differisce dall’account di pubblicazione (caso typo‑crypto).
• Rimuovere dipendenze non manutenute e consultare advisory come OSV MAL‑2026‑3400 per typo‑[email protected].
• Adottare strumenti di analisi (ad es. Socket) per monitorare in continuo le dipendenze.

FAQ

1. Chi è Sapphire Sleet e perché prende di mira npm?

Sapphire Sleet (UNC1069, BlueNoroff, STARDUST CHOLLIMA) è un gruppo nordcoreano specializzato in attacchi finanziari. Ha preso di mira banche ed exchange di criptovalute; oggi ha esteso le proprie operazioni alla supply chain del software per distribuire codice malevolo su vasta scala, puntando al furto di criptovalute o all’accesso a reti aziendali. npm, con i suoi milioni di sviluppatori, è un vettore ideale.

2. Come posso verificare se sono stato colpito?

Se la tua applicazione utilizzava versioni compromesse di debug, chalk o axios, ispeziona i bundle lato client alla ricerca di script che intercettano fetch o XMLHttpRequest. Per axios, controlla i log di rete verso gli indicatori C2 (npmjs[.]store, 216.74.123.126) e verifica l’integrità dei pacchetti con hash e strumenti di audit. La presenza del file core.js è un campanello d’allarme.

3. Perché npm v12 non è sufficiente a bloccare questi attacchi?

npm v12 neutralizza gli script di ciclo vita (es. postinstall), il vettore usato da axios. Tuttavia, gli attacchi a debug e chalk iniettavano codice direttamente nei file JavaScript del pacchetto, eseguibile senza bisogno di hook di installazione. Di conseguenza, la protezione richiede pratiche di sviluppo sicuro, verifiche di integrità e monitoraggio continuo delle dipendenze, non solo aggiornamenti della piattaforma.