Jade Sleet esce dal tunnel crypto: backdoor macOS trovati in un…

SentinelOne ha rivelato che il threat actor nordcoreano Jade Sleet ha compromesso un provider IT indiano con i backdoor FLATROOF e ROOFDECK, precedentemente usati

Il threat actor nordcoreano Jade Sleet ha compromesso un provider di servizi IT indiano usando i backdoor macOS FLATROOF e ROOFDECK, gli stessi strumenti osservati nell'attacco al bridge LayerZero/KelpDAO di marzo-aprile 2026. La rivelazione, pubblicata il 20 settembre 2026 da SentinelOne e SentinelLabs, indica che questi implant non sono più confinati al settore cryptocurrency: la vittima indiana, descritta come una "much smaller organization", non ha legami con la blockchain. L'endpoint compromesso era un MacBook Apple Silicon di un ingegnere DevOps, con accesso a credenziali cloud e source control.

Punti chiave

I backdoor FLATROOF e ROOFDECK, entrambi scritti in Rust per macOS ARM64, erano già stati osservati nell'attacco LayerZero/KelpDAO di marzo-aprile 2026
La vittima indiana è un provider IT senza legami crypto, indicando espansione del targeting di Jade Sleet oltre il settore blockchain
Gli implant erano su disco dal 18 marzo 2026, rimasti dormienti fino al 29 marzo, quando sono stati attivati dall'apertura di un workspace Cursor
Il C2 sfrutta Telegram (FLATROOF) e il protocollo decentralizzato Nostr (ROOFDECK), con aggiornamento dinamico degli implant per evasione

La catena d'attacco: da finta interview a backdoor persistente

Il meccanismo di delivery nella vittima indiana resta non confermato. Le fonti indicano che la campagna documentata da SentinelLabs utilizza finte interview di lavoro per sviluppatori, con repository GitHub che contengono un file .terraform.lock.hcl weaponizzato. Questo file punta a domini typosquatted che imitano HashiCorp: registry.hashicorp-aws[.]com, registry.hashicorp-aws[.]io e registry.hashicorp-terraform[.]io, secondo SentinelLabs via Technobezz.

L'esecuzione di terraform init attiva il provider malevolo, che deploya gli implant sul sistema target. Nel caso del provider indiano, i backdoor erano presenti su disco già dal 18 marzo 2026. Sono rimasti dormienti per undici giorni, fino al 29 marzo, quando l'apertura del workspace ~/DevOps-Automation/cloudshield in Cursor ha innescato l'esecuzione di entrambi gli implant secondi dopo.

FLATROOF è stato posizionato come SystemUpdate nella directory ~/Library/com.apple.iTunesCloud/, secondo SentinelLabs. Questo componente rimuove l'attributo quarantine e imposta il bit eseguibile su ROOFDECK, che gira senza controllo della firma. Il 14 aprile 2026, alle 18:25, FLATROOF ha ri-armato ROOFDECK, confermando la persistenza attiva del sistema.

Due backdoor, due protocolli C2: Telegram e Nostr

La divisione funzionale tra i due implant è netta. FLATROOF gestisce la raccolta dei dati e il comando-controllo tramite Telegram. ROOFDECK fornisce shell remota, movimento laterale e persistenza avanzata, usando il protocollo Nostr per un'infrastruttura C2 decentralizzata. Questo protocollo, originariamente progettato per social network resistenti alla censura, rende il takedown delle infrastrutture operativamente più complesso rispetto ai server centralizzati tradizionali.

ROOFDECK verifica l'integrità dei comandi ricevuti tramite chiave pubblica embedded prima dell'esecuzione, un meccanismo che riduce il rischio di hijacking dell'infrastruttura da parte di altri attori. Il 20 aprile 2026 — il giorno dopo che LayerZero ha pubblicamente riconosciuto l'hack KelpDAO — è stata deployata una versione aggiornata di ROOFDECK che rimuove simboli e informazioni di debug per evasione.

Quella stessa versione ha eliminato gli implant originali alle 13:15 e ha continuato il beaconing verso grenight[.]com fino al 1º giugno 2026, secondo SentinelLabs. Altri domini e IP identificati includono technicais a 176[.]97.114.232, hubpage a 45[.]11.59.140 e l'indirizzo di staging 85[.]137.56.10.

"These groups' initial access efforts include targeting third parties and their software supply chain, which is where much of the industry's exposure has moved, putting the developer endpoint at the center of the defense" — SentinelOne

Perché il MacBook di un DevOps è diventato il perimetro critico

La scelta dell'endpoint di sviluppo come punto di ingresso non è casuale. Gli ingegneri DevOps operano con privilegi elevati su infrastrutture cloud, pipeline CI/CD e repository di codice sorgente. Un compromesso su questa figura professionale espone non solo le credenziali personali, ma potenzialmente l'intero ecosistema di clienti del provider IT. Le aziende indiane di outsourcing, che servono corporazioni globali, rappresentano in questo scenario un ponte verso supply chain più ampie.

Le difese tradizionali basate su perimeter falliscono qui perché l'attacco attraversa toolchain legittime: Cursor, Terraform, GitHub Desktop. Il repository terraform-candidate-repo è stato clonato via GitHub Desktop il 13 aprile 2026, un'operazione indistinguibile dal flusso di lavoro normale di uno sviluppatore. Il beaconing condizionato all'uso dell'IDE — attivato solo all'apertura del workspace — riduce ulteriormente la superficie di rilevamento da parte di strumenti di monitoraggio generici.

SentinelLabs nota esplicitamente che "the finding suggests the tools are not limited to crypto targets". Questa espansione è coerente con un pattern più ampio: già nel luglio 2023, GitHub — allora proprietà di Microsoft — aveva osservato che Jade Sleet "mostly targets users associated with cryptocurrency and other blockchain-related organizations, but also targets vendors used by those firms". Il provider IT indiano potrebbe rappresentare una variazione su questo tema, o un'evoluzione verso targeting indipendente dal settore.

Cosa fare adesso

Le fonti indicano azioni prioritarie per le organizzazioni con sviluppatori che usano macOS e infrastrutture cloud:

Verificare la presenza di connessioni ai domini registry.hashicorp-aws[.]com, registry.hashicorp-aws[.]io, registry.hashicorp-terraform[.]io e grenight[.]com, nonché agli IP 176[.]97.114.232, 45[.]11.59.140 e 85[.]137.56.10 nei log di rete
Ispezire la directory ~/Library/com.apple.iTunesCloud/ sui sistemi macOS per file sospetti denominati SystemUpdate o binari senza firma
Controllare l'esecuzione di processi terraform che contattano registri non ufficiali di HashiCorp, in particolare quando innescati da repository GitHub non verificati
Rivedire il monitoraggio sui dispositivi di sviluppo con lo stesso rigore applicato ai server di produzione, data la centralità del "developer endpoint" nel perimetro di difesa

Domande senza risposta e il limite del dossier

Diversi elementi rimangono non confermati. Il meccanismo di delivery iniziale nella vittima indiana è "unknown at this stage" secondo SentinelOne; le finte interview documentate potrebbero essere parte di una campagna parallela. Non è chiaro se le aziende "Northwind" e "Novacart" citate nei repository siano reali o fabbricate per l'ingegneria sociale. L'obiettivo finale dell'attacco — furto di credenziali cloud, accesso a clienti, o altro — non è dichiarato dalle fonti.

Non emerge sovrapposizione infrastrutturale che colleghi il provider IT indiano a LayerZero o KelpDAO allo stato attuale. L'ipotesi che si tratti di un attacco alla supply chain verso il settore crypto resta non verificata. Allo stesso modo, non è riportato se esistano altre vittime oltre le due note.

L'aggiornamento di ROOFDECK il 20 aprile 2026, il giorno dopo la pubblica ammissione di LayerZero, suggerisce una reattività dell'attore alle controinformazioni: l'eliminazione degli implant originali e il passaggio a una versione depurata indica awareness operativa del rischio di esposizione. Questo pattern — adattamento strumentale in risposta alla disclosure pubblica — è tipico di attori nation-state con risorse per manutenzione continua del proprio arsenale.

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

Fonti

Fonti e riferimenti

Ricevi DeafLetter