Skip to content
This repository has been archived by the owner on Mar 2, 2024. It is now read-only.

Latest commit

 

History

History
348 lines (205 loc) · 15 KB

README.md

File metadata and controls

348 lines (205 loc) · 15 KB
Raw

Windows UEFI Bootkit in Rust (Codename: RedLotus)

Introducing a Windows UEFI Bootkit in Rust designed to facilitate the manual mapping of a driver manual mapper before the kernel (ntoskrnl.exe) is loaded, effectively bypassing Driver Signature Enforcement (DSE). This bootkit utilizes a UEFI runtime driver (EFI_RUNTIME_DRIVER) inspired by the work of umap by @btbd. By employing a straightforward .data function pointer hook, the driver manual mapper enables the manual mapping of various Windows kernel drivers via a user-mode program. It is important to acknowledge that the communication method involving xKdEnumerateDebuggingDevices and NtConvertBetweenAuxiliaryCounterAndPerformanceCounter, originally shared by the legendary @can1357, may be flagged by anti-cheat systems. Hence, it is crucial to emphasize that this project serves as a Proof of Concept (PoC).

It is possible to manually map my Windows kernel rootkit or Windows blue-pill hypervisor with minor modifications.

This project is inspired by the following:

Description

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, effectively disabling or bypassing security protections. This tool can 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. It's important to recognize the potential of Rust and not underestimate its power.

The image below shows how Legacy and UEFI boot works.

Legacy-and-UEFI-Boot Figure 1. Comparison of the Legacy Boot flow (left) and UEFI boot flow (right) on Windows (Vista and newer) systems (Full Credits: WeLiveSecurity)

This diagram illustrates the structure and flow of the redlotus.efi UEFI bootkit and redlotus.sys Windows kernel driver manual mapper.

redlotus.drawio.png

Install

Install Rust

To start using Rust, download the installer, then run the program and follow the onscreen instructions. You may need to install the Visual Studio C++ Build tools when prompted to do so.

Install and change to Rust nightly

rustup toolchain install nightly
rustup default nightly

Install cargo-make

cargo install cargo-make

Install WDK/SDK

  • Step 1: Install Visual Studio 2022
  • Step 2: Install Windows 11, version 22H2 SDK
  • Step 3: Install Windows 11, version 22H2 WDK

Build

Change directory to .\driver\ and build driver

cargo make sign

Change directory to .\bootkit\ and build bootkit

cargo build --target x86_64-unknown-uefi --release

Change directory to .\client\ and build client

cargo build --release

Debugging (Optional)

1. Enabling Test Mode or Test Signing Mode

To enable Test Mode or Test Signing Mode, open an elevated command prompt and enter the following command:

bcdedit /set testsigning on

2. Enabling Debugging of Windows Boot Manager (bootmgfw.efi), Windows OS Boot Loader (winload.efi), and Windows Kernel (ntoskrnl.exe)

The commands below enable debugging for the Windows Boot Manager, the boot loader, and the operating system's kernel. Using this combination allows for debugging at every startup stage. If activated, the target computer will break into the debugger three times: when the Windows Boot Manager loads, when the boot loader loads, and when the operating system starts. Enter the following commands in an elevated command prompt:

bcdedit /bootdebug {bootmgr} on
bcdedit /bootdebug on
bcdedit /debug on

3. Setting Up Network Debugging for Windbg

To set up network debugging, open an elevated command prompt and enter the command below. Replace w.x.y.z with the IP address of the host computer and n with your chosen port number:

bcdedit /dbgsettings net hostip:w.x.y.z port:n

4. Setting Up Debug Print Filter

Open the Windows registry editor by entering the following command in an elevated command prompt:

regedit

For more focused and efficient kernel development troubleshooting, set up filters to selectively display debugging messages by following these steps:

  1. Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
  1. Create a new key named Debug Print Filter.
  2. Inside this key, create a new DWORD (32) Value.
  3. Name it DEFAULT.
  4. Set its Value data to 8.

Usage

A UEFI Bootkit works under one or more of the following conditions:

  • Secure Boot is disabled on the machine, so no vulnerabilities are required to exploit it (supported by this project).

  • Exploiting a known flaw in the UEFI firmware to disable Secure Boot in the case of an out-of-date firmware version or a product no longer supported, including the Bring Your Own Vulnerable Binary (BYOVB) technique to bring copies of vulnerable binaries to the machines to exploit a vulnerability or vulnerabilities and bypass Secure Boot on up-to-date UEFI systems (1-day/one-day).

  • Exploiting an unspecified flaw in the UEFI firmware to disable Secure Boot (0-day/zero-day vulnerability).

Usage 1: Infecting the Windows Boot Manager (bootmgfw.efi) on Disk (Unsupported)

UEFI Bootkits typically target the Windows Boot Manager (bootmgfw.efi) found in the EFI partition at \EFI\Microsoft\Boot\bootmgfw.efi (also accessible at C:\Windows\Boot\EFI\bootmgfw.efi). The infection process involves adding a new section named .efi to the bootmgfw.efi and redirecting the executable's entry point to this new section. Here's a step-by-step breakdown:

  1. Convert the bootkit into position-independent code (PIC) or shellcode.
  2. Locate bootmgfw.efi (Windows Boot Manager) in the EFI partition at \EFI\Microsoft\Boot\bootmgfw.efi.
  3. Append a new .efi section to the bootmgfw.efi.
  4. Inject or copy the bootkit shellcode into the newly added .efi section.
  5. Modify the entry point of bootmgfw.efi to point to the shellcode in the .efi section.
  6. Reboot the system.

Note: This method is unsupported.

Usage 2: Running a UEFI Bootkit through the UEFI Shell (Supported)

The following outlines a supported method to execute a UEFI Bootkit using the UEFI Shell. By leveraging either the EDK2 efi shell or the UEFI-Shell, users can set up a USB drive to boot into a UEFI shell environment. From there, the bootkit can be loaded and executed directly. The steps also include specific instructions for users working with VMware Workstation.

Download EDK2 efi shell or UEFI-Shell and follow these steps:

  1. Extract downloaded efi shell and rename file Shell.efi (should be in folder UefiShell/X64) to bootx64.efi

  2. Format USB drive to FAT32

  3. Create following folder structure:

USB:.
 │   redlotus.efi
 │
 └───EFI
      └───Boot
              bootx64.efi

  1. Boot from the USB drive

    4.1. The following is required for VMware Workstation:

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

  2. A UEFI shell should start, change directory to the same location as the Windows Boot Manager (e.g. FS0). Note that the file system could be different for your machine

FS0:
  1. Copy the bootkit to the same location as the Windows Boot Manager (e.g. FS0).
cp fs2:redlotus.efi fs0:
  1. Load the the bootkit
load redlotus.efi

  1. Windows should boot automatically.

  2. Manually map your Windows kernel driver using the user-mode application (client.exe) even with Driver Signature Enforcement (DSE) enabled.

PS C:\Users\developer\Desktop> .\client.exe -h
Manually Map Windows Kernel Driver

Usage: client.exe --path <PATH>

Options:
  -p, --path <PATH>  The Windows kernel driver path to be manually mapped
  -h, --help         Print help
  -V, --version      Print version

PoC

Tested on:

  • Microsoft Windows 10 Home 10.0.19045 N/A Build 19045
  • Microsoft Windows 11 Home 10.0.22621 N/A Build 22621

This image demonstrates the loading of the bootkit (redlotus.efi) from a UEFI Shell.

poc_uefi.png

This image depicts the successful manual mapping of the driver manual mapper (redlotus.sys).

poc_win11.png

This image showcases the successful manual mapping of a Windows kernel driver (testing123.sys), which could be written in any language such as C or Rust. It demonstrates the utilization of the user-mode application (client.exe) to communicate with the driver manual mapper (redlotus.sys).

poc_win11_driver_mapper.png

Please note that depending on your Windows build and version, you may need to adjust the signatures of the hooked bootmgfw.efi and winload.efi functions, as well as the .data function pointer signature in ntoskrnl.exe. These changes are necessary to ensure compatibility and proper functioning with your specific Windows build and version.

Credits / References / Thanks / Motivation