Shade BIOS: Unleashing the Full Stealth of UEFI Malware

Shade BIOS: Unleashing the Full Stealth of UEFI Malware

Speaker: Kazuki Matsuo, Security Researcher, FFR Security (Japan)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=t17YEHymwE4

Reading Time: ~8 minutes

Type: Briefing

TL;DR

Kazuki Matsuo of FFR Security introduced ShadeBIOS, a research framework that retains UEFI BIOS in memory after the operating system boots and repurposes UEFI's own memory management, device drivers, and protocol stack to execute malicious behaviors entirely outside the OS security stack — bypassing antivirus, Windows Defender Firewall, and kernel-level detection by never touching OS APIs or driver interfaces.

Introduction

UEFI BIOS malware occupies a privileged position in the threat landscape: it runs before the operating system, can survive disk wipes and OS reinstallations, and operates at a layer that most endpoint security tools cannot observe. Yet in practice, all known UEFI bootkits in the wild — roughly nine total as of this talk — ultimately descend into userland or the kernel to perform their malicious work. This OS dependency is not an oversight; it reflects a genuine technical constraint that has limited UEFI malware's "pure BIOS" potential for years.

Kazuki Matsuo, a UEFI security researcher at FFR Security in Japan, set out to resolve that constraint. His research question was straightforward: if BIOS is the most privileged layer, why does every UEFI implant eventually have to use the OS? His answer, presented at Black Hat 2025, was ShadeBIOS — a proof-of-concept that demonstrates how an attacker can turn UEFI's own infrastructure into a hidden runtime OS, achieving command-and-control communications and sensitive data exfiltration without invoking a single OS API or driver.

The Dilemma at the Heart of UEFI Malware

▶ Watch: The OS and Hardware Dependency Dilemma (02:00)

Existing UEFI bootkits such as ESPectre disable protections like PatchGuard and then operate in the kernel. They are still vulnerable to detection by antivirus kernel drivers, and they require constant updates as OS internals change — pattern matching and hooking against specific kernel and bootloader image versions must be refreshed with every OS update.

The alternative — implementing all malicious behavior purely within BIOS code — runs into a different wall: hardware dependency. BIOS code that wants to communicate over a network interface must directly read and write hardware registers. The exact register layout depends on the specific NIC model. Real-world examples illustrate the problem: the "DailyBounce" BIOS implant (from leaked intelligence documents) worked only on Dell PowerEdge servers; "Iron Chef" targeted only specific HP ProLiant configurations. SMM backdoors in academic research directly access USB host controller registers — which only works for USB and fails completely for other input device types.

Most existing pure-BIOS malware was implemented as SMM (System Management Mode) modules, exploiting SMM's ring-minus-two position to access arbitrary physical memory. That avenue has been substantially closed by SMM isolation, introduced on modern Intel platforms. Under SMM isolation, all non-Intel SMM modules run at SMM ring 3, preventing them from mapping OS memory pages or accessing I/O without the security monitor's approval.

The fundamental dilemma: OS-dependent bootkits risk detection; hardware-dependent pure-BIOS implants are too narrow to deploy broadly. ShadeBIOS is designed to escape both constraints.

The ShadeBIOS Insight: BIOS as an OS

▶ Watch: The ShadeBIOS Concept (10:05)

Matsuo observed that UEFI BIOS already functions as a small operating system: it has its own memory allocator, its own device drivers structured around the UEFI Driver Model, its own protocol stack (HTTP, disk I/O, USB, network), and its own event management system. These capabilities exist during boot time but are conventionally destroyed when the OS loader calls ExitBootServices.

The ShadeBIOS approach is to prevent that destruction, retaining the BIOS environment in memory through the OS boot and making it usable at runtime. This yields three benefits unavailable to any existing UEFI implant:

1. OS independence: Malicious behaviors use UEFI drivers rather than OS APIs, making them invisible to antivirus, EDR, and kernel monitoring.
2. Hardware independence: Because UEFI protocols (HTTP, disk I/O, etc.) abstract the hardware, the same malware code runs unchanged across different network cards and storage controllers.
3. Implementation simplicity: No need to write custom device driver stacks or hand-code register sequences — the attacker reuses UEFI's existing, well-tested protocol implementations.

ShadeBIOS is implemented as a runtime DXE (Driver Execution Environment) module, not an SMM module. Runtime DXE modules are mapped into the high canonical virtual address space alongside kernel drivers and remain active throughout the OS lifetime. They are exempt from the SMM isolation protections that neutralize SMM backdoors on modern hardware.

Technical Implementation: Retaining BIOS Through OS Boot

▶ Watch: Memory Map Manipulation and Retention (12:05)

UEFI manages memory as a doubly linked list of EFI_MEMORY_DESCRIPTOR structures, each tagged with an EFI_MEMORY_TYPE indicating whether the region is available after OS boot. Boot-services memory types (EfiBootServicesCode, EfiBootServicesData) are conventionally reclaimed by the OS loader. Runtime memory types (EfiRuntimeServicesCode, EfiRuntimeServicesData) are preserved.

ShadeBIOS hooks GetMemoryMap (a UEFI Boot Service) and modifies the copy of the memory map returned to the OS loader, reclassifying boot-services regions containing UEFI drivers and protocols as runtime-services memory. The OS loader then preserves those regions rather than overwriting them. A portion of conventional memory is similarly hidden from the OS loader and reserved exclusively for BIOS's runtime memory allocator.

With regions retained, five additional engineering problems must be solved for the retained code to function:

1. Memory virtualization: Retained modules reference physical addresses, but the OS enables paging with virtual addressing. ShadeBIOS uses partial identity mapping (a technique Matsuo presented at Black Hat 2024) to ensure physical and virtual addresses coincide for BIOS memory regions.
2. Boot-time-only resources: Certain EFI system table members and boot services pointers are freed after ExitBootServices. ShadeBIOS copies them during boot time and resolves them at runtime.
3. UEFI variable access: Non-runtime UEFI variables become inaccessible post-boot. ShadeBIOS hooks SetVariable to create copies of needed variables with runtime attributes added.
4. Device reinitialization: OS device drivers overwrite hardware controller registers (e.g., the Command Ring Register in a USB host controller) when they initialize devices for OS use, invalidating the BIOS's device state. ShadeBIOS calls DisconnectController and ConnectController Boot Services to reset and reinitialize devices for BIOS use before performing malicious operations, then relies on the OS drivers to self-repair — network connectivity recovers in under approximately three minutes after ShadeBIOS releases the interface.
5. Exclusive control: ShadeBIOS must prevent OS interrupt handlers from interfering during operations. Rather than using CLI/STI instructions (which are unreliable because UEFI code already contains them), ShadeBIOS uses the x86 Control Register (CR) and Task Priority Register (TPR) to block OS interrupts. Since UEFI drivers use polling rather than interrupts, most protocols work without changes; timer events are emulated by manually signaling the doubly linked list of IEvent structures.

Demo: Bypassing Windows Defender Firewall

▶ Watch: ShadeBIOS Demo — Bypassing OS Security (28:12)

The demonstration compared a legitimate kernel driver with ShadeBIOS across two scenarios, using a C2 server listening on port 3003.

First, the kernel driver successfully connected and sent process memory data to the C2 server. Then the Windows Defender Firewall was configured to block port 3003. On reload, the kernel driver returned NT_STATUS_ACCESS_DENIED — firewall blocked, C2 communication failed.

ShadeBIOS was then triggered (using a small client program for demo timing purposes, not required in actual use). With port 3003 still blocked at the Windows Defender Firewall level, ShadeBIOS successfully exfiltrated the same process memory data to the C2 server. The firewall rule had no effect — ShadeBIOS communicates via UEFI's HTTP protocol stack, which bypasses the OS network stack entirely, including all firewall and EDR network interception layers.

Detection and Defense

▶ Watch: Detection Methods and Future Work (32:15)

Because ShadeBIOS operates outside OS security mechanisms, it cannot be observed or blocked at runtime by antivirus or EDR products. Detection requires preventive inspection:

• Runtime DXE module dumping: ShadeBIOS is mapped into kernel memory as a runtime DXE module. The open-source tool Chipsec (or a similar tool written by Satoshi Tanda) can dump runtime DXE modules from kernel memory for static analysis. The demo showed this approach successfully identifying a ShadeBIOS module by searching string content in the dumped binary.
• Side-effect monitoring: ShadeBIOS's device control handoff causes brief inaccessibility — a few minutes of network interruption each time it operates. Anomaly detection on unexpected interface drops could flag activity.

For broader defense against pure-BIOS malware:

• SMM isolation should be enabled on all modern platforms to neutralize SMM-based implants.
• Memory forensics targeting the kernel memory's high canonical address region can detect runtime DXE modules not attributable to known-good UEFI firmware.
• Government procurement systems in particular should perform preventive inspection of firmware before deployment, as supply-chain insertion of BIOS backdoors is specifically mentioned in documents from intelligence community leaks (Vault 7 and others) as a known-capable technique.

Notable Quotes

"It is said that if attackers took over the BIOS, they basically can do anything. But actually, this dilemma is restricting what BIOS malware can do."

— Kazuki Matsuo, ▶ 08:00

"UEFI BIOS can actually be seen as a small OS because it has its own memory management and device drivers. And moreover, its size is reasonable."

— Kazuki Matsuo, ▶ 10:05

"ShadeBIOS will use the retained UEFI drivers instead of the OS device drivers, so it is completely independent from OS detection and antivirus detection."

— Kazuki Matsuo, ▶ 26:09

"As you can see, there are no direct access to I/O, no direct read/writing registers. It just uses the abstracted interfaces such as UEFI boot services or UEFI protocols. Therefore, it works on a different machine with the same code."

— Kazuki Matsuo, ▶ 28:12

Key Takeaways

• ShadeBIOS breaks both OS and hardware dependency simultaneously, the two constraints that have historically limited UEFI malware to either detectable kernel operations or narrow, device-specific implants.
• The technique hooks GetMemoryMap to reclassify UEFI boot-services memory regions as runtime memory, preserving the entire UEFI driver infrastructure — HTTP stack, disk I/O, network protocols — through the OS boot process.
• Malicious C2 communication via ShadeBIOS bypasses Windows Defender Firewall completely because the traffic originates from the UEFI HTTP protocol stack rather than the OS network stack, which no OS-level firewall or EDR can inspect.
• Runtime DXE modules are the implementation vehicle, and they are more privileged than SMM modules on systems with SMM isolation enabled — meaning the primary defense against SMM exploits does not protect against this class of attack.
• Detection requires offline or boot-time memory forensics using tools like the runtime DXE dumper demonstrated; behavioral detection at runtime is fundamentally ineffective because ShadeBIOS never invokes OS APIs.

Slides: No slide PDF was available for this talk.