DarkBlinders spia Israele e Kurdistan: GitHub usato come centro di comando

🛡️ Executive Summary

• DarkBlinders ha compromesso obiettivi in Israele e nel Kurdistan iracheno: Dream Research Labs documenta il furto di credenziali e l’esfiltrazione di almeno 1 GB di dati da un ambiente cloud governativo.
• GitHub diventa un’infrastruttura C2 a due livelli: i repository myLic e myCode permettono di registrare le macchine infette, selezionare le vittime e attivare una backdoor PowerShell soltanto sui sistemi scelti.
• L’attribuzione converge verso UNC5795, Dust Specter e il possibile ecosistema APT34, ma il collegamento organizzativo con il gruppo iraniano resta una valutazione a media confidenza.

La campagna di cyberspionaggio DarkBlinders rivela un’operazione contro obiettivi governativi e individui di interesse strategico in Medio Oriente, nella quale l’infrastruttura di comando e controllo non dipende da un tradizionale server clandestino ma da repository GitHub utilizzati per registrare le vittime, distribuire chiavi di attivazione ed eseguire comandi da remoto. L’indagine di Dream Research Labs, pubblicata l’8 ottobre 2026, documenta attività osservate tra agosto e ottobre, con compromissioni confermate nella Regione del Kurdistan iracheno e ai danni di una figura israeliana di alto profilo collegata al settore della sicurezza. L’elemento più significativo non è soltanto la sofisticazione del malware, ma la capacità degli operatori di selezionare quali sistemi trasformare in obiettivi di spionaggio attivo, separando il primo contatto dalla piena compromissione.

DarkBlinders colpisce il cloud governativo iracheno e un obiettivo israeliano

L’indagine di Dream Research Labs nasce dall’analisi di un’operazione che utilizza pagine di phishing, falsi servizi di condivisione e un’applicazione per videoconferenze per ottenere credenziali o installare componenti malevoli. I ricercatori hanno individuato infrastrutture che impersonavano il Ministero degli Esteri del Kuwait, il Segretariato generale del Consiglio di cooperazione del Golfo e servizi cloud riconducibili al governo regionale curdo. Il perimetro delle esche indica un interesse verso ambienti diplomatici e istituzionali, ma non permette di considerare compromesse tutte le organizzazioni impersonate. Le vittime confermate attraverso l’infrastruttura di comando comprendono invece un’entità governativa della Regione del Kurdistan, associata a un ambiente cloud, e una persona israeliana di rilievo nel settore della sicurezza.

La ricostruzione assume particolare valore perché i ricercatori non si sono limitati a esaminare campioni malware. Attraverso token recuperati dai componenti malevoli hanno ottenuto accesso in sola lettura ai repository utilizzati dagli attaccanti, osservando registrazioni dei sistemi e comandi operativi già presenti. Nel caso iracheno, le evidenze comprendono furto di credenziali ed esfiltrazione di almeno un gigabyte di dati, mentre la documentazione disponibile non consente di quantificare allo stesso modo l’impatto sull’obiettivo israeliano. Dream precisa di non avere modificato i repository né inviato istruzioni agli impianti attivi. Questa distinzione è importante: il rapporto presenta una ricostruzione basata su artefatti e attività osservate, non una simulazione delle capacità teoriche del malware.

Leggi anche: Dust Specter assedia l’Iraq con SPLITDROP e GHOSTFORM.

StarkMeet nasconde il malware dietro una falsa videoconferenza

La componente di distribuzione più caratteristica della campagna è StarkMeet, presentata come una normale applicazione per riunioni online. L’installer analizzato, realizzato con Inno Setup e distribuito come versione 3.2, installa un’interfaccia apparentemente utilizzabile nella directory %LOCALAPPDATA%\StarkMeet, mentre colloca i componenti malevoli in %LOCALAPPDATA%\Microsoft\RuntimeBroker. Il programma visibile presenta riferimenti a Stark Industries e personaggi dell’universo Marvel, consente anteprime locali di videocamera, microfono e condivisione dello schermo, ma restituisce sempre un errore quando l’utente tenta di partecipare a una riunione. La falsa applicazione svolge quindi una funzione di copertura, mentre un ramo separato dell’installazione prepara il controllo remoto del sistema.

Il rapporto non recupera il messaggio originale con cui l’archivio StarkMeet.zip sarebbe stato consegnato. Una email di phishing o un invito a una riunione sono possibilità coerenti con il contesto, ma non costituiscono vettori iniziali confermati. Questa cautela non riduce la rilevanza della catena osservata: l’attore ha costruito un’applicazione abbastanza credibile da giustificare un’installazione volontaria e ha separato la componente visibile dal malware persistente. Di conseguenza, la rimozione del programma di videoconferenza non garantisce l’eliminazione della backdoor.

La campagna utilizza anche false pagine Outlook Web App associate a domini che imitano il Ministero degli Esteri kuwaitiano e il Consiglio di cooperazione del Golfo. I moduli raccolgono nome utente e password inviandoli a endpoint controllati dagli attaccanti. In parallelo, siti che imitano Google Drive presentano archivi ZIP come allegati impossibili da visualizzare in anteprima, inducendo il destinatario a scaricarli. Il phishing delle credenziali e la distribuzione del malware rappresentano quindi due percorsi distinti e complementari, capaci di produrre accesso a servizi cloud anche senza una compromissione completa dell’endpoint.

RuntimeBroker registra le vittime prima di attivare la backdoor

La catena di esecuzione sfrutta un eseguibile legittimo e firmato, originariamente denominato vshost.exe, rinominato RuntimeBroker.exe. Il componente carica RuntimeBroker.dll mediante una tecnica basata su AppDomainManager, utilizzando il contesto .NET per avviare il codice malevolo. Il loader verifica che il processo si trovi nella directory prevista e stabilisce la persistenza attraverso il valore MicrosoftRuntime nella chiave HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Il primo controllo della persistenza avviene dopo 121 secondi dall’avvio e viene ripetuto ogni ora. Una volta attivo, RuntimeBroker.dll costruisce un identificativo della vittima combinando una stringa fissa con informazioni dell’utente, del dominio e della macchina, quindi calcolando un hash SHA-256. Attraverso un token GitHub incorporato nel codice, invia al repository PeakyBlindersTeam/myLic un rapporto contenente nome del computer, account, dominio, lingua, fuso orario, layout di tastiera e risultati dei controlli ambientali. Il malware cerca anche tracce di macchine virtuali, strumenti di analisi, anomalie temporali e caratteristiche hardware sospette. Questi controlli non interrompono necessariamente l’esecuzione: producono informazioni che permettono all’operatore di valutare il sistema compromesso.

La distinzione tra registrazione e attivazione è il cuore dell’operazione. Dream ha identificato circa dieci host nei dati iniziali del repository myLic, ma soltanto due vittime nel canale utilizzato per i comandi della seconda fase. Non significa che tutte le altre macchine fossero innocue o che non esistessero ulteriori compromissioni: significa che, nei dati accessibili ai ricercatori, soltanto due sistemi risultavano progrediti fino all’impiego operativo della backdoor. La selezione consente di riservare le capacità più invasive agli obiettivi ritenuti interessanti, riducendo l’esposizione del payload completo.

GitHub myLic e myCode separano attivazione e comando remoto

Per passare alla seconda fase, RuntimeBroker.dll recupera dal repository myLic un file di licenza specifico per la vittima. Il contenuto fornisce il materiale necessario a decifrare RuntimeBrokerApi.dll, conservata localmente in forma cifrata. Il loader utilizza AES-256-CBC con padding PKCS7, derivando la chiave mediante SHA-256 della stringa di licenza e ricavando il vettore di inizializzazione dai primi 16 byte della stessa chiave. Dopo la decifratura, l’assembly viene caricato direttamente in memoria attraverso un nuovo AppDomain, senza salvare su disco la DLL in chiaro. Il file di licenza viene successivamente svuotato. Tuttavia, Dream ha recuperato il materiale necessario dalla cronologia Git del repository, dimostrando come la persistenza delle versioni precedenti possa conservare artefatti decisivi anche quando l’operatore tenta di cancellarli dal contenuto corrente. La backdoor recuperata contiene un secondo token GitHub, questa volta associato a PeakyBlindersTeam/myCode, repository destinato ai comandi e allo scambio dei risultati. Il sistema interroga il proprio file di tasking approssimativamente ogni 63 secondi e cancella il comando dopo averlo letto, mentre le risposte vengono archiviate con nomi costruiti per facilitare l’ordinamento temporale.

L’esecuzione dei comandi PowerShell avviene tramite PsProxy.dll, caricata nella memoria del processo e capace di creare un runspace attraverso System.Management.Automation. Questa architettura evita di dover avviare necessariamente un processo separato powershell.exe, limitando l’efficacia delle regole di rilevamento basate soltanto sulla comparsa del relativo processo figlio. La backdoor supporta inoltre trasferimento di file, caricamento di documenti verso il repository, download ed estrazione di archivi ZIP e interrogazione dei limiti delle API GitHub. I contenuti dei comandi e dei risultati sono codificati in Base64, senza un ulteriore livello di cifratura applicativa. Il malware prevede anche un relay alternativo basato su Cloudflare Workers, verificando che la risposta presenti caratteristiche compatibili con quelle delle API GitHub. L’impiego di piattaforme condivise non rende automaticamente sospetto il traffico verso GitHub o Cloudflare: impone piuttosto di identificare account, repository, percorsi API e comportamenti anomali associati alla campagna.

I commenti pubblici di GitHub permettono di cambiare infrastruttura

Un’altra caratteristica rilevante è il meccanismo con cui DarkBlinders può sostituire le credenziali e i repository di comando senza aggiornare direttamente il malware installato. Entrambi gli stadi includono una procedura che consulta le issue pubbliche del repository Microsoft/vscode su GitHub, cercando commenti contenenti un blocco HTML nascosto con informazioni codificate. Il contenuto, dopo una sequenza di trasformazioni crittografiche, può fornire nuovi parametri per account, repository e token. Il controllo viene effettuato periodicamente oppure in risposta a determinati errori di accesso.

L’obiettivo è evitare che la revoca di un token o la rimozione di un repository interrompa definitivamente il controllo degli impianti. In un’infrastruttura C2 tradizionale, la perdita del server può compromettere l’intera operazione. Qui l’attaccante cerca di trasformare una funzione ordinaria di una piattaforma pubblica in un canale per distribuire configurazioni sostitutive. Non risulta dal rapporto che Microsoft o GitHub abbiano collaborato con gli attaccanti: i servizi vengono sfruttati come infrastrutture legittime accessibili dall’esterno.

Questo modello presenta analogie funzionali con altre campagne che utilizzano servizi cloud per occultare le comunicazioni. Un precedente significativo è Project CAV3RN, che impiega Google Apps Script e DNS come infrastruttura di comando contro Israele. Le due operazioni non devono essere considerate automaticamente riconducibili allo stesso gruppo: il confronto riguarda soprattutto la trasformazione dei servizi affidabili in componenti intercambiabili del controllo remoto.

DarkBlinders, Dust Specter e UNC5795: le prove del collegamento

L’indagine ricostruisce una continuità tra cinque ondate operative, collegando la campagna attuale a precedenti infrastrutture GitHub e a malware già documentati da Elastic Security Labs, Unit 42 e Group-IB. La denominazione PeakyBlindersTeam si inserisce in una sequenza di account che comprende johnshelllby, arturshellby, GreenBeret0 e altre varianti del tema Peaky Blinders. Anche il servizio di gestione remota dei file TommyFiles riprende lo stesso immaginario. I nomi, da soli, non dimostrano l’identità degli operatori, ma diventano elementi investigativi quando coincidono con architetture malware, repository e modalità di comunicazione ricorrenti. La correlazione più robusta riguarda UNC5795, cluster già associato a strumenti denominati HOTAIR, AEROSTAT e TREEWORLD. Dream collega i componenti delle campagne DarkBlinders precedenti, tra cui SHELBYLOADER e SHELBYC2, alle classificazioni malware utilizzate nell’intelligence di Google. Per Dust Specter, il punto di contatto comprende invece GHOSTFORM, associato alla famiglia TREEWORLD. Queste corrispondenze, unite alle sovrapposizioni infrastrutturali, portano Dream a valutare con confidenza medio-alta che DarkBlinders e Dust Specter appartengano al medesimo cluster operativo UNC5795.

Il collegamento acquista ulteriore rilevanza considerando che Dust Specter era già stato documentato contro funzionari governativi iracheni, attraverso strumenti come SPLITDROP e GHOSTFORM. Il nuovo rapporto non si limita quindi a descrivere un malware aggiuntivo, ma propone una ricomposizione di attività precedentemente osservate con denominazioni differenti, rendendo più leggibile la continuità delle operazioni di intelligence contro il Medio Oriente.

Il possibile rapporto con APT34 resta a media confidenza

La parte più delicata dell’indagine riguarda l’attribuzione al più ampio ecosistema APT34, conosciuto anche come OilRig. Dream identifica una connessione infrastrutturale tra UNC5795 e UNC5187 attraverso l’indirizzo 89.46.233[.]239, utilizzato in periodi differenti da componenti associati ai due cluster. Il dominio meetingapp[.]site, collegato a Dust Specter, ha risolto verso quell’indirizzo tra maggio e giugno 2026, mentre un campione della famiglia ENDDOT associato a UNC5187 aveva precedentemente comunicato con lo stesso server. L’elemento che rafforza il collegamento non è il semplice riutilizzo di un indirizzo IP. I ricercatori hanno osservato impronte dei servizi, una configurazione SSH su una porta insolita e la persistenza della stessa chiave host SSH attraverso periodi differenti. Questi dati suggeriscono continuità nell’amministrazione dell’infrastruttura, pur non dimostrando che un singolo operatore ne abbia mantenuto ininterrottamente il controllo. A supporto si aggiungono le precedenti valutazioni di Recorded Future e Google/Mandiant sui rapporti tra Dust Specter, UNC5187 e APT34. Dream assegna quindi confidenza media all’ipotesi che UNC5795 e UNC5187 siano sottocluster collegati all’interno di APT34. La presenza di nameserver ParsVDS e il layout di tastiera persiano rilevato su una possibile macchina di test forniscono soltanto indizi contestuali di un collegamento iraniano, non una prova autonoma dell’identità degli attaccanti. La distinzione è essenziale perché l’attribuzione tecnica di una campagna e l’identificazione dell’organizzazione che la dirige sono questioni differenti. La possibile collocazione nel panorama OilRig richiama le operazioni di BladedFeline contro istituzioni del Kurdistan e ambienti governativi iracheni, dove la continuità degli accessi e l’impiego di backdoor specializzate erano già emersi come caratteristiche dello spionaggio regionale. Non esiste però nel rapporto una prova che BladedFeline e DarkBlinders costituiscano la stessa unità operativa.

Gli indicatori di compromissione e le priorità per i SOC

Dream pubblica un insieme esteso di domini, URL, indirizzi IP e hash SHA-256 utili alle attività di threat hunting. Tra gli elementi caratteristici figurano i domini associati alle esche StarkMeet, le imitazioni dei servizi diplomatici del Golfo, i falsi collegamenti Google Drive e i repository PeakyBlindersTeam/myLic e PeakyBlindersTeam/myCode. Per la ricerca sugli endpoint assumono particolare rilevanza la directory %LOCALAPPDATA%\Microsoft\RuntimeBroker, la persistenza MicrosoftRuntime, i caricamenti .NET inattesi e l’attività PowerShell ospitata all’interno di processi che normalmente non dovrebbero eseguirla. Gli hash pubblicati comprendono il loader RuntimeBroker, la backdoor RuntimeBrokerApi.dll, componenti StarkMeet e diversi artefatti di phishing. Il rapporto originale mette a disposizione gli indicatori completi, comprese le rispettive funzioni operative. Le piattaforme condivise non devono essere bloccate indiscriminatamente: una regola che impedisca ogni accesso a GitHub o Cloudflare avrebbe un impatto potenzialmente significativo sulle attività legittime e non rappresenterebbe una risposta proporzionata. Le rilevazioni dovrebbero invece correlare processi sorgente, percorsi API, repository specifici, modifiche alla persistenza, caricamenti di assembly e anomalie nelle comunicazioni.

Continua con: Project CAV3RN e l’uso di Google Apps Script per nascondere il comando e controllo.

Il valore strategico di DarkBlinders è la selezione delle vittime

DarkBlinders dimostra come il cyberspionaggio moderno possa separare l’accesso iniziale dall’effettivo sfruttamento dell’obiettivo. Le macchine registrate non ricevono necessariamente la stessa backdoor operativa: gli attaccanti raccolgono prima informazioni ambientali, valutano il valore del sistema e soltanto successivamente distribuiscono il materiale necessario a decifrare il secondo stadio. Questo riduce l’esposizione delle capacità più sensibili e rende meno affidabile una valutazione dell’incidente basata esclusivamente sul numero di dispositivi che hanno comunicato con il primo repository. La campagna evidenzia anche una criticità strutturale della sicurezza cloud. GitHub viene utilizzato contemporaneamente come registro delle vittime, deposito di chiavi, canale di tasking e possibile meccanismo di recupero dell’infrastruttura, mentre Cloudflare Workers può fornire un percorso alternativo alle comunicazioni. I servizi legittimi non sono compromessi in quanto tali, ma le loro funzionalità vengono incorporate nella catena offensiva. Per le organizzazioni governative e i SOC, la difesa richiede quindi visibilità sulle relazioni tra identità, endpoint e servizi esterni, oltre alle tradizionali firme malware. L’aspetto geopolitico resta altrettanto significativo. La concentrazione di obiettivi in Israele, Iraq e ambienti diplomatici del Golfo conferma un interesse verso informazioni istituzionali e di sicurezza regionale. Il possibile collegamento con APT34 amplia il quadro investigativo, senza autorizzare attribuzioni definitive superiori al livello di confidenza dichiarato dai ricercatori. Il risultato più concreto dell’indagine è la dimostrazione di una campagna operativa che ha trasformato strumenti di sviluppo ordinari in un’infrastruttura selettiva di spionaggio, arrivando a compromettere ambienti governativi e a sottrarre dati riservati.