analyzing-uefi-bootkit-persistence

分析 UEFI Bootkit 持久化

使用场景

• 受感染系统在重装操作系统或更换硬盘后重新建立 C2 通信
• Secure Boot 被篡改、禁用，或出现意外的 Machine Owner Key（MOK）注册
• 固件完整性验证与厂商提供的基线不匹配
• 内存取证发现 rootkit 组件在早期启动阶段加载
• 调查已知会部署 UEFI 植入体的高级持续性威胁（APT）行动
• 为企业终端加固审计固件安全态势

请勿使用于不具备 UEFI 的传统 BIOS 系统上基于 MBR 的标准 bootkit；请改用 MBR/VBR bootkit 分析。

前置条件

• chipsec 框架，用于 SPI flash 转储、UEFI 变量检查和固件安全模块
• UEFITool / UEFIExtract，用于固件卷解析和 DXE 驱动提取
• Python 3.8+，包含 struct、hashlib、subprocess 和 os 模块
• 可启动 Linux live USB，用于离线分析（避免运行受感染的操作系统）
• Volatility 3，用于启动阶段产物的内存取证
• YARA 及 UEFI 恶意软件规则集，用于基于模式的检测
• 可访问厂商固件基线，用于完整性比对

工作流

第 1 步：转储 SPI Flash 固件

从 SPI flash 芯片获取 UEFI 固件以进行离线分析：

# 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 firmware_dump.rom

# Verify dump integrity
sha256sum firmware_dump.rom

# Read SPI flash descriptor information
python chipsec_util.py spi info

# Check SPI flash region access permissions
python chipsec_main.py -m common.spi_access

# Verify BIOS write protection is enabled
python chipsec_main.py -m common.bios_wp

# Check SPI flash controller lock
python chipsec_main.py -m common.spi_lock

第 2 步：检查 UEFI 变量

枚举并分析 UEFI 变量，查找未经授权的修改：

# List all UEFI variables on a live system
python chipsec_util.py uefi var-list

# List UEFI variables from a SPI flash dump
python chipsec_util.py uefi var-list-spi firmware_dump.rom

# Read specific Secure Boot variables
python chipsec_util.py uefi var-read SecureBoot 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read SetupMode 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read PK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read KEK 8BE4DF61-93CA-11D2-AA0D-00E098032B8C
python chipsec_util.py uefi var-read db D719B2CB-3D3A-4596-A3BC-DAD00E67656F

# Dump UEFI key databases for analysis
python chipsec_util.py uefi keys

# Check Secure Boot configuration module
python chipsec_main.py -m common.secureboot.variables

第 3 步：分析 EFI 系统分区（ESP）

检查 ESP 中是否存在未经授权或被修改的启动组件：

# Mount ESP (typically the first FAT32 partition, ~100-500MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp

# List all files on ESP with timestamps
find /mnt/esp -type f -exec ls -la {} \;

# Check for BlackLotus indicators - custom directory under ESP:/system32/
ls -la /mnt/esp/system32/ 2>/dev/null

# Verify Windows Boot Manager signature
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi

# Hash all EFI binaries for comparison against known-good values
find /mnt/esp -name "*.efi" -exec sha256sum {} \;

# Check for unauthorized .efi files outside standard directories
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"

# Look for grubx64.efi planted by BlackLotus
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;

# Examine MeasuredBoot logs for anomalies (Windows)
# Logs located at C:\Windows\Logs\MeasuredBoot\

第 4 步：扫描固件中的已知 Bootkit 特征

分析固件转储，查找已知 UEFI 恶意软件模式：

# Extract all firmware modules with UEFIExtract
UEFIExtract firmware_dump.rom all

# Generate firmware module whitelist from vendor baseline
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom

# Compare current firmware against whitelist
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom

# Scan firmware with UEFI-specific YARA rules
yara -r uefi_bootkits.yar firmware_dump.rom

# Scan extracted modules individually
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;

# Check for modified CORE_DXE module (targeted by MoonBounce, CosmicStrand)
# Compare GUID and hash against vendor baseline

第 5 步：检测 Secure Boot 绕过机制

检查是否存在已知的 Secure Boot 绕过技术：

# Check if Secure Boot is enabled
python chipsec_main.py -m common.secureboot.variables

# Verify SMM (System Management Mode) protections
python chipsec_main.py -m common.smm

# Check SMM BIOS write protection
python chipsec_main.py -m common.bios_smi

# On Windows - check boot configuration for bypass indicators
bcdedit /enum firmware
bcdedit /v

# Check for testsigning/nointegritychecks/debug flags
bcdedit | findstr /i "testsigning nointegritychecks debug"

# Verify HVCI (Hypervisor-enforced Code Integrity) is not disabled
# BlackLotus sets HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled

# Check Secure Boot state via PowerShell
# Confirm-SecureBootUEFI returns True if properly enabled

第 6 步：执行启动链完整性验证

验证从固件到内核的启动链中的每一个组件：

# Verify firmware integrity against vendor hash
sha256sum firmware_dump.rom
# Compare with vendor-published hash

# Verify bootloader signatures
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe

# Check for unsigned or invalid boot drivers
sigcheck -u -e C:\Windows\System32\drivers\

# Analyze Measured Boot logs for unexpected EFI_Boot_Services_Application entries
# BlackLotus components appear as EV_EFI_Boot_Services_Application

# Memory forensics for boot-phase artifacts
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan

第 7 步：记录 UEFI Bootkit 分析发现

编写一份全面的分析报告：

Report should include:
- Firmware version, vendor, and platform identification
- SPI flash protection status (write protect, lock bits, access control)
- Secure Boot configuration and any bypass indicators detected
- UEFI variable anomalies (unauthorized keys, modified db/dbx, MOK enrollment)
- ESP contents inventory with hash verification against known-good baselines
- Firmware module comparison against vendor whitelist (added, modified, removed)
- Known bootkit family attribution with confidence level
- Boot chain integrity verification results for each component
- Remediation steps (reflash, key rotation, hardware replacement)
- MITRE ATT&CK mapping (T1542.001 - System Firmware, T1542.003 - Bootkit)

关键概念

术语	定义
UEFI Bootkit	持久化在 UEFI 固件或启动过程中的恶意软件，在操作系统加载之前执行，并能在重装操作系统后继续存活
SPI Flash	主板上用于存储 UEFI 固件的串行外设接口闪存芯片；LoJax 和 MoonBounce 等固件级 bootkit 会修改 SPI flash 内容
EFI 系统分区（ESP）	包含 EFI 引导加载程序和驱动的 FAT32 分区；BlackLotus 和 ESPecter 等 bootkit 会修改 ESP 上的文件以实现持久化
Secure Boot	验证启动组件数字签名的 UEFI 安全功能；可通过漏洞（CVE-2022-21894）或 MOK 注册被绕过
DXE 驱动	在 UEFI 启动期间加载的 Driver Execution Environment 驱动；固件植入体注入恶意 DXE 驱动，使其在操作系统之前执行
Machine Owner Key（MOK）	用户可安装的 Secure Boot 密钥；BlackLotus 会注册攻击者控制的 MOK 来为恶意引导加载程序签名
chipsec	Intel 平台安全评估框架，用于分析 SPI flash、UEFI 变量、Secure Boot 和硬件安全配置
HVCI	Hypervisor 强制代码完整性，一种 Windows 安全功能，bootkit 会将其禁用以加载未签名的内核驱动

工具与系统

• chipsec：Intel 框架，用于转储 SPI 闪存、读取 UEFI 变量、验证固件写保护以及审计 Secure Boot 配置
• UEFITool：开源 UEFI 固件镜像解析器，用于检查固件卷、提取 DXE 驱动以及比较模块 GUID
• sigcheck：Sysinternals 实用工具，用于验证 EFI 二进制文件和启动链组件的数字签名
• flashrom：开源 SPI 闪存编程器，用于在支持的平台上读取和写入固件芯片
• YARA：模式匹配引擎，配合 UEFI 专用规则集使用，以检测固件转储中的已知 bootkit 签名

常见场景

场景：调查在操作系统重装后仍然存活的持久性入侵

背景：一台企业终端在确认遭到入侵后进行了重新镜像，但相同的 C2 信标在数小时内恢复。该终端具有启用了 Secure Boot 的 UEFI 固件，以及 TPM 2.0 芯片。安全团队怀疑存在类似 BlackLotus 或 LoJax 的 UEFI 级植入程序。

方法：

1. 从可信的 Linux 启动 U 盘启动系统，以避免执行任何已受损的操作系统组件
2. 使用 chipsec_util.py spi dump 转储 SPI 闪存固件，以供离线分析
3. 挂载 ESP 并对所有 .efi 文件进行哈希，以便与相同硬件的已知良好值进行比较
4. 检查是否存在 ESP:/system32/ 目录（BlackLotus 指标）以及未经授权的 grubx64.efi
5. 使用 UEFIExtract 提取固件模块，并将 GUID 清单与供应商基线进行比较
6. 验证 Secure Boot 变量——查找未经授权的 MOK 注册或已被修改的 db/dbx
7. 使用 chipsec 模块检查 SPI 闪存写保护和锁定位
8. 使用 UEFI 专用 YARA 规则扫描固件转储和提取出的模块
9. 如果怀疑存在 BlackLotus，请检查注册表中 HVCI 是否被禁用，并检查 MeasuredBoot 日志中是否存在异常条目

陷阱：

• 从已受损的操作系统运行分析（rootkit 组件会躲避实时分析）
• 仅检查 ESP 而不检查 SPI 闪存固件（会遗漏 LoJax、MoonBounce 等固件级植入程序）
• 假设 Secure Boot 能阻止所有 bootkit（CVE-2022-21894 及其他绕过方式仍然存在）
• 在修复前未保留原始固件转储（关键的取证证据）
• 未验证供应商镜像真实且未被修改就重新刷写固件

输出格式

UEFI BOOTKIT PERSISTENCE ANALYSIS REPORT
============================================
System:           Lenovo ThinkPad X1 Carbon Gen 11
Firmware:         N3HET82W (1.54) - Lenovo UEFI BIOS
Platform:         Intel 13th Gen (Raptor Lake)
TPM:              2.0 (Infineon SLB 9672)
Secure Boot:      ENABLED (BYPASSED via CVE-2022-21894)
Analysis Method:  Linux live USB + chipsec + UEFITool

SPI FLASH PROTECTION STATUS
BIOS Write Protection:    DISABLED [!]
SPI Flash Lock (FLOCKDN): SET [OK]
SMM BIOS Write Protect:   DISABLED [!]
SPI Protected Ranges:     Region 0 only (descriptor)

UEFI VARIABLE ANALYSIS
SecureBoot:        Enabled (value=1)
SetupMode:         Disabled (value=0)
PK:                Lenovo Ltd. (legitimate)
KEK:               Microsoft + Lenovo (legitimate)
db:                MODIFIED - contains unauthorized entry [!]
  [!] Unknown certificate: CN=Secure Boot Signing, O=Unknown
  [!] Not present in vendor baseline db
MOK:               1 unauthorized key enrolled [!]
  [!] MOK enrolled: CN=shim, self-signed, not from distro vendor

ESP PARTITION ANALYSIS
Total EFI binaries:     12
Verified (signed):      9
Modified (hash mismatch): 2 [!]
Unauthorized:           1 [!]

  [!] EFI/Microsoft/Boot/bootmgfw.efi - MODIFIED
      Expected SHA-256: a3f2c8...
      Current SHA-256:  7b1e4d...
      Signature:        Valid (signed with unauthorized MOK)

  [!] EFI/Microsoft/Boot/grubx64.efi - UNAUTHORIZED
      SHA-256:  e9c1a7...
      Not present in vendor baseline
      Matches BlackLotus stage-2 loader signature

  [!] system32/ directory present on ESP (BlackLotus artifact)
      Directory empty (files deleted post-installation)

FIRMWARE MODULE ANALYSIS
Total firmware modules:   312
Vendor baseline modules:  312
Added modules:            0
Modified modules:         0
SPI flash integrity:      CLEAN (no firmware-level implant detected)

BOOTKIT ATTRIBUTION
Family:           BlackLotus
Confidence:       HIGH
Persistence:      ESP-based (not SPI flash)
Bypass Method:    CVE-2022-21894 (baton drop)
MITRE ATT&CK:    T1542.003 (Bootkit), T1553.006 (Code Signing Policy Modification)

INDICATORS OF COMPROMISE
- ESP:/system32/ directory (empty, post-cleanup artifact)
- ESP:/EFI/Microsoft/Boot/grubx64.efi (unauthorized, BlackLotus loader)
- Modified bootmgfw.efi (re-signed with attacker MOK)
- HVCI disabled via registry: DeviceGuard\...\Enabled = 0
- Unauthorized MOK enrollment in UEFI variable store
- MeasuredBoot log shows EV_EFI_Boot_Services_Application for grubx64.efi

REMEDIATION
1. Replace bootmgfw.efi with authentic copy from Windows installation media
2. Delete unauthorized grubx64.efi and system32/ directory from ESP
3. Reset Secure Boot keys to factory defaults (clear MOK, restore PK/KEK/db)
4. Enable BIOS write protection and verify SPI flash lock bits
5. Apply firmware update to latest version (patches CVE-2022-21894)
6. Enable HVCI and verify via Group Policy
7. Reimport only trusted certificates into Secure Boot db
8. Monitor MeasuredBoot logs for anomalous boot component loading