Lavoro: il quadro generale

I ricercatori ESET hanno recentemente scoperto attacchi mirati che utilizzavano strumenti non documentati contro varie aziende di alto profilo e governi locali, soprattutto in Asia. Questi attacchi sono stati condotti da un gruppo di spionaggio precedentemente sconosciuto che abbiamo chiamato Worok e che è attivo almeno dal 2020. Il set di strumenti di Worok include un caricatore C++ CLRLoad, una backdoor PowerShell PowHeartBeat e un caricatore C# PNGLoad che utilizza la steganografia per estrarre malware nascosti payload da file PNG.

Chi è Workok?

Durante la ProxyShell (CVE-2021-34523) divulgazione delle vulnerabilità all'inizio del 2021, abbiamo osservato attività di vari gruppi APT. Uno mostrava caratteristiche comuni con TA428:

• Tempi di attività
• Verticali mirati
• Utilizzo di ShadowPad

Il resto del set di strumenti è molto diverso: ad esempio, TA428 ha preso parte al Compromissione desktop in grado nel 2020. Riteniamo che i collegamenti non siano abbastanza forti da considerare Worok come lo stesso gruppo di TA428, ma i due gruppi potrebbero condividere strumenti e avere interessi comuni. Abbiamo deciso di creare un cluster e di chiamarlo Workok. Il nome è stato scelto dopo un mutex in un caricatore utilizzato dal gruppo. A questo gruppo è stata poi collegata un'ulteriore attività con varianti degli stessi strumenti. Secondo la telemetria di ESET, Worok è attivo dalla fine del 2020 e continua ad essere attivo al momento della stesura di questo documento.

Alla fine del 2020, Worok prendeva di mira governi e aziende in più paesi, in particolare:

• Una società di telecomunicazioni nell'Asia orientale
• Una banca in Asia centrale
• Una società del settore marittimo nel sud-est asiatico
• Un ente governativo in Medio Oriente
• Una società privata nell'Africa meridionale

C'è stata un'interruzione significativa nelle operazioni osservate dal 2021-05 al 2022-01, ma l'attività di Workok è tornata nel 2022-02, mirando a:

• Una compagnia energetica in Asia centrale
• Un ente del settore pubblico nel sud-est asiatico

La Figura 1 presenta una mappa termica visiva delle regioni e dei verticali target.

Considerando i profili degli obiettivi e gli strumenti che abbiamo visto utilizzati contro queste vittime, riteniamo che l’obiettivo principale di Worok sia rubare informazioni.

Analisi tecnica

Sebbene la maggior parte degli accessi iniziali siano sconosciuti, in alcuni casi nel 2021 e nel 2022 abbiamo visto exploit utilizzati contro le vulnerabilità ProxyShell. In questi casi, in genere vengono caricate webshell dopo aver sfruttato queste vulnerabilità, al fine di garantire la persistenza nella rete della vittima. Successivamente gli operatori hanno utilizzato vari impianti per acquisire ulteriori capacità.

Una volta ottenuto l'accesso, gli operatori hanno implementato molteplici strumenti pubblicamente disponibili per la ricognizione, tra cui Mimikatz, Lombrico, ReGeorge Scansione NBT, quindi hanno distribuito i loro impianti personalizzati: un caricatore di primo stadio, seguito da un caricatore .NET di secondo stadio (PNGLoad). Sfortunatamente, non siamo riusciti a recuperare nessuno dei carichi utili finali. Nel 2021, il caricatore della prima fase era un assembly CLR (CLRLoad), mentre nel 2022 è stato sostituito, nella maggior parte dei casi, da una backdoor PowerShell completa (PowHeartBeat): entrambe le catene di esecuzione sono illustrate nella Figura 2. Queste tre gli strumenti sono descritti in dettaglio nelle sottosezioni seguenti.

Figura 2. Catene di compromesso del lavoro

CLRLoad: caricatore di assiemi CLR

CLRLoad è un Windows PE generico che abbiamo visto sia nella versione a 32 che a 64 bit. È un caricatore scritto in C++ che carica la fase successiva (PNGLoad), che deve essere a Assembly Common Language Runtime (CLR). DLL. Quel codice viene caricato da un file situato sul disco in una directory legittima, presumibilmente per indurre in errore le vittime o gli operatori che rispondono all'incidente a pensare che si tratti di software legittimo.

Alcuni esempi CLRLoad iniziano decodificando il percorso completo del file di cui caricheranno il contenuto nella fase successiva. Questi percorsi di file sono codificati con uno XOR a byte singolo, con una chiave diversa in ogni campione. Decodificati o testo in chiaro, questi percorsi di file sono assoluti, di seguito quelli che abbiamo riscontrato:

• C:ProgrammiVMwareVMware ToolsVMware VGAuthxsec_1_5.dll
• C:ProgrammiUltraViewermsvbvm80.dll
• C:ProgrammiInternet ExplorerJsprofile.dll
• C:ProgrammiWinRarRarExtMgt.dll
• C:Programmi (x86)Foxit SoftwareFoxit Readerlucenelib.dll

Successivamente, viene creato un mutex e abbiamo visto un nome diverso in ogni campione. Il caricatore controlla questo mutex; se trovato, esce, perché il caricatore è già in esecuzione. In uno dei campioni, il mutex Wo0r0KGWhYGO è stato incontrato, il che ha dato al gruppo il nome di Worok.

CLRLoad carica quindi un assembly CLR dal percorso del file eventualmente decodificato. Essendo codice non gestito, CLRLoad ottiene ciò tramite CorBindToRuntimeEx Chiamate API di Windows nelle varianti a 32 bit o CLRCreateInstance chiamate nelle varianti a 64 bit.

PowHeartBeat: backdoor di PowerShell

PowHeartBeat è una backdoor completa scritta in PowerShell, offuscata utilizzando varie tecniche come compressione, codifica e crittografia. Sulla base della telemetria ESET, riteniamo che PowHeartBeat abbia sostituito CLRLoad nelle campagne Worok più recenti come strumento utilizzato per lanciare PNGLoad.

Il primo livello del codice backdoor è costituito da più blocchi di codice PowerShell con codifica base64. Una volta ricostruito il payload, viene eseguito tramite IEX. Una volta decodificato, viene eseguito un altro livello di codice offuscato, che possiamo vedere nella Figura 3.

Figura 3. Estratto della funzione principale decodificata del secondo strato di PowHeartBeat

Il secondo strato della backdoor first base64 decodifica lo strato successivo del suo codice, con il quale viene poi decriptato Tripla DES (Modalità CBC). Dopo la decrittazione, questo codice viene decompresso utilizzando il file gzip algoritmo, fornendo così il terzo livello di codice PowerShell, che è la backdoor vera e propria. È diviso in due parti principali: configurazione e gestione dei comandi backdoor.

Anche il livello principale del codice backdoor è scritto in PowerShell e utilizza HTTP o ICMP per comunicare con il server C&C. Funziona come illustrato nella Figura 4.

Figura 4. Funzionamento di PowHeartBeat

Configurazione

La configurazione contiene più campi, tra cui il numero di versione, la configurazione proxy opzionale e l'indirizzo C&C. La tabella 1 descrive il significato dei campi di configurazione nelle diverse versioni che abbiamo osservato.

Tabella 1. Significati dei campi di configurazione

La Figura 5 mostra un esempio della configurazione estratta da un campione PowHeartBeat (SHA-1: 757ABA12D04FD1167528FDD107A441D11CD8C427).

Figura 5. Esempio di configurazione

Crittografia dei dati

PowHeartBeat crittografa i registri e il contenuto aggiuntivo dei file di configurazione.

Il contenuto del file di registro viene crittografato tramite XOR a più byte con una chiave specificata in testo non crittografato nell'esempio. È interessante notare che Identificativo cliente viene utilizzato come sale per l'indice nell'array di chiavi. La chiave è un array da 256 byte, identico in ogni campione riscontrato. Il contenuto aggiuntivo del file di configurazione viene crittografato tramite XOR a più byte con il valore da Chiave segreta come la sua chiave.

Comunicazioni C&C

PowHeartBeat ha utilizzato HTTP per le comunicazioni C&C fino alla versione 2.4, quindi è passato a ICMP. In entrambi i casi la comunicazione non è crittografata.

HTTP

In un ciclo infinito, la backdoor invia una richiesta GET al server C&C, chiedendo l'invio di un comando. La risposta crittografata viene decrittografata dalla backdoor, che elabora il comando e scrive l'output del comando in un file il cui contenuto viene quindi inviato al server C&C tramite una richiesta POST.

Il formato delle richieste GET è il seguente:

Tieni presente che la richiesta viene costruita utilizzando gli omonimi campi di configurazione.

Nella risposta del server C&C, il terzo byte del contenuto è l'identificatore del comando che indica il comando che deve essere elaborato dalla backdoor. Lo chiameremo id_comando. Il contenuto rimanente della risposta verrà passato come argomento al comando elaborato. Questo contenuto è crittografato con l'algoritmo mostrato nella Figura 6, IDattività essendo il valore del cookie da cui prende il nome CookieTaskIdil valore dalla configurazione.

Figura 6. Richiede l'algoritmo di crittografia dei dati del contenuto

La risposta del server C&C contiene anche un altro cookie, il cui nome è specificato dalla backdoor CookieTerminalId variabile di configurazione. Il valore di questo cookie viene ripetuto nella richiesta POST dalla backdoor e non deve essere vuoto. Dopo aver eseguito il comando backdoor, PowHeartBeat invia il risultato come richiesta POST al server C&C. Il risultato viene inviato come file il cui nome è .png.

ICMP

A partire dalla versione 2.4 di PowHeartBeat, HTTP è stato sostituito da ICMP, i pacchetti inviati avevano un timeout di sei secondi ed erano non frammentato. La comunicazione tramite ICMP è molto probabilmente un modo per eludere il rilevamento.

Non ci sono grandi cambiamenti nelle versioni 2.4 e successive, ma abbiamo notato alcune modifiche nel codice:

• PowHeartBeat invia un pacchetto heartbeat ad ogni loop che contiene la stringa abcdefghijklmnopqrstuvwxyz, prima di richiedere un comando. Ciò informa il server C&C che la backdoor è pronta a ricevere comandi.
• Le richieste per ottenere comandi eseguiti dalla backdoor contengono la stringa abcdefghijklmnop.

I pacchetti heartbeat hanno il formato descritto nella Figura 7.

Figura 7. Layout del pacchetto Heartbeat

La differenza tra Identificativo cliente ed bandiera del cliente è che Identificativo cliente differisce in ogni campione mentre bandiera del cliente è lo stesso in ogni campione che utilizza ICMP. bandiera del battito cardiaco indica che la backdoor sta inviando un heartbeat. La risposta dal server C&C ha il formato descritto nella Figura 8.

Figura 8. Layout della risposta del server C&C

bandiera qui indica se c'è un comando da inviare alla backdoor. Le richieste per ottenere comandi hanno il formato descritto nella Figura 9.

Figura 9. Layout per le richieste di acquisizione dei comandi

Tieni presente che la modalità ICMP della backdoor consente di ricevere una quantità illimitata di dati, suddivisi in blocchi, e di variabili lunghezza dei dati, posizione attuale ed lunghezza totale vengono utilizzati per tenere traccia dei dati trasmessi. Le risposte a queste richieste hanno il formato descritto nella Figura 10.

Figura 10. Layout delle risposte alle richieste di acquisizione dei comandi

Come nelle risposte HTTP, l'identificatore del comando è il terzo byte di dati.

Dopo sette risposte ICMP consecutive con contenuto vuoto o formattato in modo incoerente, i trasferimenti tra la backdoor e il server C&C vengono considerati terminati.

Per quanto riguarda le richieste di invio del risultato del comando immesso al server C&C, la modalità server viene modificata in modalità post e la stringa finale (abcdefghijklmnop) viene modificato per i dati dei risultati.

Comandi backdoor

PowHeartBeat ha varie funzionalità, tra cui l'esecuzione di comandi/processi e la manipolazione dei file. La tabella 2 elenca tutti i comandi supportati dai vari campioni analizzati.

Tabella 2. Descrizioni dei comandi PowHeartBeat

In caso di errori sul lato backdoor, la backdoor utilizza uno specifico identificatore di comando 0x00 nella richiesta POST al server C&C, indicando così che si è verificato un errore.

Tieni presente che prima di inviare le informazioni al server C&C, i dati vengono compressi con gzip.

PNGLoad: caricatore steganografico

PNGLoad è il payload di seconda fase distribuito da Worok su sistemi compromessi e, secondo la telemetria ESET, caricato da CLRLoad o PowHeartBeat. Sebbene non vediamo alcun codice in PowHeartBeat che carichi direttamente PNGLoad, la backdoor ha la capacità di scaricare ed eseguire payload aggiuntivi dal server C&C, che è probabilmente il modo in cui gli aggressori hanno distribuito PNGLoad su sistemi compromessi con PowHeartBeat. PNGLoad è un caricatore che utilizza byte di file PNG per creare un payload da eseguire. È un eseguibile .NET a 64 bit, offuscato con Reattore .NET – che si maschera da software legittimo. Ad esempio, la Figura 11 mostra le intestazioni CLR di un campione mascherato da DLL WinRAR.

Figura 11. Esempio di una falsa DLL WinRAR

Una volta deoffuscato, è presente solo una classe. In questa classe c'è a Percorso principale attributo contenente il percorso della directory che la backdoor cerca, comprese le sue sottodirectory, per i file con a .png estensione, come mostrato nella Figura 12.

Immagine 12. .png elenco dei file

Ogni .png file individuato da questa ricerca di Percorso principale viene quindi controllato il contenuto incorporato steganograficamente. Innanzitutto, il bit meno significativo dei valori R (rosso), G (verde), B (blu) e A (alfa) di ciascun pixel viene recuperato e assemblato in un buffer. Se i primi otto byte di quel buffer corrispondono al numero magico visto nella Figura 13 e il successivo valore di otto byte, control, è diverso da null, il file supera il controllo del contenuto steganografico di PNGLoad. Per tali file, l'elaborazione continua con il resto del buffer decrittografato con uno XOR a più byte, utilizzando la chiave memorizzata nel file PNGLoad. SecretKeyBytes attributo e quindi il buffer decrittografato viene decompresso con gzip. Si prevede che il risultato sia uno script di PowerShell, che viene eseguito immediatamente.

Figura 13. Formato del buffer che PNGLoad crea dall'elaborazione .png file

È interessante notare che le operazioni eseguite da PNGLoad vengono registrate in un file il cui percorso è memorizzato nella variabile Percorso file di registro. Le operazioni vengono registrate solo se è presente un file il cui percorso è specificato dalla variabile interna IfLogFilePath.

Non siamo riusciti a ottenere un campione .png utilizzato insieme a PNGLoad, ma il modo in cui funziona PNGLoad suggerisce che dovrebbe funzionare con file PNG validi. Per nascondere il payload dannoso, Worok utilizza oggetti Bitmap in C#, che prendono solo informazioni sui pixel dai file, non dai metadati dei file. Ciò significa che Worok può nascondere i suoi payload dannosi in immagini PNG valide e dall'aspetto innocuo e quindi nascondersi in bella vista.

Conclusione

Worok è un gruppo di spionaggio informatico che sviluppa i propri strumenti, oltre a sfruttare quelli esistenti, per compromettere i propri obiettivi. Rubare informazioni alle loro vittime è ciò che crediamo gli operatori cerchino perché si concentrano su entità di alto profilo in Asia e Africa, prendendo di mira vari settori, sia privati ​​che pubblici, ma con un'enfasi specifica sugli enti governativi. I tempi di attività e il set di strumenti indicano possibili legami con TA428, ma effettuiamo questa valutazione con scarsa certezza. Il loro set di strumenti personalizzato include due caricatori, uno in C++ e uno in C# .NET, e una backdoor PowerShell. Sebbene la nostra visibilità sia limitata, speriamo che far luce su questo gruppo incoraggi altri ricercatori a condividere informazioni su questo gruppo.

IOC

File

Percorsi di file

Alcuni dei Percorso principale, Percorso file di registro ed IfLogFilePath valori che abbiamo riscontrato negli esempi PNGLoad:

Network NetPoulSafe

Mutex

Negli esempi CLRLoad, i nomi mutex che abbiamo riscontrato sono:

aB82UduGX0EX
ad8TbUIZl5Ga
Mr2PJVxbIBD4
oERiQtKLgPgK
U37uxsCsA4Xm
Wo0r0KGWhYGO
xBUjQR2vxYTz
zYCLBWekRX3t
3c3401ad-e77d-4142-8db5-8eb5483d7e41
9xvzMsaWqxMy

Un elenco completo di Indicatori di Compromise (IoC) e campioni è disponibile in il nostro repository GitHub.

Tecniche MITRE ATT&CK

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