You've Already Been Hacked: What if There Is a Backdoor in Your UEFI OROM?

You've Already Been Hacked: What if There Is a Backdoor in Your UEFI OROM?

Speakers: Kazuki Matsuo, Security Researcher, FFRI Security

Conference: Black Hat USA

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

Overview

This talk, presented by Kazuki Matsuo, delves into the often-overlooked security implications of Option ROMs (OROMs) found on PCIe devices. The core premise is that these small, embedded firmware chips can serve as an exceptionally stealthy and powerful vector for sophisticated UEFI firmware backdoors. Matsuo investigates the capabilities of such backdoors, the advantages they offer to attackers, and the challenges in defending against them. The research highlights a critical blind spot in current firmware security practices, particularly concerning the supply chain integrity of hardware components.

The presentation underscores that while modern security efforts increasingly focus on the main SPI flash chip of the motherboard BIOS, OROMs remain largely unscrutinized. This lack of robust inspection tools and standardized defense mechanisms makes them an ideal location for persistent, low-level malware. By demonstrating three proof-of-concept OROM backdoors—targeting the UEFI layer, kernel layer, and userland respectively—Matsuo illustrates the escalating impact and stealth a compromise at this level can achieve, from simple data exfiltration during boot to full system control.

The significance of this research lies in its exposure of a potent, yet underexplored, attack surface. As organizations fortify higher-level operating system and application security, adversaries are increasingly shifting their focus to the firmware layer. A backdoor embedded within a device's OROM represents a "bottom-up infection" that can subvert the system before the operating system even loads, potentially bypassing Secure Boot and other integrity checks, and establishing an extremely resilient presence that is difficult to detect and remove.

Background

▶ Watch: Talk introduction: Backdooring PCIE Option ROMs (0:00)

To understand the threat posed by OROM backdoors, it's essential to grasp the fundamental concepts of system firmware and its boot process. The BIOS (Basic Input/Output System) is the initial firmware that initializes hardware components and prepares the system to load the operating system. Modern systems largely use UEFI (Unified Extensible Firmware Interface), a more advanced standard for system firmware that offers greater flexibility, modularity, and security features compared to legacy BIOS.

UEFI defines several boot phases, from power-on to OS handover. A critical phase is the DXE (Driver Execution Environment) phase, where most hardware devices are initialized and abstracted by DXE modules or DXE drivers. These modules create UEFI protocols to standardize access to devices; for instance, the Simple File System Protocol allows for disk access. While many DXE modules are unloaded before the OS boots, some, known as runtime DXE drivers, persist in memory throughout the OS runtime, maintaining device functionality.

Option ROMs (OROMs) are small memory chips physically located on PCIe (Peripheral Component Interconnect Express) devices such as network cards, storage controllers, and graphics cards. These OROMs contain DXE drivers specific to their respective devices, enabling the BIOS to initialize and utilize the hardware during the boot process. When a PCIe device with an OROM is plugged in, the UEFI firmware loads and executes the DXE modules from its OROM. While not all PCIe devices have OROMs, they are commonly found in essential components, making them ubiquitous in modern computing systems. The content and structure of OROMs differ between legacy BIOS and UEFI, with this research focusing exclusively on UEFI OROMs.

Prior research into firmware malware has predominantly focused on the main SPI flash chip that stores the system's UEFI BIOS. While tools exist to read and analyze SPI flash contents, and Endpoint Detection and Response (EDR) solutions are beginning to monitor this area, OROMs have remained relatively unexamined. Existing studies that mention OROMs typically use them for auxiliary purposes, such as ensuring persistence or serving as a temporary buffer for lateral movement, rather than as the primary infection vector. This means that the unique advantages of OROMs—their stealth, direct UEFI layer infection capabilities, and specific infection routes—have not been thoroughly investigated.

The primary infection route highlighted in this research is supply chain compromise. While users might trust their PC manufacturers regarding the integrity of the main BIOS SPI flash, a PC manufacturer typically procures numerous components from various device vendors. This creates a complex supply chain where a malicious device vendor could embed a backdoor directly into the OROM of their hardware before it ever reaches the PC assembler or end-user. Other potential infection vectors include third-party attackers writing malware to OROMs and selling compromised devices through online marketplaces, or more traditional methods involving user-mode installers or physical access (e.g., evil maid attacks).

Depending on the attacker's objectives, an OROM backdoor can infect the system at different layers, each offering a trade-off between capability and stealth:

• UEFI-only infection: Limited to operations during the boot phase (e.g., file I/O, simple network communications). Tasks must be fast to avoid suspicious boot delays. UEFI protocols are generally unloaded after the OS boots, limiting runtime persistence.
• Kernel-level infection: Allows for persistent network communications and more complex operations by hooking into kernel functions. This offers greater capability than UEFI-only but requires more sophistication to maintain stealth within the OS kernel.
• Userland infection: Provides the highest level of control, enabling attackers to perform virtually any action, including running shells and complex applications. However, this level of infection is the most detectable by conventional OS-level security solutions, making it the least stealthy. Most existing UEFI malware ultimately aims for userland infection.

Matsuo's research aims to fill the gap by focusing specifically on OROMs as a primary infection vector, exploring their distinct advantages and the challenges they pose to detection and defense.

Key Findings

▶ Watch: Key merits: Stealth and direct UEFI infection (3:20)

The research yielded several critical findings regarding the feasibility and impact of OROM-based UEFI backdoors:

1. Unparalleled Stealth: OROMs offer a significantly stealthier location for malware compared to the main SPI flash chip or traditional OS-level infection points (e.g., hard drives, SSDs). The primary reason for this stealth is the lack of versatile tools available to read and analyze OROM contents. While EDRs and specialized tools are emerging for SPI flash inspection, there are virtually no off-the-shelf solutions for OROMs, creating a vast blind spot for defenders. This makes OROM backdoors exceptionally difficult to detect and analyze post-compromise.

1. Powerful Bottom-Up Infection: Unlike most malware that relies on "top-down infection" (i.e., being installed from userland), OROM backdoors enable a "bottom-up infection." By residing in the firmware of a PCIe device, the malicious code can execute early in the boot process, directly infecting the UEFI layer without touching userland or even the kernel. This grants the attacker a foundational level of control, allowing them to subvert the system before the operating system or security solutions have fully initialized, potentially bypassing mechanisms like Secure Boot or Measured Boot depending on implementation.

1. Demonstrated Capabilities Across Layers: The research successfully implemented three proof-of-concept (PoC) OROM backdoors, illustrating a spectrum of malicious capabilities:

• UEFI-only Backdoor: Demonstrated the ability to perform significant actions purely within the UEFI environment. This includes reading and writing files (using Simple File System Protocol and File Protocol) and establishing simple network communications (using HTTP Protocol) during the boot phase. Examples include exfiltrating confidential files or encrypting data (ransomware) before the OS loads, or stealing application data via runtime DXE drivers and sending it on a subsequent boot.
• Kernel-level Backdoor: While not detailed in implementation, the talk outlined its capability to achieve persistent network connections during runtime by resolving kernel exports from ntoskrnl.exe and utilizing kernel network interfaces like WSK (Winsock Kernel) and TDI (Transport Driver Interface), which interact with AFD.sys. This allows for more sustained command and control.
• Userland-level Backdoor: This PoC demonstrated that OROMs could facilitate full userland compromise, enabling complex functions like shells. While offering the highest level of control, this method sacrifices some stealth compared to purely UEFI-level operations.

1. Significant Supply Chain Risk: The research emphasizes that OROM backdoors present a severe supply chain security risk. Since PC manufacturers assemble systems from components procured from various device vendors, trusting the PC manufacturer does not guarantee the integrity of all device OROMs. An attacker could compromise a device vendor to embed backdoors at the manufacturing stage, introducing them into countless systems before they reach the end-user.

In essence, OROMs represent a highly attractive target for sophisticated attackers seeking persistent, stealthy, and low-level control over target systems, largely due to the current lack of detection and defense mechanisms specifically tailored to this firmware vector.

Technical Deep Dive

▶ Watch: How OROM backdoors are inserted (supply chain) (4:30)

The technical core of this research revolves around leveraging the unique execution context and protocols available within the UEFI environment to implement malicious functionality. The speaker detailed the UEFI-only OROM backdoor extensively, outlining its functions and limitations.

The most critical functions for any backdoor are communication with an attacker and data manipulation. For the UEFI-only backdoor, these are realized through:

1. Network Communication via HTTP Protocol:

• The HTTP Protocol within UEFI is primarily designed for HTTP Boot, allowing systems to boot from network resources.
• Crucially, this protocol is often disabled by default in UEFI firmware. An OROM backdoor would first need to modify specific UEFI variables to enable it. This modification itself could be a detection point if these variables are monitored for unauthorized changes.
• Once enabled, the backdoor can initiate HTTP requests to a command and control (C2) server during the boot process. This allows for exfiltration of data or reception of commands.
• A significant limitation is that most UEFI protocols, including HTTP Protocol, are unloaded from memory after the OS boots up. This means that UEFI-only backdoors can only perform network communications during the relatively brief boot phase. Therefore, any tasks requiring persistent network connections or time-consuming operations are not feasible for a purely UEFI-level backdoor without further escalation.

1. File System Access via Simple File System Protocol and File Protocol:

• To interact with files, the backdoor leverages standard UEFI protocols such as the Simple File System Protocol and the File Protocol. These protocols provide basic file system operations (reading, writing, enumerating files) within the UEFI environment.
• This capability allows the backdoor to steal confidential files directly from the system's storage during boot.
• Conversely, it also enables receiving data, such as encryption keys or commands, and performing actions like encrypting files (acting as ransomware) at a time specified by the attacker, all before the OS fully loads.

The talk also touched upon the concept of runtime DXE drivers within OROMs. These drivers can persist in memory even after the OS boots. This persistence opens up additional attack avenues for UEFI-only backdoors:

• Application Data Exfiltration: A runtime DXE driver could search the system's virtual memory to locate and steal sensitive application data. Since direct network communication might not be possible after OS boot, this data could be staged and then sent to the C2 server during the next system boot via the HTTP Protocol.

For backdoors requiring more persistent and complex capabilities, the research outlined escalation paths:

• Kernel-level OROM Backdoor:
• The goal here is to establish persistent network connections during runtime, which is beyond the scope of UEFI protocols post-boot.
• This is achieved by infecting the kernel, specifically targeting Windows. The backdoor would first need to find the base address of ntoskrnl.exe (the Windows kernel) in memory.
• Once the kernel's base address is known, the backdoor would parse its PE (Portable Executable) headers to resolve the addresses of kernel exports. These exports are functions provided by the kernel that other drivers or modules can use.
• By hooking or calling these kernel exports, the backdoor can gain access to kernel-level functionalities, including network communication interfaces like WSK (Winsock Kernel) and TDI (Transport Driver Interface). These interfaces typically involve IOCTLs (Input/Output Control codes) to AFD.sys, the Ancillary Function Driver for WinSock.
• A challenge with this approach is that directly accessing network cards from the PCIe tree using only UEFI modules would make the backdoor highly hardware-specific. Leveraging kernel exports provides a more generalized and stable approach for network communication.

• Userland-level OROM Backdoor:
• This represents the highest level of infection, where the OROM backdoor ultimately injects malicious code or components into the userland of the operating system.
• While the talk didn't detail the technical implementation, it noted that this type of backdoor can basically "do anything," including spawning shells or running complex applications.
• However, this increased capability comes at the cost of stealth. Userland malware is generally more susceptible to detection by conventional EDRs, antivirus software, and other OS-level security solutions. This is the realm where most existing UEFI malware ultimately aims to operate.

The core technical takeaway is that OROMs provide a platform for executing code very early in the boot process, allowing attackers to choose their desired level of compromise—from stealthy, boot-time UEFI manipulation to full, persistent OS-level control—with corresponding trade-offs in capability and detectability.

Demo / Proof of Concept

▶ Watch: Deep dive into UEFI-only OROM backdoors (7:50)

The presentation included a clear demonstration of the UEFI-only OROM backdoor, illustrating its immediate and stealthy capabilities during the system's boot sequence.

The demonstration showcased the following:

• Objective: To exfiltrate confidential file contents from the target machine.
• Mechanism: The malicious code, embedded within the OROM of a PCIe device, executes during the UEFI DXE phase. It leverages the UEFI HTTP Protocol to establish a network connection.
• Execution Timeline: The critical aspect of the demo was that the file contents were successfully sent to the attacker's command and control (C2) server before the operating system even began to load. The speaker explicitly pointed out the log of the BIOS and OS boot, highlighting that the data transmission occurred prior to the OS taking over.
• Setup: A separate laptop was configured to act as the C2 server, receiving the exfiltrated data.
• Result: The demo successfully showed the file contents appearing on the C2 server, proving that data can be stolen in a highly stealthy manner during the boot process, bypassing any OS-level security measures that have yet to initialize.

While the talk mentioned the implementation of three proof-of-concept OROM backdoors (UEFI-only, kernel-level, and userland-level), the detailed demonstration focused specifically on the UEFI-only variant. This choice effectively highlighted the unique stealth and impact achievable purely within the UEFI environment, without resorting to more complex kernel or userland escalation, thereby emphasizing the foundational threat posed by OROM compromise. The demo served as a powerful illustration of the "bottom-up infection" capability and the merits of OROMs as a stealthy malware location.

Defensive Implications

▶ Watch: Demo: UEFI-only backdoor exfiltrating data during boot (10:00)

The insights from this research reveal significant vulnerabilities in current cybersecurity postures, necessitating a re-evaluation of firmware security strategies. Defenders must consider the following implications:

1. Enhanced Supply Chain Scrutiny: The most critical defensive implication arises from the supply chain attack vector. Organizations must implement rigorous security audits and trust verification processes for all hardware components, especially PCIe devices, procured from third-party vendors. This includes demanding evidence of firmware integrity and secure development practices from device manufacturers. Relying solely on the trustworthiness of the PC assembler is insufficient.

1. Development of OROM Inspection Tools: A major finding was the "lack of versatile ways to read OROM contents." This represents a significant blind spot. The security community and hardware vendors must prioritize the development of open-source or commercial tools capable of dumping, parsing, and analyzing OROM firmware images from PCIe devices. This would enable security researchers and enterprises to scan for known malicious patterns or unauthorized modifications.

1. Strengthening Firmware Integrity Measures:

• Secure Boot: While Secure Boot helps ensure that only cryptographically signed firmware and OS loaders execute, an OROM backdoor might operate before some Secure Boot checks are fully enforced or could potentially tamper with the Secure Boot configuration itself. Implementations of Secure Boot need to be robust enough to validate the integrity of all loaded OROMs.
• Measured Boot and Remote Attestation: Measured Boot involves logging cryptographic hashes of critical boot components into the TPM (Trusted Platform Module). These measurements can then be verified remotely via attestation. Extending Measured Boot to include all loaded OROMs would provide a baseline for detecting tampering. Organizations should leverage remote attestation to verify the integrity of the entire boot chain, including PCIe device firmware, before granting access to sensitive resources.

1. Monitoring of UEFI Variables and Protocols: Backdoors leveraging UEFI protocols, such as the HTTP Protocol, often require enabling them by modifying UEFI variables. Monitoring changes to critical UEFI variables (e.g., those related to network boot, boot order, or security settings) can serve as an early warning sign of compromise. Disabling unnecessary UEFI protocols by default can also reduce the attack surface.

1. Runtime DXE Driver Monitoring: The ability of OROMs to contain runtime DXE drivers that persist after OS boot opens avenues for persistent data theft. Security solutions, particularly EDRs, need to extend their monitoring capabilities to track the behavior and integrity of runtime DXE drivers, looking for anomalous network activity, memory access patterns, or file system interactions originating from these low-level components.

1. Hardware-Level Security: Consider implementing hardware-level security features provided by chipsets (e.g., Intel Boot Guard, AMD Secure Processor) which aim to establish a hardware root of trust. These technologies can help ensure that the initial stages of firmware execution are protected, potentially extending to the validation of OROMs.

1. Awareness and Training: Security teams and IT professionals need to be educated about the threat posed by firmware-level attacks, particularly those exploiting OROMs. Understanding these attack vectors is the first step towards developing effective defense strategies.

In summary, the research highlights that focusing solely on OS-level or even main BIOS SPI flash security is no longer sufficient. The threat landscape demands a holistic approach that extends deep into the hardware supply chain and the firmware of peripheral devices.

Key Takeaways

• OROMs are a Stealthy and Powerful Attack Vector: PCIe device Option ROMs (OROMs) are a highly stealthy and effective location for UEFI firmware backdoors, largely due to the current lack of dedicated inspection tools.
• Bottom-Up Infection Bypasses OS Defenses: OROM backdoors enable "bottom-up" infection, allowing malicious code to execute and compromise the system directly at the UEFI layer, often before the operating system and higher-level security solutions are initialized.
• Significant Supply Chain Risk: The supply chain of PCIe devices is a critical vulnerability, as malicious device vendors could embed backdoors into OROMs at the manufacturing stage, introducing compromise before deployment.
• Diverse Attack Capabilities: OROM backdoors can operate at various layers—UEFI-only, kernel-level, or userland-level—offering a spectrum of capabilities from boot-time data exfiltration and ransomware to persistent full system control.
• UEFI-Only Backdoors Are Potent: Even purely UEFI-level backdoors, operating only during the boot phase, can perform impactful malicious activities such as stealing confidential files via HTTP protocol or encrypting data.
• Urgent Need for OROM Security Measures: Defenders must extend their firmware security strategies beyond the main SPI flash to include comprehensive inspection, integrity validation, and monitoring of PCIe device OROMs to mitigate this emerging threat.

About the Speaker(s)

Kazuki Matsuo is a security researcher at FFRI Security, a security company based in Japan. Prior to his work at FFRI Security, he was a master's student at Waseda University, where this specific research was conducted in collaboration with his current company. His primary research interests lie in UEFI security, but he also has expertise in areas such as trusted computing, Windows kernel internals, and other "negative rings" (low-level system components). Matsuo expressed gratitude to his collaborators at FFRI Security and his professor at Waseda University for their valuable advice and support during the research.