Attacco Miasma a Red Hat: un worm ruba-credenziali si diffonde da npm

Bypassare la pubblicazione fiduciaria OIDC

La mossa più subdola dell'aggressore è stata sfruttare l'accesso legittimo per aggirare una delle più solide garanzie di sicurezza della supply chain moderna. Ha utilizzato l'account compromesso per iniettare flussi di lavoro GitHub Actions malevoli direttamente nei repository sorgente .

Una caratteristica chiave di questi flussi di lavoro era l'uso di OpenID Connect (OIDC) per la pubblicazione fiduciaria. Normalmente, OIDC permette a GitHub Actions di autenticarsi su npm per pubblicare pacchetti senza l'uso di token a lunga scadenza. Poiché i flussi di lavoro malevoli giravano sull'infrastruttura ufficiale di Red Hat usando l'account compromesso, erano in grado di generare attestazioni di provenienza SLSA valide. Questo ha di fatto applicato un timbro di legittimità verificabile ai pacchetti manomessi, inducendo gli sviluppatori a fidarsi di rilasci che celavano una backdoor .

Il payload di Miasma: un ladro di credenziali auto-propagante

Il codice malevolo era incorporato in uno script preinstall definito nel file package.json. Ciò significa che il payload veniva eseguito automaticamente nel momento in cui uno sviluppatore lanciava

npm install

Il payload è stato identificato come una variante personalizzata del worm Mini Shai-Hulud, disponibile pubblicamente e associato al gruppo di criminali informatici TeamPCP . Una volta in esecuzione, il payload JavaScript offuscato di circa 4,2 MB agiva come un infostealer completo, prendendo di mira un'ampia gamma di materiale sensibile :

• Segreti CI/CD e di automazione: Segreti di GitHub Actions e token OIDC appena generati .
• Credenziali per piattaforme cloud: Chiavi e token per Amazon Web Services (AWS), Google Cloud Platform (GCP) e Microsoft Azure .
• Token di infrastruttura: Token HashiCorp Vault per la gestione dei segreti e token Kubernetes (kubeconfig) per l'orchestrazione dei container .
• Chiavi di sviluppo e accesso: Chiavi private SSH, token di autenticazione npm e il contenuto dei file .env locali .

Oltre al puro furto, il worm possedeva un meccanismo di auto-propagazione. Se rilevava che il sistema compromesso aveva un repository Git configurato con un remote origin, clonava il repository, vi iniettava il suo codice malevolo e ne caricava le modifiche. Questo permetteva al malware di diffondersi a progetti a valle e ulteriormente nelle pipeline CI/CD collegate . Come firma finale, il worm modificava la descrizione dei repository compromessi in "Miasma: The Spreading Blight" .

La risposta ufficiale di Red Hat

Red Hat ha prontamente riconosciuto l'incidente e ha pubblicato il bollettino di sicurezza RHSB-2026-006 . L'azienda ha sottolineato che il raggio d'azione dell'attacco era contenuto. I pacchetti compromessi erano strettamente limitati a componenti front-end interni e strumenti API client utilizzati per la Red Hat Hybrid Cloud Console.

Fondamentalmente, Red Hat ha dichiarato che il codice con backdoor non è stato distribuito in alcun software destinato ai clienti o in prodotti Red Hat di produzione. L'azienda ha immediatamente rimosso tutti i pacchetti interessati dal registro npm al momento del rilevamento .

Passi di riparazione d'emergenza

Aziende di sicurezza come Aikido, OX Security, Orca Security e Wiz hanno emesso linee guida urgenti per qualsiasi organizzazione che possa aver installato pacchetti dal namespace @redhat-cloud-services il 1° giugno 2026 o intorno a quella data .

1. Ruotare immediatamente tutte le credenziali

Dare per scontato che qualsiasi credenziale presente in un ambiente compromesso sia stata violata. Questo include tutte le chiavi API dei provider cloud, i token dei runner CI/CD, le chiavi SSH, i token Vault e i token di pubblicazione npm. La rotazione è l'unica strada sicura da percorrere.

2. Verificare i repository Git per la firma del worm

Eseguire una ricerca nei repository GitHub della propria organizzazione. Qualsiasi repository con la stringa di descrizione "Miasma: The Spreading Blight" è stato attivamente compromesso dal motore di auto-propagazione del worm e contiene codice malevolo .

3. Controllare le GitHub Actions per anomalie

Verificare manualmente i flussi di lavoro di GitHub Actions. Cercare pull request inaspettate, modifiche non autorizzate ai file dei flussi di lavoro esistenti o l'aggiunta di segreti sconosciuti. Qualsiasi iniezione a questo livello rappresenta un meccanismo di persistenza critico .

4. Controllare le versioni dei pacchetti installati

Incrociare i dati della propria cartella node_modules e dei file di lock con l'elenco completo delle 96 versioni di pacchetti compromessi pubblicato da Aikido e Red Hat. Se si trova una corrispondenza, considerare quella macchina e le sue credenziali associate come completamente compromesse e isolarla immediatamente .

Attribuzione: il collegamento con TeamPCP

Il payload di Miasma deriva direttamente dal worm Mini Shai-Hulud, uno strumento di raccolta credenziali che è stato recentemente reso open-source dal gruppo di criminali informatici TeamPCP. Gli aggressori hanno esteso il worm di base con nuovi raccoglitori specificamente mirati alle credenziali cloud di GCP e Azure, dimostrando un'evoluzione attiva e continua della minaccia . La campagna sottolinea una tendenza pericolosa in cui gli strumenti di attacco open-source vengono rapidamente trasformati in armi e perfezionati per colpire obiettivi di alto valore nella supply chain.