网络安全 Analyzing Uefi Bootkit Persistence

Model: minimax-m3 | ¥0.20/call

网络安全Claude Opus 4.7安全审计AnalyzingUefi

Analyzing Uefi Bootkit Persistence：网络安全 skill: analyzing-uefi-bootkit-persistence，适用于安全分析、取证与威胁排查场景。

Calls: 1

Skill Documentation

网络安全 Analyzing Uefi Bootkit Persistence

摘要

Analyzing Uefi Bootkit Persistence：网络安全 skill: analyzing-uefi-bootkit-persistence，适用于安全分析、取证与威胁排查场景。

> 来源: mukul975/Anthropic-Cybersecurity-Skills (18k stars) — 网络安全专业技能集

> 原文件: skills/analyzing-uefi-bootkit-persistence/SKILL.md

> 模型推荐: claude-opus-4-7 (安全分析深度推理)

这个 skill 是干嘛的

mukul975 整理的 100+ 个网络安全专业 skill — 覆盖渗透测试 / 取证 / 威胁情报 / 合规审计 / 云安全 / 移动安全等领域。每个 skill 对应一个具体的安全分析任务。

michael 强调"skill 要有相应的指导功能,指导用户使用",所以加了下面两节让 Agent 和用户对接。

---

🤖 Agent 使用说明

1. 用户提到"分析 X 日志 / 取证 / 检测威胁 / 渗透测试 / 安全审计"时触发对应 skill

2. skill 按操作步骤执行(取证镜像 / 解析日志 / 跑威胁情报)

3. 涉及破坏性操作前必须 ask user 确认

4. 完工后跑自检

5. 区分"防御性分析" vs "恶意代码审计"

👤 用户需要做什么?

1. 告诉 Agent 你要做什么(分析日志 / 取证 / 安全审计 / 渗透测试)

2. 按 Agent 提示提供文件/镜像/日志/哈希

3. 涉及破坏性操作时明确告诉 Agent"继续"或"取消"

4. 全程 Agent 自动化,你只需提供数据 + 回答决策点

---

原 skill 内容(mukul975/Anthropic-Cybersecurity-Skills/skills/analyzing-uefi-bootkit-persistence/SKILL.md,截断到 12k chars)

---

name: analyzing-uefi-bootkit-persistence

description: 'Analyzes UEFI bootkit persistence (SPI flash implants, ESP modifications,

Secure Boot bypass, UEFI variable manipulation) using chipsec for firmware integrity

verification, detecting known families like BlackLotus, LoJax, and MoonBounce.

Use for UEFI malware analysis, firmware persistence investigation, or Secure Boot

bypass detection.

domain: cybersecurity

subdomain: firmware-security

tags:

UEFI
bootkit
firmware
Secure-Boot
chipsec
ESP
persistence

version: 1.0.0

author: mukul975

license: Apache-2.0

d3fend_techniques:

Platform Hardening
Restore Object
Platform Monitoring
Firmware Verification
Firmware Embedded Monitoring Code

nist_csf:

ID.RA-01
PR.PS-01
PR.PS-02

mitre_attack:

T1542.001
T1542.003
T1553.006
T1542
T1014

---

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 -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

Step 2: Inspect UEFI Variables

Enumerate and analyze UEFI variables for unauthorized modifications:

# 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

Step 3: Analyze EFI System Partition (ESP)

Inspect the ESP for unauthorized or modified boot components:

# 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\

Step 4: Scan Firmware for Known Bootkit Signatures

Analyze the firmware dump for known UEFI malware patterns:

# 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

Step 5: Detect Secure Boot Bypass Mechanisms

Check for known Secure Boot bypass techniques:

# 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

Step 6: Perform Boot Chain Integrity Verification

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

# 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

Step 7: Document UEFI Bootkit Analysis Findings

Compile a comprehensive analysis report:

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)

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**:

1. Boot the system from a trusted Linux live USB to avoid executing any compromised OS components

2. Dump SPI flash firmware using `chipsec_util.py spi dump` for offline analysis

3. Mount the ESP and hash all `.efi` files for comparison against known-good values from identical hardware

4. Check for the `ESP:/system32/` directory (BlackLotus indicator) and unauthorized `grubx64.efi`

5. Extract firmware modules with UEFIExtract and compare GUID inventory against vendor baseline

6. Verify Secure Boot variables -- look for unauthorized MOK enrollment or modified db/dbx

7. Check SPI flash write protection and lock bits using chipsec modules

8. Scan firmware dump and extracted modules with UEFI-specific YARA rules

9. 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

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 Boo

## 常见问题（FAQ）

## 使用「Analyzing Uefi」这个 skill 能解决什么问题?
本 skill 专注于Analyzing Uefi，网络安全 skill: analyzing-uefi-bootkit-persistence。它将相关流程标准化，帮助用户更快拿到可靠结果，减少重复手工操作。

## 什么情况下适合使用「Analyzing Uefi」?
当你需要在Analyzing Uefi Bootkit Persistence相关工作中获得稳定、可复用的产出时最适合——无论是单次任务还是纳入日常工作流，都能直接调用。

## 使用「Analyzing Uefi」前需要准备什么?
需要明确授权范围内的目标系统或样本文件，并准备隔离的分析环境（虚拟机/沙箱）。

Open AIMS China Panel