analyzing-uefi-bootkit-persistence

# 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: ```bash # Using chipsec to dump SPI flash contents python chipsec_util.py spi dump firmware_dump.rom # Using flashrom as an alternative flashrom -p internal -r ...