In 2012, my colleagues Deepak Gupta and Xiaoning Li explained in a white paper how some malware can operate at the kernel level to bypass Microsoft’s security for 64-bit Windows systems.
Today a small utility program named KPP-Destroyer can be found online.
Previous versions of KPP-Destroyer had some bugs on a Windows 8.1 computer, but the fourth release, posted on July 1, seems fully operational. When you run the tools, it asks for the boot sequence you wish to patch. In my test computer (with secure boot disabled) I had three options and asked the tool to act on the current one.
After a reboot, I had a new entry (Windows 8.1 Patched) in my multiboot menu:
Running BCDEDIT, I saw some changes:
A flag nointegritycheck is enabled to disable integrity checks. The file d6gt2rg.exe has taken the place of winload.exe. The default kernel (ntoskrnl.exe) has been replaced by sei2f4v4g9.exe.
- When the flag nointegritycheck is enabled there is no warning when you attempt to install an unsigned driver. In this case, no integrity check allows the patched winload.exe to load. If you restore or disable the parameter (bcdedit /set nointegritychecks OFF) the boot fails and a blue screen explains the Automatic Repair process couldn’t repair your PC.
- To keep the original winload.exe (Windows Boot Loader), the patched version is given a random name (d6gt2rg.exe in this case) and added to the boot process. Its job is to load the patched ntoskrnl.exe, the core part of Windows. During this task, a code integrity check point (ImgpValidateImageHash) must be skipped. The malware does this by changing five bytes.
- Three bytes at offset 42D94h (to avoid ImgpValidateImageHash)
- Two bytes in the file header to correct the PE checksum
- Ntoskrnl.exe is also patched and saved under another random name (sei2f4v4g9.exe). To override the winload default selection of the kernel, the kernel option was set to point to the new filename.
In my test, three symbols for module ntoskrnl.exe were affected:
- nt!MiValidateSectionCreate (to bypass the return of the nt!SeValidateImageHeader call)
And finally, a single test with GMER alerting about numerous SSDT hooks proves that PatchGuard has been bypassed. (The following screen, from another test, shows the patched ntoskrnl.exe as 17h1kwrl4t.exe.)
Malware developers found ways to bypass PatchGuard for Windows 7, and now with this program we can see it is also possible to automate the job under Windows 8. Unfortunately, I am sure this process will be used in future malicious threats.