分析UEFI引导工具包持久化机制 是做什么的?
何时使用
- 受感染系统在重新安装操作系统或更换硬盘后重新建立了C2通信
- 安全启动被篡改、禁用或显示意外的机器所有者密钥(MOK)注册
- 固件完整性验证失败,与供应商提供的基准不匹配
- 内存取证揭示引导早期阶段加载了Rootkit组件
- 调查已知部署UEFI植入的APT活动
- 为企业端点加固审计固件安全状况
不要用于 无UEFI的传统BIOS系统上的标准MBR引导工具包;应使用MBR/VBR引导工具包分析。
前提条件
- chipsec框架:用于SPI闪存转储、UEFI变量检查和固件安全模块
- UEFITool / UEFIExtract:用于固件卷解析和DXE驱动程序提取
- Python 3.8+:包含struct、hashlib、subprocess和os模块
- 可引导Linux Live USB:用于离线分析(避免运行受感染的操作系统)
- Volatility 3:用于引导阶段工件的内存取证
- 包含UEFI恶意软件规则集的YARA:用于基于模式的检测
- 访问供应商固件基准:用于完整性比较
工作流程
步骤1:转储SPI闪存固件
获取UEFI固件(来自SPI闪存芯片)以进行离线分析:
# 使用chipsec转储SPI闪存内容
python chipsec_util.py spi dump firmware_dump.rom
# 使用flashrom作为替代方案
flashrom -p internal -r firmware_dump.rom
# 验证转储完整性
sha256sum firmware_dump.rom
# 读取SPI闪存描述符信息
python chipsec_util.py spi info
# 检查SPI闪存区域访问权限
python chipsec_main.py -m common.spi_access
# 验证BIOS写保护已启用
python chipsec_main.py -m common.bios_wp
# 检查SPI闪存控制器锁定
python chipsec_main.py -m common.spi_lock
步骤2:检查UEFI变量
枚举并分析UEFI变量是否被非授权修改:
# 在活动系统上列出所有UEFI变量
python chipsec_util.py uefi var-list
# 从SPI闪存转储中列出UEFI变量
python chipsec_util.py uefi var-list-spi firmware_dump.rom
# 读取特定的安全启动变量
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
# 转储UEFI密钥数据库进行分析
python chipsec_util.py uefi keys
# 检查安全启动配置模块
python chipsec_main.py -m common.secureboot.variables
步骤3:分析EFI系统分区(ESP)
检查ESP是否存在非授权或修改过的启动组件:
# 挂载ESP(通常是第一个FAT32分区,约100-500MB)
mkdir /mnt/esp
mount /dev/sda1 /mnt/esp
# 列出ESP上所有文件及时间戳
find /mnt/esp -type f -exec ls -la {} \;
# 检查BlackLotus指示器 - ESP:/system32/下的自定义目录
ls -la /mnt/esp/system32/ 2>/dev/null
# 验证Windows引导管理器签名
sigcheck -a /mnt/esp/EFI/Microsoft/Boot/bootmgfw.efi
# 对所有EFI二进制文件进行哈希计算,与已知正常值比较
find /mnt/esp -name "*.efi" -exec sha256sum {} \;
# 检查标准目录之外的非授权.efi文件
find /mnt/esp -name "*.efi" | grep -v "Microsoft\|Boot\|ubuntu\|grub"
# 查找BlackLotus植入的grubx64.efi
find /mnt/esp -name "grubx64.efi" -exec sha256sum {} \;
# 检查MeasuredBoot日志是否存在异常(Windows)
# 日志位于 C:\Windows\Logs\MeasuredBoot\
步骤4:扫描固件中已知的引导工具包特征
分析固件转储中已知的UEFI恶意软件模式:
# 使用UEFIExtract提取所有固件模块
UEFIExtract firmware_dump.rom all
# 从供应商基准生成固件模块白名单
python chipsec_main.py -m tools.uefi.whitelist -a generate,baseline.json,firmware_vendor.rom
# 将当前固件与白名单进行比较
python chipsec_main.py -m tools.uefi.whitelist -a check,baseline.json,firmware_dump.rom
# 使用UEFI特定的YARA规则扫描固件
yara -r uefi_bootkits.yar firmware_dump.rom
# 逐个扫描提取的模块
find firmware_dump.rom.dump -name "*.efi" -exec yara -r uefi_bootkits.yar {} \;
# 检查修改过的CORE_DXE模块(MoonBounce、CosmicStrand的目标)
# 将GUID和哈希与供应商基准进行比较
步骤5:检测安全启动绕过机制
检查已知的安全启动绕过技术:
# 检查安全启动是否启用
python chipsec_main.py -m common.secureboot.variables
# 验证SMM保护
python chipsec_main.py -m common.smm
# 检查SMM BIOS写保护
python chipsec_main.py -m common.bios_smi
# 在Windows上检查启动配置是否存在绕过迹象
bcdedit /enum firmware
bcdedit /v
# 检查testsigning/nointegritychecks/debug标志
bcdedit | findstr /i "testsigning nointegritychecks debug"
# 验证HVCI未被禁用
# BlackLotus设置 HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
# 通过PowerShell检查安全启动状态
# Confirm-SecureBootUEFI 如果正确启用则返回True
步骤6:执行启动链完整性验证
验证从固件到内核的每个启动链组件:
# 根据供应商哈希验证固件完整性
sha256sum firmware_dump.rom
# 与供应商发布的哈希进行比较
# 验证引导加载程序签名
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
sigcheck -a C:\Windows\System32\winload.efi
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# 检查未签名或无效的引导驱动程序
sigcheck -u -e C:\Windows\System32\drivers\
# 分析MeasuredBoot日志中是否存在意外的EFI_Boot_Services_Application条目
# BlackLotus组件显示为EV_EFI_Boot_Services_Application
# 对引导阶段工件进行内存取证
vol3 -f memory.dmp windows.modules
vol3 -f memory.dmp windows.driverscan
步骤7:记录UEFI引导工具包分析结果
编写全面的分析报告:
报告应包括:
- 固件版本、供应商和平台标识
- SPI闪存保护状态(写保护、锁定位、访问控制)
- 安全启动配置及检测到的任何绕过迹象
- UEFI变量异常(非授权密钥、修改的db/dbx、MOK注册)
- ESP内容清单及与已知正常基准的哈希验证
- 与供应商白名单的固件模块比较(新增、修改、删除)
- 已知引导工具包家族归属及置信度
- 各组件的启动链完整性验证结果
- 修复步骤(重新刷写、轮换密钥、更换硬件)
- MITRE ATT&CK映射(T1542.001 - 系统固件, T1542.003 - 引导工具包)
关键概念
| 术语 | 定义 |
|---|---|
| UEFI引导工具包 | 持久化于UEFI固件或启动过程中的恶意软件,在操作系统加载前执行,并能在操作系统重新安装后存活 |
| SPI闪存 | 主板上存储UEFI固件的串行外设接口闪存芯片;像LoJax和MoonBounce这样的固件级引导工具包会修改SPI闪存内容 |
| EFI系统分区(ESP) | 包含EFI引导加载程序和驱动程序的FAT32分区;像BlackLotus和ESPecter这样的引导工具包会修改ESP上的文件以保持持久化 |
| 安全启动 | 验证启动组件数字签名的UEFI安全功能;可通过漏洞(CVE-2022-21894)或MOK注册绕过 |
| DXE驱动 | 在UEFI启动期间加载的驱动程序执行环境驱动;固件植入物会注入在操作系统之前执行的恶意DXE驱动 |
| 机器所有者密钥(MOK) | 用户可安装的安全启动密钥;BlackLotus会注册攻击者控制的MOK来签名恶意引导加载程序 |
| chipsec | Intel平台安全评估框架,用于分析SPI闪存、UEFI变量、安全启动和硬件安全配置 |
| HVCI | 基于管理程序的代码完整性,一项Windows安全功能,引导工具包会禁用它以加载未签名的内核驱动 |
工具与系统
- chipsec:用于转储SPI闪存、读取UEFI变量、验证固件写保护和审计安全启动配置的Intel框架
- UEFITool:用于检查固件卷、提取DXE驱动以及比较模块GUID的开源UEFI固件镜像解析器
- sigcheck:用于验证EFI二进制文件和启动链组件数字签名的Sysinternals实用工具
- flashrom:用于在支持的平台上读写固件芯片的开源SPI闪存编程器
- YARA:与UEFI特定规则集一起使用的模式匹配引擎,用于检测固件转储中的已知引导工具包特征
常见场景
场景:调查在操作系统重新安装后仍然存活的持久性感染
背景:一个企业端点在确认被入侵后重新进行了镜像安装,但几小时内相同的C2信标活动再次出现。该端点配备了启用了安全启动的UEFI固件和TPM 2.0芯片。安全团队怀疑存在类似于BlackLotus或LoJax的UEFI级植入物。
方法:
- 从可信的Linux Live USB启动系统,以避免执行任何受感染的操作系统组件
- 使用
chipsec_util.py spi dump转储SPI闪存固件以进行离线分析 - 挂载ESP并对所有
.efi文件进行哈希计算,与来自相同硬件的已知正常值进行比较 - 检查
ESP:/system32/目录(BlackLotus指示器)和非授权的grubx64.efi - 使用UEFIExtract提取固件模块,并将GUID清单与供应商基准进行比较
- 验证安全启动变量——查找非授权的MOK注册或修改的db/dbx
- 使用chipsec模块检查SPI闪存写保护和锁定位
- 使用UEFI特定的YARA规则扫描固件转储和提取的模块
- 如果怀疑是BlackLotus,请检查注册表中HVCI是否被禁用,以及MeasuredBoot日志中是否存在异常条目
陷阱:
- 在受感染的操作系统中运行分析(Rootkit组件会向实时分析隐藏自身)
- 仅检查ESP而不检查SPI闪存固件(会遗漏像LoJax、MoonBounce这样的固件级植入物)
- 假设安全启动能阻止所有引导工具包(存在CVE-2022-21894和其他绕过方法)
- 在修复之前未保存原始固件转储(关键的法证证据)
- 未验证供应商镜像的真实性和未修改就直接重新刷写固件
输出格式
UEFI引导工具包持久化分析报告
============================================
系统: Lenovo ThinkPad X1 Carbon Gen 11
固件: N3HET82W (1.54) - Lenovo UEFI BIOS
平台: Intel 13th Gen (Raptor Lake)
TPM: 2.0 (Infineon SLB 9672)
安全启动: 已启用(已通过CVE-2022-21894绕过)
分析方法: Linux Live USB + chipsec + UEFITool
SPI闪存保护状态
BIOS写保护: 已禁用 [!]
SPI闪存锁定 (FLOCKDN): 已设置 [OK]
SMM BIOS写保护: 已禁用 [!]
SPI保护范围: 仅区域0(描述符)
UEFI变量分析
SecureBoot: 已启用 (值=1)
SetupMode: 已禁用 (值=0)
PK: Lenovo Ltd.(合法)
KEK: Microsoft + Lenovo(合法)
db: 已修改 - 包含非授权条目 [!]
[!] 未知证书:CN=Secure Boot Signing, O=Unknown
[!] 不在供应商基准db中
MOK: 已注册1个非授权密钥 [!]
[!] 已注册MOK:CN=shim, 自签名, 非来自发行版供应商
ESP分区分析
EFI二进制文件总数: 12
已验证(已签名): 9
已修改(哈希不匹配): 2 [!]
非授权: 1 [!]
[!] EFI/Microsoft/Boot/bootmgfw.efi - 已修改
预期SHA-256:a3f2c8...
当前SHA-256:7b1e4d...
签名:有效(使用非授权MOK签名)
[!] EFI/Microsoft/Boot/grubx64.efi - 非授权
SHA-256: e9c1a7...
不在供应商基准中
匹配BlackLotus阶段2加载器签名
[!] ESP上存在system32/目录(BlackLotus工件)
目录为空(文件在安装后被删除)
固件模块分析
固件模块总数: 312
供应商基准模块数: 312
新增模块: 0
修改模块: 0
SPI闪存完整性: 干净(未检测到固件级植入物)
引导工具包归属
家族: BlackLotus
置信度: 高
持久化: 基于ESP(非SPI闪存)
绕过方法: CVE-2022-21894(baton drop)
MITRE ATT&CK: T1542.003(引导工具包),T1553.006(代码签名策略修改)
危害指标
- ESP:/system32/目录(为空,清理后工件)
- ESP:/EFI/Microsoft/Boot/grubx64.efi(非授权,BlackLotus加载器)
- 已修改的bootmgfw.efi(使用攻击者MOK重新签名)
- 通过注册表禁用HVCI:DeviceGuard\...\Enabled = 0
- UEFI变量存储中非授权的MOK注册
- MeasuredBoot日志显示grubx64.efi的EV_EFI_Boot_Services_Application
修复
1. 用Windows安装介质中的原始副本替换bootmgfw.efi
2. 从ESP中删除非授权的grubx64.efi和system32/目录
3. 将安全启动密钥恢复为出厂默认设置(清除MOK,恢复PK/KEK/db)
4. 启用BIOS写保护并验证SPI闪存锁定位
5. 将固件更新到最新版本(修补CVE-2022-21894)
6. 启用HVCI并通过组策略进行验证
7. 仅将受信任的证书重新导入安全启动db
8. 监控MeasuredBoot日志中的异常启动组件加载情况