{ "id": "1cfd041a-3140-41f3-a2d5-e7803c9222bd", "created_at": "2026-04-06T01:31:26.624915Z", "updated_at": "2026-04-10T03:24:29.457949Z", "deleted_at": null, "sha1_hash": "05634754416e2b6416b2b6523bb2843e2e170c68", "title": "Bootkits are not dead. Pitou is back!", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 546783, "plain_text": "Bootkits are not dead. Pitou is back!\r\nBy TG Soft S.r.l. - https://www.tgsoft.it\r\nArchived: 2026-04-06 01:09:22 UTC\r\nTG Soft's Research Centre (C.R.A.M.) has analyzed in\r\nthe last months new versions of Bootkit dubbed Pitou.\r\nFrom September to October 2017 we have seen new\r\nsamples of  Pitou in the wild.\r\nThe first version of Pitou has beeen released on April\r\n2014. It maybe an evolution of the rootkit \"Srzizbi\"\r\ndeveloped on 2008.\r\nPitou is a spambot, the main goal is send spam form the\r\ncomputer of victim.\r\nCONTENTS\r\n==\u003e Bootkit installation\r\n \r\n==\u003e Switch from Real Mode to Protect Mode on\r\nWindows Xp 32 bit==\u003e Pitou on Windows 10 64\r\nbit ==\u003e Pitou Driver 32bit==\u003e Pitou \u0026 Curiosity\r\n==\u003e IOC\r\n==\u003e Conclusions\r\nIt uses the sophisticated technique of Bootkit to bypass the Microsoft Kernel-Mode Code Signing policy for load\r\nthe own driver (kernel payload) on Windows.\r\nThe Bootkits have reached the peak of popularity from 2010 to 2012 with Sinowal, TDL4, TDSS (Olmasco),\r\nCidox (Rovnix) and GAPZ. These Bootkits was diseappear after 2012 and seemed the end of era of Bootkit. In the\r\n2014 Pitou was detected as a new Bootkit, but it seem that not have had a big diffusion in the wild.\r\nIn the last months of 2017 Pitou is back!\r\nPitou spreads in various way:\r\ndrive-by-download from compromised websites\r\nfrom others malware\r\nPitou can infect all operating system of Windows: from XP to Windows 10 (32/64 bit)\r\nPitou maybe considered as the last Bootkit that infects the partitions type MBR (it cannot infect UEFI).\r\nPitous is known with name \"Backboot\".\r\nThe sample analyzed:\r\nName: 63.TMP.EXE\r\nSize: 673.792 byte\r\nMD5: B6BA98AB70571172DA9731D2C183E3CC\r\nFound: 20 September 2017\r\nCompilation Time Date Stamp: 19 September 2017 20:55:31\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 1 of 12\n\nFirst submission on VT: 2017-09-23 04:58:27\r\nBootkit installation\r\nWhen the dropper is executed, the malware infects the Master Boot Record of disk in the following way:\r\nPitou uses the \"standard\" technique of infection of the MBR. It overwrites the last 1 MB with the loader of Pitou\r\nand the Driver in the unpartitioned space.\r\nIn 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\r\nDriver (kernel payload) in encrypted form.\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 2 of 12\n\nHere we can see the dump of MBR\r\ninfected:\r\nThe code of MBR infected by Pitou reads the 17 sectors at end of disk (in the unpartitioned space) in memory at\r\naddress 500:0 as we can see here:\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 3 of 12\n\nThe 17 sectors are encrypted, so Pitou decrypts it with this easy algorithm (xor and ror):\r\nThe next step is hook the int 13h at address 500:9Bh:\r\nAfter that Pitou has hooked the int 13h, it decrypts the original MBR at address 0:7C00h and executes it.\r\nSwitch from Real Mode to Protect Mode\r\nNow that Pitou has passed the control at original MBR, Pitou is hooked only at int 13h. Here we can see the\r\nroutine of int 13h of Pitou:\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 4 of 12\n\nThe routine Pitou detects each request of read of sectors, function ah=42h (Extended Read Sectors) and ah=02h\r\n(Read Sectors), this permits at Pitou to know when the process of boot will read the file C:\\NTLDR or\r\nC:\\BOOTMGR.\r\nIn this step Pitou must hook C:\\NTLDR or C:\\BOOTMGR for \"survive\" when there is the switch from real mode\r\ninto protect mode:\r\nPitou patches \"ntldr\" with:\r\nxxxxxxxx   call gate selector 8:600h\r\n00000600   jmp 0x5183\r\nThe first patch is \"call gate selector 8:600h\", so the \"ntldr\" will go at address 0x00000600. At address 0x00000600\r\nPitou has patched this area of memory with \"0xe9 0x7e 0x4b 0x0 0x0\" so jump (jmp) at address 0x00005183\r\n(0x600 + 0x4b7e + 0x5 = 0x5183)\r\nThe address 0x00005183 in protect mode is equal in real mode at address 500:0183 where Pitou is saved in this\r\nmoment.\r\nNow Pitou is working in protect mode, but the area of memory where Pitou is saved can be overwritten by\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 5 of 12\n\nWindows or the memory can be paged.\r\nSo Pitou needs to allocate \"safe\" memory, it will allocate 2 pages and it will copy the loader at 32 bit in the new\r\narea of memory.\r\nNow Pitou parses the NTLDR to hook the call at function KiSystemStartup. The hook is made before the NTLDR\r\ncalls KiSystemStartup, because at thata moment the NLDR has loaded the \"NTOSKRNL.EXE\" but not executed.\r\nThe hook permits to Pitou to know the base of address of module \"NTOSKRNL.EXE\", then Pitou will parse the\r\nmodule \"NTOSKRNL.EXE\" to insert a new hook.\r\nThe last hook in \"NTOSKRNL.EXE\" permits to Pitou to know that the kernel of Windows (NTOSKRNL.EXE) is\r\nrunning properly.\r\nNow Pitou can use the API exported by NTOSKRNL.EXE:\r\nPitou creates a new system thread calling the function PsCreateSystemthread exported by NTOSKRNL.EXE. The\r\nthread will load the driver bypassing the Microsoft Kernel-Mode Code Signing policy.\r\nIn this phase Pitou will do:\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 6 of 12\n\n1. Allocate 0xfde00 bytes in memory (\"physical memory\" )\r\n2. Read and decrypt the last 0x7ef sectors of disk in the \"physical\r\nmemory\"\r\n3. Allocate a buffer with size equal at ImageSize of driver for the\r\n\"virtual memory\"\r\n4. \"Load\" the driver from \"physical memory\" to \"virtual memory\"\r\n5. Create the structure \"DriverObject\" to pass at Entrypoint of driver\r\nHere we can see as Pitou execute the driver:\r\nBack on top\r\nPitou on Windows 10 64 bit\r\nThe loader of Pitou on Windows 10 64 bit uses 3 different codes:\r\n16 bit (from BIOS to Bootmgr)\r\n32 bit (from Bootmgr to Bootmgr.exe)\r\n64 bit (from Winload.exe to NTOSKRNL.EXE)\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 7 of 12\n\nIn the scheme the point 1 indicates the hook at int 13h by Pitou to know when the \"Bootmgr\" is read.  The second\r\nhook is made inside the \"Bootmgr\" to swtich from real mode into protect mode. In this phase the \"Bootmgr\" will\r\nextract from it a file PE dubbed \"Bootmgr.exe\". The file \"Bootmgr.exe\" works in 32 bit and is executed by\r\nBootmgr. At this point Pitou (32 bit) will hook the \"Bootmgr.exe\" to know when it will load the file \"Winload.exe\"\r\n(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\r\nparse the file \"Winload.exe\" to hook  when \"Winload.exe\" will load and execute the \"NTOSKRNL.EXE\". When\r\nthe hook inside \"Winload.exe\" is called, then Pitou will parse \"NTOSKRNL.EXE\" to hook the function\r\n\"InbvIsBootDriverInstalled\".\r\nThe last hook in the function \"InbvIsBootDriverInstalled\" is need to know when \"NTOSKRNL.EXE\" is loaded\r\nand ready.\r\nAs in the previous case, Pitou will load the driver 64 bit bypassing the Microsoft Kernel-Mode Code Signing\r\npolicy.\r\nBack on top\r\n \r\nPitou Driver 32bit\r\nWe have analyzed the driver 32 bit of Pitou, the 64 bit version is similar.\r\nThe driver extracted from the end of disk has the following characteristics:\r\nSize: 437.248 byte\r\nMD5: EA286ABDE0CBBF414B078400B1295D1C\r\nCompilation Time Date Stamp: 10 July 2017 15:59:35\r\nNo submission on VT\r\nFully obfuscated: difficult to analyze in static way\r\nAnti-VM\r\nStealth\r\nSpamBot (works completely in kernel mode)\r\nObfuscation\r\nThe driver is obfuscated as we can see:It contains a lot of random strings as\r\n\"Again, one can talk, for to kill\" to evade the AVs.\r\nWe can see some levels of obfuscation. The first level is at \"DriverEntry\":\r\nThe DriverEntry sets a local variable [ebp+var_C] with value 0x209fdc, after it calls a lot of subroutines that\r\nmodifies this value each time until to arrive to call the subroutine \"call [ebp+var_C]\" with the real\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 8 of 12\n\n\"DriverEntry\".\r\nA second level of obfuscation is the use of hashes of blocks of 16 byte of code/data to calculate the addresses of\r\nobjects, structures, strings, data and etc.\r\nThese hashes change everytime with the execution of drivers, so it is very difficult to take a snapshot for the\r\nanalysis.\r\nHere an example:\r\nAnti-VM\r\nPitou checks if it is running under VM, Sandboxing or in emulated/virtualized environments:\r\nMS_VM_CERT, VMware -\u003e VMWare\r\nParallels -\u003e Paralles Desktop for Mac\r\nSeaBIOS -\u003e SeaBIOS emulator\r\ni440fx, 440BX -\u003e QEMU emulator\r\nBochs -\u003e Bochs emulator\r\nQEMU0 -\u003e QEMU emulator\r\nVRTUALMICROSFT -\u003e Hyper-V\r\nOracle, VirtualBox -\u003e Oracle VM VirtualBox\r\ninnotek -\u003e Innotek VirtualBox (Oracle VM VirtualBox)\r\nIf it is running under VM or in emuIated/virtualized environments then it stops to work.\r\nStealth\r\nPitou uses technique to be stealth, as other bootkits, it hooks the Miniport Device Object of disk to detect the\r\nrequest of read/write of sectors of disk:\r\nIRP_MJ_DEVICE_CONTROL\r\nIRP_MJ_INTERNAL_DEVICE_CONTROL\r\n\\Driver\\ACPI -\u003e MajorFunction[IRP_MJ_DEVICE_CONTROL] = 81aefe43  Hook in ???\r\n81aefe43 55               push    ebp\r\n81aefe44 8bec             mov     ebp,esp\r\n81aefe46 51               push    ecx\r\n81aefe47 53               push    ebx\r\n81aefe48 8b5d08           mov     ebx,[ebp+0x8]\r\n81aefe4b 33c0             xor     eax,eax\r\n\\Driver\\ACPI -\u003e MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = 81ae9a5f  Hook in ???\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 9 of 12\n\n81ae9a5f 55               push    ebp\r\n81ae9a60 8bec             mov     ebp,esp\r\n81ae9a62 83e4f8           and     esp,0xf8\r\n81ae9a65 83ec24           sub     esp,0x24\r\n81ae9a68 833d68b9b48100   cmp     dword ptr [81b4b968],0x0\r\n81ae9a6f 8b4d0c           mov     ecx,[ebp+0xc]\r\nWhen an application in \"user mode\" send a request to read the MBR, this is intercepted by\r\nPitou in kernel mode, that instead will read the original MBR at end of disk hiding the\r\ninfection.\r\nAbove we can see the hook in the miniport of device \"ACPI\" on:\r\nIRP_MJ_DEVICE_CONTROL and  IRP_MJ_INTERNAL_DEVICE_CONTROL\r\nServer C/C\r\nPitou connects at server C/C with IP 195.154.237.14 Port 7384 TCP, and is hosted in Paris.\r\nIn encrypted form it receives commands to send spam:\r\nemail addresses\r\nbody\r\nsmtps\r\nIf Pitou cannot connect at server C/C then it generates 4 domains (DGA), examples:\r\nunpeoavax.mobi\r\nilsuiapay.us\r\nivbaibja.net\r\nasfoeacak.info\r\nSpamBot\r\nPitou sends spam from the pc of victim, this operation is made totally in kernel mode.\r\nHere some example of spam sent by Pitou:\r\nAs you can see  Pitou sends spam of Viagra and Cialis.\r\nBack on top\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 10 of 12\n\nPitou \u0026 Curiosity\r\nIn this paragraph we speak about a little curiosity. We well know the researcher \"MalwareTech\" for the kill switch\r\nof \"WannaCry\", he is a very famous and smart researcher anti-malware.\r\nMalwareTech has written a POC of Bootkit called TinyXPB in April 2014 (Github):\r\nhttps://github.com/MalwareTech/TinyXPB\r\nIn the analysis of Pitou by F-Secure, they have reported that the first detection of Pitou was in April 2014.\r\nWe have found some similarities in the code of Pitou :\r\nThe loader 16 bit is identical at version written by MalwareTech in TinyXPB\r\nThe loader 32 bit is a little different\r\nFrom our point of view, we can say that there are some things in the loader 16 bit which was already developed by\r\nothers Bootkit, so in the code of Pitou there aren't new ideas.\r\nWe guess the author of Pitou has taken inspiration by MalwareTech.\r\nBack on top\r\nIOC\r\nMD5\r\nB6BA98AB70571172DA9731D2C183E3CC (dropper)\r\nEA286ABDE0CBBF414B078400B1295D1C (driver 32 bit)\r\nEC08C0243B2C1D47052C94F7502FB91F (dropper)\r\n9A7632F3ABB80CCC5BE22E78532B1B10 (driver 32 bit)\r\n264A210BF6BDDED5B4E35F93ECA980C4 (driver 64 bit)\r\nIP195.154.237.14\r\nConclusions\r\nPitou is the last known \"MBR\" Bootkit that uses this sophisticated technique. The Bootkit has a very strong\r\narsenal that can bypasses the Kernel Mode Code Signing policy ans is very difficult to detect, because they have a\r\nhigh degree of stealth.\r\nWe are surprise to see again Bootkits that infects the Master Boot Record. Nowadays the new machines uses\r\nBIOS with UEFI or with huge hard disk, then the partitions cannot be of type MBR, so in the next period we\r\nguess to see more UEFI Bootkit than MBR Bootkit..\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 11 of 12\n\nAuthor: Gianfranco Tonello\r\nCentro Ricerche Anti-Malware di TG Soft\r\nBack on top\r\nAny information published on our site may be used and published on other websites, blogs, forums, facebook\r\nand/or in any other form both in paper and electronic form as long as the source is always and in any case cited\r\nexplicitly “Source: CRAM by TG Soft www.tgsoft.it” with a clickable link to the original information and / or web\r\npage from which textual content, ideas and / or images have been extrapolated.\r\nIt 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\r\nsummary articles the following acknowledgment/thanks “Thanks to Anti-Malware Research Center C.R.A.M. by\r\nTG Soft of which we point out the direct link to the original information: [direct clickable link]”\r\nSource: https://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nhttps://www.tgsoft.it/english/news_archivio_eng.asp?id=884\r\nPage 12 of 12", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.tgsoft.it/english/news_archivio_eng.asp?id=884" ], "report_names": [ "news_archivio_eng.asp?id=884" ], "threat_actors": [ { "id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d", "created_at": "2022-10-25T16:07:24.139848Z", "updated_at": "2026-04-10T02:00:04.878798Z", "deleted_at": null, "main_name": "Safe", "aliases": [], "source_name": "ETDA:Safe", "tools": [ "DebugView", "LZ77", "OpenDoc", "SafeDisk", "TypeConfig", "UPXShell", "UsbDoc", "UsbExe" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439086, "ts_updated_at": 1775791469, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/05634754416e2b6416b2b6523bb2843e2e170c68.pdf", "text": "https://archive.orkl.eu/05634754416e2b6416b2b6523bb2843e2e170c68.txt", "img": "https://archive.orkl.eu/05634754416e2b6416b2b6523bb2843e2e170c68.jpg" } }