Bootkits are not dead. Pitou is back!

Pitou is the last Bootkit that infects the MBR and sends spam again in the 2018.

TG Soft's Research Centre (C.R.A.M.) has analyzed in the last months new versions of Bootkit dubbed Pitou. From September to October 2017 we have seen new samples of  Pitou in the wild.

The first version of Pitou has beeen released on April 2014. It maybe an evolution of the rootkit "Srzizbi" developed on 2008.
Pitou is a spambot, the main goal is send spam form the computer of victim.



==> Bootkit installation
==> Switch from Real Mode to Protect Mode on Windows Xp 32 bit

==> Pitou on Windows 10 64 bit

==> Pitou Driver 32bit

==> Pitou & Curiosity

==> IOC

==> Conclusions

It uses the sophisticated technique of Bootkit to bypass the Microsoft Kernel-Mode Code Signing policy for load the own driver (kernel payload) on Windows.

The Bootkits have reached the peak of popularity from 2010 to 2012 with Sinowal, TDL4, TDSS (Olmasco), Cidox (Rovnix) and GAPZ. These Bootkits was diseappear after 2012 and seemed the end of era of Bootkit. In the 2014 Pitou was detected as a new Bootkit, but it seem that not have had a big diffusion in the wild.
In the last months of 2017 Pitou is back!

Pitou spreads in various way:
  • drive-by-download from compromised websites
  • from others malware
Pitou can infect all operating system of Windows: from XP to Windows 10 (32/64 bit)

Pitou maybe considered as the last Bootkit that infects the partitions type MBR (it cannot infect UEFI).
Pitous is known with name "Backboot".

The sample analyzed:

Name: 63.TMP.EXE
Size: 673.792 byte
MD5: B6BA98AB70571172DA9731D2C183E3CC
Found: 20 September 2017
Compilation Time Date Stamp: 19 September 2017 20:55:31
First submission on VT: 2017-09-23 04:58:27

Bootkit installation

When the dropper is executed, the malware infects the Master Boot Record of disk in the following way:

Pitou uses the "standard" technique of infection of the MBR. It overwrites the last 1 MB with the loader of Pitou and the Driver in the unpartitioned space.
In the first 17 sectors of the last 1 MB there is the code of loader of Pitou and in the following sectors there is the Driver (kernel payload) in encrypted form.

Here we can see the dump of MBR infected:

The code of MBR infected by Pitou reads the 17 sectors at end of disk (in the unpartitioned space) in memory at address 500:0 as we can see here:


The 17 sectors are encrypted, so Pitou decrypts it with this easy algorithm (xor and ror):


The next step is hook the int 13h at address 500:9Bh:

After that Pitou has hooked the int 13h, it decrypts the original MBR at address 0:7C00h and executes it.

Switch from Real Mode to Protect Mode

Now that Pitou has passed the control at original MBR, Pitou is hooked only at int 13h. Here we can see the routine of int 13h of Pitou:


The routine Pitou detects each request of read of sectors, function ah=42h (Extended Read Sectors) and ah=02h (Read Sectors), this permits at Pitou to know when the process of boot will read the file C:\NTLDR or C:\BOOTMGR.

In this step Pitou must hook C:\NTLDR or C:\BOOTMGR for "survive" when there is the switch from real mode into protect mode:


Pitou patches "ntldr" with:
  • xxxxxxxx   call gate selector 8:600h
  • 00000600   jmp 0x5183
The first patch is "call gate selector 8:600h", so the "ntldr" will go at address 0x00000600. At address 0x00000600 Pitou has patched this area of memory with "0xe9 0x7e 0x4b 0x0 0x0" so jump (jmp) at address 0x00005183 (0x600 + 0x4b7e + 0x5 = 0x5183)
The address 0x00005183 in protect mode is equal in real mode at address 500:0183 where Pitou is saved in this moment.
Now Pitou is working in protect mode, but the area of memory where Pitou is saved can be overwritten by Windows or the memory can be paged.
So Pitou needs to allocate "safe" memory, it will allocate 2 pages and it will copy the loader at 32 bit in the new area of memory.

Now Pitou parses the NTLDR to hook the call at function KiSystemStartup. The hook is made before the NTLDR calls KiSystemStartup, because at thata moment the NLDR has loaded the "NTOSKRNL.EXE" but not executed. The hook permits to Pitou to know the base of address of module "NTOSKRNL.EXE", then Pitou will parse the module "NTOSKRNL.EXE" to insert a new hook.

The last hook in "NTOSKRNL.EXE" permits to Pitou to know that the kernel of Windows (NTOSKRNL.EXE) is running properly.
Now Pitou can use the API exported by NTOSKRNL.EXE:

Pitou creates a new system thread calling the function PsCreateSystemthread exported by NTOSKRNL.EXE. The thread will load the driver bypassing the Microsoft Kernel-Mode Code Signing policy.

In this phase Pitou will do:

  1. Allocate 0xfde00 bytes in memory ("physical memory" )
  2. Read and decrypt the last 0x7ef sectors of disk in the "physical memory"
  3. Allocate a buffer with size equal at ImageSize of driver for the "virtual memory"
  4. "Load" the driver from "physical memory" to "virtual memory"
  5. Create the structure "DriverObject" to pass at Entrypoint of driver

Here we can see as Pitou execute the driver:

Back on top

Pitou on Windows 10 64 bit


The loader of Pitou on Windows 10 64 bit uses 3 different codes:

  • 16 bit (from BIOS to Bootmgr)
  • 32 bit (from Bootmgr to Bootmgr.exe)
  • 64 bit (from Winload.exe to NTOSKRNL.EXE)

In the scheme the point 1 indicates the hook at int 13h by Pitou to know when the "Bootmgr" is read.  The second hook is made inside the "Bootmgr" to swtich from real mode into protect mode. In this phase the "Bootmgr" will extract from it a file PE dubbed "Bootmgr.exe". The file "Bootmgr.exe" works in 32 bit and is executed by Bootmgr. At this point Pitou (32 bit) will hook the "Bootmgr.exe" to know when it will load the file "Winload.exe" (64 bit). This hook is need to survive at switch from 32 bit to 64 bit. When this hook is called, Pitou (64 bit)  will parse the file "Winload.exe" to hook  when "Winload.exe" will load and execute the "NTOSKRNL.EXE". When the hook inside "Winload.exe" is called, then Pitou will parse "NTOSKRNL.EXE" to hook the function "InbvIsBootDriverInstalled".
The last hook in the function "InbvIsBootDriverInstalled" is need to know when "NTOSKRNL.EXE" is loaded and ready.
As in the previous case, Pitou will load the driver 64 bit bypassing the Microsoft Kernel-Mode Code Signing policy.



Back on top

Pitou Driver 32bit

We have analyzed the driver 32 bit of Pitou, the 64 bit version is similar.
The driver extracted from the end of disk has the following characteristics:

Size: 437.248 byte
MD5: EA286ABDE0CBBF414B078400B1295D1C
Compilation Time Date Stamp: 10 July 2017 15:59:35
No submission on VT
Fully obfuscated: difficult to analyze in static way
SpamBot (works completely in kernel mode)


The driver is obfuscated as we can see:

It contains a lot of random strings as "Again, one can talk, for to kill" to evade the AVs.

We can see some levels of obfuscation. The first level is at "DriverEntry":

The DriverEntry sets a local variable [ebp+var_C] with value 0x209fdc, after it calls a lot of subroutines that modifies this value each time until to arrive to call the subroutine "call [ebp+var_C]" with the real "DriverEntry".

A second level of obfuscation is the use of hashes of blocks of 16 byte of code/data to calculate the addresses of objects, structures, strings, data and etc.
These hashes change everytime with the execution of drivers, so it is very difficult to take a snapshot for the analysis.
Here an example:


Pitou checks if it is running under VM, Sandboxing or in emulated/virtualized environments:

  • MS_VM_CERT, VMware -> VMWare
  • Parallels -> Paralles Desktop for Mac
  • SeaBIOS -> SeaBIOS emulator
  • i440fx, 440BX -> QEMU emulator
  • Bochs -> Bochs emulator
  • QEMU0 -> QEMU emulator
  • Oracle, VirtualBox -> Oracle VM VirtualBox
  • innotek -> Innotek VirtualBox (Oracle VM VirtualBox)

If it is running under VM or in emuIated/virtualized environments then it stops to work.


Pitou uses technique to be stealth, as other bootkits, it hooks the Miniport Device Object of disk to detect the request of read/write of sectors of disk:

\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]

When an application in "user mode" send a request to read the MBR, this is intercepted by Pitou in kernel mode, that instead will read the original MBR at end of disk hiding the infection.

Above we can see the hook in the miniport of device "ACPI" on: IRP_MJ_DEVICE_CONTROL and  IRP_MJ_INTERNAL_DEVICE_CONTROL

Server C/C

Pitou connects at server C/C with IP Port 7384 TCP, and is hosted in Paris.
In encrypted form it receives commands to send spam:

  • email addresses
  • body
  • smtps

If Pitou cannot connect at server C/C then it generates 4 domains (DGA), examples:

  • unpeoavax.mobi
  • ilsuiapay.us
  • ivbaibja.net
  • asfoeacak.info


Pitou sends spam from the pc of victim, this operation is made totally in kernel mode.
Here some example of spam sent by Pitou:

As you can see  Pitou sends spam of Viagra and Cialis.




Back on top

Pitou & Curiosity

In this paragraph we speak about a little curiosity. We well know the researcher "MalwareTech" for the kill switch of "WannaCry", he is a very famous and smart researcher anti-malware.

MalwareTech has written a POC of Bootkit called TinyXPB in April 2014 (Github): https://github.com/MalwareTech/TinyXPB

In the analysis of Pitou by F-Secure, they have reported that the first detection of Pitou was in April 2014.

We have found some similarities in the code of Pitou :
  • The loader 16 bit is identical at version written by MalwareTech in TinyXPB
  • The loader 32 bit is a little different

From our point of view, we can say that there are some things in the loader 16 bit which was already developed by others Bootkit, so in the code of Pitou there aren't new ideas.
We guess the author of Pitou has taken inspiration by MalwareTech.

Back on top



B6BA98AB70571172DA9731D2C183E3CC (dropper)
EA286ABDE0CBBF414B078400B1295D1C (driver 32 bit)

EC08C0243B2C1D47052C94F7502FB91F (dropper)
9A7632F3ABB80CCC5BE22E78532B1B10 (driver 32 bit)
264A210BF6BDDED5B4E35F93ECA980C4 (driver 64 bit)




Pitou is the last known "MBR" Bootkit that uses this sophisticated technique. The Bootkit has a very strong arsenal that can bypasses the Kernel Mode Code Signing policy ans is very difficult to detect, because they have a high degree of stealth.

We are surprise to see again Bootkits that infects the Master Boot Record. Nowadays the new machines uses BIOS with UEFI or with huge hard disk, then the partitions cannot be of type MBR, so in the next period we guess to see more UEFI Bootkit than MBR Bootkit..

Author: Gianfranco Tonello
Centro Ricerche Anti-Malware di TG Soft

Back on top

Any information published on our site may be used and published on other websites, blogs, forums, facebook and/or in any other form both in paper and electronic form as long as the source is always and in any case cited explicitly “Source: CRAM by TG Soft www.tgsoft.it” with a clickable link to the original information and / or web page from which textual content, ideas and / or images have been extrapolated.
It will be appreciated in case of use of the information of C.R.A.M. by TG Soft www.tgsoft.it in the report of summary articles the following acknowledgment/thanks “Thanks to Anti-Malware Research Center C.R.A.M. by TG Soft of which we point out the direct link to the original information: [direct clickable link]”

Vir.IT eXplorer PRO is certified by the biggest international organisation: