Malware CanisterWorm

Un sofisticato attacco alla catena di approvvigionamento, inizialmente mirato al diffuso scanner Trivy, si è esteso a una compromissione più ampia che ha interessato numerosi pacchetti npm. Si sospetta che gli autori della campagna abbiano utilizzato un worm auto-propagante precedentemente sconosciuto, noto come CanisterWorm, aumentando significativamente la portata e l'impatto dell'intrusione.

Il malware prende il nome dall'utilizzo di un contenitore ICP (Internet Computer Protocol), ovvero contratti intelligenti a prova di manomissione ospitati su una blockchain decentralizzata, come parte della sua infrastruttura di comando. Questo rappresenta il primo caso documentato pubblicamente di contenitori ICP utilizzati come arma per recuperare endpoint di comando e controllo (C2), introducendo una tattica innovativa e resiliente che complica le tradizionali strategie di mitigazione.

Pacchetti compromessi e vettore di accesso iniziale

L'attacco ha colpito numerosi pacchetti npm di diversa portata, dimostrando un ampio raggio d'azione all'interno della catena di fornitura del software:

• 28 pacchetti nell'ambito di @EmilGroup
• 16 pacchetti rientranti nell'ambito di @opengov
• Pacchetti aggiuntivi inclusi @teale.io/eslint-config, @airtm/uuid-base32 e @pypestream/floating-ui-dom

Questa campagna segue a ruota una violazione delle credenziali che ha permesso agli aggressori di pubblicare versioni dannose di strumenti correlati a Trivy, nello specifico trivy, trivy-action e setup-trivy, contenenti funzionalità integrate per il furto di credenziali. Si ritiene che l'operazione sia collegata a un gruppo di criminali informatici specializzato nel cloud, identificato come TeamPCP.

Flusso di lavoro per la gestione delle infezioni e infrastruttura di comando decentralizzata

La catena di infezione inizia durante il processo di installazione del pacchetto npm, dove uno script post-installazione esegue un loader. Questo loader distribuisce una backdoor basata su Python, progettata per comunicare con il contenitore ICP. Il contenitore funge da resolver di dead drop, restituendo un URL che indirizza il sistema infetto a scaricare ed eseguire il payload della fase successiva.

La natura decentralizzata dell'infrastruttura ICP offre un vantaggio significativo agli aggressori. Poiché il contenitore può aggiornare dinamicamente l'URL del payload, gli autori delle minacce possono distribuire nuovi file binari dannosi su tutti i sistemi infetti senza modificare il malware già distribuito. Questa architettura rende inoltre considerevolmente più difficili le operazioni di smantellamento.

Meccanismo di persistenza e tecniche di furtività

La persistenza si ottiene attraverso la creazione di un servizio utente systemd configurato per riavviare automaticamente il processo dannoso. Le caratteristiche principali includono:

• Riavvio automatico imposto tramite la direttiva Restart=always
• Un ritardo di 5 secondi prima di riavviare la backdoor se terminata
• Mascherare il servizio come un software legittimo di monitoraggio di PostgreSQL con il nome 'pgmon'

Questo approccio garantisce un funzionamento continuo riducendo al minimo la probabilità di rilevamento, mimetizzandosi con i servizi di sistema legittimi.

Distribuzione adattiva del carico utile e comportamento dell’interruttore di spegnimento

La backdoor comunica periodicamente con il contenitore ICP ogni 50 minuti, utilizzando uno User-Agent del browser falsificato per non destare sospetti. L'URL restituito determina l'azione successiva:

• Se l'URL punta a un payload valido, il malware lo scarica ed esegue
• Se l'URL contiene 'youtube.com', il malware entra in uno stato dormiente

Questo meccanismo funge di fatto da interruttore di spegnimento remoto. Alternando l'URL del contenitore tra un link YouTube innocuo e un payload dannoso, l'attaccante può attivare o disattivare il malware su tutti i sistemi infetti. In particolare, i payload precedentemente eseguiti continuano a essere in esecuzione in background, poiché il malware non termina i processi precedenti.

Un sistema di blocco simile, basato su YouTube, è stato osservato anche in un binario di Trivy infettato da trojan (versione 0.69.4), che comunica con la stessa infrastruttura ICP tramite un dropper Python separato.

Capacità dei vermi e propagazione automatizzata

Inizialmente, la propagazione si basava su uno script eseguito manualmente chiamato deploy.js, che sfruttava i token di autenticazione npm rubati per iniettare codice dannoso nei pacchetti accessibili. Questo script non veniva attivato durante l'installazione, ma fungeva da strumento autonomo per estendere la portata dell'attacco.

Le varianti successive di CanisterWorm si sono evolute in modo significativo. Nelle versioni più recenti, come quelle presenti in @teale.io/eslint-config (versioni 1.8.11 e 1.8.12), il worm incorpora l'autopropagazione direttamente nel processo di installazione del pacchetto. Il meccanismo aggiornato include:

• Estrazione dei token di autenticazione npm dall'ambiente infetto
• Esecuzione immediata della routine di propagazione come processo in background separato.
• Pubblicazione automatizzata di pacchetti compromessi tramite credenziali rubate.

Questo cambiamento trasforma l'attacco da una campagna gestita manualmente in un sistema di propagazione completamente autonomo.

L’escalation si trasforma in una minaccia autosostenuta per la catena di approvvigionamento.

L'introduzione della raccolta automatizzata di token e dell'autopropagazione rappresenta un'escalation critica. Qualsiasi workstation di sviluppo o pipeline CI/CD che installi un pacchetto compromesso e contenga credenziali npm accessibili diventa un nodo di propagazione attivo. Ciò crea un effetto a cascata in cui i pacchetti infetti portano a ulteriori infezioni nelle dipendenze a valle.

A questo punto, la minaccia si evolve oltre la semplice compromissione di un singolo account, trasformandosi in un ecosistema autosufficiente di distribuzione di malware. Ogni nuovo ambiente infetto contribuisce alla diffusione, consentendo una crescita esponenziale e rendendo il contenimento significativamente più difficile.

A peggiorare la situazione, artefatti di test come un payload segnaposto ('hello123') indicano che gli aggressori stanno attivamente perfezionando e convalidando la catena di attacco prima di distribuire binari dannosi pienamente operativi.