Scarica in PDF

2 aprile 2021

Introduzione

Alla fine di settembre 2020 al laboratorio di virus Doctor Web si è rivolto uno degli istituti di ricerca scientifici russi. I collaboratori dell'istituto avevano notato una serie di problemi tecnici che potevano indicare la presenza di software malevolo su uno dei server della rete locale. Durante l'indagine gli analisti di virus hanno stabilito che all'istituto di ricerca è stato condotto un attacco mirato con l'utilizzo di backdoor specializzati. Lo studio dei dettagli dell'incidente informatico ha mostrato che la rete dell'azienda era stata compromessa molto prima di quando si è rivolta a noi per assistenza e — a giudicare dai dati a nostra disposizione — da più di un gruppo APT.

I dati ottenuti durante l'indagine suggeriscono che un primo gruppo APT ha compromesso la rete interna dell'istituto di ricerca ad autunno 2017. L'infezione iniziale veniva effettuata tramite BackDoor.Farfli.130 — una variante di un backdoor anche conosciuto come Gh0st RAT. In seguito, a primavera 2019 nella rete è stato installato Trojan.Mirage.12, e a giugno 2020 BackDoor.Siggen2.3268.

Un secondo gruppo di hacker ha compromesso la rete dell'istituto non più tardi di aprile 2019, questa volta l'infezione è iniziata con l'installazione del backdoor BackDoor.Skeye.1. Nel processo di lavoro abbiano inoltre scoperto che approssimativamente nello stesso periodo — a maggio 2019 — Skeye è stato installato nella rete locale di un altro istituto di ricerca russo.

Nel frattempo, a giugno 2019, l'azienda FireEye ha pubblicato un report su un attacco mirato al settore statale di diversi paesi dell'Asia centrale, effettuato con l'utilizzo del medesimo backdoor. Successivamente, nel periodo da agosto a settembre 2020, gli analisti di virus Doctor Web hanno registrato l'installazione da parte di questo gruppo nella rete dell'azienda di vari trojan, incluso un backdoor DNS mai riscontrato prima BackDoor.DNSep.1, nonché uno ben noto BackDoor.PlugX.

Notiamo inoltre che a dicembre 2017 sui server dell'istituto di ricerca che ci ha contattato era stato installato BackDoor.RemShell.24. Campioni di questa famiglia erano in precedenza descritti dagli specialisti di Positive Technologies nell'indagine Operation Taskmasters. Per quanto riguarda questo backdoor, non abbiamo dati tali che ci permettano di determinare inequivocabilmente quale dei due gruppi APT lo utilizzava.

Chi c'è dietro gli attacchi?

L'attività del primo gruppo APT non ci permette di identificare inequivocabilmente gli aggressori come uno dei gruppi di hacker descritti in precedenza. Allo stesso tempo, l'analisi dei programmi malevoli e dell'infrastruttura utilizzati ha mostrato che questo gruppo è attivo almeno dal 2015.

Il secondo gruppo APT che ha attaccato l'istituto di ricerca, a nostro avviso, è il TA428 precedentemente descritto dai ricercatori dell'azienda Proofpoint nel materiale Operation Lag Time IT. Questa conclusione è supportata dai seguenti fatti:

1. nel codice dei backdoor BackDoor.DNSep e BackDoor.Cotx ci sono evidenti intersezioni e prestiti;
2. BackDoor.Skeye.1 e Trojan.Loader.661 venivano utilizzati in uno stesso attacco, e il secondo dei due è un noto strumento del TA428;
3. i backdoor analizzati da noi in questi attacchi hanno intersezioni negli indirizzi dei server di controllo e nell'infrastruttura di rete con i backdoor utilizzati dal gruppo TA428.

Ora vediamo più nel dettaglio le relazioni identificate. Nel grafo è mostrata una parte dell'infrastruttura utilizzata nell'attacco con le intersezioni tra i backdoor Skeye e un altro backdoor APT conosciuto — PoisonIvy:

In questo grafo sono mostrate le intersezioni nell'infrastruttura dei backdoor Skeye e Cotx:

Un'analisi dettagliata del backdoor DNSep e il suo successivo confronto con il codice del backdoor Cotx hanno rilevato somiglianze sia nella logica generale dell'elaborazione di comandi provenienti dal server di controllo e sia nelle implementazioni specifiche dei singoli comandi.

Una scoperta interessante nell'ambito di questa indagine è stato il backdoor Logtu, di cui un campione abbiamo descritto in precedenza in una ricerca su un incidente informatico nel Kirghizistan. L'indirizzo del suo server di controllo corrisponde all'indirizzo del server del backdoor Skeye: atob[.]kommesantor[.]com. A tal proposito abbiamo condotto anche un'analisi comparativa di BackDoor.Skeye.1 con i campioni BackDoor.Logtu.1 e BackDoor.Mikroceen.11.

Descrizioni tecniche dettagliate dei malware rilevati sono disponibili nella versione PDF della ricerca e nella libreria di virus Dr.Web.

Analisi comparativa del codice di BackDoor.DNSep.1 e BackDoor.Cotx.1

Nonostante i canali di comunicazione con il server di controllo di Cotx e DNSep siano radicalmente diversi, siamo riusciti a trovare corrispondenze interessanti nel codice di entrambi i backdoor.

La funzione responsabile dell'elaborazione dei comandi dal server di controllo accetta come argomento la seguente struttura:

struct st_arg
{
  _BYTE cmd;
  st_string arg;
};

Inoltre, se la funzione richiesta accetta più argomenti, sono tutti scritti nel campo arg con il separatore |.

Il set di comandi di BackDoor.Cotx.1 è più ampio di quello di BackDoor.DNSep.1 e include tutti i comandi che quest'ultimo ha.

Nella tabella sotto è visibile una corrispondenza quasi completa del codice di alcune funzioni dei backdoor. E allo stesso tempo dobbiamo tenere presente che in Cotx è utilizzata la codifica Unicode, mentre in DNSep ANSI.

BackDoor.DNSep.1	BackDoor.Cotx.1
Gestione del comando di invio della lista della directory o delle informazioni sul disco
Funzione di ottenimento delle informazioni sui dischi
Funzione di enumerazione dei file in una cartella
Funzione di raccolta delle informazioni sui file in una cartella

I dati ottenuti come risultato dell'analisi suggeriscono che durante la creazione del backdoor DNSep il suo autore aveva accesso ai codici sorgente di Cotx. In quanto queste risorse non sono di pubblico dominio, presumiamo che l'autore o il gruppo di autori di DNSep sia legato al gruppo TA428. Questa supposizione è supportata anche dal fatto che il campione di DNSep è stato trovato nella rete compromessa dell'istituzione colpita insieme agli altri backdoor conosciuti del TA428.

Analisi comparativa del codice dei backdoor Skeye, Mikroceen, Logtu

Nel processo di studio del backdoor Skeye abbiamo scoperto che l'indirizzo del suo server di controllo viene utilizzato anche dal backdoor della famiglia Logtu. Per l'analisi comparativa abbiamo utilizzato i campioni da noi precedentemente descritti BackDoor.Logtu.1 e BackDoor.Mikroceen.11.

Funzioni di logging

Il logging in tutti i casi è offuscato in un modo o nell'altro.

• BackDoor.Mikroceen.11 — messaggi in formato %d-%d-%d %d:%d:%d <msg>\r\n vengono scritti nel file %TEMP%\WZ9Jan10.TMP, dove <msg> — stringa di testo casuale. Nel campione 2f80f51188dc9aea697868864d88925d64c26abc i messaggi vengono scritti nel file 7B296FB0.CAB;
• BackDoor.Logtu.1 — messaggi in formato [%d-%02d-%02d %02d:%02d:%02d] <rec_id> <error_code>\n<opt_message>\n\n prima della scrittura nel file %TEMP%\rar<rnd>.tmp vengono criptati tramite l'operazione XOR con la chiave 0x31;
• BackDoor.Skeye.1 — messaggi in formato %4d/%02d/%02d %02d:%02d:%02d\t<rec_id>\t<error_code>\n vengono scritti nel file %TEMP%\wcrypt32.dll.

Anche la logica generale della sequenza di scrittura dei messaggi nel log è simile in tutti e tre i campioni:

• l'inizio dell'esecuzione viene registrato;
• in Logtu e Mikroceen viene scritta nel log la connessione diretta al server di controllo;
• in ogni caso viene indicato tramite quale proxy è stata effettuata la connessione al server;
• in caso di errore in fase di ricezione del proxy da una qualche fonte, nel log viene registrato un record separato.

Dobbiamo notare che un logging così dettagliato e allo stesso tempo offuscato è estremamente raro. L'offuscamento consiste in quello che nel log vengono scritti alcuni codici di messaggi e, in una serie di casi, dati aggiuntivi. Oltre a ciò, in questo caso può essere individuato uno schema generale della sequenza di registrazione degli eventi:

• inizio dell'esecuzione;
• tentativo di connessione diretta;
• ottenimento degli indirizzi proxy;
• record sulla connessione tramite un server specifico.

Ricerca del server proxy

La sequenza di connessione al server di controllo anche è simile in tutti e tre campioni. Inizialmente ciascun backdoor cerca di connettersi al server direttamente, e se la connessione non è riuscita, può utilizzare server proxy di cui gli indirizzi possono essere ricevuti da tre fonti, oltre a quella incorporata.

BackDoor.Mikroceen.11 può ottenere indirizzi di server proxy:

• dal file %WINDIR%\debug\netlogon.cfg;
• dal proprio file di log;
• cercando le connessioni a host remoti attraverso le porte 80, 8080, 3128, 9080 nella tabella TCP.

Ricerca del proxy nel proprio file di log:

Ricerca nelle connessioni attive:

BackDoor.Logtu.1 può ottenere indirizzi di server proxy:

• dal registro HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• dalla sezione HKU del registro in base al SID dell'utente attivo;
• tramite WinHTTP API WinHttpGetProxyForUrl inviando richiesta a google.com.

BackDoor.Skeye.1 può ottenere indirizzi di server proxy:

• dalla sezione HKCU Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer;
• dalla sezione HKU in base al SID dell'utente attivo;
• cercando le connessioni a host remoti attraverso le porte 80, 8080, 3128, 9080 nella tabella TCP.

Intersezioni nell'infrastruttura di rete

Alcuni campioni utilizzavano in comune la stessa infrastruttura di rete. Un frammento del grafo mostra in modo visivo la correlazione tra le famiglie.

Identificatori

Nei campioni di Logtu e Mikroceen sono presenti stringhe utilizzate come identificatori delle build o versioni. Alcuni di esse hanno lo stesso formato.

Inoltre, in un numero significativo di campioni questo identificatore è pari al valore TEST o test.

Esempio in BackDoor.Logtu.1 (9ea2488f07bf3edda23d9b7759c2d0c3c8501f92):

Esempio in BackDoor.Mirkoceen.11 (81bb895a833594013bc74b429fb1f24f9ec9df26):

Così, l'analisi comparativa ha identificato nelle famiglie esaminate somiglianze:

• nella logica della registrazione del log degli eventi e nel suo offuscamento;
• nella logica della connessione al server di controllo e negli algoritmi di ricerca degli indirizzi proxy;
• nell'infrastruttura di rete utilizzata.

Conclusione

Nel corso dell'indagine sugli attacchi a istituti di ricerca russi i nostri analisti di virus hanno trovato e descritto più famiglie di backdoor mirati, tra cui campioni precedentemente sconosciuti. Va sottolineato separatamente il lungo funzionamento nascosto dei programmi malevoli nella rete compromessa dell'istituzione colpita — la presenza non autorizzata del primo gruppo APT rimaneva inosservata dal 2017.

Una caratteristica particolare è la presenza di intersezioni nel codice e nell'infrastruttura di rete dei campioni analizzati. Presumiamo che le relazioni identificate indichino l'appartenenza dei backdoor esaminati agli stessi gruppi di hacker.

Gli specialisti Doctor Web consigliano di monitorare regolarmente lo stato di operatività di importanti risorse di rete e prestare tempestivamente attenzione a errori di funzionamento che possono indicare la presenza di software malevolo nella rete. Il principale pericolo degli attacchi mirati consiste non solo nella compromissione dei dati, ma anche in una lunga presenza dei malintenzionati nella rete aziendale. Tale scenario permette loro di monitorare il lavoro dell'istituzione per anni e al momento giusto ottenere l'accesso alle informazioni sensibili. Nel caso di sospetto dell'attività malevola nella rete, consigliamo di contattare il laboratorio di virus Doctor Web che fornisce servizi di investigazione su incidenti informatici legati a virus. La tempestiva adozione di misure adeguate permette di ridurre i danni e prevenire le gravi conseguenze di attacchi mirati.

Indicatori di compromissione