Gli hacker nordcoreani trasformano i test Terraform per candidati in una porta d’accesso alle reti degli sviluppatori

Jade Sleet ha violato un piccolo fornitore indiano di servizi tecnologici

SentinelOne ha attribuito la compromissione di un fornitore indiano di servizi IT a Jade Sleet, un gruppo di minacce nordcoreano noto per colpire aziende di criptovalute e i loro fornitori. L’intrusione ha avuto come obiettivo un MacBook con Apple Silicon assegnato a un ingegnere DevOps.

La vittima era molto più piccola rispetto alle organizzazioni precedentemente associate al gruppo. Questa differenza è significativa perché dimostra che Jade Sleet non limita le proprie operazioni alle principali piattaforme blockchain. I fornitori più piccoli possono offrire un accesso indiretto ai clienti, alle infrastrutture di sviluppo e a relazioni tecniche privilegiate.

Jade Sleet è noto anche con i nomi PUKCHONG, Slow Pisces, TraderTraitor e UNC4899. Storicamente le sue operazioni si sono concentrate sul furto di criptovalute, ma sviluppatori e fornitori terzi restano obiettivi ricorrenti perché i loro sistemi possono contenere credenziali o consentire l’accesso ad ambienti di maggior valore.

Gli aggressori hanno distribuito due backdoor per macOS basate su Rust, FLATROOF e ROOFDECK. FLATROOF è noto anche come Gaslight. Entrambi gli impianti erano già comparsi durante la compromissione del bridge LayerZero di KelpDAO, avvenuta tra marzo e aprile 2026, e SentinelOne ha individuato la vittima indiana durante la ricerca dello stesso malware.

A questo incidente non sono associati identificativi CVE né un punteggio formale di gravità. Si tratta di una campagna d’intrusione basata sull’ingegneria sociale e su contenuti dannosi destinati agli sviluppatori, non di una vulnerabilità divulgata in Terraform, Cursor o macOS.

Falsi progetti di selezione nascondono la trappola iniziale

La campagna prende di mira sviluppatori e persone in cerca di lavoro con esercizi tecnici di selezione apparentemente legittimi. I repository GitHub sono realizzati in modo da sembrare prove di programmazione o progetti di infrastruttura collegati all’azienda impersonata.

Tra i nomi dei repository osservati figurano:

• gtn-candidate-repo
• Northwind-IAC
• novacart-interview
• terraform-candidate-repo

I temi vengono scelti in base al ruolo professionale della vittima. Un candidato DevOps o addetto all’infrastruttura potrebbe quindi trovare configurazioni Terraform, automazione cloud o attività di deployment del tutto normali per una prova tecnica.

L’elemento dannoso è un file di lock delle dipendenze Terraform denominato .terraform.lock.hcl. Il file punta verso infrastrutture controllate dagli aggressori, tra cui registry.hashicorp-aws[.]com. Quando la vittima esegue terraform init, Terraform può recuperare moduli controllati dagli aggressori.

La tecnica sfrutta la fiducia riposta nell’esercizio, non una vulnerabilità confermata di Terraform. Lo sviluppatore apre volontariamente il progetto ed esegue un’inizializzazione standard, mentre la configurazione delle dipendenze del repository reindirizza parte del processo verso un’infrastruttura ostile.

SentinelOne ha rilevato che i pacchetti erano personalizzati per singole vittime e utilizzati in ambienti di sviluppo preparati per un solo ingegnere alla volta. Questo livello di personalizzazione riduce l’efficacia dei sistemi di rilevamento basati esclusivamente su hash comuni dei file o su contenuti identici dei repository.

Gli investigatori non hanno stabilito con precisione come il malware sia arrivato sul MacBook dell’ingegnere DevOps. Il meccanismo Terraform dannoso fa parte della campagna più ampia, ma le prove disponibili non consentono di definire l’esatta sequenza di distribuzione nel caso di questa vittima.

Impianti dormienti attivati attraverso l’ambiente di sviluppo

FLATROOF e ROOFDECK erano presenti sul sistema dell’ingegnere il 18 marzo 2026. Sono rimasti inattivi fino al 29 marzo, quando hanno iniziato a inviare beacon e a interagire con l’host.

I primi avvii registrati provenivano da Cursor, pochi secondi dopo che lo sviluppatore aveva aperto un workspace denominato cloudshield nel percorso:

~/DevOps-Automation/cloudshield

La tempistica collega l’esecuzione al normale flusso di lavoro dello sviluppatore. Tuttavia, non dimostra quale componente del workspace, dipendenza o azione automatizzata abbia avviato gli impianti.

Una versione più recente di ROOFDECK è stata installata il 20 aprile 2026, un giorno dopo che LayerZero aveva riconosciuto pubblicamente l’incidente di KelpDAO. L’impianto aggiornato ha rimosso dal MacBook i binari ROOFDECK e FLATROOF esistenti.

Inoltre, è arrivato privo di simboli e informazioni di debugging. La rimozione di questi elementi offre ai difensori meno contesto forense e rende più difficile il reverse engineering, suggerendo che gli operatori stessero perfezionando attivamente i propri strumenti dopo l’esposizione pubblica della precedente operazione.

La sequenza supporta anche la valutazione secondo cui ROOFDECK sarebbe un impianto utilizzato in una fase successiva. Anziché garantire necessariamente l’accesso iniziale, sembra essere distribuito dopo che un aggressore ha stabilito un punto d’appoggio e desidera mantenere un controllo più duraturo.

FLATROOF ruba dati mentre ROOFDECK amplia il controllo

FLATROOF è una backdoor scritta in Rust e progettata per i sistemi macOS basati su ARM. Comunica tramite Telegram e supporta l’esecuzione remota di comandi, oltre al caricamento e al download di file.

Un componente Python consente di ampliare la raccolta di dati dall’host. Il malware può acquisire dati da Chrome, Brave, Firefox e Safari, rubare la cronologia dei comandi del Terminale, enumerare le applicazioni installate, raccogliere informazioni su hardware e software e acquisire un’istantanea dei processi in esecuzione.

Può inoltre copiare login.keychain-db. Su una workstation di sviluppo, queste funzionalità potrebbero esporre materiale di autenticazione, sessioni del browser, accessi al cloud, dettagli sui servizi interni e comandi utilizzati in precedenza per l’amministrazione.

Anche ROOFDECK è scritto in Rust e prende di mira i Mac basati su ARM, ma utilizza il protocollo Nostr per il comando e controllo decentralizzato. Offre funzionalità di ricognizione, accesso remoto alla shell, manipolazione dei file, movimento laterale e persistenza tramite macOS Launch Agents.

I comandi inviati a ROOFDECK sono firmati con la chiave privata dell’operatore. L’impianto contiene una chiave pubblica che utilizza per verificare l’integrità dei comandi prima di eseguirli, limitando la possibilità che soggetti non autorizzati impartiscano istruzioni attraverso lo stesso canale di comunicazione.

Le sue funzioni sono suddivise in gestori di comandi separati. ROOFDECK implementa inoltre internamente numerose operazioni su directory e file, invece di dipendere interamente dalle utilità standard della shell installate sul Mac. SentinelOne ha confrontato questo approccio progettuale con quello degli strumenti LightlessCan di Lazarus.

Nel complesso, i due impianti offrono funzionalità complementari: FLATROOF privilegia la raccolta e il furto di dati, mentre ROOFDECK fornisce un ambiente persistente per l’accesso alla shell, la persistenza e il movimento oltre l’endpoint originario.

Un Mac di uno sviluppatore può esporre molto più di una singola workstation

La vittima diretta è l’ingegnere il cui MacBook con Apple Silicon è stato compromesso. Il rischio più ampio riguarda tutti gli ambienti che si fidavano di quel dispositivo.

Gli endpoint DevOps interagiscono comunemente con sistemi di controllo del codice sorgente, console di gestione cloud, piattaforme CI/CD, registri di pacchetti e repository di infrastruttura come codice. Possono inoltre contenere token di deployment, materiale SSH, sessioni del browser e file di configurazione non disponibili ai normali utenti aziendali.

La compromissione di un fornitore IT introduce un ulteriore rischio per la supply chain. L’accesso ottenuto da un fornitore potrebbe potenzialmente essere utilizzato contro i clienti a valle, anche se in questo caso non sono state divulgate compromissioni specifiche ai danni di clienti.

La storia di Jade Sleet aiuta a spiegare la scelta dell’obiettivo. Nel luglio 2023 GitHub ha dichiarato che il gruppo prendeva di mira utenti di criptovalute e blockchain, oltre ai fornitori che servivano queste organizzazioni. All’inizio del 2025, al gruppo è stato associato il furto di circa 1,5 miliardi di dollari dall’infrastruttura cold-wallet di Bybit, in seguito alla compromissione dell’ambiente di sviluppo di Safe{Wallet}.

La recente intrusione attribuita al fornitore indiano di servizi IT segue la stessa logica strategica: raggiungere risorse di valore compromettendo prima le persone e i sistemi coinvolti nella loro realizzazione, gestione o manutenzione.

Cosa dovrebbero verificare i team di sviluppo e sicurezza

Le organizzazioni dovrebbero iniziare esaminando i file .terraform.lock.hcl e i moduli Terraform alla ricerca di dipendenze inattese, checksum modificati e riferimenti a registri non attendibili. Qualsiasi presenza di registry.hashicorp-aws[.]com richiede un approfondimento.

I team di sicurezza dovrebbero correlare le esecuzioni di terraform init con le connessioni in uscita dalle workstation degli sviluppatori. I repository ricevuti tramite colloqui o conversazioni di selezione non richiesti dovrebbero essere esaminati in un ambiente isolato prima dell’esecuzione di qualsiasi comando di build, inizializzazione o installazione delle dipendenze.

Sui sistemi Apple Silicon, i difensori dovrebbero cercare:

• Artefatti di FLATROOF o Gaslight e ROOFDECK
• Attività di comando e controllo basate su Telegram non previste
• Traffico Nostr non coerente con il normale utilizzo aziendale
• macOS Launch Agents non riconosciuti
• Processi sospetti avviati da Cursor
• Accessi ai profili dei browser, alle cronologie del Terminale o a login.keychain-db
• Raccolta di inventari delle applicazioni e istantanee dei processi
• Binari delle backdoor rimossi o sostituiti senza una ragione apparente
• Eseguibili sconosciuti privi di simboli e dati di debugging

Se è possibile che un endpoint di sviluppo sia stato compromesso, le organizzazioni dovrebbero ruotare le credenziali e i token disponibili su quel sistema. La risposta dovrebbe comprendere account cloud, controllo del codice sorgente, servizi CI/CD, registri di pacchetti e sistemi legati alle criptovalute, non limitarsi alla password locale di macOS.

Le reti di sviluppo dovrebbero inoltre essere segmentate dalla produzione, limitando l’accesso laterale a quanto necessario per ciascun ruolo. Registri affidabili, controlli d’integrità indipendenti, build riproducibili e revisione obbligatoria delle modifiche alle dipendenze possono ridurre l’esposizione a esercizi tecnici dannosi.

L’assunto difensivo di fondo deve cambiare: un esercizio di programmazione è contenuto eseguibile proveniente da terzi. Deve essere sottoposto allo stesso livello di controllo di qualsiasi altro software non attendibile.