(in)sicurezza digitale

2026-07-02 12:54:21

Da un runner Jenkins ad Amazon Redshift: come il worm Shai-Hulud trasforma una CI/CD in una breach cloud

Si parla di:
Toggle

Un worm nato per infettare pacchetti npm, pensato per propagarsi da un progetto all’altro sottraendo token di pubblicazione, si è trasformato in un vettore capace di arrivare fino a un data warehouse Amazon Redshift in produzione. È la traiettoria che i ricercatori di FortiGuard Labs hanno ricostruito analizzando una compromissione partita da un semplice runner Jenkins esposto: nel giro di poche ore, l’attaccante è passato da un job di build a pieni poteri amministrativi sull’intero account AWS.

Shai-Hulud: la storia del worm che ha terrorizzato npm

Battezzato con il nome dei vermi delle sabbie di Dune, Shai-Hulud è emerso per la prima volta alla fine del 2025 come campagna di supply chain attack contro l’ecosistema npm, e da allora è stato attribuito al cluster tracciato come TeamPCP. Il meccanismo è quello del worm classico: un pacchetto compromesso esegue codice malevolo durante l’installazione o all’interno di una pipeline CI, ruba i token e le credenziali di build presenti sulla macchina, e li usa per pubblicare versioni trojanizzate di altri pacchetti di cui il maintainer ha accesso — propagandosi così, in autonomia, lungo l’intero grafo delle dipendenze.

La variante più recente, Shai-Hulud 2.0, ha alzato ulteriormente l’asticella: all’infezione di un pacchetto legittimo vengono iniettati due file, setup_bun.js e bun_environment.js, attivati tramite uno script di preinstall (anziché postinstall come nella prima ondata) — una modifica che amplia sensibilmente la superficie di impatto perché il codice malevolo scatta prima ancora che l’installazione del pacchetto sia completa. Il payload offuscato raccoglie credenziali da oltre 100 percorsi di file diversi, spaziando da provider cloud a wallet di criptovalute, tool AI e app di messaggistica, e installa hook di persistenza dentro Claude Code, VS Code e servizi a livello di sistema operativo, capaci di sopravvivere al riavvio della macchina. Secondo le stime della community, la campagna 2.0 ha compromesso almeno 796 pacchetti npm unici (1.092 versioni), toccando oltre 25.000 repository riconducibili a circa 350 maintainer.

Dal runner Jenkins a Redshift: la ricostruzione di FortiGuard Labs

Il caso analizzato da FortiCNAPP nasce a metà maggio 2026, quando gli analisti individuano su un ambiente cliente l’accesso persistente a un Jenkins runner con un pattern di credential-harvesting coerente con Shai-Hulud. Il runner, raggiungibile da internet, viene usato dall’attaccante come testa di ponte: sfruttando il ruolo IAM associato al job Jenkins, l’operatore compie un’escalation di privilegi fino a ottenere pieno accesso amministrativo sull’account cloud, dopodiché modifica i controlli di rete del database e avvia l’estrazione di dati da Amazon Redshift.

La sequenza operativa ricostruita da FortiGuard Labs è particolarmente istruttiva perché mostra quanto velocemente un accesso CI/CD apparentemente marginale possa tradursi in un data breach cloud su vasta scala:

• Creazione di un utente IAM con nome cloudops-monitor, pensato per confondersi con account di monitoraggio legittimi.
• Attribuzione della policy AdministratorAccess al nuovo utente ed emissione di access key.
• Modifica dei security group per allargare l’accesso di rete verso i database.
• Tentativi di modifica della configurazione di accesso a RDS e Redshift.
• Enumerazione sistematica di AWS Secrets Manager, con recupero dei secret collegati al data warehouse.
• Uso ripetuto della Redshift Data API (chiamate ExecuteStatement, DescribeStatement e successivo recupero dei risultati) per interrogare ed esfiltrare dati senza bisogno di una connessione diretta al cluster.
• Creazione di policy IAM con nomi espliciti dal chiaro intento di esfiltrazione, assunzione di ruoli con session name come exfil, e uso di SSM SendCommand insieme alla verifica di identità su Amazon SES — probabilmente in preparazione di un canale di invio dati o notifiche verso l’esterno.

Questa catena mostra un salto qualitativo rispetto alle prime campagne Shai-Hulud, centrate quasi esclusivamente sul furto di token npm e credenziali di sviluppatori: qui l’obiettivo finale è chiaramente il dato strutturato in un data warehouse aziendale, raggiunto attraverso l’abuso sistematico dei permessi IAM disponibili nella pipeline compromessa.

Perché la CI/CD è il bersaglio ideale

I runner Jenkins, GitHub Actions e sistemi CI/CD analoghi sono per costruzione dei nodi ad alto privilegio: hanno bisogno di credenziali per pubblicare pacchetti, effettuare il deploy su infrastruttura cloud e interagire con registry e repository. Quando queste credenziali sono sovradimensionate rispetto al reale bisogno — un ruolo IAM che consente escalation invece di essere ristretto al minimo indispensabile — un singolo pacchetto npm compromesso durante una build automatica può bastare per compiere il salto da “sviluppatore infettato” a “amministratore dell’intero account cloud”. È esattamente lo scenario che rende Shai-Hulud diverso da un comune infostealer: non si limita a rubare, usa quello che ruba per muoversi lateralmente e scalare privilegi in autonomia.

Raccomandazioni per i difensori

• Applicare il principio del minimo privilegio ai ruoli IAM usati dai runner CI/CD: nessun job di build dovrebbe poter assumere ruoli con permessi di amministrazione dell’account.
• Isolare i runner Jenkins/CI da internet o proteggerli dietro autenticazione forte e reti segmentate.
• Monitorare la creazione di utenti/ruoli IAM anomali, in particolare l’attribuzione di AdministratorAccess a identità nuove o non previste nell’infrastructure-as-code.
• Alert su chiamate massive alla Redshift Data API o pattern insoliti di query su data warehouse da identità di servizio.
• Verificare l’eventuale presenza degli script setup_bun.js e bun_environment.js in node_modules, e controllare gli script di preinstall dei pacchetti recentemente aggiornati.
• Applicare lockfile e pinning delle versioni, con verifica delle firme dei pacchetti dove disponibile, per limitare l’impatto di aggiornamenti automatici malevoli.
• Ruotare immediatamente tutte le credenziali (token npm, chiavi AWS, secret in Secrets Manager) se si sospetta una compromissione, anche parziale, della toolchain di sviluppo.

Il caso ricostruito da FortiGuard Labs è un promemoria scomodo: la supply chain del software open source non è più solo un problema di sviluppatori, ma un vettore diretto verso i dati più sensibili dell’azienda, quando la fiducia implicita accordata alle pipeline di build non è accompagnata da controlli granulari sui permessi cloud.

Indicatori di compromissione

Malware: Shai-Hulud / Shai-Hulud 2.0 (worm supply chain, ecosistema npm/PyPI)
Attore: TeamPCP (cluster tracciato)

File iniettati nei pacchetti compromessi:
  setup_bun.js
  bun_environment.js
Trigger: script "preinstall" (2.0) invece di "postinstall" (1.0)

Scala campagna 2.0 (stime community):
  796+ pacchetti npm unici compromessi
  1.092 versioni di pacchetto interessate
  25.000+ repository coinvolti
  ~350 maintainer impattati

Catena post-compromissione osservata da FortiGuard Labs (caso Jenkins -> Redshift):
  - Nuovo utente IAM: cloudops-monitor
  - Policy attribuita: AdministratorAccess
  - Modifica security group per esporre database
  - Enumerazione AWS Secrets Manager
  - Uso Redshift Data API: ExecuteStatement / DescribeStatement
  - Ruoli assunti con session name: "exfil"
  - Attività su SSM SendCommand e verifica identità Amazon SES

Persistenza osservata su endpoint sviluppatore:
  Hook in Claude Code, VS Code, servizi OS-level (sopravvivono al reboot)

Riferimento tecnico: FortiGuard Labs,
"From CI/CD to Cloud Data: How Shai Hulud Persistence Leads to Redshift Breach"