Miasma colpisce npm Red Hat: malware con SLSA provenance valida

Il 1° giugno 2026, 32 pacchetti npm @redhat-cloud-services sono stati compromessi tramite un account GitHub personale di un dipendente Red Hat. Il malware Miasma ha

Il primo giugno 2026, una compromissione di account GitHub personale di un dipendente Red Hat ha trasformato 32 pacchetti npm della namespace @redhat-cloud-services in vettori di un worm per il furto di credenziali. L'attacco non ha sfruttato vulnerabilità zero-day né tecniche di iniezione sofisticate: ha invece abusato di OIDC trusted publishing e attestazioni SLSA perfettamente valide per rendere il malware indistinguibile da software autentico. La campagna, denominata Miasma, dimostra che le infrastrutture di sicurezza della supply chain possono essere weaponizzate contro chi le ha progettate.

Punti chiave

Il 1° giugno 2026, 32 pacchetti npm nella namespace @redhat-cloud-services sono stati compromessi attraverso l'account GitHub personale di un dipendente Red Hat, con 96 versioni malevole totali.
Gli attaccanti hanno introdotto commit orfani nei repository frontend-components e javascript-clients, attivando workflow GitHub Actions minimi per ottenere token OIDC e pubblicare pacchetti con attestazioni SLSA valide.
Il payload Miasma, derivato dal framework Mini Shai-Hulud pubblicato da TeamPCP su BreachForums il 12 maggio 2026, utilizza obfuscazione multi-strato e cifratura unica per infezione, rendendo gli IOC hash-specifici efficaci solo per singole versioni.
Il malware raccoglie credenziali da ambienti cloud, CI/CD, browser e wallet, si autoproaga attraverso il registry npm ed espone dati exfiltrati tramite repository GitHub pubblici appartenenti alle vittime.

Il meccanismo dell'abuso: OIDC e SLSA al servizio del malware

L'attacco si è articolato in due ondate il primo giugno: la prima alle 10:53 UTC, la seconda tra le 13:44 e le 13:46 UTC, con commit SHAs specifici documentati da Wiz Research. Gli attaccanti hanno compromesso l'account GitHub personale di un dipendente Red Hat — non un account corporate — e hanno iniettato commit orfani nei repository RedHatInsights/frontend-components e RedHatInsights/javascript-clients.

Questi commit introducevano workflow GitHub Actions minimali progettati per richiedere token OIDC per la pubblicazione npm trusted. Una volta ottenuto il token, i pacchetti compromessi sono stati pubblicati con attestazioni SLSA (Supply Chain Levels for Software Artifacts) perfettamente valide. Secondo Microsoft Threat Intelligence, i pacchetti "carried authentic provenance signatures"; Wiz Research conferma che sono stati "published packages with valid SLSA provenance attestations". Il risultato: i pacchetti apparivano autentici ai security scanner standard, che verificano la firma e la provenance senza analizzare il contenuto effettivo.

La compromissione ha generato 96 versioni malevole — alcune fonti indicano "90+" secondo Microsoft — distribuite attraverso circa 80.000 download settimanali stimati da Wiz Research, fino a 117.000 secondo l'analisi preliminare Red Hat citata da The Record. La maggior parte delle versioni malevole è stata revocata entro poche ore; due rimanevano attive al momento della prima segnalazione di Wiz.

Anatomia del payload: obfuscazione, Bun e il tripwire distruttivo

Il payload Miasma, 4.29 MB secondo l'analisi Microsoft, si attiva attraverso uno script preinstall che esegue automaticamente durante npm install. La catena di esecuzione è insolita: un processo node avvia una shell, che scarica e lancia il runtime Bun JavaScript, che a sua volta esegue il payload secondario.

L'obfuscazione è multi-strato e intenzionalmente sofisticata. Il payload utilizza decodifica ROT, decrittazione AES-128-GCM, offuscamento Obfuscator.io e un cifrario custom basato su PBKDF2-HMAC-SHA-256. Secondo Rescana e Wiz, ogni infezione genera un payload cifrato in modo unico: questo meccanismo rende gli indicatori di compromissione basati su hash efficaci solo per versioni specifiche, complicando la detection a livello di rete e la risposta agli incidenti.

Microsoft Threat Intelligence ha documentato dieci fasi della catena d'attacco, dal caricamento iniziale all'esfiltrazione finale. Una fase rilevante per gli ambienti CI/CD: il malware scansiona /proc/[pid]/cmdline alla ricerca di processi 'Runner.Worker', quindi estrae segreti tramite pattern matching su isSecret:true, raccogliendo token GitHub, credenziali npm e altri secret dal memory space del runner.

Il payload include un meccanismo di tripwire distruttivo: se rileva un token esca (decoy token), esegue rm -rf ~/ per cancellare la home directory della vittima. L'esfiltrazione avviene attraverso tre canali C2, inclusi repository GitHub pubblici con nomi randomizzati appartenenti alle vittime stesse — una tecnica che sfrutta l'infrastruttura legittima della piattaforma per nascondere il traffico malevolo.

Miasma e la sua genealogia: dal deserto di Arrakis alla mitologia greca

Il malware è una variante derivata dal framework Mini Shai-Hulud, pubblicato come open-source su BreachForums il 12 maggio 2026 dal gruppo TeamPCP. Wiz Research ha documentato che le modifiche rispetto all'originale sono "largamente cosmetiche", con riferimenti all'universo di Dune sostituiti da temi della mitologia greca: il marker di campagna è "Miasma: The Spreading Blight", mentre elementi come "spartan" sostituiscono i riferimenti originali.

Nonostante le modifiche superficiali, la funzionalità core e il tradecraft rimangono "sostanzialmente simili" secondo Wiz. Miasma introduce però nuovi collector per identità cloud: specificamente, moduli per l'enumerazione di identità GCP e Azure, assenti nella versione originale di Shai-Hulud. Questa evoluzione indica un target mirato su ambienti multi-cloud enterprise.

L'attribuzione a TeamPCP è valutata con "medium confidence" da più fonti. The Record cita che il codice sorgente completo è stato reso pubblico, rendendo possibile l'attività di copycat. Il dossier non stabilisce se l'attacco del primo giugno sia stato condotto direttamente da TeamPCP o da un attore che ha riutilizzato il framework pubblicato.

Cosa fare adesso

Audit dei lockfile e delle dipendenze transitivamente collegate: verificare la presenza di versioni nella namespace @redhat-cloud-services installate il primo giugno 2026 o successivamente, con attenzione alle dipendenze transitive che potrebbero non essere visibili nei manifest principali.
Rotazione completa delle credenziali potenzialmente esposte: includere token GitHub personali e di organizzazione, token npm, credenziali AWS/GCP/Azure, chiavi SSH, token HashiCorp Vault, token Kubernetes e secret memorizzati nei runner GitHub Actions, considerando che il malware ha accesso al memory space dei processi CI/CD.
Rivalutazione dei confini di trust per OIDC trusted publishing: la compromissione di un account personale ha bypassato controlli corporate; le pipeline di pubblicazione devono implementare verifiche aggiuntive del contenuto oltre alla validazione della provenance, inclusa l'analisi statica del codice prima della firma SLSA.
Rafforzamento del monitoraggio su catene di processo anomale: l'pattern node → shell → bun → payload è atipico per l'ecosistema npm e dovrebbe essere segnalato come indicatore di compromissione nelle piattaforme EDR e nei log di runtime.

La lezione: quando la firma valida non basta più

Il caso Miasma inverte la logica convenzionale della supply chain security: l'infrastruttura di trust è diventata l'infrastruttura di attacco. OIDC trusted publishing e SLSA provenance sono stati progettati per garantire che il software provenga da una pipeline legittima; qui hanno garantito esattamente questo, anche quando la pipeline era stata compromessa all'origine. Il problema non è nella tecnologia di attestazione, ma nell'assunto che la validazione della firma impliciti validazione del contenuto.

Per le organizzazioni enterprise, la conseguenza è una ricalibrazione necessaria del modello di minaccia. La segmentazione tra account personali e corporate, il controllo dei commit orfani, l'analisi del contenuto pre-pubblicazione e il monitoraggio runtime devono diventare layer aggiuntivi — non sostitutivi — della verifica di provenance. La sicurezza della supply chain richiede ora "verify after trusting", non semplicemente "trust but verify".

Red Hat ha confermato che nessun prodotto ufficiale è stato spedito con versioni compromesse. L'analisi preliminare dell'azienda, citata da The Record, stabilisce che "based on current findings, no actions from customers are required". Tuttavia, questa valutazione si riferisce alla distribuzione dei prodotti Red Hat, non all'installazione diretta dei pacchetti npm da parte dei team di sviluppo che potrebbero aver acquisito le versioni malevole prima della revoca.

"The payload appears to be derived from the (Mini) Shai-Hulud malware open-sourced by TeamPCP. The observed modifications are largely cosmetic, with references to the Dune universe replaced by Greek mythology themes (i.e 'spartan'), while the underlying functionality and tradecraft remain substantially similar." — Wiz Research

Domande frequenti

Perché gli scanner di sicurezza non hanno rilevato i pacchetti compromessi?: I pacchetti disponevano di attestazioni SLSA valide e firme autentiche, generate attraverso OIDC trusted publishing da una pipeline legittima. Gli scanner che verificano solo la provenance e la firma non analizzano il contenuto effettivo del payload, che era offuscato e cifrato in modo unico per infezione.
Qual è la differenza tra l'incidente Miasma/Red Hat del primo giugno e l'incidente AsyncAPI 'miasma-train-p1' di luglio?: Sono campagne distinte. L'incidente del primo giugno ha colpito la namespace @redhat-cloud-services con accesso iniziale tramite account GitHub personale compromesso. L'incidente AsyncAPI di luglio, documentato da Unit42, utilizza un payload evoluto ma con vettore di accesso iniziale e contesto operativo differenti. Non vanno trattati come lo stesso evento.
Perché l'attribuzione a TeamPCP è incerta?: Il codice sorgente di Mini Shai-Hulud è stato pubblicato pubblicamente su BreachForums il 12 maggio 2026. Questa disponibilità rende impossibile distinguere con certezza tra l'attore originale e operatori che hanno riutilizzato il framework, motivo per cui le fonti valutano l'attribuzione con "medium confidence".

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti