Stealth Falcon in preda ai cieli del Medio Oriente con Deadglyph

Per anni, il Medio Oriente ha mantenuto la sua reputazione di terreno fertile per le minacce avanzate persistenti (APT). Nel corso del monitoraggio di routine delle attività sospette sui sistemi di clienti di alto profilo, alcuni con sede in questa regione, ESET Research si è imbattuta in una backdoor molto sofisticata e sconosciuta che abbiamo chiamato Deadglyph. Abbiamo derivato il nome da artefatti trovati nella backdoor (come 0xDEADB001, mostrato anche in RIF _Rif111452440 h Table 1
), abbinato alla presenza di un omoglifo attacco. Per quanto ne sappiamo, questa è la prima analisi pubblica di questa backdoor precedentemente non documentata, utilizzata da un gruppo che mostra un notevole grado di sofisticazione e competenza. Sulla base del targeting e di ulteriori prove, attribuiamo con elevata sicurezza Deadglyph al gruppo Stealth Falcon APT.

L'architettura di Deadglyph è insolita in quanto è composta da componenti cooperanti: uno un binario x64 nativo, l'altro un assembly .NET. Questa combinazione è insolita perché il malware in genere utilizza un solo linguaggio di programmazione per i suoi componenti. Questa differenza potrebbe indicare uno sviluppo separato di questi due componenti sfruttando al tempo stesso le caratteristiche uniche dei distinti linguaggi di programmazione che utilizzano. È inoltre possibile sfruttare linguaggi diversi per ostacolare l'analisi, poiché il codice misto è più difficile da navigare ed eseguire il debug.

I tradizionali comandi backdoor non sono implementati nel binario backdoor; vengono invece ricevuti dinamicamente dal server di comando e controllo (C&C) sotto forma di moduli aggiuntivi. Questa backdoor presenta anche una serie di funzionalità per evitare di essere rilevata.

In questo post del blog, diamo uno sguardo più da vicino a Deadglyph e forniamo un'analisi tecnica di questa backdoor, del suo scopo e di alcuni dei componenti aggiuntivi che abbiamo ottenuto. Presenteremo anche le nostre scoperte su Deadglyph al LABScon 2023 conferenza.

Punti chiave del post sul blog:

• ESET Research ha scoperto una sofisticata backdoor con un'architettura insolita che abbiamo chiamato Deadglyph.
• I componenti principali vengono crittografati utilizzando una chiave specifica della macchina.
• I tradizionali comandi backdoor vengono implementati tramite moduli aggiuntivi ricevuti dal suo server C&C.
• Abbiamo ottenuto tre dei tanti moduli: creatore di processi, lettore di file e raccoglitore di informazioni.
• Attribuiamo Deadglyph al gruppo Stealth Falcon.
• Inoltre, abbiamo trovato un downloader di shellcode correlato; postuliamo che potrebbe essere potenzialmente utilizzato per l'installazione di Deadglyph.

La vittima dell'infiltrazione analizzata è un ente governativo del Medio Oriente che è stato compromesso a fini di spionaggio. Anche un campione correlato trovato su VirusTotal è stato caricato sulla piattaforma di scansione dei file da questa regione, in particolare dal Qatar. La regione target è raffigurata sulla mappa in RIF _Rif143614671 h figura 1
.

Stealth Falcon (noto anche come Project Raven o FruityArmor) è un gruppo pericoloso legato agli Emirati Arabi Uniti secondo MITRE. Attivo dal 2012, Stealth Falcon è noto per prendere di mira attivisti politici, giornalisti e dissidenti in Medio Oriente. È stato scoperto e descritto per la prima volta da Citizen Lab, che ha pubblicato un . di una campagna di attacchi spyware nel 2016.

Nel gennaio 2019, Reuters ha pubblicato un rapporto investigativo sul Project Raven, un'iniziativa che presumibilmente impiega ex agenti della NSA e mira agli stessi tipi di obiettivi di Stealth Falcon. Sulla base di questi due rapporti che si riferiscono agli stessi obiettivi e attacchi, Amnesty International ha concluso (mostrato RIF _Rif144978712 h figura 2
) che Stealth Falcon e Project Raven sono in realtà lo stesso gruppo.

Nel settembre 2019, noi ricerca pubblicata su una porta sul retro, attribuita a Stealth Falcon, che utilizzava una tecnica insolita, Servizio trasferimento intelligente in background, per la comunicazione C&C. Riveliamo ora il risultato della nostra analisi approfondita di quella che presumibilmente è l'ultima aggiunta al set di strumenti di spionaggio di Stealth Falcon.

Porta sul retro del glifo morto

La catena di caricamento di Deadglyph è costituita da più componenti, come illustrato in RIF _Rif144978760 h figura 3
. Il componente iniziale è un caricatore di shellcode del registro, che carica lo shellcode dal registro. Questo shellcode estratto, a sua volta, carica la parte x64 nativa della backdoor: l'Esecutore. L'esecutore carica successivamente la parte .NET della backdoor: l'orchestratore. In particolare, l'unico componente sul disco di sistema come file è il componente iniziale, che ha la forma di una libreria di collegamento dinamico (DLL). I restanti componenti vengono crittografati e archiviati in un valore di registro binario.

Sebbene il metodo preciso del vettore di compromissione iniziale non sia ancora stato determinato, il nostro sospetto è che un componente dell'installatore sia coinvolto nell'implementazione di ulteriori componenti e nella creazione di persistenza all'interno del sistema.

Nel resto di questa sezione analizzeremo ogni componente.

Caricatore di shellcode del registro

Il componente iniziale di Deadglyph è una piccola DLL con una singola esportazione, denominata 1. Questo componente viene persistente utilizzando Sottoscrizione agli eventi di Strumentazione gestione Windows (WMI). e funge da caricatore di shellcode del registro. Viene eseguito tramite la riga di comando rundll32 C:WINDOWSSystem32pbrtl.dll,#1.

Il caricatore dello shellcode del registro inizia la sua operazione decrittografando il percorso dello shellcode crittografato memorizzato nel registro di Windows, utilizzando RC4. Sospettiamo che il percorso sia unico per ciascuna vittima; nel caso qui analizzato il percorso del registro era:

SoftwareClassesCLSID{5abc7f42-1112-5099-b082-ce8d65ba0c47}cAbRGHLg

La chiave del registro principale è una delle due hklm or HKCU, a seconda che il processo corrente sia in esecuzione con privilegi elevati o meno. La stessa logica può essere trovata in altri componenti.

Successivamente, il caricatore deriva una chiave RC4 specifica per la macchina utilizzando l'UUID di sistema recuperato dal file tabella firmware SMBIOS non elaborata. Utilizzando questa chiave, carica, decrittografa e quindi esegue lo shellcode. È importante evidenziare che questo approccio di derivazione della chiave garantisce che non venga eseguita una decrittazione corretta se il caricatore viene eseguito su un computer diverso.

È interessante notare che il caricatore può anche essere configurato tramite un flag nel suo file .data per utilizzare una chiave hardcoded per decrittografare lo shellcode, invece di quella specifica della macchina.

Abbiamo individuato un attacco con omoglifi che imitava Microsoft Corporation nel file VERSIONEINFO risorsa di questo e di altri componenti PE. Questo metodo utilizza caratteri Unicode distinti che appaiono visivamente simili, ma in questo caso non identici, ai caratteri originali, in particolare la lettera maiuscola greca San (U+03FA, Ϻ) e la lettera minuscola cirillica O (U+043E, о) in Ϻicrоsоft Corpоrapportoоn.

Shellcode del registro

Composto da due parti, lo shellcode del registro è costituito da una routine di decrittazione e da un corpo crittografato. Innanzitutto, la routine di decrittografia ruota ciascun byte del corpo crittografato verso sinistra di uno (ROL0x01). Successivamente, il controllo viene trasferito a questo corpo decrittografato. Il corpo decriptato è costituito da un caricatore PE e da un file PE, quest'ultimo è l'Esecutore, che rappresenta la parte nativa della backdoor. Questo caricatore è responsabile dell'analisi e del caricamento del file PE associato.

esecutore

L'Executor è la parte x64 nativa della backdoor Deadglyph, che esegue le seguenti operazioni:

• carica la sua configurazione,
• inizializza il runtime .NET,
• carica la parte .NET incorporata della backdoor (l'orchestrator) e
• funge da libreria per l'orchestratore.

Innanzitutto, due configurazioni predefinite integrate nel file .data sezione sono decodificati AES. Le configurazioni comprendono vari parametri, tra cui chiavi di crittografia, impostazioni di sicurezza ed evasione e il punto di ingresso del componente successivo.

Durante l'esecuzione iniziale, queste due configurazioni predefinite vengono archiviate nel registro di Windows, da dove vengono caricate nelle esecuzioni successive, consentendo l'implementazione degli aggiornamenti. Il percorso del registro per ciascuna configurazione viene generato con il seguente formato:

{HKCU|HKLM}ClassiSoftwareCLSID{ }(Predefinito)

è un GUID generato, unico per ciascuna vittima.

Successivamente, viene inizializzato il runtime .NET, quindi l'esecutore RC4 decodifica la parte .NET della backdoor nota come orchestrator. L'orchestratore si trova all'interno del .rsrc sezione dell'Esecutore. La configurazione specifica il metodo di esecuzione dell'orchestrator come punto di ingresso. Inoltre, viene fornita una struttura distinta per facilitare l'accessibilità delle funzioni dell'Esecutore da parte dell'Orchestratore.

Dopo aver avviato l'Orchestrator, l'Executor funge da libreria di supporto per l'Orchestrator. L'Executor contiene molte funzioni interessanti; ne descriviamo alcuni nella sezione seguente, nel contesto del loro utilizzo da parte dell'Orchestrator e degli ulteriori moduli caricati.

Orchestrator

Scritto in .NET, l'Orchestrator è il componente principale della backdoor Deadglyph. Il ruolo primario di questo componente consiste nello stabilire una comunicazione con il server C&C e nell'eseguire comandi, spesso facilitati dal ruolo intermediario dell'Esecutore. A differenza dei componenti precedenti, l'orchestrator è offuscato e utilizza .NET Reactor. Internamente, la backdoor viene chiamata agente, che è un nome comune per la parte client in vari framework post-sfruttamento.

Inizializzazione

L'orchestrator carica innanzitutto la propria configurazione e due moduli incorporati, ciascuno accompagnato dal proprio set di configurazioni, dalle risorse. Queste risorse sono Sgonfiare compresso e AES crittografato. A essi fa riferimento un ID con hash SHA-1 in un nome di risorsa. Una panoramica di queste risorse è fornita in RIF _Rif111452440 h Table 1
.

Tabella 1. Risorse dell'orchestrator

Nome della risorsa	ID (decimale)	ID (esadecimale)	Descrizione
43ed9a3ad74ed7ab74c345a876b6be19039d4c8c	2570286865	0x99337711	Configurazione dell'orchestratore.
3a215912708eab6f56af953d748fbfc38e3bb468	3740250113	0xDEEFB001	Modulo di rete.
42fb165bc9cf614996027a9fcb261d65fd513527	3740250369	0xDEEFB101	Configurazione del modulo di rete.
e204cdcf96d9f94f9c19dbe385e635d00caaf49d	3735924737	0xDEADB001	Modulo temporizzatore.
abd2db754795272c21407efd5080c8a705a7d151	3735924993	0xDEADB101	Configurazione del modulo timer.

La configurazione dell'orchestrator e dei moduli incorporati viene archiviata in formato XML. Un esempio di configurazione dell'orchestrator è mostrato in RIF _Rif111452611 h
figura 4
.

La descrizione delle voci di configurazione dell'orchestrator è mostrata in RIF _Rif111452782 h Table 2
.

Tabella 2. Voci di configurazione dell'orchestrator

Dopo che i componenti della risorsa sono stati caricati, vengono creati più thread per eseguire attività distinte. Uno di questi thread è responsabile della conduzione dei controlli ambientali, una funzione implementata all'interno dell'Executor. Un altro thread è dedicato a stabilire una comunicazione periodica con il server C&C, consentendo il recupero dei comandi. Infine, viene utilizzato un set di tre thread allo scopo di eseguire i comandi ricevuti e successivamente trasmettere qualsiasi output generato al server C&C.

Il thread di controllo dell'ambiente monitora i processi in esecuzione per identificare quelli indesiderati. Questo thread opera con due elenchi distinti di nomi di processi. Se viene rilevato un processo nel primo elenco, la comunicazione C&C e l'esecuzione del comando vengono sospese finché il processo indesiderato non esiste più. Se c'è una corrispondenza per qualsiasi processo nel secondo elenco, la backdoor si chiude immediatamente e si disinstalla.

Nessuno dei due elenchi è stato configurato nell'istanza analizzata, quindi non sappiamo quali processi potrebbero essere generalmente controllati; riteniamo che probabilmente abbia lo scopo di eludere strumenti di analisi che potrebbero rilevare attività sospette e portare alla scoperta della backdoor.

Comunicazione

L'orchestrator utilizza due moduli integrati per la comunicazione C&C: timer e rete. Come l'orchestrator, questi moduli sono offuscati con .NET Reactor. La configurazione per entrambi i moduli viene fornita dall'orchestrator. All'interno dell'orchestrator è inclusa una configurazione preimpostata per i moduli; facoltativamente, l'orchestrator può anche caricare una versione di configurazione aggiornata dal registro:

{HKCU|HKLM}ClassiSoftwareCLSID{ }

La backdoor contiene un'interessante misura di sicurezza relativa alla comunicazione. Se la backdoor non riesce a stabilire una comunicazione con il server C&C per un tempo superiore ad una soglia predefinita, configurata all'interno dell'Executor, viene attivato un meccanismo di auto-disinstallazione. Tale soglia temporale è espressa in ore ed è stata fissata ad un'ora nel caso esaminato.

Questo approccio ha un duplice scopo. Da un lato impedisce la generazione di richieste di rete ridondanti verso un server inaccessibile. D’altro canto riduce le possibilità di un successivo rilevamento nel caso in cui gli operatori perdano il controllo della backdoor.

Modulo timer

Questo piccolo modulo esegue la richiamata specificata a un intervallo configurabile. Viene utilizzato dall'orchestrator in combinazione con il modulo di rete per comunicare periodicamente con il server C&C. Per impedire la creazione di modelli rilevabili nei log di rete, l'intervallo di esecuzione è soggetto a randomizzazione, in base a una percentuale specificata nella configurazione. Nel caso analizzato, l'intervallo è stato impostato su cinque minuti, con una variazione del ±20% introdotta per casualità.

Un altro metodo per evitare schemi di rete rilevabili nella comunicazione periodica può essere trovato nella generazione di richieste inviate al server C&C. Questo meccanismo, implementato nell'Executor, prevede l'inclusione di riempimento di varia lunghezza, composto da byte casuali, all'interno delle richieste, risultando in richieste di diverse dimensioni.

Modulo di rete

Il modulo Rete implementa la comunicazione con i server C&C specificati nella sua configurazione. Può inviare dati a un server C&C utilizzando richieste POST HTTP(S). In particolare, offre diversi meccanismi per acquisire i dettagli della configurazione del proxy. Questa caratteristica suggerisce una potenziale attenzione agli ambienti in cui l’accesso diretto a Internet non è disponibile.

Un esempio di configurazione decodificata (e abbellita) è mostrato in RIF _Rif144978805 h figura 5
.

Le voci di configurazione contengono dettagli relativi alle comunicazioni di rete: URL C&C, agente utente HTTP e, facoltativamente, una configurazione proxy.

Quando si comunica con il server C&C, sotto HTTPS viene utilizzato un protocollo binario personalizzato con contenuto crittografato.

Comandi

L'orchestrator riceve comandi dal server C&C sotto forma di attività, che vengono accodate per l'esecuzione. Vengono elaborati tre tipi di attività:

• Compiti dell'orchestratore,
• Compiti dell'esecutore e
• Carica attività.

I primi due tipi vengono ricevuti dal server C&C e il terzo viene creato internamente per caricare l'output di comandi ed errori.

Compiti dell'orchestratore

Le attività dell'orchestrator offrono la possibilità di gestire la configurazione dei moduli Rete e Timer e anche di annullare le attività in sospeso. La panoramica delle attività dell'orchestrator è mostrata in RIF _Rif111101783 h Table 3
.

Tabella 3. Attività dell'orchestrator

Compiti dell'esecutore

Le attività dell'esecutore offrono la possibilità di gestire la backdoor ed eseguire moduli aggiuntivi. È interessante notare che la tradizionale funzionalità backdoor non è intrinsecamente presente all'interno del file binario stesso. Invece, queste funzioni vengono ottenute dal server C&C sotto forma di file PE o shellcode. L'intera portata del potenziale della backdoor rimane sconosciuta senza questi moduli aggiuntivi, che ne sbloccano effettivamente le vere capacità. Una panoramica delle attività del modulo è mostrata in RIF _Rif117677179 h Table 4
, che include dettagli sui pochi moduli identificati. Allo stesso modo, RIF _Rif117677188 h Table 5
fornisce una panoramica delle attività di gestione associate all'Esecutore.

Tabella 4. Attività dell'esecutore – moduli

Tipologia	Descrizione
0x??–0x63	Sconosciuto
0x64	Lettore di file
0x65	Sconosciuto
0x66	Sconosciuto
0x67	Sconosciuto
0x68	Sconosciuto
0x69	Creatore di processi
0x6A	Sconosciuto
0x6B	Sconosciuto
0x6C	Raccoglitore di informazioni
0x6D	Sconosciuto
0x6E	Sconosciuto

Tabella 5. Compiti dell'esecutore – gestione

Tipologia	Descrizione
0x6F-0x76	Non implementato
0x77	Imposta la configurazione dell'esecutore
0x78	Ottieni la configurazione dell'esecutore
0x79-0x7C	Non implementato
0x7D	Aggiornanento
0x7E	smettere
0x7F	Disinstallare

Il comando che imposta la configurazione dell'Executor può modificare:

• elenchi di processi indesiderati,
• soglia temporale dell'errore di comunicazione C&C e
• limite temporale per lo svolgimento dei moduli aggiuntivi.

moduli

Siamo riusciti a ottenere tre moduli unici dal server C&C, ciascuno corrispondente a un diverso tipo di attività dell'Esecutore, come mostrato in RIF _Rif117677179 h Table 4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003100310037003600370037003100370039000000
. Sulla base delle informazioni disponibili, stimiamo che ci siano da nove a quattordici moduli in totale. Poiché i moduli sono in realtà comandi backdoor, devono eseguire un'operazione di base e quindi, facoltativamente, restituire il proprio output. I moduli che abbiamo ottenuto sono DLL con un'esportazione senza nome (ordinal 1), in cui risolvono le funzioni API necessarie e chiamano la funzione principale.

Una volta eseguiti, i moduli vengono forniti con una funzione di risoluzione API, che può risolvere le API Windows e le API Executor personalizzate. Le API di Windows fanno riferimento a un hash DWORD, calcolato dal nome dell'API e dalla relativa DLL. I valori hash piccoli (<41) vengono trattati in modo speciale, facendo riferimento alla funzione API Executor. L'Executor API comprende un totale di 39 funzioni accessibili ai moduli. Queste funzioni riguardano una varietà di operazioni, tra cui:

• operazioni sui file,
• crittografia e hashing,
• compressione,
• Caricamento PE,
• accedere alla rappresentazione del token e
• utilità.

Nel resto di questa sezione descriviamo i moduli che abbiamo ottenuto.

Creatore di processi

Moduli 0x69 esegue la riga di comando specificata come un nuovo processo e fornisce l'output risultante all'orchestrator. Il processo può essere creato con un utente diverso e il suo tempo di esecuzione può essere limitato. In particolare, un insolito API di lavoro viene utilizzato nella funzionalità di questo modulo.

Questo modulo è stato servito con la riga di comando cmd.exe /c elencoattività /v.

Supponiamo che serva come comando inattivo inviato automaticamente, mentre gli operatori aspettano che accada qualcosa di interessante sul computer compromesso.

Raccoglitore di informazioni

Moduli 0x6C raccoglie informazioni estese sul computer tramite query WMI e le trasmette all'orchestrator. Vengono raccolte informazioni su quanto segue:

• sistema operativo,
• adattatori di rete,
• software installato,
• azionamenti,
• servizi,
• piloti,
• processi,
• utenti,
• variabili d'ambiente, e
• software di sicurezza.

Lettore di file

Moduli 0x64 legge il file specificato e restituisce il contenuto all'orchestrator. Facoltativamente, è possibile eliminare il file dopo la lettura.

Abbiamo visto questo modulo utilizzato per recuperare il file di dati di Outlook della vittima

c:Utenti AppDataLocalMicrosoftOutlookoutlook.ost.

Catena con downloader di shellcode

Durante l'indagine su Deadglyph, abbiamo riscontrato un file CPL dubbio firmato con un certificato scaduto e senza controfirma con un timestamp, che era stato caricato su VirusTotal dal Qatar. Dopo un esame più attento, è diventato evidente che questo file CPL funzionava come un downloader di shellcode a più fasi, condividendo alcune somiglianze di codice con Deadglyph. La catena di carico è illustrata in RIF _Rif143693067 h figura 6
.

Nella sua forma iniziale, che funge da prima fase, questo file prevede di avere un file . Cpl estensione (file del Pannello di controllo) e deve essere eseguito tramite un'azione di doppio clic. Dopo l'esecuzione in questo modo, lo shellcode incorporato viene sottoposto a decrittografia XOR e i processi in esecuzione vengono controllati per identificare un processo host adatto per la successiva iniezione.

If avp.exe (un processo di sicurezza endpoint di Kaspersky) è in esecuzione, %windir%system32UserAccountBroker.exe si usa. Altrimenti verrà utilizzato il browser predefinito. Quindi, crea il processo host in uno stato sospeso, inserisce lo shellcode dirottando il suo thread principale e riprende il thread.

La seconda fase, lo shellcode, è composta da due parti. La prima parte dello shellcode risolve gli hash API, utilizzando la stessa tecnica unica di calcolo dell'hash impiegata in Deadglyph, e decrittografa le stringhe con i nomi dei processi. Avvia un thread di autoeliminazione con il compito di sovrascrivere e successivamente cancellare il file della prima fase. Successivamente, lo shellcode procede a ispezionare i processi attualmente attivi, individuando una soluzione di sicurezza.

Se viene rilevato uno qualsiasi dei processi specificati, lo shellcode crea un thread dormiente con la priorità più bassa (THREAD_PRIORITY_IDLE) e gli consente di rimanere attivo per una durata di 60 secondi prima di terminare il suo funzionamento. Questo intervallo viene probabilmente implementato come misura precauzionale per eludere determinati meccanismi di rilevamento utilizzati dalle soluzioni di sicurezza. Infine lo shellcode procede invocando l'esecuzione della seconda parte del suo codice.

La seconda parte dello shellcode carica un file PE incorporato con la fase tre e ne richiama l'esportazione con un numero ordinale 1.

La terza fase, una DLL, funge da caricatore .NET e contiene il payload al suo interno .rsrc .

Per caricare il payload, viene inizializzato il runtime .NET. Durante l'inizializzazione di .NET vengono eseguite due tecniche intriganti, apparentemente destinate a eludere Windows Scansione Antimalware Scan Interface (AMSI).:

• Il caricatore .NET aggancia temporaneamente il file GetModuleHandleW importare nel caricato clr.dll, durante la chiamata ICorRuntimeHost::Start. L'hook manomette il valore restituito quando GetModuleHandleW si chiama con NULL. Restituisce un puntatore a un PE fittizio senza sezioni.
• Quindi corregge sottilmente il file AmsiInitialize importa la stringa del nome nel file .rdata sezione del carico clr.dll a amsiinizializzare.

La quarta fase è un assembly .NET, offuscato con ConfuserEx, che funge da downloader di shellcode. Innanzitutto, decrittografa XOR la ​​sua configurazione in formato XML dalle sue risorse. Viene presentata una versione abbellita della configurazione estratta RIF _Rif143695453 h figura 7
. Le voci di configurazione contengono dettagli relativi alla comunicazione di rete e ai processi bloccati.

Prima di procedere, controlla i processi in esecuzione rispetto a un elenco di processi bloccati dalla configurazione. Se viene rilevata una corrispondenza, l'esecuzione si interrompe. È importante notare che nell'istanza analizzata questa blocklist non è stata impostata.

Successivamente, invia una richiesta HTTP GET al server C&C per recuperare alcuni shellcode, utilizzando i parametri specificati nella configurazione (URL, User-Agent e facoltativamente Proxy). Purtroppo durante la nostra indagine non siamo riusciti ad acquisire alcun codice shell dal server C&C. Tuttavia, ipotizziamo che il contenuto recuperato potrebbe potenzialmente fungere da programma di installazione per Deadglyph.

Successivamente, lo shellcode recuperato viene eseguito all'interno di un thread appena creato. Dopo aver atteso il completamento dell'esecuzione del thread shellcode, il downloader dello shellcode rimuove tutti i file presenti nella directory %WINDIR%ServiceProfilesLocalServiceAppDataLocalTempTfsStoreTfs_DAV.

Infine, tenta di cancellarsi dopo un intervallo di 20 secondi, utilizzando il comando successivo, prima di concludere la sua operazione ed uscire:

scelta cmd.exe /CY /N /DY /T 20 & Del /f /q

Questa autocancellazione non ha senso in questa catena. Ciò è dovuto al fatto che il downloader dello shellcode viene eseguito all'interno di un browser o di un processo di sistema dopo essere stato iniettato, anziché funzionare come un eseguibile indipendente. Inoltre, il file iniziale era già stato cancellato nella seconda fase. Questa osservazione suggerisce che il downloader dello shellcode potrebbe non essere un carico utile esclusivo di questa catena e potrebbe anche essere utilizzato separatamente in altre operazioni.

Conclusione

Abbiamo scoperto e analizzato una sofisticata backdoor utilizzata dal gruppo Stealth Falcon che abbiamo chiamato Deadglyph. Ha un'architettura insolita e le sue funzionalità backdoor sono fornite dal suo C&C sotto forma di moduli aggiuntivi. Siamo riusciti a ottenere tre di questi moduli, scoprendo solo una frazione delle potenzialità complete di Deadglyph.

In particolare, Deadglyph vanta una serie di meccanismi di controrilevamento, incluso il monitoraggio continuo dei processi di sistema e l’implementazione di modelli di rete randomizzati. Inoltre, la backdoor è in grado di disinstallarsi da sola per ridurre al minimo la probabilità che venga rilevata in determinati casi.

Inoltre, la nostra indagine ci ha portato alla scoperta di un'avvincente catena di download di shellcode a più fasi su VirusTotal. Sospettiamo che questa catena di downloader venga probabilmente sfruttata nel processo di installazione di Deadglyph.

Per qualsiasi domanda sulla nostra ricerca pubblicata su WeLiveSecurity, contattaci all'indirizzo threatintel@eset.com.
ESET Research offre report di intelligence APT privati ​​e feed di dati. Per qualsiasi domanda su questo servizio, visitare il Intelligence sulle minacce ESET .

IOCS

File

SHA-1	Nome del file	rivelazione	Descrizione
C40F1F46D230A85F702DAA38CFA18D60481EA6C2	pbrtl.dll	Win64/Deadglyph.A	Caricatore di shellcode del registro.
740D308565E215EB9B235CC5B720142428F540DB	N/A	Win64/Deadglyph.A	Porta sul retro del glifo morto – Esecutore.
1805568D8362A379AF09FD70D3406C6B654F189F	N/A	MSIL/Deadglyph.A	Deadglyph Backdoor – Orchestratore.
9CB373B2643C2B7F93862D2682A0D2150C7AEC7E	N/A	MSIL/Deadglyph.A	Modulo Rete orchestratore.
F47CB40F6C2B303308D9D705F8CAD707B9C39FA5	N/A	MSIL/Deadglyph.A	Modulo timer dell'orchestratore.
3D4D9C9F2A5ACEFF9E45538F5EBE723ACAF83E32	N/A	Win64/Deadglyph.A.gen	Modulo creatore di processi.
3D2ACCEA98DBDF95F0543B7C1E8A055020E74960	N/A	Win64/Deadglyph.A	Modulo lettore di file.
4E3018E4FD27587BD1C566930AE24442769D16F0	N/A	Win64/Deadglyph.A	Modulo di raccolta informazioni.
7F728D490ED6EA64A7644049914A7F2A0E563969	N/A	Win64/Iniettore.MD	Prima fase della catena di download dello shellcode.

Certificati

Numero di serie	00F0FB1390F5340CD2572451D95DB1D92D
Identificazione personale	DB3614DAF58D041F96A5B916281EA0DC97AA0C29
Soggetto CN	RHM LIMITATA
Soggetto O	RHM LIMITATA
Soggetto l	St. Albans
Soggetti	Hertfordshire
Soggetto C	GB
E-mail	rhm@rhmlimited[.]co.uk
Valido dal	2021-03-16 00:00:00
Valido per	2022-03-16 23:59:59

Server C&C

IP	Dominio	Visto per la prima volta	Commento
185.25.50[.]60	chessandlinkss[.]com	2021-08-25	Server C&C Deadglyph.
135.125.78[.]187	easymathpath[.]com	2021-09-11	Server C&C Deadglyph.
45.14.227[.]55	unisciti a noisalute[.]com	2022-05-29	Server C&C per il download di Shellcode.

Tecniche MITRE ATT&CK

Questa tabella è stata creata utilizzando Versione 13 del framework MITRE ATT&CK.

tattica	ID	Nome	Descrizione
Sviluppo delle risorse	T1583.001	Acquisire l'infrastruttura: domini	Stealth Falcon ha registrato domini per i server C&C e per ottenere un certificato di firma del codice.
	T1583.003	Acquisire infrastruttura: server privato virtuale	Stealth Falcon ha utilizzato provider di hosting VPS per i server C&C.
	T1587.001	Capacità di sviluppo: malware	Stealth Falcon ha sviluppato malware personalizzato, inclusi caricatori personalizzati e la backdoor Deadglyph.
	T1588.003	Ottieni capacità: certificati di firma del codice	Stealth Falcon ha ottenuto un certificato di firma del codice.
	T1047	Windows Management Instrumentation	Deadglyph utilizza WMI per eseguire la catena di caricamento.
	T1059.003	Interprete di comandi e script: Shell dei comandi di Windows	Utilizza il downloader Shellcode cmd.exe per cancellare se stesso.
	T1106	API nativa	Utilizza un modulo Deadglyph CreateProcessW ed CreateProcessAsUserW Funzioni API per l'esecuzione.
	T1204.002	Esecuzione utente: file dannoso	La catena di download dello shellcode richiede all'utente di fare doppio clic ed eseguirla.
Persistenza	T1546.003	Esecuzione attivata da eventi: sottoscrizione di eventi di Strumentazione gestione Windows	Il caricatore Deadglyph iniziale viene mantenuto utilizzando la sottoscrizione dell'evento WMI.
Evasione della difesa	T1027	File o informazioni offuscati	I componenti Deadglyph sono crittografati. Deadglyph Orchestrator e i moduli incorporati vengono offuscati con .NET Reactor. Il downloader dello shellcode è offuscato da ConfuserEx.
	T1070.004	Rimozione dell'indicatore: eliminazione dei file	Deadglyph può disinstallarsi da solo. La catena di downloader dello shellcode si cancella ed elimina i file nella cache WebDAV.
	T1112	Modifica il registro	Deadglyph memorizza la sua configurazione e il payload crittografato nel registro.
	T1134	Accesso alla manipolazione dei token	Deadglyph può impersonare un altro utente.
	T1140	Deoffuscare/decodificare file o informazioni	Deadglyph decodifica le stringhe crittografate. La catena di download dello shellcode ne decrittografa i componenti e le configurazioni.
	T1218.011	Esecuzione proxy binario di sistema: Rundll32	Il caricatore Deadglyph iniziale viene eseguito utilizzando rundll32.exe.
	T1480.001	Guardrail di esecuzione: codifica ambientale	Deadglyph viene crittografato utilizzando una chiave specifica della macchina derivata dall'UUID del sistema.
	T1562.001	Impair difese: disabilita o modifica gli strumenti	Il downloader dello shellcode evita la scansione AMSI tramite patch clr.dll in memoria .
	T1620	Caricamento codice riflettente	Deadglyph carica in modo riflessivo i suoi moduli utilizzando un caricatore PE personalizzato.
Ricerca e Sviluppo	T1007	Individuazione dei servizi di sistema	A Il modulo Deadglyph rileva i servizi utilizzando la query WMI SELEZIONA * DA Win32_Service.
	T1012	Interrogare il Registro di sistema	La catena di downloader dello shellcode interroga il registro per il browser predefinito.
	T1016	Scoperta della configurazione di rete del sistema	Un modulo Deadglyph rileva gli adattatori di rete utilizzando query WMI SELEZIONA * DA Win32_NetworkAdapter ed SELEZIONA * FROM Win32_NetworkAdapterConfiguration dove InterfaceIndex=%d.
	T1033	Scoperta del proprietario/utente del sistema	Un modulo Deadglyph rileva gli utenti con la query WMI SELEZIONA * DA Win32_UserAccount.
	T1057	Scoperta dei processi	Un modulo Deadglyph rileva i processi utilizzando la query WMI SELEZIONA * DA Win32_Process.
	T1082	Scoperta delle informazioni di sistema	Un modulo Deadglyph rileva informazioni di sistema come versione del sistema operativo, unità, variabili di ambiente e driver utilizzando query WMI.
	T1518	Scoperta del software	Un modulo Deadglyph rileva il software installato utilizzando la query WMI SELEZIONA * DA Win32_Prodotto.
	T1518.001	Scoperta del software: Scoperta del software di sicurezza	Un modulo Deadglyph rileva il software di sicurezza utilizzando le query WMI SELEZIONA * DA Prodotto AntiVirus, SELEZIONA * DA Prodotto AntiSpyware ed SELEZIONA * DA Prodotto Firewall. La catena di downloader di shellcode controlla i processi in esecuzione per una soluzione di sicurezza.
Collezione	T1005	Dati dal sistema locale	Deadglyph ha un modulo per leggere i file.
Comando e controllo	T1071.001	Protocollo del livello di applicazione: protocolli Web	Deadglyph e il downloader dello shellcode comunicano con il server C&C tramite il protocollo HTTP.
	T1090	delega	Deadglyph e il downloader di shellcode possono utilizzare il proxy HTTP per la comunicazione C&C.
	T1573.001	Canale crittografato: crittografia simmetrica	Deadglyph utilizza AES per crittografare le comunicazioni C&C.
exfiltration	T1041	Esfiltrazione sul canale C2	Deadglyph utilizza il canale C&C per l'esfiltrazione.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://www.welivesecurity.com/en/eset-research/stealth-falcon-preying-middle-eastern-skies-deadglyph/