Shade BIOS: Unleashing the Full Stealth of UEFI Malware

## Overview

In the presentation **"Shade BIOS: Unleashing the Full Stealth of UEFI Malware,"** researcher Kazuki Matsuo from FFRI Security explores how attackers can achieve complete stealth at the firmware layer without relying on post-boot operating system hooks or device-specific hardware drivers. While infecting BIOS is often considered overkill for general corporate targeting, Matsuo highlights its critical importance in national security and cloud infrastructure. In national security contexts, firmware backdoors offer stealth across diverse hardware vendors and survive before OS deployment. In cloud platforms, BIOS executes earlier than hypervisors and holds the inherent privilege to compromise both the host virtualization layer and all hosted virtual machines.

---

## Limitations of Existing UEFI Malware: The Dilemma

Matsuo identifies around nine existing in-the-wild UEFI bootkits (e.g., LoJax, Cosmic Strand) alongside leaked backdoors (e.g., Vector EDK, Dirty Bounce, Iron Chef). Current firmware implants suffer from a fundamental trade-off between **OS dependency** and **hardware dependency**:

- **OS Dependency:** Although bootkits modify bootloaders or kernel images to disable safeguards (such as LoJax disabling Driver Signature Enforcement or Cosmic Strand disabling PatchGuard), they execute their core malicious payloads within the kernel or userland. Because they rely on kernel hooks and pattern matching, they must be updated whenever the OS changes and risk detection by OS-level antivirus kernel drivers. - **Hardware/Device Dependency:** The secrets and sensitive data attackers seek only exist at OS runtime. However, UEFI destroys boot environments (boot services, disk I/O, network protocols) during OS handoff. Implementing runtime actions directly within firmware historically forced attackers to write custom, low-level hardware register drivers. Consequently, leaked tools like Dirty Bounce exclusively targeted Dell PowerEdge servers, while Iron Chef only supported specific HP ProLiant versions. - **SMM Deprecation and Isolation:** Previous firmware research relied heavily on System Management Mode (SMM / "Ring -2"). Under modern SMM isolation mechanisms (such as Intel's SMM ring separation and paging), untrusted or third-party SMM modules run in SMM Ring 3. These modules lack direct access to OS physical memory (triggering page faults) and have I/O filtered by an SMM Ring 0 security monitor. In contrast, Runtime DXE modules remain mapped into high canonical virtual memory alongside kernel drivers, retaining full access to OS memory and I/O.

---

## Shade BIOS: Retaining Boot-Time Firmware in Runtime

Because UEFI firmware inherently functions as a lightweight operating system equipped with device drivers and memory management, Matsuo developed **Shade BIOS**. The framework retains UEFI boot components in memory during runtime, enabling firmware implants to leverage standard UEFI boot services, protocols, and drivers without OS visibility or custom hardware driver stacks.

Shade BIOS operates via two core mechanisms:

1. **Retaining BIOS Memory:** - UEFI memory map structures are tracked in a doubly linked list. The OS loader invokes the `GetMemoryMap` boot service to locate disposable memory regions (`EfiBootServicesCode` and `EfiBootServicesData`). - Shade BIOS hooks `GetMemoryMap` and alters the reported type of these regions to `EfiRuntimeServicesCode` and `EfiRuntimeServicesData`. As a result, the OS loader preserves UEFI drivers and protocols in memory without reclaiming them.

2. **Resolving Runtime Execution Challenges:** - **Runtime Memory Management:** To prevent the BIOS memory allocator from allocating memory out of `EfiConventionalMemory` actively used by the OS, Shade BIOS hooks `GetMemoryMap` to mark a segment of conventional memory as runtime services data for BIOS use. It then unlinks the OS-assigned conventional memory chunks from the actual internal memory map so the BIOS allocator only assigns dedicated pages. - **Memory Virtualization:** Retained modules execute assuming physical memory addressing and contain hardcoded physical pointers. Shade BIOS resolves this using a partial identity mapping paging scheme. - **Boot-Time Only Resources:** Pointers inside UEFI System Tables and Boot Services that are freed upon OS handoff are backed up during boot and restored at runtime. - **UEFI Variables:** Retained code frequently attempts to access boot-time variables that lack runtime attributes. Shade BIOS hooks `SetVariable` during boot to duplicate these variables with runtime access flags added. - **Hardware Controller Conflicts:** OS device drivers reinitialize hardware registers (e.g., overwriting the USB Host Controller's CRC register to point to the OS command ring instead of the UEFI command ring). Shade BIOS addresses this by executing UEFI driver re-initialization routines without embedding device-specific code.