Sommario
Il gruppo di minaccia identificato come JINX-0132 è protagonista di una campagna di cryptojacking di ampia portata che prende di mira server DevOps pubblicamente accessibili. Tra le tecnologie compromesse figurano strumenti fondamentali per la gestione delle infrastrutture cloud-native come HashiCorp Nomad, HashiCorp Consul, Docker API e Gitea. L’aspetto più inquietante della campagna è la sua efficacia nel colpire ambienti mal configurati, anche all’interno di grandi organizzazioni dotate di infrastrutture robuste. Lo sfruttamento di configurazioni predefinite e vulnerabilità note, unito all’uso esclusivo di strumenti open source non modificati, rende la campagna difficile da individuare e mitigare con strumenti di difesa tradizionali.
Nomad: configurazione predefinita come vettore di esecuzione remota
Il componente più significativo di questa campagna è lo sfruttamento delle API pubbliche di HashiCorp Nomad, una piattaforma di orchestrazione di carichi di lavoro. In configurazione predefinita, Nomad consente l’invio di job agli agent senza autenticazione, rendendo possibile l’esecuzione arbitraria di codice (RCE). JINX-0132 ha utilizzato questo comportamento per avviare task che installano ed eseguono XMRig, un software per il mining di Monero, attraverso comandi shell standard che scaricano il software da repository GitHub ufficiali.
L’abuso è particolarmente grave quando i server Nomad gestiscono centinaia di nodi client, poiché forniscono risorse computazionali immense che vengono utilizzate per generare criptovaluta a favore degli attaccanti, con impatti economici rilevanti per l’infrastruttura vittima.
Consul: health check manipolati come backdoor per l’esecuzione
Come Nomad, anche HashiCorp Consul può essere manipolato se non configurato correttamente. In assenza di ACL (Access Control List), Consul consente la registrazione di nuovi servizi e check di stato da remoto. JINX-0132 sfrutta questa possibilità per registrare servizi fittizi i cui health check contengono comandi bash che scaricano ed eseguono XMRig. Questo abuso, documentato anche da precedenti minacce come DreamBus, si dimostra ancora oggi estremamente efficace, soprattutto in ambienti dove le configurazioni di sicurezza sono state trascurate.
Docker API: vecchio vettore, nuova campagna
La Docker API è un classico punto debole. Se configurata per accettare connessioni TCP da 0.0.0.0, chiunque può avviare container da remoto. JINX-0132 ha utilizzato questa possibilità per avviare container contenenti miner Monero o per montare il filesystem host, ottenendo privilegi root. La potenza di questo vettore sta nella sua semplicità: una singola richiesta API è sufficiente per compromettere l’intero host, e da lì espandersi lateralmente nella rete.
Gitea: sfruttamento di versioni obsolete e configurazioni errate
Anche Gitea, piattaforma per la gestione di repository Git, è stata sfruttata. Le versioni dalla 1.1.0 alla 1.12.5 permettono, se mal configurate, l’esecuzione di script post-receive via Git hook. Un utente malintenzionato può sfruttare questa caratteristica per eseguire codice sul sistema. JINX-0132 potrebbe ottenere l’accesso a tali account tramite registrazioni aperte o credenziali esposte.
Altre versioni, come la 1.4.0, sono vulnerabili a RCE non autenticato, mentre il rischio si amplifica se l’installazione viene lasciata sbloccata. La presenza di configurazioni errate in installazioni pubbliche è ancora elevata, soprattutto per ambienti auto-gestiti da team DevOps senza processi di hardening strutturati.
Strategia “living off the open-source”: no payload personalizzati
Una delle peculiarità di questa campagna è l’assenza di indicatori di compromissione tradizionali. JINX-0132 non usa server di comando e controllo, né malware personalizzati. Il codice di mining è scaricato da repository ufficiali, e i comandi sono generici. L’unico indicatore concreto è l’indirizzo Monero del wallet utilizzato per il mining, facilmente modificabile. Questa strategia rende la campagna particolarmente difficile da rilevare tramite sistemi di sicurezza basati su firme.
Impatto su larga scala e esposizione globale
Secondo i dati forniti da Wiz, il 25% degli ambienti cloud include almeno uno dei servizi DevOps vulnerabili. Il 5% di questi è esposto a Internet senza protezione, e il 30% di questi presenta misconfigurazioni. Una ricerca su Shodan rivela migliaia di istanze Nomad e Consul accessibili pubblicamente, molte delle quali in ambienti AWS, Azure e GCP.
I server compromessi mostrano una potenza computazionale elevatissima. I costi mensili in termini di risorse consumate dal mining non autorizzato possono raggiungere decine di migliaia di euro, con effetti a cascata su disponibilità di servizio, consumi energetici e reputazione aziendale.
Prevenzione: configurare correttamente è cruciale
I responsabili DevOps devono adottare buone pratiche di sicurezza per proteggere queste tecnologie:
- Nomad: attivare le ACL e limitare l’accesso alle API.
- Consul: disabilitare gli script nei check (
enable-script-checks=false) e legare le API solo all’indirizzolocalhost. - Docker: evitare assolutamente il binding a 0.0.0.0, riservando l’accesso locale al socket Unix.
- Gitea: aggiornare alle ultime versioni, disabilitare git hook per default e assicurarsi che l’installazione sia bloccata (
INSTALL_LOCK=true).
Il ruolo delle piattaforme di sicurezza: da Wiz al monitoraggio runtime
Soluzioni come Wiz possono scansionare in modo continuo l’ambiente cloud, rilevando:
- esposizioni pubbliche di Nomad, Consul, Docker e Gitea;
- configurazioni deboli;
- container o VM che eseguono mining non autorizzato.
L’integrazione di sensori runtime permette anche di identificare in tempo reale comportamenti sospetti legati a cryptojacking, con detection specifiche per XMRig e altre varianti.
La campagna JINX-0132 rappresenta un’evoluzione significativa nel panorama del cryptojacking. L’approccio “living off open source”, l’uso di vettori tradizionali ma trascurati come Nomad e Consul, e la scalabilità dell’attacco su infrastrutture cloud dimostrano quanto sia importante una configurazione sicura, continua verifica delle esposizioni e aggiornamento delle piattaforme DevOps. La mancanza di payload personalizzati non implica minore pericolosità: al contrario, richiede nuove strategie difensive, basate su comportamento e contesto, piuttosto che su firme. Le aziende devono trattare le configurazioni DevOps con la stessa attenzione riservata alle applicazioni business-critical.
