Weaponizing UEFI Option ROMs for Stealthy Persistence

TLDR: This research demonstrates how attackers can embed malicious backdoors into UEFI Option ROMs (OROM) on PCI-E devices to achieve persistent, stealthy code execution before the OS even boots. By leveraging runtime DXE drivers and manipulating page tables, the technique bypasses modern security controls like Secure Boot, CFG, and ACG. Pentesters should prioritize auditing firmware integrity on hardware, while defenders must focus on monitoring for suspicious network traffic originating from pre-boot environments.

Hardware-level persistence is the holy grail for any red team engagement. If you can compromise the firmware, you own the machine regardless of how many times the user reinstalls the operating system or swaps the hard drive. While most researchers focus on SPI flash implants, the research presented at Black Hat 2024 by Kazuki Matsuo highlights a more accessible, yet equally dangerous, attack surface: the UEFI Option ROM (OROM) on PCI-E devices.

The Mechanics of an OROM Backdoor

Option ROMs are small memory chips found on PCI-E devices like network cards, storage controllers, and GPUs. During the early stages of the boot process, the UEFI firmware identifies these devices and executes the DXE (Driver Execution Environment) drivers stored within their OROMs. Because this happens before the OS kernel or any EDR solution is loaded, it provides a perfect window for an attacker to inject malicious code.

The research identifies three distinct infection scenarios, but the most compelling is the "UEFI + Kernel + Userland" chain. By placing a malicious DXE driver in the OROM, an attacker can ensure their code runs every time the system initializes. The driver remains resident in memory during the runtime phase, allowing it to hook system functions.

To achieve persistent command and control, the backdoor hooks the Afd.sys driver, which handles socket communications on Windows. By intercepting IOCTLs to Afd.sys, the malware can communicate over the network without triggering standard userland monitoring tools.

Bypassing Modern Security Features

Modern Windows environments are hardened with Control Flow Guard (CFG) and Arbitrary Code Guard (ACG). These features are designed to prevent the exact type of memory corruption and code injection this research performs. However, the researchers found a clever way around them using "Partial Identity Mapping."

Since the DXE driver runs with high privileges, it can modify the page tables of any process. By creating a custom page table that maps a physical address containing the shellcode to a virtual address, the attacker can make that memory region writable and executable. The shellcode is then executed by calling RtlCreateUserThread within a target process like csrss.exe.

To bypass CFG, the researchers patch the ntdll!LdrpDispatchUserCallTarget function. Because the shellcode resides in a memory region that the attacker has manually mapped, they can effectively redirect execution flow without triggering the CFG checks that would normally flag an invalid jump.

Practical Engagement Scenarios

For a pentester, this research changes the threat model for hardware supply chain assessments. If you are performing a physical security audit or a high-stakes red team engagement, you cannot assume that the hardware is clean. An attacker with physical access to a machine can swap a legitimate network card for one with a backdoored OROM.

The demo shown during the talk used a simple Python HTTP server to act as a C2, with netcat used to send the initial trigger. The simplicity of the exfiltration is what makes it dangerous. If you are testing an environment, consider using tools like DbgView to monitor for unexpected debug strings during the boot process, as these can often reveal the presence of unauthorized DXE drivers.

Defensive Strategies

Defending against firmware-level attacks is notoriously difficult because the attacker is operating below the visibility of the operating system. The most effective defense is the strict enforcement of Secure Boot, ensuring that only signed, trusted OROMs are allowed to execute. However, as the researchers noted, many devices ship with unsigned or improperly signed firmware, and some vendors even provide "official" firmware that lacks proper signatures.

Organizations should also implement robust hardware inventory management. If a device is not explicitly required for the system's function, it should be physically removed or disabled in the BIOS. Furthermore, network-level monitoring is critical. Since the backdoor needs to communicate with a C2 server, look for anomalous traffic patterns that occur immediately after the system finishes its POST (Power-On Self-Test) but before the user logs in.

This research serves as a stark reminder that the "root of trust" is only as strong as the weakest component in the PCI-E bus. As we continue to harden the OS and the hypervisor, the focus of offensive research will inevitably shift further down the stack. Investigating the firmware of your peripheral devices is no longer optional for high-security environments; it is a necessity. If you haven't started auditing your hardware supply chain, now is the time to start.