Cyber security: il valore della protezione dei dati con BooleBox
20 Aprile 2018
Cyber Crime Conference 2018 – Comunicato Post Evento
23 Aprile 2018

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.

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:

  1. Analisi dell’infezione a basso livello del Master Boot Record e caricamento del driver
  2. Analisi del driver di Pitou

Installazione del Bootkit Pitou

Quando il dropper di Pitou viene eseguito, il malware infetta il Master Boot Record come in figura 1:

Figura 1: infezione del Master Boot Record

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.

Figura 2: dump del Master Boot Record infetto da Pitou

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).

Figura 3: lettura dei 17 settori del “loader” di Pitou

I 17 settori letti sono cifrati, Pitou li decifra con un algoritmo di xor e ror (figura 4).

Figura 4: Algoritmo di decifratura del “loader” di Pitou

Il prossimo passo è quello di agganciarsi all’interrupt 13h all’indirizzo 500:9bh (figura 5).

Figura 5: Hook dell’interrupt 13h

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).

Figura 6: Decifratura dell’MBR originale

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.

Figura 7: 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).

Figura 8: Hook di “C:/NTLDR” per il passaggio dalla modalità reale a quella protetta

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).

Figura 9: Pitou usa le API esportate da NTOSKRNL.EXE per creare un thread di sistema

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:

  1. Alloca oxfde00 byte in memoria (fisica)
  2. Legge e decifra gli ultimi 0x7ef settori del disco
  3. Alloca un buffer di dimensione uguale all’ImageSize del driver per la memoria virtuale
  4. Carica il driver dalla memoria “fisica” a quella “virtuale”
  5. Crea una struttura “DriveObject” e la passa all’EntryPoint del driver

Figura 10

In figura 11 possiamo vedere come Pitou esegue il driver.

Figura 11: esecuzione del driver di Pitou

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.

Figura 12: Windows 10 a 64 – schema d’infezione di Pitou

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.

Figura 13: Offuscamento dl driver

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”.

Figura 14: Offuscamento del vero “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.

Figura 15: Offuscamento a livello di hash

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

Figura 17

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.

Figura 18: Messaggi spam inviati da Pitou

Come si può notare, Pitou inviamo messaggi spam di Viagra e Cialis.

Conclusioni

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:

  • Analista di Virus/Malware dal 1990 con pubblicazione di numerose analisi presso il VTC (Virus Test Center) dell’Università di Amburgo e numerose riviste italiane.
  • Sviluppatore software specializzato nella produzione di tecnologie AntiMalware:
    • dal 1992 sviluppa software di identificazione euristica e dal 1993 l’AntiVirus VirIT per DOS;
    • dal 1997 sviluppa la suite AntiVirus-AntiSpyware-AntiMalware Vir.IT eXplorer PRO per Windows®;
    • dal 2013 sviluppa il software AntiMalware per Androd[TM] VirIT Mobile Security
  • WildList reporter (www.wildlist.org): analista/reporter della WildList;
  • Membro AMTSO Anti-Malware Testing Standards Organization (www.amtso.org).
  • Membro VIA Virus Information Alliance di Microsoft.
  • Membro MVI Microsoft Virus Initiative.
Download PDF
Condividi sui Social Network:

ISCRIVITI ALLA NEWSLETTER DI ICT SECURITY MAGAZINE

Una volta al mese riceverai gratuitamente la rassegna dei migliori articoli di ICT Security Magazine

Rispettiamo totalmente la tua privacy, non cederemo i tuoi dati a nessuno e, soprattutto, non ti invieremo spam o continue offerte, ma solo email di aggiornamento.
Privacy Policy