AWS collega alla Corea del Nord gli attacchi supply chain open source

🛡️ Executive Summary

• Un gruppo collegato alla Corea del Nord compromette maintainer e progetti open source per distribuire malware attraverso pacchetti e strumenti legittimi.
• I payload colpiscono workstation e pipeline CI/CD per rubare credenziali AWS, token GitHub, chiavi SSH e configurazioni Kubernetes.
• AWS raccomanda dipendenze bloccate, verifica della provenienza, isolamento delle build, rotazione dei segreti e monitoraggio continuo degli ambienti di sviluppo.

Amazon Web Services ha collegato alla Corea del Nord una serie di attacchi contro la supply chain open source che hanno interessato progetti utilizzati quotidianamente da sviluppatori, pipeline CI/CD e infrastrutture cloud. Gli operatori non si limitano a pubblicare pacchetti con nomi ingannevoli, ma cercano di assumere il controllo di account legittimi, repository e processi di distribuzione già considerati affidabili. Una volta compromesso un componente, il malware raggiunge automaticamente workstation, server di build e ambienti di produzione, dove ricerca credenziali AWS, token GitHub, chiavi SSH, file Kubernetes e segreti utilizzabili per estendere l’accesso. L’obiettivo è trasformare la fiducia nell’open source in un percorso diretto verso infrastrutture aziendali e asset finanziari.

Gli attaccanti colpiscono i maintainer invece del codice

La campagna descritta da AWS mostra un cambiamento importante rispetto al tradizionale typosquatting. Gli operatori nordcoreani non cercano soltanto di convincere gli sviluppatori a installare una copia contraffatta di una libreria, ma prendono di mira le persone che possiedono i privilegi necessari per pubblicare aggiornamenti autentici. Il percorso può iniziare attraverso falsi colloqui di lavoro, offerte di collaborazione, inviti a riunioni, richieste di assistenza tecnica o contributi apparentemente legittimi a un progetto. Lo scopo è sottrarre credenziali, token di sessione o chiavi utilizzate per accedere a GitHub, npm, PyPI e ad altri servizi di sviluppo. Una volta assunto il controllo dell’identità del maintainer, il gruppo può distribuire una release malevola attraverso lo stesso canale utilizzato per gli aggiornamenti ufficiali. La firma del nome del pacchetto, la reputazione del progetto e la cronologia delle versioni continuano così ad apparire affidabili agli utenti e ai sistemi automatizzati. Lo stesso modello è emerso nella compromissione di AsyncAPI attraverso pacchetti npm e workflow GitHub, dove l’attacco alla pipeline di pubblicazione ha trasformato dipendenze note in strumenti per distribuire codice ostile. La superficie più esposta non è quindi soltanto il repository, ma l’intero sistema di identità, automazioni e segreti che permette a un progetto open source di pubblicare nuove versioni.

Axios diventa il passaggio più visibile della campagna

Tra gli episodi ricondotti alla stessa attività figura la compromissione di Axios, una delle librerie JavaScript più utilizzate per effettuare richieste HTTP. Gli aggressori hanno assunto il controllo di un account autorizzato alla pubblicazione su npm e distribuito due versioni malevole del pacchetto. Il codice principale di Axios non era stato modificato in modo evidente: il file package.json conteneva invece una nuova dipendenza, plain-crypto-js, preparata per eseguire automaticamente uno script durante l’installazione. Questa scelta riduceva la probabilità che una revisione superficiale del codice sorgente individuasse la compromissione, soprattutto perché le versioni distribuite attraverso npm non corrispondevano a commit e tag verificabili nel repository pubblico. Il malware identificava il sistema operativo e installava payload differenti su Windows, Linux e macOS, garantendo alla campagna una copertura multipiattaforma. Dopo l’esecuzione, alcuni componenti sostituivano i propri file con copie apparentemente pulite, eliminando lo script di post-installazione e riducendo le prove disponibili per le analisi successive. Il comportamento dimostra perché controllare una directory node_modules dopo l’incidente può non essere sufficiente: il codice osservato al momento dell’indagine potrebbe essere differente da quello effettivamente eseguito durante l’installazione.

Il vero bersaglio sono credenziali cloud e pipeline CI/CD

I payload non erano progettati soltanto per assumere il controllo della workstation dello sviluppatore. La raccolta prendeva di mira file .npmrc, token GitHub, chiavi SSH, credenziali Docker, configurazioni Kubernetes, variabili d’ambiente delle pipeline e file utilizzati dai principali provider cloud. Un laptop di sviluppo può contenere accessi a repository privati, ambienti di staging, registri dei container e account amministrativi; un runner CI può invece possedere token capaci di pubblicare artefatti, firmare release o distribuire direttamente in produzione. Gli aggressori cercano quindi di usare la prima compromissione come punto di partenza per raggiungere risorse più importanti. Il rischio aumenta quando le stesse credenziali vengono condivise tra sviluppo e produzione, quando i token non hanno una scadenza breve o quando le pipeline dispongono di privilegi superiori a quelli strettamente necessari. Una dipendenza malevola può essere eseguita durante npm install, pip install o la costruzione di un container senza alcuna interazione umana, consentendo al malware di accedere immediatamente ai segreti presenti nell’ambiente. La strategia ricorda le campagne che hanno distribuito SleeperGem attraverso pacchetti RubyGems indirizzati alle workstation degli sviluppatori, nelle quali l’ambiente di sviluppo diventava il ponte verso codice sorgente, chiavi e infrastrutture interne.

La Corea del Nord usa l’open source come moltiplicatore

L’attribuzione formulata da AWS si basa sulla convergenza tra infrastrutture, malware, procedure operative e tecniche di social engineering già associate ad attori nordcoreani. Il modello è coerente con le campagne nelle quali falsi recruiter e società inesistenti avvicinano programmatori e professionisti IT, chiedendo loro di eseguire test tecnici o progetti dimostrativi contenenti codice malevolo. In altri casi sono gli stessi operatori nordcoreani a proporsi come lavoratori remoti, utilizzando identità rubate per ottenere occupazione presso aziende occidentali e accedere direttamente a sistemi e dati. Gli attacchi alla supply chain rappresentano un’evoluzione particolarmente efficiente di questa strategia: compromettere un singolo maintainer permette di raggiungere contemporaneamente migliaia di sviluppatori e numerose organizzazioni. L’operazione non richiede che ogni vittima venga selezionata e contattata individualmente, perché sono i package manager e le automazioni aziendali a distribuire il payload. Le precedenti attività di Lazarus contro l’ecosistema npm attraverso PolinRider avevano già mostrato l’interesse nordcoreano per librerie, sviluppatori e processi di distribuzione del software. Il nuovo quadro indica però una strategia più ampia, nella quale il controllo dei progetti open source viene utilizzato per rubare accessi cloud, raggiungere criptovalute e creare nuove opportunità di compromissione.

La provenienza del pacchetto vale più del nome

Il caso mette in discussione l’idea che un pacchetto sia affidabile soltanto perché possiede milioni di download, una lunga cronologia o un maintainer conosciuto. Tutti questi segnali descrivono il progetto, ma non garantiscono che la singola versione scaricata sia stata costruita dal codice pubblico attraverso una pipeline integra. Gli aggressori possono compromettere l’account utilizzato per la pubblicazione, modificare esclusivamente il manifest distribuito nel registro oppure inserire una dipendenza transitoria che non compare nel repository principale. Per ridurre il rischio è necessario verificare la corrispondenza tra release, commit, tag e artefatti, utilizzare firme e attestazioni di provenienza e impedire che un singolo account possa pubblicare autonomamente aggiornamenti critici. Anche MFA resistente al phishing, chiavi hardware e protezione dei token di automazione diventano controlli essenziali, perché l’integrità del codice dipende dall’integrità delle identità autorizzate a distribuirlo. La sicurezza deve estendersi inoltre ai workflow GitHub Actions, ai registri dei container, agli account bot e ai secret utilizzati durante la build. Un repository pubblico perfettamente pulito non esclude che il pacchetto consegnato agli utenti sia stato manipolato in una fase successiva.

AWS chiede di trattare ogni installazione come codice eseguibile

Nel rapporto con cui AWS attribuisce alla Corea del Nord gli attacchi contro la supply chain open source, l’azienda evidenzia la necessità di combinare prevenzione, rilevamento e risposta. Le organizzazioni devono bloccare le versioni delle dipendenze attraverso lockfile verificati, evitare aggiornamenti automatici non controllati e confrontare gli artefatti scaricati con repository e build ufficiali. Gli script eseguiti durante l’installazione richiedono particolare attenzione, perché i campi preinstall, install e postinstall possono avviare codice con gli stessi privilegi dell’utente o del runner CI. Le pipeline dovrebbero operare in ambienti temporanei, senza credenziali permanenti e con accesso di rete limitato alle risorse realmente necessarie. I segreti devono essere forniti soltanto alla fase che li utilizza e avere durata breve, mentre i ruoli cloud devono rispettare il principio del privilegio minimo. Amazon Inspector, sistemi EDR e strumenti di analisi della software composition possono individuare pacchetti già classificati come malevoli, ma non sostituiscono la verifica della provenienza e il monitoraggio dei comportamenti durante la build. L’installazione di una dipendenza deve essere considerata equivalente all’esecuzione di codice esterno all’interno della rete aziendale.

La risposta richiede la rotazione completa dei segreti esposti

Quando un pacchetto malevolo viene eseguito su una workstation o in una pipeline, rimuovere la dipendenza non basta. Devono essere considerati potenzialmente compromessi token npm, credenziali GitHub, chiavi SSH, password dei registri Docker, file kubeconfig e accessi AWS, Azure o Google Cloud presenti nell’ambiente. La risposta richiede la revoca e la rotazione dei segreti, l’analisi dei log di autenticazione, la verifica delle pubblicazioni effettuate durante la finestra di esposizione e il controllo di eventuali modifiche a repository, workflow e ruoli cloud. È necessario esaminare anche build e container prodotti durante il periodo interessato, perché il malware potrebbe aver inserito componenti persistenti negli artefatti destinati alla produzione. Le organizzazioni dovrebbero ricostruire le release da commit verificati in ambienti puliti e controllare la distinta base software prima di procedere alla ridistribuzione. Il rischio principale degli attacchi nordcoreani alla supply chain non coincide quindi con il singolo pacchetto compromesso: riguarda la possibilità che le credenziali sottratte vengano utilizzate per generare una seconda compromissione, pubblicare nuove versioni malevole e trasformare ogni vittima in un ulteriore punto di distribuzione.