ABBATTIMENTO DI BLACKENERGY, PARTE 2 – “IL SEGNO”

Non farò un discorso su cosa sia un framework BlackEnergy, poiché se ne è già scritto molto, anche senza di me, tuttavia voglio fare riferimento alle informazioni di questa particolare recensione:

Tutti, incontrate il Flashplayer!

Durante l’indagine sull’attacco alla nostra infrastruttura, abbiamo rilevato vari campioni di malware e tra questi Flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/)In breve, flashplayerapp estrae main_light.dll nel proprio spazio di memoria e trasferisce il controllo ad esso. Questa libreria è una versione leggera di BlackEnergy ed è utilizzata per la comunicazione C&C per scaricare il carico utile principale con funzionalità a seconda degli obiettivi perseguiti dall’attaccante. Crea un file: C:UsersuserAppdataAdobecache.datSebbene criptato, questo file contiene varie informazioni, tra cui la versione build (come 2015lstb), l’indirizzo del centro di comando e controllo da cui può recuperare vari carichi (come hxxps://188.40.8.72/l7vogLG/BVZ99/rt170v/solocVI/eegL7p.php), ecc. Mentre esaminavo questo campione, ho spostato l’attenzione dal C&C in quanto una particolare parte del codice ha catturato la mia attenzione, poiché era un evidente segno dell’utilizzo di una tecnica chiamata permutazione del codice. Lasciami tradurre una citazione da questa fonte http://hacks.clan.su/publ/11-1-0-481:

Quindi ecco come si presentava il frammento di codice (le istruzioni aggiunte dal motore di permutazione sono evidenziate in rosso e non influiscono assolutamente sulla funzionalità, rendono solo il codice più difficile da comprendere):Rimuovendo le stringhe non necessarie, otteniamo un meccanismo che elabora tutti i nomi delle funzioni in kernel32.dlltrasformandoli (i nomi) in una forma di hash che poi confronta con un certo valore:Ricreiamo questo meccanismo usando C come esempio. Di conseguenza, otteniamo un’utilità che può produrre per noi un “dizionario” che contiene i nomi di tutte le funzioni nella libreria kernel32.dll e i valori hash di questi nomi. Proviamo a cercare i valori hash che abbiamo ottenuto durante l’analisi inversa del codice nel nostro nuovo “dizionario”. Per prima cosa cerchiamo il valore dal registro EAX (0x5147F60F), e lo confrontiamo con il valore di riferimento:La nostra teoria sta funzionando: il nostro campione ha elaborato il nome della prima funzione, creato l’hash e ora lo sta confrontando con il valore di riferimento contenuto nel buffer (0xC8AC8026). Cerchiamo questo valore e… ecco che otteniamo la funzione LoadLibraryA!Per saltare un altro muro di testo come esempio, menzionerò solo che il nostro “campione” utilizza lo stesso approccio per cercare un’altra funzione chiamata GetProcAdress.Utilizzando queste due funzioni, il nostro “campione” può caricare altre librerie ed estrarre gli indirizzi per le funzioni di cui ha bisogno.

Le tracce lasciate dall’Engine

La tecnica di rendere l’analisi del codice statico difficile tramite chiamata di funzione basata su un valore hash piuttosto che sul suo nome non è nuova. Tuttavia, mi ha portato al seguente pensiero: nonostante come il codice dannoso venga elaborato, conosciamo l’algoritmo di hashing dei nomi delle funzioni e quindi possiamo cercare con fiducia queste due funzioni (LoadLibraryA e GetProcAdress) nel codice. Così, ho iniziato a cercarle nei motori di ricerca per i riferimenti a questo hash (0xC8AC8026) per vedere se qualcuno ha utilizzato lo stesso motore del nostro esempio prima e, con mia sorpresa, ho trovato qualcosa:Questo hash è menzionato per la prima volta nel 2006 (l’articolo si trova solo su archive.org): https://web.archive.org/web/20060614030412/http://osix.net/modules/article/?id=789

Più tardi, nel 2008, un potenziale autore dell’algoritmo appare sul forum:https://exelab.ru/f/index.php?action=vthread&forum=6&topic=11845

Successivamente, nel 2009, un articolo di analisi sul shellcode MS08-067 viene pubblicato sui blog.technet.com:http://blogs.technet.com/b/srd/archive/2009/06/05/shellcode-analysis-via-msec-debugger-extensions.aspx

Poi, nel 2013, la rivista “XAKEP” (una delle più grandi stampe russe su IT e Sicurezza Informatica) pubblica un articolo https://xakep.ru/2011/06/23/55780/ dove menzionano lo stesso identico algoritmo che crea lo stesso hash (!):Aspetta un attimo, la situazione che abbiamo qui è che lo stesso algoritmo che genera gli stessi valori hash è in uso da oltre 10 anni e nessuno se n’è accorto? Se fosse altrimenti, allora affinché il flashplayerapp.exe (https://www.virustotal.com/ru/file/c787166ad731131c811d1a63080ac871ec11f10bcd77b9a1e665f1c9bbaa9a54/analysis/) fosse lo stesso come appare ora, sarebbe impossibile che passasse inosservato dalle soluzioni antivirus mentre viviamo già nell’anno 2016:C’è un chiaro “segno” lasciato da questo motore di permutazione concreto che è stato utilizzato nel nostro campione analizzato e mi sembra una firma valida. Inoltre, è piuttosto facile da tracciare direttamente nel testo chiaro:Bene, abbiamo le nostre ipotesi e la teoria è chiarita, quindi procediamo alla pratica e proviamo a trasformare le nostre conclusioni in una firma/regola Yara:

rule API_Hash

{meta: description = “Hash of LoadLibrary that is {26 80 ac c8} e GetProcAddres {ee ea c0 1f}”26 80 ac c8

$a = {ee ea c0 1f

$b = {

condition: $a and $b

}