UEFI Attack Surface Research

The Unified Extensible Firmware Interface (UEFI) has replaced legacy BIOS as the industry-standard firmware interface for x86, x64, and ARM platforms. While UEFI brings significant security improvements — Secure Boot, cryptographic verification, and a standardized architecture — it also introduces a dramatically expanded attack surface.

UEFI firmware executes before the operating system, before any security agent loads, and before most hardware-based attestation begins. A compromise at this layer provides the attacker with:

• Persistence that survives OS reinstalls, disk replacements, and factory resets
• Stealth invisible to all OS-level security tools (EDR, AV, HIDS)
• Privilege equivalent to hypervisor or System Management Mode (SMM)
• Control over boot process, Secure Boot policy, and hardware initialization

1.1 Business Impact

2.1 UEFI Boot Phases

3.1 What is a UEFI Bootkit?

A UEFI bootkit is malicious code that resides in the SPI flash storage (firmware) and executes during the UEFI boot process, before the OS loads. Unlike traditional bootkits that resided on disk (MBR/VBR) and were removed during OS reinstallation, UEFI bootkits survive all software-based remediation.

3.2 Bootkit Insertion Vectors

3.3 Bootkit Capability Matrix

4.1 How Secure Boot Works

Secure Boot ensures that only cryptographically signed and trusted software executes during the boot process. The UEFI firmware contains Platform Key (PK) and Key Exchange Keys (KEK). The signature database (db) contains authorized signatures or hashes. The forbidden database (dbx) contains revoked signatures. Each binary (bootloader, driver, option ROM) is verified before execution.

4.2 Known Secure Boot Bypasses

4.3 Secure Boot Bypass Attack Flow

4.4 Detection of Secure Boot Bypass

5.1 DXE Driver Injection

The Driver Execution Environment (DXE) loads hundreds of UEFI drivers during boot. Each driver represents a potential attack surface.

Attack Method: Compromise running OS (kernel privilege), write malicious DXE driver to SPI flash or EFI System Partition (ESP), modify boot order or driver load order, then malicious driver loads during next boot before any security software.

Detection: Firmware integrity scanning (e.g., CHIPSEC), driver hash verification against golden images, boot-time driver enumeration logging.

5.2 UEFI Runtime Variable Attacks

UEFI variables store configuration data in NVRAM. Attackers can modify BootOrder to load malicious bootloader first, set SetupMode=1 to allow unsigned code, inject Boot#### variables pointing to attacker-controlled binaries, or overwrite SecureBoot=Disabled in variable storage.

Forensic Artifacts: Unexpected BootOrder values, unknown Boot#### variables, SecureBoot state changes without authorized update, AuditMode or DeployedMode transitions.

5.3 Option ROM Attacks

PCIe devices (NICs, storage controllers, GPUs) can ship with Option ROMs containing UEFI drivers. Attackers can flash malicious Option ROM to PCIe device, leverage DMA capabilities to read/write system memory, and execute code in UEFI context during device initialization.

Detection: Option ROM scanning and hash verification against vendor database.

5.4 ACPI Table Manipulation

ACPI tables provide power management and hardware configuration. Malicious modifications can inject code via DSDT (Differentiated System Description Table), manipulate FACP (Fixed ACPI Description Table) for SMM abuse, or add malicious SSDT (Secondary System Description Table) entries.

Tooling: acpiexec, iasl for table inspection.

5.5 SMM (System Management Mode) Subversion

SMM is the highest privilege execution environment (Ring -2). SMM code executes in response to System Management Interrupts (SMIs) and can access all system memory.

Attack Vectors: SMI handler buffer overflow leading to SMM code execution, SMM callout via runtime service, SMM cache poisoning, and software-generated SMI with attacker-controlled parameters.

Detection: SMM integrity monitoring via CHIPSEC module common.smm, SMI handler enumeration and analysis, memory scanning for SMM-resident implants.

6.1 Comprehensive Malware Database

6.2 BlackLotus Deep Dive

BlackLotus (2022-2023) is the most sophisticated publicly documented UEFI bootkit.

6.3 MoonBounce Deep Dive

MoonBounce (discovered by Kaspersky, 2021) targeted AMI UEFI firmware on enterprise laptops.

7.1 Firmware Integrity Scanning Tools

7.2 CHIPSEC Audit Modules

7.3 Detection Analytics (MITRE ATT&CK)

7.4 Enterprise Detection Controls

7.5 Windows-Specific Detection

7.6 Linux-Specific Detection

8.1 Architectural Controls

8.2 Microsoft Recommended Mitigations for BlackLotus/Batman

8.3 Vendor Firmware Update Best Practices

• Enable automatic firmware updates from trusted vendors for timely security patch deployment
• Verify checksums before flashing to prevent corrupted/malicious updates
• Use hardware-backed update verification to prevent rollback attacks
• Maintain recovery image for rapid restoration if compromise detected
• Disable legacy BIOS compatibility (CSM) to reduce attack surface

8.4 Incident Response for Bootkit Compromise

When bootkit is suspected, follow these steps:

1. Isolate affected system – Assume all data is compromised
2. Capture forensic artifacts – SPI flash dump (hardware programmer preferred), UEFI variable export, TPM event log, Secure Boot event logs
3. Determine persistence mechanism – SPI flash vs. ESP vs. Option ROM
4. Remediate – For SPI flash compromise: physical reflash with verified image or motherboard replacement. For ESP compromise: secure wipe and OS reinstall. For Option ROM compromise: replace affected PCIe device
5. Verify remediation – CHIPSEC audit, Secure Boot re-verification
6. Root cause analysis – How did initial compromise occur?

9.1 SPI Flash Acquisition

Physical acquisition (preferred): Identify SPI flash chip (Winbond, Macronix, etc.), connect programmer (CH341A, Dediprog, Bus Pirate), dump full flash contents (8MB-32MB typical).

Software acquisition (limited): CHIPSEC (chipsec_main.py -a -l log.txt) and UEFITool for runtime extraction.

Analysis: Binary diff against known-good image, UEFITool volume extraction, disassemble suspicious DXE or SMM modules, check for unexpected PEI or DXE drivers.

9.2 Forensic Artifacts

9.3 Signature-Based Detection (Blacklist)

10.1 DXE Driver Loading Order – AprioriDxe

10.2 BiosGuardDxe – Critical Security Driver

10.3 Critical DXE Drivers for Security Research

10.4 EFI Boot Services Hooking

10.5 Indicators of Compromise (IoC) – DXE Level

System Management Mode (SMM) is the highest privilege level in x86/x64 – Ring -2, beyond hypervisor (Ring -1) and kernel (Ring 0). SMM code executes in response to System Management Interrupts (SMIs) and can access all system memory, including hypervisor and kernel space.

11.1 SMM Architecture – Attack Surface

11.2 BlackLotus SMM Techniques (CVE-2022-21894)

• Triggered vulnerable SMI handler via runtime service abuse
• Executed arbitrary code in SMM (Ring -2)
• Modified Secure Boot variables (db/dbx) from SMM – invisible to OS
• Patched TPM measurements to report false attestation

11.3 SMM Detection Methodology

11.4 SMM Indicators of Compromise (IoC)

12.1 Phase 1: Assessment (Week 1-2)

• Inventory UEFI versions across fleet – Firmware version report
• Secure Boot status audit – Compliance dashboard
• Identify non-Secure Boot systems – Remediation list
• CHIPSEC scan on high-value systems – Baseline report

12.2 Phase 2: Hardening (Week 3-8)

• Enable Secure Boot enterprise-wide – Critical
• Update dbx with all known revocations – Critical
• Enable TPM + BitLocker (with PCR 0-7) – Critical
• Configure firmware write protection – High
• Disable legacy boot (CSM) – High
• Implement UEFI variable monitoring – Medium

12.3 Phase 3: Continuous Monitoring (Ongoing)

• Firmware version drift detection – Monthly
• Secure Boot attestation – Continuous (via MDE/CrowdStrike)
• CHIPSEC full audit – Quarterly (critical systems)
• UEFI variable baseline comparison – Weekly
• Option ROM scanning – Upon new device enrollment

GGSEC is a specialized security research laboratory focused exclusively on firmware-level threats, embedded systems auditing, and supply chain risk assessment.

13.1 GG SEC Internal Tooling

14.1 Quick Reference Card – Windows Detection Commands

14.2 Quick Reference Card – Linux Detection Commands

14.3 Critical CVEs to Track

14.4 References

1. ESET Research. (2023). "BlackLotus UEFI bootkit: Myth or reality?"
2. Kaspersky. (2021). "MoonBounce: the dark side of UEFI firmware."
3. Microsoft Security Response Center. (2023). "CVE-2022-21894 Secure Boot Security Feature Bypass Vulnerability."
4. MITRE ATT&CK. (2024). "Bootkit (T1542.003)" and "System Firmware (T1542.001)."
5. Binarly Research. (2023). "LogoFAIL: Image parser vulnerabilities in UEFI DXE drivers."
6. Quarkslab. (2020). "The BootHole vulnerability: GRUB2 bootloader compromise."
7. Google Project Zero. (2020). "CVE-2020-10713: GRUB2 BootHole."
8. Intel Corporation. (2023). "CHIPSEC: Platform Security Assessment Framework."
9. National Institute of Standards and Technology. (2018). "NIST SP 800-193: Platform Firmware Resiliency Guidelines."
10. US-CERT. (2023). "AA23-165A: BlackLotus UEFI Bootkit."