Proteggi ciò che crei

Le altre nostre risorse

Chiudi

La mia libreria
La mia libreria

+ Aggiungi alla libreria

Supporto
Supporto 24/7 | Regole per contattare

Richieste

Profile

Back to news

Indagine su attacchi mirati a istituti di ricerca russi

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.

#drweb

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:

#drweb

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

#drweb

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
#drweb #drweb
Funzione di ottenimento delle informazioni sui dischi
#drweb #drweb
Funzione di enumerazione dei file in una cartella
#drweb #drweb
Funzione di raccolta delle informazioni sui file in una cartella
#drweb #drweb

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.

#drweb

Ricerca del proxy nel proprio file di log:

#drweb

Ricerca nelle connessioni attive:

#drweb

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.

#drweb

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.

#drweb

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.

#drweb

Identificatori

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

BackDoor.Mikroceen.11 BackDoor.Logtu.1
SHA1 Id SHA1 id
ce21f798119dbcb7a63f8cdf070545abb09f25ba intl0113 029735cb604ddcb9ce85de92a6096d366bd38a24 intpz0220
0eb2136c5ff7a92706bc9207da32dd85691eeed5 hisa5.si4 7b652e352a6d2a511f226e4d0cc22f093e052ad8 retail2007
2f80f51188dc9aea697868864d88925d64c26abc josa5w5n 1c5e5fd53fc2ee778342a5cae3ac2eb0ac345ed7 retail
2e50c075343ab20228a8c0c094722bbff71c4a2a enc0225 00ddcc200d1031b8639026532c0087bfcc4520c9 716demo
3bd16f11b5b3965a124a6fc3286297e5cfe77715 520299 b599797746ae8ccf7907cf88de232faa30ec95e6 gas-zhi
5eecdf63e85833e712a1ff88df1341bbf32f4ab8 Strive 2d672d7818a56029b337e8792935195d53576a9d jjlk
bd308f4d1a32096a3b90cfdae45bbc5c13e5e801 R0916
b1be4b2f874c8309f553acce90287c8c6bb2b6b1 frsl.1ply
21ffd24b8074d7cffdf4cc339d1fa8fe892eba27 Wdv
8fbec09e646311a285aee06b3dd45ccf58928703 intz726
19921cc47b3de003186e65fd12b82235030f060d 122764
0f70251abc8c64cbc7b24995c3d32927514d0a4b V20180224
149947544ca4f7baa5bc3d00b080d0e943d8036b SOE
e7f5a33b33e023a82ac9eee6ed40e4a38ce95277 int815
b4790eec7daa9f931bed43a53f66168b477599a7 UOE
ab660a3ac46d563c756463bd1b64cc45f347a1f7 B.Z11NOV20D
d0181759a175fbcc60975983b351f88970f484f9 299520
7a63fc9db2bc1e9b1ef793723d5877e6b4c566b8 WinVideo
13779006d0dafbe4b27bd282230df299eef2b8dc SSLSSL
f53c77695a162c78c68f693f57f65752d17f6030 int007server
924341cab6106ef993b506193e6786e459936069 intl1211
8ebf78c84cd7f66ca8708467a28d83658bcf6710 intl821
f2856d7d138430e164f83662e251ee311950d83c intl821

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

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

#drweb

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

#drweb

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

La tua opinione conta per noi

Per fare una domanda relativa alla notizia all'amministrazione del sito, inserire @admin all'inizio del commento. Se una domanda si fa all'autore di uno dei commenti — inserire @ prima del suo nome.


Altri commenti

Sviluppatore russo degli antivirus Dr.Web
Esperienza di sviluppo dal 1992
Dr.Web viene utilizzato in 200+ paesi del mondo
L'antivirus viene fornito come un servizio dal 2007
Supporto ventiquattro ore su ventiquattro

Dr.Web © Doctor Web
2003 — 2021

Doctor Web — sviluppatore russo dei software di protezione antivirus delle informazioni Dr.Web. I prodotti Dr.Web vengono sviluppati fin dal 1992.

125124, Russia, Mosca, la 3° via Yamskogo polya, 2, 12A