Note: This project is incomplete and work is in progress (W.I.P).
While it's possible to use this for advanced adversary simulation or emulation (red teaming), it's unlikely to be used in most engagements. This tool can also be used for game hacking and is a side project for those interested in fun, learning, malware research, and spreading security awareness. It also demonstrates that Rust can handle both low-level and high-level tasks. One important capability of this tool is its ability to load a kernel driver before the operating system, or even execute shellcode in the kernel to bypass Windows security protections. It's important to recognize the potential of Rust and not underestimate its power.
Feel free to check out my Windows Kernel Rootkit and Blue Pill Hypervisor in pure Rust:
This project is mostly inspired by:
-
Secret Club's article on Bootkitting Windows Sandbox by mrexodia
-
bootlicker by Austin Hudson (realoriginal / ilove2pwn_ / secidiot / mumbai)
TODO
A kernel driver can be loaded during boot using a bootkit. A bootkit can run code before the operating system and potentially inject malicious code into the kernel or load a malicious kernel driver by infecting the boot process and taking over the system's firmware or bootloader.
The image below shows how Legacy and UEFI boot works.
Figure 1. Comparison of the Legacy Boot flow (left) and UEFI boot flow (right) on Windows (Vista and newer) systems (Full Credits: WeLiveSecurity)
-
There are a few ways to achieve the same objective as shown below:
-
Hook/detour
Archpx64TransferTo64BitApplicationAsm
inbootmgfw.efi
(Windows OS loader), which transfers execution to the OS loader (winload.efi
) or -
ImgArchStartBootApplication
to catch the moment when the Windows OS loader (winload.efi
) is loaded in the memory but still has not been executed or -
Hook/Detour
ExitBootServices
, which is UEFI firmware service that signals the end of the boot process and transitions the system from the firmware environment to the operating system environment.1.1. The following is required if UEFI Secure Boot is enabled:
- Patch
BmFwVerifySelfIntegrity
to bypass self integrity checks. - Execute
bcdedit /set {bootmgr} nointegritychecks on
to skip the integrity checks. - Inject
bcdedit /set {bootmgr} nointegritychecks on
option dynamically by modifying theLoadOptions
.
1.2. The following is required to allocate an additional memory buffer for the malicious kernel driver, because as a UEFI Application it will be unloaded from memory after returning from its entry point function.
BlImgAllocateImageBuffer
orBlMmAllocateVirtualPages
in the Windows OS loader (winload.efi
).
- Patch
-
-
Hook/detour
OslArchTransferToKernel
inwinload.efi
(Windows OS loader), which transfers execution to the Windows Kernel (ntoskrnl.exe
) to catch the moment when the OS kernel and some of the system drivers are already loaded in the memory, but still not been executed, which is a perfect moment to perform more in-memory patching.- Patch
SepInitializeCodeIntegrity
, a parameter toCiInitialize
inntoskrnl.exe
to disable Driver Signature Enforcement (DSE). - Patch
KeInitAmd64SpecificState
inntoskrnl.exe
to disable PatchGuard.
- Patch
The UEFI Bootkit works under one or more of the following conditions:
a) Turn off secure boot
b) Install your own secure boot keys and keep secure boot on
c) Bring your vulnerable binary (BYOVB) that is not in the "deny list" to exploit a 1-day and bypass secure boot.
d) Exploit a 0-day to bypass secure boot.
Typically UEFI Bootkits infect the Windows Boot Manager bootmgfw.efi
located in EFI partition \EFI\Microsoft\Boot\bootmgfw.efi
or C:\Windows\Boot\EFI\bootmgfw.efi
as shown below:
- Convert our bootkit to shellcode
- Find
bootmgfw.efi
(Windows Boot Manager) - Add
.efi
section tobootmgfw.efi
(Windows Boot Manager) - Inject/copy bootkit shellcode to the
.efi
section inbootmgfw.efi
- Change entry point of the
bootmgfw.efi
(Windows Boot Manager) to.efi
bootkit shellcode - Reboot
- Compile the project
cargo build --target x86_64-unknown-uefi
Download EDK2 efi shell or UEFI-Shell and follow these steps:
-
Extract downloaded efi shell and rename file
Shell.efi
(should be in folderUefiShell/X64
) tobootx64.efi
-
Format some USB drive to FAT32
-
Create following folder structure:
USB:.
│ bootkit.efi
│
└───EFI
└───Boot
bootx64.efi
-
Boot from the USB drive
-
VMware Workstation:
VM -> Settings -> Hardware -> Add -> Hard Disk -> Next -> SCSI or NVMe (Recommended) -> Next -> Use a physical disk (for advanced users) -> Next -> Device: PhysicalDrive1 and Usage: Use entire disk -> Next -> Finish.
-
Start VM by clicking
Power On to Firmware
-
Select Internal Shell (Unsupported option) or EFI Vmware Virtual SCSI Hard Drive (1.0)
-
-
An UEFI shell should start, change directory to your USB (
FS1
should be the USB since we are booting from it) and list files:
FS1:
ls
- You should see file
bootkit.efi
, if you do, load it:
bootkit.efi
- Now you should see output from the bootkit.efi application. If it is successful, Windows should boot automatically otherwise, exit and boot into Windows (change to Windows boot media - usually
FS0
- and run\EFI\Microsoft\Boot\bootmgfw.efi
or\EFI\Boot\bootx64.efi
)
Special thanks to btbd, ajkhoury, Mattiwatti, mrexodia, SamuelTulach, realoriginal, Cr4sh, matrosov, not-matthias and welivesecurity
-
https://secret.club/2022/08/29/bootkitting-windows-sandbox.html
-
https://github.com/Cr4sh/s6_pcie_microblaze/tree/master/python/payloads/DmaBackdoorBoot
-
Rootkits and Bootkits: https://nostarch.com/rootkits by Alex Matrosov
-
https://www.welivesecurity.com/2021/10/05/uefi-threats-moving-esp-introducing-especter-bootkit/
-
https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/
-
https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/
-
https://securelist.com/cosmicstrand-uefi-firmware-rootkit/106973/