La prima parte è qui.

La quinta domanda chiedeva se era possibile estrarre qualche file dal processo inizialmente responsabile per l’attacco. Dato che il processo sospettato era Acrobat Reader, tramite Volatility ne ho estratto l’immagine in memoria del processo, dopodiché ho provato ad usare foremost su di essa. Il risultato è interessante, anche perché due file PDF estratti dall’impronta in memoria del processo non vengono estratti se invece si esegue foremost sull’intera immagine della memoria. I due file interessanti sono rispettivamente di 60kbyte e di 600kbyte, ed il primo è cifrato.

Usando i PDF-tools di Didier Stevens si riesce ad analizzare la struttura dei file PDF, anche se tutti risultano corrotti in vari modi.

Quello cifrato non riserva particolari sorprese, mentre quello da 600kbyte ha una “azione automatica” eseguita all’apertura del documento, ossia l’esecuzione di un codice Javascript. Il codice Javascript è nascosto in un blocco con il tag di identificazione del tipo offuscato: /F#6c#61#74e#44e#63#6fde e /#41#53#43II#38#35#44#65#63#6fd#65 che in realtà corrispondono a: /FlateDecode /ASCII85Decode. Usando l’utility pdf-parser.py, sempre nei PDF-tools, si riesce ad estrarre il blocco ed a mettere le mani in un consistente blocco (84kbyte) di codice Javascript pesantemente offuscato.

La sesta domanda chiede di individuare la tecnica usata per sferrare l’attacco. Questa è forse la risposta che ha richiesto più lavoro. L’attacco viene portato dal file PDF usando un tag di tipo /AA, che nel formato PDF sta per Add Action. In breve, è possibile associare un’azione alla visualizzazione di una determinata pagina. In questo caso l’azione è stata di mandare in esecuzione il blocco di codice Javascript. Per capire cosa abbia fatto il codice, occorre invertire l’offuscamento, ma le cose non sono così semplici. Il Javascript usato da Acrobat Reader è certamente standard, tanto da essere possibile eseguirlo in Firefox, ad esempio, ma quello che cambia drasticamente sono le funzioni disponibili all’interno dell’ambiente di esecuzione. In Acrobat, Javascript ha a disposizione tutte le funzioni necessarie per lavorare con i file PDF (e non solo quelli), funzioni che in Firefox, ad esempio, non esistono. Quindi eseguire il blocco di codice Javascript in Firefox, racchiudendolo tra i tag SCRIPT non produce alcun risultato utile. Esaminando un po’ il codice “a vista” si riesce ad individuare una chiamata alla funzione Javascript eval( ). Riuscire a vedere il parametro (la stringa) passata ad eval spesso significa vedere il codice non offuscato. Installando Firebug in Firefox si riesce nell’intento. Basta piazzare un breakpoint subito prima della chiamata alla funzione eval e si ottiene il codice Javascript in chiaro.

Ebbene, il codice Javascript contiene ben tre differenti shellcode, da usare in funzione della versione di Acrobat Reader (7, 8 o 9). In tutti e tre i casi il risultato dell’esecuzione dello shellcode è che viene scaricato un file eseguibile ed avviato senza possibilità di intervento dell’utente.

La settima domanda chiede di individuare eventuali file sospetti caricati da un qualsiasi processo attivo nella macchina in esame, e se tale file possa essere messo in relazione con l’attacco iniziale. Anche qui Volatility fa la parte del leone, utilizzando anche un plugin sviluppato da Michael Hale Ligh. Nel processo relativo a WinLogon si trovano quattro file sospetti: \WINDOWS\system32\sdra64.exe, \WINDOWS\system32\lowsec\user.ds, \_AVIRA_2109 e \WINDOWS\system32\lowsec\local.ds. Dalla successiva analisi si vedrà che tali file sono associati proprio al malware Zbot. Eseguendo il citato plugin di Volatility per estrarre codice iniettato in altri processi sul processo di WinLogon, si ottengono sei file, ma solo uno di loro contiene stringhe relative ai file sospetti trovati prima. Interessante è anche una lista di nomi di funzioni esportate da alcune DLL di sistema di Windows. Tali funzioni vengono utilizzate per iniettare codice in altri processi. Lo stesso file, passato a VirusTotal per l’analisi viene identificato come una variante di Zbot.

Tags: Honeynet project, memory forensic, sfide

Ho da poco inviato la mia soluzione alla quarta sfida del progetto Honeynet, riguardante il VoIP. Nell’attesa dei risultati, previsti per la fine di luglio, vediamo la soluzione data alla terza sfida del progetto, che riguardava l’analisi di una immagine di memoria acquisita live su un computer presumibilmente colpito da una qualche forma di malware.

Problemi con l’home banking

Nella mia soluzione ho premesso un riassunto generale di come si è svolta la sequenza di azioni dedotte dall’analisi. Non era richiesta, ma ho pensato che, data la complessità della sfida, fornire un quadro generale avrebbe aumentato la comprensione.

Il campione da esaminare è l’immagine della memoria, un file da 500mbyte.

Tutto inizia con un messaggio e-mail, contenente un allegato in PDF, che all’apertura in Acrobat Reader provoca l’esecuzione di un frammento di Javascript che, sfruttando una falla in Acrobat, riesce a scaricare ed a mandare in esecuzione un eseguibile, senza alcun intervento da parte dell’utente.
L’eseguibile è una variante del malware Zbot, un pezzo del kit di crimeware denominato ZeuS. Questo malware, fra le altre cose, posiziona alcune chiavi di registro relative al processo di WinLogon, assicurandosi l’avvio ad ogni partenza del sistema. Alla partenza sfrutta il meccanismo degli hooks per iniettare codice in tutti i processi di sistema ed utente di cui ha bisogno per fare il suo lavoro.

Andiamo con la prima domanda, che chiede di elencare i processi in esecuzione al momento dell’acquisizione della memoria del computer colpito e di indicare quale sia il processo responsabile della prima fase dell’attacco.
Ricavare questo da una immagine di memoria non è proprio banale, per cui mi sono documentato ed ho trovato una raccolta di strumenti per l’analisi della memoria di Windows, denominata Volatility.
Tramite questi strumenti, open source, è possibile ricavare parecchie informazioni senza andare di editor esadecimale e di certosina pazienza.
Con la funzione di elenco processi di Volatility, appunto, in pochi secondi si ha la lista completa. Ora si tratta di individuare quello responsabile. Se tutto è nato da un PDF allegato ad un messaggio e-mail, è molto probabile che il colpevole sia Acrobat Reader (che ha PID 1752), ma per puntare il dito con più certezza occorre andare avanti con l’analisi.

La domanda successiva chiede di mostrare l’elenco dei socket aperti sul computer vittima, e di indicare se vi siano processi sospetti che abbiano socket aperti.
Occorre incrociare i dati di tre liste, quella dei processi, quella dei socket aperti e quella delle connessioni di rete, in quanto le ultime due fanno riferimento al PID del processo che li gestisce, mentre la lista dei socket elenca anche su che protocollo e quale porta è attivo il socket, dato da incrociare con la connessione TCP o UDP che lo usa.
In breve, saltano fuori tre connessioni sospette, due con un indirizzo IP di un hosting israeliano, una con un indirizzo IP di un hosting maltese.
Vi sono anche altri socket sospetti, due dei quali fanno riferimento alle porte usate nel servizio UPnP di Windows (vedere l’articolo della knowledge base kb832017).
Vi sono dei riferimenti ad un indirizzo IP (192.168.0.1), che tornano ad una semplice ricerca di stringhe all’interno dell’immagine. Verosimilmente si tratta delle pagine di amministrazione web di un router/gateway per piccoli uffici. Sempre nell’immagine della memoria si trovano tracce di queste pagine web e di alcune transazioni SOAP volte ad aprire porte da Internet verso il computer in analisi.
Potrebbe non essere significativo, ma potrebbe anche essere il segno di un tentativo di sfruttare una nota vulnerabilità del protocollo UPnP, per cui non si possono trattare come innocue.
In definitiva, abbiamo due processi con porte aperte o connessioni sospette: PID 880, una istanza di svchost.exe, ed il processo di Acrobat Reader, che pur essendo responsabile probabilmente solo della violazione iniziale, ha ancora due connessioni in piedi col server web che ha originato l’attacco.

La terza domanda chiede di elencare gli eventuali URL sospetti nella memoria del processo sotto indagine.
Gli URL ci sono, cercandoli sia usando gli indirizzi IP trovati in precedenza, sia usando il nome “search-network-plus.com”, con cui è stato registrato l’indirizzo IP dell’hosting israeliano. Gli URL dell’hosting maltese fanno pensare ad un sito terzo, forse violato, su cui è stato inserito uno script PHP che provvede a reindirizzare il visitatore verso l’hosting israeliano, che provvede a fornire il file PDF forgiato.

La quarta domanda chiede se vi siano riferimenti riconducibili a problemi con l’home banking, quali siano i processi e gli URL.
Un URL in particolare è molto interessante, quello che riporta il nome di un noto istituto bancario americano. L’URL è scritto usando alcuni caratteri a mo’ di wildcard. Ebbene, questo schema è del tutto identico a quello usato nel malware Zbot per indicare in quali pagine web visitate è da iniettare il codice HTML per rubare le credenziali di accesso.
In pratica, questo malware riesce a intercettare tutto il traffico con Internet e sulla base degli URL indicati riesce a modificare al volo il codice HTML ricevuto dal sito dell’istituto bancario. Queste modifiche sono volte a deviare le credenziali inserite dall’ignaro utente verso che controlla il malware. In breve, opera come in una operazione di phishing, ma il sito che viene visitato è quello della banca, e il furto di credenziali avviene nel computer dell’utilizzatore e vittima, non in un sito contraffatto.

Tags: Honeynet project, memory forensic, sfide