Amazon ha attribuito a un gruppo di hacker legato alla Corea del Nord
una serie di attacchi alla catena di distribuzione di alcune librerie JavaScript open source molto diffuse, pubblicate nel registro Node Package Manager (NPM), la raccolta di pacchetti software scritti in JavaScript pubblicamente disponibile in rete, più grande e maggiormente implementata dalle aziende di tutto il mondo.

Per chi segue la sicurezza informatica in Italia, i nomi di questi pacchetti non sono una novità.

L’Agenzia per la Cybersicurezza Nazionale (ACN) aveva infatti già segnalato entrambe le compromissioni più rilevanti, quella di Axios e quella di debug e chalk, attraverso due bollettini pubblicati sul portale csirt.gov.it rispettivamente nel marzo 2026 e nel settembre 2025.

Il filo che collega Amazon e gruppi della Corea del Nord dietro agli attacchi

Secondo l’analisi di Amazon Threat Intelligence, le compromissioni di questi pacchetti sarebbero riconducibili allo stesso attore statale, noto alla comunità della sicurezza informatica con diversi nomi in codice: Sapphire Sleet, Stardust Chollima, BlueNoroff, CageyChameleon e Alluring Pisces.

Il filo che collega questi pacchetti compromessi sarebbe stato individuato proprio a partire dal monitoraggio della campagna più recente, quella che ha colpito il pacchetto axios.

Il 31 marzo 2026, il Google Threat Intelligence Group (GTIG) ha infatti rilevato l’inserimento di una dipendenza malevola in due versioni della libreria, veicolo per l’installazione di una backdoor denominata WAVESHAPER.V2, un trojan di accesso remoto capace di operare su più sistemi operativi, di cifrare le comunicazioni con il centro di comando e controllo dell’attaccante e di cancellare le proprie tracce una volta eseguito.

Ingegneria sociale con il supporto dell’intelligenza artificiale

GTIG aveva attribuito l’attacco a un attore già noto, classificato con la sigla UNC1069 e riconosciuto per l’impiego di tecniche di ingegneria sociale mirate a instaurare un contatto diretto con le vittime, già osservate in una campagna condotta tra marzo e giugno 2024 6 con il supporto di strumenti di intelligenza artificiale.

Analizzando l’infrastruttura di comando e controllo legata a quell’episodio, Amazon avrebbe individuato un dominio registrato nel 2025 che ha permesso di risalire a un malware inserito nel pacchetto typo-crypto, ritenuto un banco di prova per le campagne più estese condotte nel settembre 2025 su debug e chalk e poi, di nuovo, su axios.

Ad accomunare gli episodi, secondo Amazon, non sarebbero soltanto gli indicatori tecnici, ma anche l’approccio organizzativo: in ciascun caso gli attaccanti avrebbero fatto leva su tecniche di ingegneria sociale per conquistare la fiducia degli amministratori dei pacchetti e ottenere così i privilegi necessari a pubblicarne versioni compromesse.

CSIRT Italia alle organizzazioni italiane: verificare le dipendenze

Il bollettino di CSIRT Italia sul caso axios porta la stessa data di quella prima
rilevazione, il 31 marzo 2026. Segno che l’allerta era arrivata alle organizzazioni italiane in tempi rapidi.

Questo, identificato dalla sigla BL01/260331/CSIRT-ITA, ricostruisce l’attacco con un buon livello di dettaglio.

Secondo l’Agenzia, l’attaccante è riuscito a impossessarsi dell’account di uno dei manutentori del progetto e a pubblicare sul registro NPM due versioni modificate della libreria, aggirando i controlli automatizzati normalmente previsti dalla pipeline di rilascio.

Le versioni compromesse richiamavano una dipendenza aggiuntiva che, una volta installata, scaricava ed eseguiva silenziosamente il trojan di accesso remoto adattato al sistema operativo della vittima.

Il malware era progettato per cancellare le proprie tracce al termine dell’installazione, rendendo più difficile accorgersi dell’infezione con i normali strumenti di controllo.

Il registro NPM ha rimosso le versioni compromesse una volta individuato il problema, e CSIRT Italia ha raccomandato alle organizzazioni italiane di verificare le proprie dipendenze, aggiornare alla versione sicura e, nei casi più seri, considerare compromessi i sistemi coinvolti.

Il secondo bollettino e l’errore umano

Relativo alla compromissione di debug e chalk, il secondo bollettino racconta invece una vicenda che parte da un errore umano.

Un manutentore molto noto nell’ambiente NPM, identificato con lo pseudonimo Qix, è stato ingannato da un’email di phishing che imitava una comunicazione ufficiale del registro NPM e lo avvertiva di un presunto blocco imminente del proprio account.

Convinto dalla comunicazione fraudolenta, il manutentore ha fornito le proprie credenziali e il codice di autenticazione a due fattori, permettendo così all’attaccante di prendere il controllo del suo profilo e di pubblicare versioni modificate di numerosi pacchetti ampiamenteutilizzati nello sviluppo di applicazioni JavaScript e Node.js.

Anche in questo caso CSIRT Italia ha diffuso l’allerta alle organizzazioni nazionali, suggerendo strumenti per verificare la presenza delle versioni compromesse tra le proprie dipendenze.

Il punto debole: la fiducia riposta in chi gestisce i pacchetti

In entrambi i casi, il punto debole sfruttato dall’attaccante non è stato un errore nel codice dei pacchetti, ma la fiducia riposta in chi li gestisce.

È un dettaglio che ricorre spesso nella sicurezza del software open source, un ecosistema costruito sul lavoro di poche persone da cui dipendono, a cascata, migliaia di aziende.

Colpendo un numero ristretto di pacchetti molto diffusi, un gruppo può ottenere un accesso potenziale a migliaia di ambienti informatici in un colpo solo, un approccio più efficiente rispetto a colpire le organizzazioni una alla volta.

Tecniche legate all’AI

Inoltre, secondo Amazon Threat Intelligence, le evoluzioni più recenti della tecnica rivelano una minaccia che non deriva più dai singoli pacchetti compromessi, i quali presi singolarmente non eseguono più codice malevolo una volta installati, ma dall’azione concatenata innescata dall’installazione di più pacchetti che agiscono in modo complementare sui sistemi infettati.

Questa strategia, che evita ai singoli pacchetti di essere rilevati individualmente dai sistemi di sicurezza, sarebbe stata ulteriormente affinata adattando il codice ai diversi ambienti e sistemi operativi in cui viene eseguito, e ricorrendo a strumenti di intelligenza artificiale generativa per correggere le porzioni di codice più facilmente riconoscibili come sospette dagli antivirus e dai sistemi di rilevamento.

Lo slopsquatting

Amazon cita anche un’altra tecnica emergente legata all’intelligenza artificiale, lo slopsquatting, che consiste nel registrare nomi di pacchetti inesistenti ma suggeriti per errore da un assistente di intelligenza artificiale, nella speranza che qualche sviluppatore li scarichi per sbaglio.

Le contromisure di Amazon per difendersi dalla Corea del Nord e dai suoi attacchi

Sul fronte della risposta, Amazon segnala di aver condiviso gli indicatori individuati con il database internazionale Open Source Vulnerabilities e di aver diffuso le informazioni attraverso il proprio servizio di rilevamento delle minacce.

L’azienda ha inoltre ricordato la propria partecipazione, insieme alla Linux Foundation, all’iniziativa Akrites, nata per difendere il software open source critico dalle minacce abilitate dall’intelligenza artificiale.

Le allerte di CSIRT Italia sulla stessa filiera di dipendenze

Il bollettino sulla compromissione di debug e chalk già citato porta la data del 9 settembre 2025 e precisa una finestra di esposizione risalente all’8 settembre, raccomandando alle organizzazioni di bloccare le versioni delle dipendenze tramite i file package-lock.json o yarn.lock.

Nei mesi successivi, CSIRT Italia ha continuato a pubblicare allerte sulla stessa filiera di dipendenze: un attacco multistadio alla supply chain CI/CD legato all’attore TeamPCP e al malware CanisterWorm, la compromissione dei componenti Cloud Application Programming Model di SAP, la campagna worm Mini Shai-Hulud, che ha colpito oltre 160 pacchetti tra cui TanStack e gli SDK di Mistral AI, e la violazione del namespace @redhat-cloud-services di Red Hat, con 32 pacchetti e 96 versioni malevole.

Lo scenario: il caso Amazon non è isolato

Il quadro che ne emerge è quello di una minaccia strutturale sull’ecosistema di dipendenze su cui si appoggia buona parte dello sviluppo software italiano, non di un episodio isolato.

Questa esposizione arriva mentre il quadro normativo rende la sicurezza della catena di fornitura un obbligo esplicito.

L’articolo 21 della direttiva NIS2 (UE 2022/2555) include la sicurezza della supply chain tra gli obblighi chiave per i soggetti essenziali e importanti, richiedendo la mappatura dei fornitori con accesso a dati o sistemi critici.

Sul piano nazionale, la Determinazione ACN 127437/2026 ha introdotto l’obbligo di dichiarare i cosiddetti fornitori rilevanti sulla piattaforma dell’Agenzia.

Sul piano operativo, le linee guida pubblicate da ACN articolano la gestione degli incidenti in cinque fasi, preparazione, rilevamento, risposta, ripristino e
miglioramento, un modello di riferimento anche per allerte come quella lanciata da Amazon.

Implicazioni per le organizzazioni soggette alla NIS2

Il Rapporto Clusit 2026 aggrava il quadro: 507 attacchi gravi registrati in Italia nel 2025, in aumento del 42% sull’anno precedente, a fronte di un record globale di 5.265 incidenti, il 48,7% in più rispetto al 2024.

Il rapporto dedica un approfondimento alla sicurezza della filiera ICT, in cui la compromissione NPM di settembre 2025 legata al worm Shai-Hulud, un episodio distinto da quello di debug e chalk descritto in precedenza, sebbene avvenuto nello stesso mese, oltre 500 pacchetti coinvolti e furto di credenziali cloud di Microsoft, Amazon e Google, viene citata come uno degli episodi più rilevanti dell’anno.

Accanto a questo si citano i dati di ENISA, secondo cui oltre il 10% degli incidenti censiti in Europa coinvolge soggetti terzi, e del Verizon DBIR, che colloca al 30% a livello globale la quota di violazioni legate alla catena di fornitura, un valore raddoppiato rispetto all’anno precedente.

Nel complesso, l’attribuzione di Amazon aggiunge continuità a una minaccia che le autorità italiane osservano da quasi un anno, collocandola nell’orbita di un attore statuale nordcoreano orientato al profitto più che di gruppi criminali indipendenti.

Per le organizzazioni soggette alla normativa NIS2, l’implicazione pratica è duplice: consolidare fin da subito pratiche di blocco delle versioni delle dipendenze e monitoraggio delle pipeline di sviluppo, e formalizzare, entro i termini previsti, la gestione del rischio di filiera secondo il modello indicato da ACN.