Lazarus amplia gli attacchi supply chain con PolinRider e falsi pacchetti Rollup

🛡️ Executive Summary

• PolinRider si espande su npm, Packagist, moduli Go ed estensioni Chrome compromettendo repository e account maintainer.
• Nuovi pacchetti npm mascherati da polyfill Rollup consegnano payload per accesso remoto, furto credenziali e dati wallet.
• Gli sviluppatori devono verificare dipendenze, task VS Code, cronologie Git riscritte, segreti esposti e installazioni sospette.

Gli attacchi nordcoreani alla supply chain open source stanno entrando in una fase più ampia, distribuita e difficile da contenere. La campagna PolinRider, collegata ai cluster Contagious Interview e Famous Chollima, ha superato il perimetro iniziale di npm e ora coinvolge repository GitHub, pacchetti Packagist, moduli Go ed estensioni Chrome, con oltre 100 progetti o artefatti malevoli identificati. In parallelo, i ricercatori di JFrog hanno individuato un secondo cluster npm che si maschera da tooling per polyfill di Rollup, imitando nomi, metadati e struttura di progetti legittimi per colpire ambienti JavaScript durante build e import. Le due operazioni non sono identiche, ma condividono un obiettivo strategico: compromettere sviluppatori, workstation e pipeline CI/CD per rubare credenziali, dati dei browser, chiavi SSH, file sensibili e wallet crypto. L’attacco non punta più soltanto all’utente finale, ma alla macchina che produce software, dove un singolo segreto rubato può aprire accesso a repository, cloud, package registry e infrastrutture aziendali.

PolinRider si espande oltre npm e colpisce più ecosistemi open source

PolinRider rappresenta una delle evoluzioni più aggressive delle campagne nordcoreane contro sviluppatori e maintainer. Secondo le analisi di Socket, l’operazione ha coinvolto 108 progetti unici tra pacchetti, repository e componenti distribuiti su più ecosistemi, con nuovi artefatti identificati in Packagist, moduli Go ed estensioni Chrome.

La scelta non è casuale: gli attaccanti non vogliono dipendere da un solo registro, ma aumentare la superficie di esposizione sfruttando community diverse, linguaggi differenti e flussi di lavoro eterogenei. Nei repository compromessi, i loader vengono inseriti in file di configurazione, risorse apparentemente innocue o falsi font .woff2, rendendo più difficile una revisione manuale rapida. In alcuni casi, la compromissione avviene tramite account maintainer legittimi, elemento che aumenta la fiducia apparente dei progetti modificati. Per uno sviluppatore, clonare un repository conosciuto o aggiornare una dipendenza già presente può sembrare un’operazione sicura, ma PolinRider sfrutta proprio questa fiducia implicita per trasformare strumenti di lavoro ordinari in vettori di compromissione.

Git riscritto, task VS Code e loader nascosti complicano la detection

La campagna usa tecniche pensate per eludere sia i controlli automatici sia l’analisi umana. Gli attaccanti riscrivono la cronologia Git con force push e commit retrodatati, facendo apparire le modifiche malevole come parte di attività precedenti. Questo approccio complica le indagini che si basano solo sulla cronologia visibile del repository e rende necessario controllare audit log, attività degli account, token usati e anomalie nei pattern di pubblicazione. Un altro punto critico è l’abuso dei task di Visual Studio Code configurati con esecuzione automatica all’apertura della cartella. In questo scenario, il malware può attivarsi prima ancora che lo sviluppatore esegua manualmente una build o un comando npm. I loader JavaScript vengono inoltre nascosti con padding di spazi bianchi, nomi di file fuorvianti e risorse che sembrano asset statici. La logica è chiara: colpire l’ambiente di sviluppo nel momento in cui la fiducia è massima e l’attenzione è concentrata sul codice applicativo, non sui file di configurazione o sui metadati del progetto.

Blockchain e payload cifrati rendono PolinRider più resiliente

Uno degli elementi più rilevanti di PolinRider è l’uso di infrastrutture blockchain come canale per recuperare payload di secondo stadio. I loader contattano servizi legati a TRON, Aptos e BNB Smart Chain per ottenere dati cifrati che vengono poi decodificati localmente tramite chiavi XOR ed eseguiti con eval. Questo modello riduce la dipendenza da server centralizzati facilmente bloccabili e permette agli attaccanti di aggiornare o sostituire gli stadi successivi senza modificare immediatamente tutti i pacchetti compromessi.

I payload osservati includono malware come DEV#POPPER e OmniStealer, già associati a operazioni nordcoreane contro sviluppatori e ambienti crypto. DEV#POPPER abilita accesso remoto ed esecuzione di comandi, mentre OmniStealer punta a dati browser, credenziali e wallet. L’abuso della blockchain come infrastruttura di consegna rende la campagna più persistente e sposta il problema dal semplice blocco di domini al monitoraggio comportamentale delle richieste verso servizi non necessari in ambienti di sviluppo.

I falsi pacchetti Rollup imitano tooling legittimo per JavaScript

Il secondo filone riguarda una famiglia di pacchetti npm che si presenta come tooling per polyfill di Rollup. JFrog ha documentato pacchetti di ingresso come rollup-packages-polyfill-core e rollup-runtime-polyfill-core, progettati per imitare il legittimo ecosistema rollup-plugin-polyfill-node attraverso nomi credibili, README simili, repository metadata coerenti e struttura dei file apparentemente funzionale. L’inganno è efficace perché Rollup è ampiamente usato nelle pipeline JavaScript e i polyfill sono componenti plausibili nei progetti frontend e build tool.

La catena include anche pacchetti secondari come swift-parse-stream, quirky-token, react-icon-svgs e rollup-plugin-polyfill-connect, alcuni dei quali si presentano come utility per SVG o parsing. La parte visibile può sembrare utile, mentre il comportamento malevolo si attiva attraverso entry point CommonJS, import durante build o installazioni silenziose di dipendenze secondarie. Questo aspetto è importante perché non tutti gli attacchi supply chain dipendono dagli script lifecycle di npm: alcuni si attivano quando il pacchetto viene effettivamente importato o caricato da una configurazione.

Remote access, clipboard e wallet: il payload punta agli sviluppatori

Il malware mascherato da polyfill esegue una catena multi-stadio con controlli anti-analisi, verifica di ambienti sandbox, cloud o container e recupero di payload cifrati da endpoint remoti. Dopo la decrittazione AES-256, lo stadio successivo installa dipendenze come axios, socket.io-client, ssh2 e node-pty, costruendo un impianto capace di fornire accesso remoto, sessioni terminali e interazione con il sistema compromesso.

Le funzionalità osservate includono scansione del filesystem, ricerca di file .env, chiavi SSH, configurazioni Git, profili browser e cartelle di estensioni wallet come MetaMask. Il monitoraggio della clipboard aumenta il rischio di furto di token, seed phrase o password copiate temporaneamente dall’utente. Per un attaccante nordcoreano orientato a guadagni finanziari e furto di asset digitali, una workstation developer è un bersaglio ad altissimo valore: può contenere accessi a repository privati, credenziali cloud, chiavi di firma, token npm, segreti CI/CD e wallet personali o aziendali.

Lazarus industrializza il targeting degli sviluppatori

Il collegamento con cluster nordcoreani come Lazarus, Contagious Interview e Famous Chollima conferma una tendenza ormai consolidata: gli sviluppatori sono diventati target primari, non vittime collaterali. Le campagne nordcoreane hanno usato nel tempo falsi colloqui, offerte di lavoro, repository dimostrativi, pacchetti npm, estensioni VS Code e moduli apparentemente legittimi per ottenere accesso a sistemi ricchi di segreti. La novità di questa fase è la scala multi-ecosistema e la maturità delle tecniche di evasione. Compromettere un maintainer permette di distribuire codice malevolo attraverso canali fidati; imitare tooling popolare consente di sfruttare l’urgenza dei team di sviluppo; usare payload cifrati e infrastrutture decentralizzate riduce l’efficacia delle blacklist statiche. Il modello operativo diventa industriale: pubblicazione o compromissione, offuscamento, recupero dello stadio successivo, furto credenziali, accesso remoto, movimento laterale e monetizzazione tramite asset crypto o accessi aziendali.

Le difese devono spostarsi dal package name al comportamento

La risposta difensiva non può limitarsi al blocco dei nomi dei pacchetti già noti, perché gli attori cambiano rapidamente artefatti, account e infrastrutture. Le organizzazioni dovrebbero controllare lockfile, dipendenze transitive, script di build, task VS Code, file insoliti nei repository, modifiche retrodatate e attività anomale degli account maintainer. Gli ambienti CI/CD devono eseguire build in sandbox isolate, con segreti a privilegio minimo e rotazione immediata in caso di sospetta esposizione. È consigliabile limitare il traffico in uscita verso blockchain RPC, servizi non necessari, pastebin, endpoint di storage temporaneo e domini appena registrati. Sulle workstation developer, i controlli EDR devono monitorare node, npm, PowerShell, shell interattive, accessi a directory browser, lettura di file .env, uso anomalo della clipboard e creazione di processi terminali remoti tramite librerie come node-pty. In caso di compromissione, rimuovere il pacchetto non basta: occorre ricostruire l’ambiente da una base pulita, revocare token, rigenerare chiavi SSH, ruotare segreti cloud e verificare accessi ai repository.

La supply chain open source resta il fronte più esposto

Le campagne PolinRider e Rollup polyfill dimostrano che la supply chain open source è ormai un teatro operativo stabile per attori statali e criminali. L’open source non è il problema; lo è il consumo cieco di dipendenze senza verifiche, isolamento e controllo degli artefatti. Gli aggressori nordcoreani sfruttano la velocità dello sviluppo moderno, dove pacchetti, plugin e template vengono installati rapidamente per rispettare scadenze di prodotto. Ogni ambiente developer diventa un’estensione della superficie d’attacco aziendale. Per questo la sicurezza deve entrare prima dell’installazione, non solo dopo la scoperta di una CVE o di un advisory. Registry firewall, policy di allowlist, attestazioni di provenienza, revisione dei maintainer, scansione comportamentale e separazione dei segreti dai processi di build diventano misure operative essenziali. La lezione è netta: chi controlla una dipendenza può arrivare alla macchina dello sviluppatore; chi controlla la macchina dello sviluppatore può arrivare al software, ai segreti e all’infrastruttura che quel software governa.