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.

6.4 OEM Persistence Modules — The Legitimate Backdoor Class

A category distinct from malware deserves separate treatment: vendor-supplied firmware modules that implement the same technical primitives as an implant, but ship from the factory. They are legitimate by intent and indistinguishable from an implant by behaviour. Threat actors have repurposed them directly.

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 / Baton Drop

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. Note that a host-side dump may return a blank ME region where descriptor permissions deny the read — full image size does not imply full image content.

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 Documented SMI Handler Vulnerability Classes

11.3 SMM Detection Methodology

11.4 SMM Indicators of Compromise (IoC)

Microsoft’s Secure Boot certificates issued in 2011 reach expiry in June 2026. This is the first refresh of the Secure Boot chain of trust since its introduction, and it changes the operational picture for every fleet in scope of this paper.

Why it matters operationally

Assessment checklist

Recommended actions

• Inventory KEK certificate issue year across the fleet — 2011 versus 2023 — before the expiry window closes
• Compare each device’s DBX against the current published UEFI revocation list; missing entries indicate a device that stopped receiving updates
• Verify firmware update availability per model; OEM support status determines whether a device can receive the 2023 trust anchors at all
• Treat end-of-support hardware that cannot accept new anchors as a separate, tracked risk population
• Note that TPM presence and BitLocker enrollment do not imply correct Secure Boot configuration — verify independently

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 GGSEC Firmware Toolkit (ggfw)

ggfw is GGSEC’s in-house firmware analysis platform, covering SPI acquisition, offline image analysis, and platform security assessment in a single tool. It was developed after the first release of this paper and now serves as the primary instrument behind GGSEC’s firmware engagements. The analyses reproduced in §9.4 and §10 were produced with it.

Current release: v0.8.0 Beta. GUID identification uses an LVFS-derived bundled database.

13.2 Supporting Tooling

13.5.1 Methodology

This paper draws on vendor advisories, peer-reviewed and industry security research, conference proceedings, and first-party firmware analysis conducted by GGSEC. CVE identifiers, malware attributions and persistence mechanisms have been cross-checked against primary vendor and researcher sources rather than secondary reporting. Where the research community has not reached consensus on attribution, that uncertainty is stated rather than resolved editorially.

13.5.2 Limitations

• Offensive implementation detail — exploit code, SPI write procedures, bootkit loader internals — is deliberately omitted. This document is written for defenders, firmware auditors and security architects.
• Firmware-level attribution is technically difficult. Attributions reflect community consensus at the time of writing and should be treated as provisional.
• Heuristic detection findings, including those produced by GGSEC tooling, indicate items warranting manual review. They are not malware verdicts.
• Offline firmware analysis cannot establish runtime state. Secure Boot enablement, ME/CSE version and active service status require live host queries.
• CVE status information is time-sensitive. Verify against vendor advisories before operational use.

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 / Smolár, M. (2023). "BlackLotus UEFI bootkit: Myth confirmed." WeLiveSecurity, 1 March 2023.
2. Microsoft Security Response Center. (2023). "Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign."
3. NSA. (2023). "BlackLotus Mitigation Guide" (CSI, June 2023).
4. Binarly REsearch. (2024). "PKfail: Untrusted Platform Keys undermine Secure Boot" (CVE-2024-8105).
5. Kamluk, V., Belov, S., Sacco, A. (2014). "Absolute Backdoor Revisited." Black Hat USA.
6. Eclypsium. (2023). "Supply Chain Risk from Gigabyte App Center Backdoor."
7. Kaspersky. (2021). "MoonBounce: the dark side of UEFI firmware."
8. Microsoft Security Response Center. (2023). "CVE-2022-21894 Secure Boot Security Feature Bypass Vulnerability."
9. MITRE ATT&CK. (2024). "Bootkit (T1542.003)" and "System Firmware (T1542.001)."
10. Binarly Research. (2023). "LogoFAIL: Image parser vulnerabilities in UEFI DXE drivers."
11. Quarkslab. (2020). "The BootHole vulnerability: GRUB2 bootloader compromise."
12. Google Project Zero. (2020). "CVE-2020-10713: GRUB2 BootHole."
13. Intel Corporation. (2023). "CHIPSEC: Platform Security Assessment Framework."
14. National Institute of Standards and Technology. (2018). "NIST SP 800-193: Platform Firmware Resiliency Guidelines."
15. US-CERT. (2023). "AA23-165A: BlackLotus UEFI Bootkit."