I Bootkit non sono morti, il ritorno di Pitou!
Negli ultimi mesi del 2017 è stato riscontrato in circolazione un bootkit chiamato Pitou. Il suo picco di infezione è stato monitorato tra il mese di settembre 2017 e gennaio 2018, dove sono stati individuati alcuni dropper che installavano il bootkit Pitou.
Introduzione al bootkit Pitou: evoluzione e diffusione
Pitou non è un bootkit di nuova generazione, infatti la sua prima versione risale ad aprile 2014, ed esso potrebbe essere un’evoluzione di un rootkit chiamato “Srzizbi”, quest’ultimo sviluppato a partire dal 2008. Pitou appartiene alla famiglia degli spambot, il suo principale obiettivo è quello di inviare spam attraverso il computer della vittima, utilizzando un sofisticato sistema d’infezione a basso livello.
Usa una tecnica sofisticata di Bootkit per bypassare la policy “Microsoft Kernel-Mode Code Signing”, per caricare un proprio driver in Windows senza la firma digitale.
I Bootkit hanno raggiunto l’apice della popolarità tra il 2010 e 2012 con i malware Sinowal, TDL4, TDSS (Olmasco), Cidox (Rovnix) e GAPZ. Tra questi possiamo annoverare anche un famosissimo rootkit chiamato ZeroAccess. Dal 2012 in poi, questi magnifici sei, uno dietro l’altro sono spariti dalla circolazione, dando inizio alla fine dell’era dei Bootkit e lasciando spazio ad altre tipologie di malware meno sofisticate. Sicuramente questo è dovuto alle nuove versioni del sistema operativo Windows di Microsoft, dove sono stati introdotti nuovi sistemi protezione a basso livello come il “Secure Boot technology”.
Nel 2014 Pitou è stato individuato come appartenente ad una nuova famiglia di Bootkit, ma questa nuova tipologia di minaccia non ha avuto una grande diffusione a livello mondiale.
Negli ultimi mesi del 2017 abbiamo riscontrato il ritorno di Pitou, dove sono stati individuati alcuni dropper che installano questo bootkit.
Pitou si diffonde in svariati modi:
- Drive-by-download: attraverso la navigazione su siti compromessi;
- Attraverso altri malware che hanno precedentemente infettato il computer della vittima
Pitou, conosciuto anche con il nome di “Backboot”, può infettare tutte le versioni dei sistemi operativi Microsoft: da Windows XP a Windows 10 (32/64 bit).
Pitou può essere considerato come l’ultimo dei “Bootkit”, che infetta le partizioni di tipo MBR (non può infettare le partizioni UEFI).
Il campione del malware analizzato:
| Nome: | 63.TMP.EXE |
| Dimensione: | 673.792 byte |
| MD5: | B6BA98AB70571172DA9731D2C183E3CC |
| Trovato il: | 20 Settembre 2017 |
| Data di compilazione: | 19 Settembre 2017 20:55:31 |
| Primo inoltro a VT: | 2017-09-23 04:58:27 |
L’articolo è prettamente tecnico ed è suddiviso in due parti:
- Analisi dell’infezione a basso livello del Master Boot Record e caricamento del driver
- Analisi del driver di Pitou
Processo di installazione del bootkit Pitou
Quando il dropper di Pitou viene eseguito, il malware infetta il Master Boot Record come in figura 1:
Pitou usa la tecnica standard di infezione del Master Boot Record, esso sovrascrive l’ultimo mega byte con un “loader” e il suo driver nello spazio del disco non partizionato. Nei primi 17 settori dell’ultimo mega byte c’è il codice del loader di Pitou e nei settori successivi troviamo il driver (kernel payload) in forma cifrata.
In figura 2 possiamo vedere il “dump” del Master Boot Record infetto.
Il codice dell’MBR infettato da Pitou legge i 17 settori alla fine del disco nello spazio non partizionato in memoria all’indirizzo 500:0 (figura 3).
I 17 settori letti sono cifrati, Pitou li decifra con un algoritmo di xor e ror (figura 4).
Il prossimo passo è quello di agganciarsi all’interrupt 13h all’indirizzo 500:9bh (figura 5).
Dopo che Pitou si è agganciato all’interrupt 13h, decifra il Master Boot Record originale (quello prima dell’infezione) all’indirizzo 0:7C00h e lo manda in esecuzione per far partire il “boot” del sistema operativo (figura 6).
Passaggio dalla modalità reale alla modalità protetta
Adesso che Pitou ha passato il controllo all’MBR originale, esso è agganciato solamente all’interrupt 13h . In figura 7 possiamo vedere la routine dell’interrupt 13h di Pitou.
La routine di Pitou intercetta ogni richiesta di lettura di settori del disco, processando le funzioni ah=42h (Extended Read Sectors) e ah=02h (Read Sectors). Questo permette a Pitou di conoscere quando il processo di bootstrap leggerà il file “C:\NTLDR” oppure “C:\BOOTMGR” (in base alla versione di Windows) .
In questa fase Pitou deve agganciarsi al file “C:\NTLDR” oppure “C:\BOOTMGR” per sopravvivere al passaggio dalla modalità reale a quella protetta (figura 8).
Pitou sovrascrive (“patch”) il file “NTLDR” con le seguenti istruzioni:
- xxxxxxxx call gate selector 8:600h
- 00000600 jmp 0x5183
La prima istruzione “call gate selector 8:600h” fa saltare il codice all’indirizzo 0x00000600. All’indirizzo 0x00000600 Pitou ha “patchato” questa area di memoria con gli opcode “0xe9 0x7e 0x4b 0x0 0x0”, in questo modo esegue un salto (“jump”) all’indirizzo 0x00005183 (0x600 + 0x4b7e + 0x5 = 0x5183). L’indirizzo di memoria 0x00005183 in modalità protetta equivale in modalità reale all’indirizzo 500:0183 dove Pitou è memorizzato in quel momento.
Adesso Pitou sta lavorando in modalità protetta, ma l’area di memoria dove Pitou è memorizzato può essere sovrascritta da Windows in qualsiasi momento oppure la memoria può essere “paged”. Quindi Pitou deve necessariamente allocare della memoria “sicura”, allora alloca 2 pagine di memoria dove viene copiato il “loader” a 32 bit.
Il passo successivo di Pitou è quello di cercare all’interno del file “C:\NTLDR” la chiamata alla funzione KiSystemStartup per agganciarsi. L’aggancio viene fatto prima che NTLDR chiami la funzione KiSystemStartup, perché in quel momento NTLDR ha caricato in memoria, ma non eseguito, il modulo “NTOSKRNL.EXE”.
L’hook permette a Pitou di conoscere la base dell’indirizzo di memoria del modulo “NTOSKRNL.EXE”, in questo modo può analizzare il suddetto modulo ed inserire un nuovo hook in esso. Questo ultimo hook permette a Pitou di sapere che il modulo kernel di Windows (NTOSKRNL.EXE) è in esecuzione e sta funzionando perfettamente. Adesso Pitou può usare le API esportate dal modulo kernel NTOSKRNL.EXE (figura 9).
In figura 9 Pitou crea un nuovo thread di sistema chiamando la funzione PsCreateSystemthread esportata da NTOSKRNL.EXE. Il thread caricherà il driver di Pitou bypassando la policy “Microsoft Kernel-Mode Code Signing”.
In questa fase Pitou eseguirà le seguenti operazioni:
|
In figura 11 possiamo vedere come Pitou esegue il driver.
Comportamento di Pitou su Windows 10 a 64 bit
Nella figura 12 possiamo vedere lo schema d’infezione di Pitou utilizzato per caricare il suo driver in ambiente Windows 10 a 64 bit.
Il loader di Pitou in ambiente Windows 10 a 64 bit usa tre differenti tipologie di codice:
- 16 bit (dal BIOS al Bootmgr)
- 32 bit (dal Bootmgr al Bootmgr.exe)
- 64 bit (da Winload.exe al NTOSKRNL.EXE)
Nello schema in figura 12, il punto 1 indicata l’hook di Pitou all’interrupt 13h per conoscere quando il “Bootmgr” verrà letto. Il secondo hook avviene all’interno del “Bootmgr” per passare dalla modalità reale a quella protetta.
In questa fase il “Bootmgr” estrae da esso un file PE chiamato “Bootmgr.exe”. Il file “Bootmgr.exe” lavora a 32 bit ed è eseguito dal “Bootmgr”. A questo punto Pitou (32 bit) si aggancia a “Bootmgr.exe” per sapere quando esso caricherà il file “Winload.exe” (64 bit). Questo hook è necessario per sopravvivere al passaggio da 32 a 64 bit. Quando questo hook è chiamato, Pitou (64 bit) analizzerà il file “Winload.exe” per agganciarsi quando “Winload.exe” caricherà ed eseguirà il file “NTOSKRNL.EXE”. Quando l’hook all’interno di “Winload.exe” è chiamato, allora Pitou analizzerà il modulo “NTOSKRNL.EXE” per agganciarsi alla funzione “InbvIsBootDriverInstalled”.
L’ultimo hook nella funzione “InbvIsBootDriverInstalled” è necessario per conoscere quando “NTOSKRNL.EXE è caricato correttamente.
Come nel caso precedente a 32 bit, Pitou caricherà il driver a 64 bit bypassando la policy “Microsoft Kernel-Mode Code Signing”.
Analisi driver a 32 bit di Pitou
Abbiamo analizzato il driver a 32 bit di Pitou, la versione a 64 bit è analoga a quella a 32 bit.
Il driver estratto dalla fine del disco ha le seguenti caratteristiche:
Dimensione: 437.248 byte
MD5: EA286ABDE0CBBF414B078400B1295D1C
Data di compilazione: 10 July 2017 15:59:35
Data di invio a VT: –
Offuscamento: Elevato offuscamento, che rende difficile l’analisi statica
Anti-VM: Si
Stealth: Si
Target: SpamBot (lavora completamente in kernel mode)
Offuscamento
In figura 13 possiamo vedere un primo livello di offuscamento.
Come possiamo vedere in figura 13, il driver a livello statico si presenta con un sacco di stringhe casuali, come “Again, one can talk, for to kill”, con lo scopo di evadere l’intercettazione degli anti-virus
In figura 14 possiamo vedere un altro offuscamento a livello della chiamata “DriverEntry”.
Il DriverEntry imposta una variabile locale [ebp+var_C] con il valore 0x209fdc, dopo vengono chiamate una serie di subroutine, che modificano questo valore ad ogni chiamata, fino ad arrivare alla chiamata della subroutine “call [ebp+var_C]” con il reale valore del “DriverEntry”.
Un altro livello di offuscamento è l’uso di hash calcolati su blocchi di 16 byte di codice o dati per determinare l’indirizzo di oggetti, struttura dati, stringhe e etc. Questi hash cambiano in continuazione con l’esecuzione del codice del driver, così è molto difficile prendere uno “snapshot” della situazione per l’analisi. In figura 15 vediamo un esempio di offuscamento.
Anti-VM
Pitou controlla se viene eseguito all’interno di una Virtual Machine o in un’ambiente emulato/virtualizzato:
- MS_VM_CERT, VMware -> VMWare
- Parallels -> Paralles Desktop for Mac
- SeaBIOS -> SeaBIOS emulator
- i440fx, 440BX -> QEMU emulator
- Bochs -> Bochs emulator
- QEMU0 -> QEMU emulator
- VRTUALMICROSFT -> Hyper-V
- Oracle, VirtualBox -> Oracle VM VirtualBox
- innotek -> Innotek VirtualBox (Oracle VM VirtualBox)
Se viene eseguito in ambiente virtualizzato o emulato allora non esegue nessuna operazione.
Stealth
Pitou usa tecniche per rendersi invisibile, come altri bootkit, esso si aggancia la Miniport Device Object del disco per intercettare le richieste di lettura/scrittura dei settori del disco (figura 16):
- IRP_MJ_DEVICE_CONTROL
- IRP_MJ_INTERNAL_DEVICE_CONTROL
\Driver\ACPI -> MajorFunction[IRP_MJ_DEVICE_CONTROL] = 81aefe43 Hook in ??? 81aefe43 55 push ebp 81aefe44 8bec mov ebp,esp 81aefe46 51 push ecx 81aefe47 53 push ebx 81aefe48 8b5d08 mov ebx,[ebp+0x8] 81aefe4b 33c0 xor eax,eax \Driver\ACPI -> MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = 81ae9a5f Hook in ??? 81ae9a5f 55 push ebp 81ae9a60 8bec mov ebp,esp 81ae9a62 83e4f8 and esp,0xf8 81ae9a65 83ec24 sub esp,0x24 81ae9a68 833d68b9b48100 cmp dword ptr [81b4b968],0x0 81ae9a6f 8b4d0c mov ecx,[ebp+0xc]
Figura 16: Hook delle funzioni IRP_MJ_DEVICE_CONTROL e IRP_MJ_INTERNAL_DEVICE_CONTROL
Quando un’applicazione in “user mode” invia una richiesta di lettura dell’MBR, questa è intercettata da Pitou in kernel mode, che invece andrà a leggere l’MBR originale e non quello infetto, nascondendo l’infezione in atto.
In figura 16 possiamo vedere l’hook nel miniport del device ACPI su IRP_MJ_DEVICE_CONTROL e IRP_MJ_INTERNAL_DEVICE_CONTROL
Server C/C
Pitou si collega al server di comando e controllo con indirizzo IP 195.154.237.14 attraverso la porta TCP 7384. L’indirizzo IP sopra indicato è localizzato a Parigi.
Pitou comunica in forma cifrata con il server di C/C e invia messaggi di spam. Dal server di comando e controllo riceve le seguenti informazioni:
- Indirizzi email
- Corpo del messaggio
- Smtps
Se Pitou non riesce a collegarsi al server di comando e controllo, allora genera 4 domini attraverso l’algoritmo DGA, esempio:
- unpeoavax.mobi
- ilsuiapay.us
- ivbaibja.net
- asfoeacak.info
SpamBot
Pitou invia messaggi di spam dal computer della vittima, questa operazione è eseguita totalmente in modalità kernel. In figura 18 alcuni esempi di messaggi spam inviati da Pitou.
Come si può notare, Pitou inviamo messaggi spam di Viagra e Cialis.
Conclusioni e prospettive future dei bootkit
Pitou è l’ultimo dei Bootkit conosciuti che infettano il Master Boot Record, utilizzando queste sofisticate tecniche. I Bootkit dispongo di un forte arsenale per bypassare la policy del “Kernel Mode Code Signing” e sono molto difficili da individuare , perché hanno un elevato grado di invisibilità.
Siamo sorpresi di vedere ancora oggi, Bootkit che infettano il Master Boot Record. Oggi i nuovi computer usano BIOS con partizioni UEFI o dischi di dimensioni notevoli, i quali non possono essere formattati con partizioni di tipo MBR. Così ci aspettiamo che nel prossimo periodo vi sarà un maggior numero di Bootkit tipo UEFI.
A cura di: Gianfranco Tonello
Laureato in ingegneria informatica a Padova e CEO di TG Soft Security Software Specialist
Analista di virus&malware e sviluppatore di tecnologie AntiMalware
