Ok, il titolo di questo post è complicato ed è per addetti ai lavori, ovviamente non scendo troppo in tecnicismi… magari anche l’utente comune capisce che cosa sto raccontando.
Durante l’analisi di malware giunto alla mia casella e-mail personale ho scoperto una nuova tecnica di comunicazione di malware con il proprio centro di controllo, nonostante l’indirizzo HTTP di questo centro di controllo ritorni un HTTP Status 404; vediamola nel dettaglio.
- STAGE 1
Lo stage 1 si presenta come mail innoqua che mi spinge a cliccare sul finto file excel allegato, facendomi credere si tratti di una fattura a me intestata.
Ovviamente non si tratta di un file excel ma di un file eseguibile:
dreams@ai:~/Desktop/Malware/malware$ file Fat._febbraio_2016\ xls_.XLS.exe
Fat._febbraio_2016 xls_.XLS.exe: PE32 executable (GUI) Intel 80386, for MS Windows
Per ora ignoriamo i dettagli di funzionamento di questo specifico malware sapendo che il suo obbiettivo è solo quello di scaricare lo stage 2 una volta avviato, download che avviene dall’indirizzo hxxp[:]//www.tajjquartet.com/ff/serif/payload.exe.
Difatto lo stage 1 si caratterizza per un attacco di phishing verso l’utente con l’incoulazione di un trojan-downloader.
- STAGE 2
A questo punto inizia la vera e propria infezione della macchina, payload.exe oltre ad effettuare alcune verifiche tecniche (ad es: se sta girando su un ambiente virtuale, se si tratta di una sandbox etc etc) si preoccupa di disattivare il firewall di windows e altre feature di sicurezza e successivamente rilascia (drop) un ulteriore eseguibile contenuto al suo interno, lo avvia e gli garantisce la persistenza al riavvio (crea la chiave di registro per l’autostart), il file droppato si chiama winhelp.exe posizionato nella home directory dell’utente.
Lo stage 2 si caratterizza per l’esecuzione di un trojan-dropper e la modifica della politica di sicurezza della macchina (all’insaputa dell’utente).
- STAGE 3
A questo punto la macchina risulta compromessa, ad ogni avvio viene avviato winhelp.exe ipotizzo che il suo compitoa principale sia quello di mantenere attiva la comunicazione con il C&C, ok in che modo??
Dall’analisi delle stringhe in memoria non si trova nessun riferimento a URL in particolare, però mi ha colpito immediatamente la presenza di header HTTP e di un base64
dreams@ai:~/Desktop/Malware/malware$ strings winhelp.exe.txt | grep “=”
=uhj
=hH8A
hh=A
exec=1&task_id=%S
cmd=1&uid=%s&os=%s&av=%s&version=%s&quality=%i
fail=1&task_id=%S
OPEN=%s
action=Run
aHR0cDovL2NvbnNpbGRlcnR1ZnVuLnh5ei9jc3MvYWpheC5waHA= <—- BASE64
auth=1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 <—- header
Accept-Language: en-us,en;q=0.5
[…]
A questo punto passo la stringa base64 al motore di decodifica e vediamo che accade:
dreams@ai:~/Desktop/Malware/malware$ decode aHR0cDovL2NvbnNpbGRlcnR1ZnVuLnh5ei9jc3MvYWpheC5waHA=
Decoding base64
hxxp[:]//consildertufun.xyz/css/ajax.php
“bingo!” mi viene da affermare anche perchè dal resto dell’analisi non emerge alcun altro URL ne, tanto meno, altri metodi di comunicazione verso l’esterno, quindi non può essere che questo il mio c&c.
Purtroppo qualcosa non torna, difatto facendo una prova per vedere se effettivamente il C&C fosse ancora attivo ottengo come risultato un bel 404 file not found.
A questo punto un analista normalmente penserebbe che il C&C non è più attivo e quindi l’analisi finisce qui… eppure il giorno successivo accade un altro fatto, ricevo una nuova mail contenente un nuovo stage 1, nome diverso, mittente diverso allegato diverso ma l’analisi di questo emerge che punta al medesimo stage 2, ovvero payload.exe.
Perchè continua la distrubuzione di un malware verso un C&C che non funziona?
Probabilmente sono stato troppo frettoloso nel classificare il centro di controllo come morto.. inizio a vagliare le possibilità, magari il C&C viene attivato solo in determinati orari o in determinati giorni… o forse… forse c’è dell’altro.. così ricontrollo meglio le stringhe di winhelp.exe e noto una caratterista che pensavo fosse semplicemente un camuffamento per far sembrare la sessione http in uscita più uamana.
dreams@ai:~/Desktop/Malware/malware$ strings winhelp.exe.txt | grep cooki -i
document.cookie=
Cookie: %s
Cookie: authkeys=21232f297a57a5a743894a0e4a801fc3
Cookie: authkeys=21232f297a57a5a743894a0e4a801fc3
Cookie: authkeys=21232f297a57a5a743894a0e4a801fc3
Cookie: authkeys=21232f297a57a5a743894a0e4a801fc3
Perchè utilizzare veramente un cookie?
Incuriosito da questo dettaglio passo a fare una analisi del malware in contesto reale, con una reale connessione ad internet. Dopo qualche tempo recupero il file pcap generato con tutte le connessioni di rete e noto che effettivamente i post avvengono verso il sito, ed il sito risponde 404, ma qualcosa cambiava:
La dimensione (Length) della sessione variava, e anche di tanto… come era possibile? cosa stava facendo realmente questo malware?
Approfondisco l’analisi di una specifica sessione HTTP (la prima, tanto per iniziare), ed ecco l’estratto:
Per chi è abituato a vedere codice HTML noterà subito il commento appeso a fine pagina tra le righe chiamate DEBUG, anche in questo caso abbiamo un bel base64 che passato subito al motore di decodifica ci mostra quanto segue:
dreams@ai:~/Desktop/Malware/malware$ decode cG9uZw==
Decoding base64
pong
PONG? ebbene si… il c&c è vivo e risponde correttamente…
Ovviamente l’analisi poi è continuata, il malware ha scaricato ulteriori stage per effettuare altre attività che ora ometto.
Nella mia piccola carriera di analisi malware e di attacchi informatici non ero mai capitato in una casisitica come questa.
Mi ha colpito la semplice genialità dell’utilizzare una stato HTTP permesso e “valido” ma per abitudine considerato “non valido” per ingannare tutte le potenziali analisi.
Ne vedremo delle belle…
/*
* 