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.