Sandboxed malware analysis

Che titolone eh? Chiariamo da subito un concetto: il 99% delle piattaforme antivirus/antimalware si basano su due metodi di rilevamento: 

• le signatures
• l'analisi euristica.

Con le prime si va banalmente a consultare un database di hash di files o di stringhe caratteristiche per individuare una corrispondenza con un qualche pattern noto. Come funziona il tutto? Semplificando possiamo immaginare l'apparizione di un nuovo malware "in the wild" basato su un singolo eseguibile. Qualche utente sospettoso o qualche team di ricerca invia una copia dell'eseguibile "sospetto" ai centri di analisi e costoro sostanzialmente fanno due cose: calcolano l'hash del file e cercano nell'eseguibile delle stringhe. I risultati vengono ficcati nel file delle definizioni dei nostri antivirus e costituisce la "signature" del malware in questione. L'antivirus in real-time verificherà i files che entrano nel sistema e ne farà l'hashing e la ricerca di stringhe all'interno. Se troverà una corrispondenza, segnalerà l'elemento come infetto.

L'analisi euristica è un po' più sofisticata, ma meno accurata. Si basa sostanzialmente su una analisi del codice da cui cercare di "intuirne" l'esecuzione e definirne pertanto la sua "malevolenza" o meno. Si imposta normalmente una soglia per definirne l'accuratezza o, come alcuni in gergo dicono, il "paranoid level". Se il codice analizzato comporta operazioni quali la scrittura su aree di sistema, l'esecuzione da entry point non sicuri o l'attivazione di sessioni tramite protocolli noti (ad esempio irc), eccetera, allora l'antivirus segnalerà l'attività sospetta.

Fin qui tutto tranquillo, no? Beh, ad essere sinceri manca una "lieve" copertura: chi ci difende da un malware che sfrutta tecniche avanzate di evasione (Advanced Evasion Techniques)? Come fare a capire se un processo che non conosciamo è legittimo o se fa parte di una sofisticata minaccia persistente (Advanced Persistent Threat)?

Non possiamo.

Con gli strumenti di tradizionale endpoint security non è possibile intercettare questo genere di minacce.

Occorre una analisi specializzata basta su tecniche di sandboxing.

Cos'è una sandbox? Avete presente nei parchi giochi quei recinti con la sabbia dove si fanno giocare i bambini? Ecco, il paragone con l'informatica è questo: così come nelle sandbox "fisiche" si lasciano liberi i bambini di fare quello che gli pare essendo sicuri che non faranno danni, così nelle sandbox informatiche si lasciano liberi i malware di fare quello che gli pare, essendo sicuri che non faranno danni e dandoci l'opportunità di analizzarne il comportamento.

Chi dispone di un server VmWare può creare uno switch logico e qui collegare il client "tipo". Chi invece usa VmWare player dovrà configurare le schede di rete delle vm in host mode, in maniera tale da non farle interagire al di fuori del sistema.

Ma mettere in piedi una macchina virtuale da sola e lanciarci un virus mica ci permette di sapere come si comporta la minaccia. Occorre come minimo un altro sistema per l'analisi. Io uso normalmente due distro specifiche per il pentesting e l'analisi forense: REMnux, che è sostanzialmente fatta apposta per il reverse engineering dei malware e la sempre ottima Kali. A queste conviene associare alcuni elementi sulla macchina di test: 

• Un debugger per poter analizzare il processo in esecuzione (e per questo IDA o OllyDBG andranno benissimo)
• Degli strumenti per l'analisi dei process trees ed il monitoring di sistema (la suite sysinternals contiene una quantità impressionante di strumenti per la gestione ed il monitoring dei sistemi microsoft)
• Uno sniffer (e qui, ovviamente, Wireshark la fa da padrone incontrastato)
• Un buon hex editor fa comodo (Io uso PSPad)
• Un unpacker può essere utile (Qui ne trovate una buona collezione)

Una delle prime cose che è utile fare per procedere con l'analisi è CREARE UN CLEAN SNAPSHOT DELLA MACCHINA DI TEST!! So che sembra ovvio, ma credetemi: quando si viene messi sotto pressione è facile dimenticarsi di mantenere uno snapshot aggiornato e pulito da usare come base.

Solitamente, la prima cosa che si fa è attivare il Wireshark per tenere sotto controllo il traffico di rete, quindi il process explorer e process monitor di sysinternals per vedere la catena di processi che il malware andrà eventualmente attivare ed i cambiamenti al sistema che effettuerà. Se saremo fortunati, il malware andrà a scrivere qualcosa nel registro o sul filesystem per potersi attivare allo startup. In alcuni casi i malware "creano" dei processi figlio tramite la generazione dinamica di codice batch che richiama altri processi. Il motivo di tale comportamento è presto detto: un antivirus euristico che analizza un binario capisce subito se questo vuole scrivere sul registro. Ma se l'eseguibile crea un batch che a sua volta fa una push nel registro della chiave per l'autostartup, l'antivirus non lo potrà mai intercettare... Altro strumento comodo per tenere sotto controllo il registro è autoruns, sempre della sysinternals suite. Permette di visualizzare tutti i processi che vengono avviati automaticamente dal sistema, assieme agli entry point ed ai triggers. Magari il malware è un bot che fa parte di una botnet. In tal caso wireshark ci mostrerà i tentativi di contatto con il CnC (Command and Control) server. A questo punto può capitare che l'analisi diventi impossibile, perchè alcuni bot e malware capiscono di trovarsi in esecuzione su una sandbox perchè non riescono a contattare il server CnC e pertanto si mettono in "quiet mode" o, addirittura, si autoterminano. Alcuni malware molto avanzati fanno una rapida scansione del sistema prima di qualsiasi altra operazione e, se rilevano di trovarsi in un ambiente virtuale, escono dall'esecuzione immediatamente. Si tratta in ambo i casi di tecniche di evasione fatte per impedire l'analisi. In tal caso, occorrererà per forza creare una sandbox fisica se si vorrà continuare l'analisi...

Quando i malware cominciano a generare traffico di rete, è il momento di mettere in funzione i sistemi di analisi. In primo luogo garantire la name resolution: andremo quindi a configurare come dns sul client l'indirizzo della nostra macchina di analisi, dove attiveremo fakedns (in REMnux) o dnschef (in Kali) per rispondere alle richieste con l'indirizzo della macchina di analisi stessa.

Ad ogni DNS request, le macchine di analisi risponderanno con il proprio indirizzo, così da permettere alle sessioni di rete di avere un terminatore. A questo punto, in funzione dei protocolli che verranno impiegati dal client di test, si potrà cercare di capire il tipo di servizio che viene richiesto: di solito i malware comunicano con l'esterno con IRC, FTP, HTTP, TFTP, SFTP, HTTPS. Ultimamente IRC viene sfruttato sempre di meno perchè la maggior parte dei firewall aziendali bloccano il traffico IRC...Una volta capito il tipo di servizio richiesto, si può cercare di rispondere con un setup..Attivare un server ftp o http per rispondere ci permetterà di scoprire che cosa il client cerca di recuperare dalla rete: a questo punto potremo provare ad andare a recuperare manualmente i componenti in giro sfruttando le richieste stesse per "popolare" il server web o ftp di ciò che il malware richiede, siano essi stringhe di comandi o parti di codice per fare altre e più complesse operazioni. Di recente mi è capitato di analizzare un malware che richiedeva, tramite varie richieste ftp ed http ad alcuni siti di personal storage in Russia, pezzi di eseguibili di altri programmi, principalmente per scattare foto dalla webcam del pc infetto, scaricare archivi di posta, cercare numeri di carte di credito o password, scattare screenshots o generare spam.

!!!ATTENZIONE!!!

La malware analysis su sandbox è una attività che comporta diversi rischi:

• Può richiedere moltissimo tempo: ci sono dei malware che apparentemente non fanno proprio nulla di nulla per ore prima di attivarsi. Altri addirittura hanno come trigger solo lo scoccare di un momento specifico e poi non vengono più eseguiti. Ecco a cosa serve avere uno snapshot aggiornato: se un malware ha come trigger l'esecuzione solo a mezzanotte del 31/12, bisognerà fare in modo che il nostro client di prova sia configurato in modo tale da avere l'orologio fissato a pochi minuti prima della mezzanotte del 31/12.
• Spesso occorre recuperare su siti "poco raccomandabili" dei pezzi di codice. Questo espone il pc al rischio di essere infettato da altri malware. E' buona norma pertanto non collegarsi con macchine o browser facilmente attaccabili. Una buona soluzione consiste nel recupero tramite wget di ciò che serve. o, più in generale, ricorrere a client testuali da riga di comando. Meno estensioni si usano meglio è.
• In alcuni casi i server remoti sono gestiti direttamente dai creatori dei malware. Meglio non attirare troppo la loro attenzione con molteplici contatti, magari anche ripetuti in un periodo di tempo breve...
• Il fatto che un malware sembri non fare nulla di nocivo non significa che ci si può giocare liberamente o "adattarselo per fare uno scherzo". Se credete di aver scoperto un nuovo malware, segnalatelo tramite le pagine di segnalazione malware dei fornitori di IT Security più noti (e.g.: McAfee Threat Center).

Buon divertimento!