Se l’estate è generalmente sinonimo di vacanze e relax, sembra che il gruppo Sednit non si sia riposato ma che stia sviluppando nuovi componenti da aggiungere alla famiglia di malware Zebrocy.
Il gruppo Sednit – noto anche come APT28, Fancy Bear, Sofacy o STRONTIUM – è attivo almeno dal 2004 e negli ultimi anni è stato spesso al centro dell’attenzione.
Il 20 agosto 2019, il gruppo ha lanciato una nuova campagna destinata ai loro classici obiettivi: ambasciate e ministeri degli affari esteri nei paesi dell’Europa orientale e dell’Asia centrale.
Quest’ultima campagna è iniziata con un’email di phishing contenente un allegato dannoso che avvia una lunga catena di downloader e termina con una backdoor. Un esempio di tale e-mail è stato caricato su VirusTotal il 22 agosto, due giorni dopo la sua ricezione. Una panoramica del vettore di attacco è stata recentemente pubblicata da Telsy TRT.
Tuttavia, abbiamo identificato altri indizi che potrebbero aiutare a delineare un quadro più completo della campagna.
Come previsto da altri ricercatori, il gruppo Sednit ha aggiunto un nuovo linguaggio di sviluppo nel proprio set di strumenti, più precisamente per il loro downloader: il linguaggio Nim. Comunque i loro sviluppatori non hanno smesso di migliorare anche il downloader di Golang, oltre a riscrivere la backdoor da Delphi a Golang.
Un complicato Sistema di infezione
La Figura 1 illustra i diversi passaggi di compromissione di una vittima, dall’email malevola inizialmente ricevuta nella posta in arrivo, alla backdoor distribuita su obiettivi ritenuti “abbastanza interessanti” dagli operatori.
Figura 1. Panoramica del processo di infezione
Quando una vittima viene presa di mira dai componenti di Zebrocy, il processo è di solito piuttosto evidente. Forse perché, in questo caso, la vittima ha almeno sei componenti dannosi rilasciati sul computer prima dell’esecuzione del payload finale. Tali attività possono facilmente innescare diversi campanelli di allarme per un prodotto di sicurezza.
Il documento allegato all’email di phishing è vuoto ma fa riferimento a un modello remoto, wordData.dotm, ospitato su Dropbox. L’apertura di questo documento in Word comporta il download di wordData.dotm, come mostrato nella Figura 2, e la sua integrazione nell’ambiente di lavoro del documento associato, incluso qualsiasi contenuto attivo presente nel modello.
Figura 2. Documento Word vuoto che scarica un template remoto
Il file wordData.dotm contiene macro pericolose che verranno successivamente eseguite[1]. Include anche un archivio ZIP rilasciato ed estratto dalle stesse macro.
Come mostrato nella Figura 1, le macro in wordData.dotm aprono un altro documento (lmss.doc che è stato decompresso dall’archivio estratto da wordData.dotm). Le macro in lmss.doc eseguono lmss.exe (il nuovo downloader Nim di Zebrocy, anch’esso estratto dall’archivio incorporato in wordData.dotm) anziché wordData.dotm che avvierebbe direttamente il downloader.
Tuttavia è importante notare che lmss.doc, contenente il codice VBA che esegue il nuovo downloader Nim, incorpora anche un eseguibile con codifica base64. Secondo le proprietà del documento, lmss.doc è stato creato nel gennaio 2019 e modificato il 20 agosto, quindi poche ore prima dell’inizio della campagna.
Figura 3. Date di creazione e ultima modifica di lmss.doc
L’eseguibile incorporato in lmss.doc è un downloader di AutoIt (SHA-1: 6b300486d17d07a02365d32b673cd6638bd384f3) utilizzato in passato per una campagna lanciata proprio nel periodo in cui fu creato lmss.doc. Qui, il downloader di AutoIt viene ignorato e non ha altro scopo se non quello di aumentare le dimensioni del documento stesso. L’operatore probabilmente ha dimenticato di rimuovere il precedente downloader incorporato: non sarebbe la prima volta che gli operatori Sednit commettono errori di questo tipo.
I downloader
Gli operatori di Sednit hanno utilizzato numerosi downloader scritti in diverse linguaggi. Questa campagna ne impiega la versione più recente: il Nim. È un semplice binario predisposto per scaricare ed eseguire altri componenti, a cui però sono stati aggiunti due piccoli dettagli. Il primo è probabilmente usato come trucco anti-sandbox e verifica che la prima lettera del file eseguito (lettera l qui o 0x6C in esadecimale) non sia stata cambiata.
Figura 4. Controllo nome file
Il secondo è un tipo di offuscamento in cui l’operatore sostituisce le lettere “placeholder” in una stringa con quelle corrette, a offset definiti. Come mostrato nella Figura 5, in questo modo il downloader ricostruisce la stringa URL di download corretta per evitare strumenti di analisi che potrebbero altrimenti individuarla e segnalarla come pericolosa.
Figura 5. Output Hex-Rays della deoffuscazione delle stringhe
Ad esempio, la stringa o-ps-c..ll è “patchata” a tre offset rispettivamente da s, v e d, in modo da restituire come valore ospsvc.dll. Nel caso dell’URL, poiché l’inizio della stringa nel downloader è h @@ p: //, gli strumenti che cercano http: // non la cattureranno.
Il downloader di Nim recupera la sua payload della libreria a collegamento dinamico (DLL), chiamato ospsvc.dll, in C: \ ProgramData \ Java \ Oracle \ e la esegue come servizio tramite regsvr32 / s.
ospsvc.dll è un downloader scritto in Golang e diverso dagli altri downloader Sednit visti in passato.
I precedenti downloader Golang di Sednit sono stati descritti dettagliatamente da altri ricercatori [1] [2] [3] e sembra che gli sviluppatori di Sednit abbiano riscritto il loro precedente downloader Delphi in Golang. Quei precedenti downloader raccolgono molte informazioni sul computer della vittima e le inviano al loro server C&C. Tuttavia, questo nuovo è abbastanza limitato nelle capacità di raccolta dei dati, come descritto di seguito.
La sua funzione main_init () contiene librerie che sono inizializzate e non necessitano di ulteriori spiegazioni a causa dei loro nomi.
Figure 6. output Hex-Rays dell’inizializzazione delle funzioni in main_init(), usando il plugin IDAGolangHelper
Poiché la DLL viene eseguita come servizio, tramite il downloader Nim, è necessario esaminare main_DllRegisterServer () anziché main_main (). Le stringhe e la chiave possono essere decodificate usando un semplice ciclo XOR. Questa semplice crittografia è abbastanza efficace contro gli strumenti che estraggono staticamente stringhe sovrapposte dai binari.
Figura 7. Output IDA Pro di stringhe crittografate sovrapposte
Oltre a scaricare la fase successiva del malware, altre funzione importanti sono l’acquisire le schermate del desktop della vittima ed eseguire i comandi ricevuti dal server C&C.
Gli screenshot vengono acquisiti ogni 35 secondi durante i primi minuti dell’esecuzione di questo downloader, quindi vengono inviati al server C&C in forma codificata in base64. Il nome host e i valori % USERPROFILE% vengono inviati anche al server C&C codificato in base64. Anche la risposta del server C&C è semplice: è una concatenazione di stringhe con codifica base64, separate da “|”.
<spazi>|<cmd da eseguire>|<nome del file binario da rilasciare>|<binario da rilasciare>
Secondo i dati della nostra telemetria, questo downloader è stato utilizzato per eseguire tre diversi malware. Il primo è il dumper che abbiamo descritto nel nostro precedente articolo su Zebrocy. Il secondo è la solita backdoor Delphi, anch’essa eseguita come servizio tramite lo stesso comando utilizzato dal downloader Nim. La terza che abbiamo visto è una nuova backdoor scaricata ed eseguita sul computer della vittima, come viene descritto nella sezione successiva.
La nuova backdoor
Analisi
La nuova backdoor di Zebrocy non è scritta come al solito in Delphi, ma in Golang. Per quanto ne sappiamo, questa è la prima volta che viene rilevata questa backdoor, ma risulta molto simile a quella di Delphi.
Guardando di nuovo il codice di inizializzazione della libreria della funzione main_init () (Figura 8) possiamo notare delle nuove voci. Tra le principali funzionalità aggiunte troviamo un algoritmo AES, codifica esadecimale e capacità di catturare screenshot.
Figura 8. Differenze tra le funzioni backdoor e downloader inizializzate in main_init ()
Si noti che image_png_init sostituisce image_jpeg_init per l’acquisizione di schermate. Le immagini in formato JPG sono generalmente di dimensioni inferiori rispetto a quelle nel formato PNG.
La backdoor viene avviata con un argomento che è una stringa con codifica esadecimale. Tutti tranne l’ultimo blocco di sei byte di questa stringa sono crittografati con XOR con la chiave memorizzata negli ultimi sei byte della stringa stessa. Il seguente frammento di python descrive la logica di decodifica.
key = arg[-6:].decode(‘hex’)
enc = arg[:-6].decode(‘hex’)
”.join(chr(ord(i) ^ ord(j)) for i, j in zip(itertools.cycle(key), enc))
Successivamente l’indirizzo del server C&C viene crittografato e archiviato su disco. Tale crittografia viene eseguita utilizzando l’algoritmo AES-128 ECB con una chiave generata dal nome host. Quindi non c’è possibilità di ottenere questo server C&C solo analizzando il binario. Non esiste una persistenza definita dai downloader come abbiamo visto in passato, né la backdoor ha alcun meccanismo di persistenza.
Questa nuova backdoor ha varie funzionalità che erano già state notate in precedenza nella backdoor Delphi di Zebrocy:
- manipolazione dei file come creazione, modifica ed eliminazione
- funzionalità di cattura screenshot
- enumerazione delle unità
- esecuzione di comandi (tramite cmd.exe)
- pianificare un’attività con il seguente nome Windows \ Software \ OSDebug (che gli operatori potrebbero utilizzare per impostarne manualmente la persistenza)
Come nella backdoor di Delphi, esiste un set molto limitato di comandi, ma la possibilità di eseguire comandi arbitrari tramite cmd.exe estende possibilità come la persistenza o la raccolta di informazioni. Un’altra somiglianza rilevata è un numero di versione di tre cifre (nel formato x.y.z); l’attuale versione è 4.y.z.
Rete
Il protocollo di rete condivide alcune somiglianze con la versione Delphi della backdoor. La prima interazione con il server C&C recupera una chiave AES a 32 bit per crittografare le comunicazioni future. La richiesta per l’acquisizione di pacchetti è simile alla seguente:
POST [REDACTED URI] HTTP/1.1
Host: [REDACTED IP]
User-Agent: Go-http-client/1.1
Content-Length: 297
Content-Type:multipart/form-data; boundary=b116f1e0a94eff1bb406531e74bb0feba65687cf90ec8a64fc409f230fbd
Accept-Encoding: gzip
–b116f1e0a94eff1bb406531e74bb0feba65687cf90ec8a64fc409f230fbd
Content-Disposition: form-data; name=”filename”; filename=”[REDACTED]”
Content-Type: application/octet-stream
1
–b116f1e0a94eff1bb406531e74bb0feba65687cf90ec8a64fc409f230fbd–
Chi ha esperienza con Sednit potrebbe pensare che la Content-Disposition e le parole chiave impiegate siano familiari. In precedenza erano utilizzate dalla backdoor Delphi nel suo protocollo di rete; utilizza inoltre l’algoritmo AES per crittografare lo pseudo corpo (incluso dopo i dati di tipo contenuto). Si noti che anche se Content-Disposition e la seconda istanza di Content-Type sono intestazioni HTTP reali, qui vengono utilizzate all’interno del corpo del messaggio HTTP. Il campo perimetrale viene randomizzato per ogni scambio e il campo del nome file all’interno dell’intestazione pseudo Content-Disposition può essere decrittografato con il seguente frammento di Python:
len_filename = len(filename)
len_key = 14
xor_key = filename[-len_key:].decode(‘hex’)
filename = filename[:len_filename-len_key].decode(‘hex’)
val_filename = ”.join(chr(ord(i)^ord(j)) for i,j in zip(itertools.cycle(xor_key),filename))
random_int = val_filename[-4:]
rivelando la seguente stringa:
757365722D504318162020190821151055207C.inc
La stringa quindi può ultriormente essere decodificata producendo questi dati:
Username: 757365722D5043
SID*: 181620
Date: 20190821151055
Random: 207C.inc
* 6 byte derivano dai Security Identifiers dell’utente attuale (SID) S-1-5-21-xxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-1000
Lo stesso modello viene eseguito anche da altre interazioni con il server C&C, tranne per il fatto che lo pseudo corpo, rappresentato con il numero 1 nell’esempio sopra, è sostituito dall’output del comando richiesto dal server C&C. Anche il corpo completo del messaggio viene crittografato, utilizzando lo stesso algoritmo AES utilizzato in precedenza, con la chiave fornita nel primo scambio.
Conclusioni
Nuovi downloader, nuova backdoor: il gruppo Sednit è sempre attivo e continua a migliorare i suoi componenti. Nuovo? Non proprio. Osservandolo, sembra che il gruppo Sednit stia eseguendo il porting del codice originale o lo stia implementando in altri linguaggi nella speranza di eludere più efficacemente i sistemi di rilevamento. Il sistema di compromissione iniziale rimane invariato, ma l’utilizzo di un servizio come Dropbox per scaricare un modello remoto è insolito per il gruppo.
ESET consiglia a tutti gli utenti di prestare la massima attenzione prima di aprire gli allegati ad email sospette.
Continueremo a monitorare le nuove attività del gruppo Sednit e pubblicheremo i dettagli delle nostre analisi su questo blog. Per qualsiasi domanda, contattaci all’indirizzo assistenza@eset.it.
Indicatori di Compromissione (IoC)
[1] A seconda della versione di Microsoft Word, le macroVBA vengono disabilitato per default e viene richiesta l’interazione dell’utente per abilitarle.
Lascia un commento