analyzing-uefi-bootkit-persistence skill by mukul975

Analyzing UEFI Bootkit Persistence

When to Use

A compromised system re-establishes C2 communication after OS reinstallation or disk replacement
Secure Boot has been tampered with, disabled, or shows unexpected Machine Owner Key (MOK) enrollment
Firmware integrity verification fails against vendor-provided baselines
Memory forensics reveals rootkit components loading during early boot phase
Investigating advanced persistent threat (APT) campaigns known to deploy UEFI implants
Auditing firmware security posture for enterprise endpoint hardening

Do not use for standard MBR-based bootkits on legacy BIOS systems without UEFI; use MBR/VBR bootkit analysis instead.

Prerequisites

chipsec framework for SPI flash dumping, UEFI variable inspection, and firmware security modules
UEFITool / UEFIExtract for firmware volume parsing and DXE driver extraction
Python 3.8+ with struct, hashlib, subprocess, and os modules
Bootable Linux live USB for offline analysis (avoid running compromised OS)
Volatility 3 for memory forensics of boot-phase artifacts
YARA with UEFI malware rule sets for pattern-based detection
Access to vendor firmware baselines for integrity comparison

Workflow

Step 1: Dump SPI Flash Firmware

Acquire the UEFI firmware from the SPI flash chip for offline analysis:

# Using chipsec to dump SPI flash contents
python chipsec_util.py spi dump firmware_dump.rom
 
# Using flashrom as an alternative
flashrom -p internal

Step 2: Inspect UEFI Variables

Enumerate and analyze UEFI variables for unauthorized modifications:

Step 3: Analyze EFI System Partition (ESP)

Inspect the ESP for unauthorized or modified boot components:

Step 4: Scan Firmware for Known Bootkit Signatures

Analyze the firmware dump for known UEFI malware patterns:

Step 5: Detect Secure Boot Bypass Mechanisms

Check for known Secure Boot bypass techniques:

Step 6: Perform Boot Chain Integrity Verification

Verify every component in the boot chain from firmware through kernel:

Step 7: Document UEFI Bootkit Analysis Findings

Compile a comprehensive analysis report:

Key Concepts

Term	Definition
UEFI Bootkit	Malware that persists in UEFI firmware or the boot process, executing before the operating system loads and surviving OS reinstallation
SPI Flash	Serial Peripheral Interface flash memory chip on the motherboard storing UEFI firmware; firmware-level bootkits like LoJax and MoonBounce modify SPI flash contents
EFI System Partition (ESP)	FAT32 partition containing EFI bootloaders and drivers; bootkits like BlackLotus and ESPecter modify files on the ESP for persistence
Secure Boot	UEFI security feature that verifies digital signatures of boot components; can be bypassed via vulnerabilities (CVE-2022-21894) or MOK enrollment
DXE Driver	Driver Execution Environment driver loaded during UEFI boot; firmware implants inject malicious DXE drivers that execute before the OS
Machine Owner Key (MOK)	User-installable Secure Boot key; BlackLotus enrolls attacker-controlled MOKs to sign malicious bootloaders
chipsec	Intel platform security assessment framework for analyzing SPI flash, UEFI variables, Secure Boot, and hardware security configurations
HVCI	Hypervisor-enforced Code Integrity, a Windows security feature that bootkits disable to load unsigned kernel drivers

Tools & Systems

chipsec: Intel framework for dumping SPI flash, reading UEFI variables, verifying firmware write protection, and Secure Boot configuration auditing
UEFITool: Open-source UEFI firmware image parser for inspecting firmware volumes, extracting DXE drivers, and comparing module GUIDs
sigcheck: Sysinternals utility for verifying digital signatures of EFI binaries and boot chain components
flashrom: Open-source SPI flash programmer for reading and writing firmware chips on supported platforms
YARA: Pattern matching engine used with UEFI-specific rule sets to detect known bootkit signatures in firmware dumps

Common Scenarios

Scenario: Investigating Persistent Compromise Surviving OS Reinstallation

Context: An enterprise endpoint was reimaged after a confirmed breach, but identical C2 beaconing resumed within hours. The endpoint has UEFI firmware with Secure Boot enabled, and a TPM 2.0 chip. The security team suspects a UEFI-level implant similar to BlackLotus or LoJax.

Approach:

Boot the system from a trusted Linux live USB to avoid executing any compromised OS components
Dump SPI flash firmware using chipsec_util.py spi dump for offline analysis
Mount the ESP and hash all .efi files for comparison against known-good values from identical hardware
Check for the ESP:/system32/ directory (BlackLotus indicator) and unauthorized grubx64.efi
Extract firmware modules with UEFIExtract and compare GUID inventory against vendor baseline
Verify Secure Boot variables -- look for unauthorized MOK enrollment or modified db/dbx
Check SPI flash write protection and lock bits using chipsec modules
Scan firmware dump and extracted modules with UEFI-specific YARA rules
If BlackLotus is suspected, check registry for HVCI disabled and MeasuredBoot logs for anomalous entries

Pitfalls:

Running analysis from the compromised OS (rootkit components hide from live analysis)
Only checking the ESP without examining SPI flash firmware (misses firmware-level implants like LoJax, MoonBounce)
Assuming Secure Boot prevents all bootkits (CVE-2022-21894 and other bypasses exist)
Not preserving the original firmware dump before remediation (critical forensic evidence)
Reflashing firmware without verifying the vendor image is authentic and unmodified

Output Format