Pacchetti npm Red Hat colpiti: oltre 30 repo distribuiscono un malware per il furto di credenziali cloud
Una campagna coordinata di attacco alla supply chain npm per il furto di credenziali cloud ha colpito uno dei nomi più riconoscibili nel software aziendale. Attaccanti sconosciuti hanno compromesso oltre 30 pacchetti npm di Red Hat Cloud Services, prima dirottando l'account GitHub di un dipendente Red Hat e poi usando quell'accesso per inviare commit malevoli. Il malware incorporato in questi pacchetti, identificato come una variante del ceppo "Mini Shai-Hulud", viene eseguito automaticamente al momento dell'installazione e inizia immediatamente a esfiltrare credenziali cloud, incluse chiavi di accesso AWS, GCP e Azure, insieme a chiavi SSH e file di configurazione Kubernetes.
Questo incidente si distingue non per una debolezza intrinseca di npm, ma per il modo in cui gli attaccanti sono entrati: attraverso un'identità di sviluppatore legittima e considerata attendibile.
Come sono stati compromessi i pacchetti npm Red Hat
La catena di attacco è iniziata con la compromissione di un singolo account GitHub appartenente a un dipendente Red Hat. Una volta all'interno di quell'account, gli attaccanti hanno avuto l'accesso necessario per inviare codice direttamente ai repository collegati ai pacchetti npm di Red Hat Cloud Services. Poiché i commit provenivano da un account di collaboratore riconosciuto, le pipeline automatizzate e i revisori hanno avuto una soglia molto più alta per rilevare qualcosa di sospetto.
Questa è la caratteristica distintiva di un attacco alla supply chain del software: il payload malevolo viaggia all'interno di software legittimo, firmato e distribuito attraverso canali considerati attendibili. Gli sviluppatori che hanno installato o aggiornato uno qualsiasi dei pacchetti interessati durante la finestra di compromissione hanno eseguito il malware sui propri sistemi senza alcun avviso evidente. I pacchetti stessi hanno continuato a funzionare normalmente, rendendo il rilevamento ancora più difficile.
La variante del malware "Mini Shai-Hulud" è progettata specificamente per essere eseguita al momento dell'installazione, nel momento in cui uno sviluppatore digita npm install. Non attende il lancio dell'applicazione o l'interazione con l'utente. Questo approccio riduce drasticamente il tempo tra l'infezione e l'esfiltrazione.
Quali credenziali sono state rubate e perché sono importanti
L'elenco degli obiettivi del malware è come una lista di controllo degli elementi più dannosi che un attaccante potrebbe estrarre dalla postazione di lavoro di uno sviluppatore o dall'esecutore di una pipeline CI/CD. I file delle credenziali di AWS, Google Cloud Platform e Azure sono obiettivi primari, poiché queste chiavi spesso comportano autorizzazioni estese sull'infrastruttura di produzione. Le chiavi private SSH e i file di configurazione Kubernetes completano il bottino, offrendo agli attaccanti potenziali percorsi di movimento laterale verso reti interne e cluster di orchestrazione di container.
Per le organizzazioni che eseguono pipeline di build automatizzate, il rischio di esposizione è amplificato. I sistemi CI/CD spesso memorizzano credenziali cloud di lunga durata come variabili d'ambiente o segreti montati. Un singolo esecutore di build infetto potrebbe consegnare silenziosamente chiavi che controllano interi ambienti cloud, aprendo potenzialmente la porta all'esfiltrazione di dati, al dispiegamento di ransomware o a un accesso persistente come backdoor.
Questo è anche il motivo per cui i team di sicurezza dovrebbero tenere presente che i punti di ingresso nella supply chain spesso si concatenano in compromissioni più profonde del sistema. Il recente avviso di CISA sulla CVE-2026-31431, una vulnerabilità di escalation dei privilegi locali su Linux è un promemoria diretto: gli attaccanti che arrivano su un sistema con credenziali rubate o accesso iniziale raramente si fermano lì. Cercano l'anello successivo della catena.
Perché gli attacchi alla supply chain sono un punto cieco per la sicurezza standard
Gli strumenti di sicurezza tradizionali si basano sul presupposto che la minaccia sia rappresentata da codice esterno, non firmato o sconosciuto. Firewall, agenti di rilevamento degli endpoint e scanner basati su firme sono calibrati per segnalare le anomalie. Gli attacchi alla supply chain sovvertono questo modello nascondendosi all'interno di software che porta una firma legittima e arriva attraverso un canale previsto.
In questo caso, il marchio Red Hat e la cronologia dell'account GitHub associato avrebbero conferito ai pacchetti compromessi un elevato grado di fiducia implicita. Gli sviluppatori che lavorano su infrastrutture adiacenti a Red Hat potrebbero aver installato questi pacchetti proprio perché si aspettavano che fossero ben mantenuti e sicuri.
Gli strumenti standard di scansione delle dipendenze che verificano la presenza di versioni vulnerabili note non rileverebbero un ladro di credenziali eseguito al momento dell'installazione, a meno che la versione malevola non fosse già stata segnalata in un database di vulnerabilità. L'attacco sfrutta il divario tra il rilevamento "noto come dannoso" e l'analisi comportamentale.
Difese stratificate: gestione dei segreti, segmentazione di rete e VPN
Nessun controllo singolo ferma un attacco sofisticato alla supply chain, ma difese stratificate possono ridurre significativamente il raggio d'azione.
Gestione dei segreti invece di file di credenziali locali. La mitigazione più efficace consiste nell'eliminare del tutto i file di credenziali statici dalle macchine degli sviluppatori e dagli esecutori CI/CD. Strumenti che rilasciano credenziali a breve durata e just-in-time fanno sì che, anche se una credenziale viene rubata, scada prima che un attaccante possa farne un uso significativo.
Blocco delle dipendenze e verifica dell'integrità. Fissare i pacchetti a hash di commit specifici e verificati, anziché a intervalli di versione variabili, limita l'esposizione a modifiche impreviste del codice. Combinare questo con controlli automatici di integrità sul contenuto dei pacchetti aggiunge un ulteriore livello di rilevamento.
Segmentazione di rete e filtraggio del traffico in uscita. Il malware Mini Shai-Hulud deve inviare i dati rubati da qualche parte. Limitare le connessioni in uscita dagli ambienti di build e dalle macchine degli sviluppatori a endpoint noti può impedire l'esfiltrazione anche quando il malware viene eseguito con successo. Le VPN e le architetture di rete zero-trust possono applicare queste politiche di uscita in modo coerente tra team distribuiti.
Autenticazione a più fattori su ogni account sviluppatore. La compromissione iniziale è stata il furto di un account GitHub. Requisiti MFA forti, in particolare chiavi di sicurezza hardware o autenticazione basata su passkey, rendono il dirottamento dell'account sostanzialmente più difficile.
Monitoraggio comportamentale nelle pipeline CI/CD. Generare avvisi su query DNS in uscita o connessioni di rete inaspettate durante la fase di build può far emergere malware eseguito all'installazione prima che le credenziali rubate vengano utilizzate.
Cosa significa per te
Se il tuo ambiente di sviluppo o di operations dipende da uno qualsiasi dei pacchetti npm di Red Hat Cloud Services, la priorità immediata è verificare quali versioni dei pacchetti sono in uso, cercare indicatori di compromissione nei log di rete relativi agli eventi di installazione e ruotare tutte le credenziali cloud che potrebbero essere state presenti sui sistemi interessati.
Più in generale, questo incidente è un invito a rivedere completamente l'igiene delle credenziali cloud. Le credenziali sono archiviate come file sulle macchine degli sviluppatori? Le variabili d'ambiente CI/CD hanno privilegi minimi? L'MFA è applicato su ogni account con diritti di pubblicazione dei pacchetti?
Gli attacchi alla supply chain riescono perché sfruttano la fiducia. La contromisura consiste nel costruire sistemi che non si basano solo sulla fiducia implicita: identità verificate, segreti a tempo limitato e monitoraggio comportamentale sono le fondamenta. Inizia oggi con un audit delle credenziali e tratta ogni dipendenza come una potenziale superficie d'attacco che merita un'attenzione approfondita.
