分析引导套件与Rootkit样本
何时使用
- 系统在重装操作系统后仍持续出现受感染迹象
- 尽管有明确的感染证据，防病毒软件和EDR无法检测到恶意软件
- UEFI安全启动已被禁用或显示完整性违规
- 内存取证揭示Rootkit行为（隐藏进程、钩子系统调用）
- 调查已知部署引导套件的国家级威胁（APT28、APTT41、方程式组织）
请勿用于 标准的用户模式恶意软件；引导套件和Rootkit在根本不同的层级运行，需要专门的分析技术。
前提条件
- 磁盘镜像工具（dd、FTK Imager），用于获取MBR/VBR扇区
- UEFITool，用于UEFI固件卷分析和模块提取
- chipsec，用于硬件级固件安全评估
- 支持x86实模式（16位）的Ghidra，用于MBR代码分析
- Volatility 3，用于内核级Rootkit痕迹检测
- 可引导的Linux Live U盘，用于离线系统分析
工作流程
步骤1：捕获引导扇区和固件
提取MBR、VBR和UEFI固件以进行离线分析：
# 捕获MBR（磁盘前512字节）
dd if=/dev/sda of=mbr.bin bs=512 count=1
# 捕获第一个磁道（通常包含MBR之外的引导套件代码）
dd if=/dev/sda of=first_track.bin bs=512 count=63
# 捕获VBR（卷引导记录 - 分区的第一个扇区）
dd if=/dev/sda1 of=vbr.bin bs=512 count=1
# 捕获UEFI系统分区
mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/
# 转储UEFI固件（需要chipsec或flashrom）
# 使用chipsec：
python chipsec_util.py spi dump firmware.rom
# 使用flashrom：
flashrom -p internal -r firmware.rom
# 验证固件转储完整性
sha256sum firmware.rom
步骤2：分析MBR/VBR中的引导套件代码
检查引导扇区代码是否存在恶意修改：
# 反汇编MBR代码（16位实模式）
ndisasm -b16 mbr.bin > mbr_disasm.txt
# 与已知的干净Windows MBR进行比较
# 标准Windows MBR以：EB 5A 90（JMP 0x5C, NOP）开头
# 标准Windows 10 MBR：33 C0 8E D0 BC 00 7C（XOR AX,AX; MOV SS,AX; MOV SP,7C00h）
python3 << 'PYEOF'
with open("mbr.bin", "rb") as f:
mbr = f.read()
# 检查MBR签名（字节510-511应为0x55AA）
if mbr[510:512] == b'\x55\xAA':
print("[*] 有效的MBR签名 (0x55AA)")
else:
print("[!] 无效的MBR签名")
# 检查已知的引导套件签名
bootkit_sigs = {
b'\xE8\x00\x00\x5E\x81\xEE': "TDL4/Alureon 引导套件",
b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "标准 Windows MBR (干净)",
b'\xEB\x5A\x90\x4E\x54\x46\x53': "标准 NTFS VBR (干净)",
}
for sig, name in bootkit_sigs.items():
if sig in mbr:
print(f"[{'!' if '干净' not in name else '*'}] 签名匹配: {name}")
# 检查分区表条目
print("\n分区表:")
for i in range(4):
offset = 446 + (i * 16)
entry = mbr[offset:offset+16]
if entry != b'\x00' * 16:
boot_flag = "活动" if entry[0] == 0x80 else "非活动"
part_type = entry[4]
start_lba = int.from_bytes(entry[8:12], 'little')
size_lba = int.from_bytes(entry[12:16], 'little')
print(f" 分区 {i+1}: 类型=0x{part_type:02X} {boot_flag} 起始LBA={start_lba} 大小={size_lba} 扇区")
PYEOF
步骤3：分析UEFI固件中的植入物
检查UEFI固件卷中是否存在未经授权的模块：
# 使用UEFITool提取UEFI固件组件
# GUI：打开 firmware.rom -> 检查固件卷
# CLI：
UEFIExtract firmware.rom all
# 列出所有DXE驱动程序（UEFI植入最常见的攻击目标）
find firmware.rom.dump -name "*.efi" -exec file {} \;
# 与已知干净的固件模块列表进行比较
# 每个UEFI模块都有一个GUID - 与供应商基线进行比较
# 验证安全启动配置
python chipsec_main.py -m common.secureboot.variables
# 检查SPI闪存写保护
python chipsec_main.py -m common.bios_wp
# 检查已知的UEFI恶意软件模式
yara -r uefi_malware.yar firmware.rom
已知UEFI引导套件检测点：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28)：
- 修改SPI闪存
- 添加一个DXE驱动程序，用于向Windows投放代理
- 在OS重装和磁盘更换后仍能持久存在
BlackLotus：
- 利用CVE-2022-21894绕过安全启动
- 修改EFI系统分区引导加载程序
- 在启动期间安装内核驱动程序
CosmicStrand：
- 修改CORE_DXE固件模块
- 在启动期间钩子内核初始化
- 将Shellcode放入Windows内核内存
MoonBounce：
- CORE_DXE模块中的SPI闪存植入
- 修改GetVariable()函数
- 通过引导链部署用户模式植入
ESPecter：
- 修改ESP上的Windows启动管理器
- 修补winload.efi以禁用DSE
- 加载未签名内核驱动程序
步骤4：检测内核级Rootkit行为
分析运行中的系统以查找Rootkit痕迹：
# Rootkit检测的内存取证
# SSDT钩子检测
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"
# 隐藏进程 (DKOM)
vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt
# 使用diff查找隐藏进程
# 内核回调注册（Rootkit注册回调以进行过滤）
vol3 -f memory.dmp windows.callbacks
# 驱动程序分析
vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules
# 检查未签名驱动程序
vol3 -f memory.dmp windows.driverscan | while read line; do
driver_path=$(echo "$line" | awk '{print $NF}')
if [ -f "$driver_path" ]; then
sigcheck -nobanner "$driver_path" 2>/dev/null | grep "Unsigned"
fi
done
# IDT钩子检测
vol3 -f memory.dmp windows.idt
步骤5：引导过程完整性验证
验证整个引导链的完整性：
# 验证Windows启动管理器签名
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi
# 验证winload.efi
sigcheck -a C:\Windows\System32\winload.efi
# 验证ntoskrnl.exe
sigcheck -a C:\Windows\System32\ntoskrnl.exe
# 检查测量启动日志（如果TPM可用）
# Windows: BCDEdit /enum firmware
bcdedit /enum firmware
# 验证安全启动状态
Confirm-SecureBootUEFI # PowerShell cmdlet
# 检查启动配置是否被篡改
bcdedit /v
# 查找启动配置更改
# testsigning：应为 No
# nointegritychecks：应为 No
# debug：应为 No
bcdedit | findstr /i "testsigning nointegritychecks debug"
步骤6：记录引导套件/Rootkit分析
编写全面的分析发现：
分析应记录：
- 引导扇区（MBR/VBR）完整性状态，附十六进制比较
- UEFI固件模块清单和完整性验证
- 安全启动状态及检测到的任何绕过机制
- 已识别的内核级钩子（SSDT、IDT、IRP、内联）
- 发现的隐藏进程、驱动程序和文件
- 持久化机制（SPI闪存、ESP、MBR、内核驱动程序）
- 引导链完整性验证结果
- 如果可能，归因于已知的引导套件家族
- 补救步骤（重新刷新固件、重建MBR、更换硬件）
关键概念
| 术语 | 定义 |
|---|---|
| 引导套件 | 感染引导过程（MBR、VBR、UEFI）的恶意软件，在操作系统加载前执行，获得持久的底层控制 |
| MBR（主引导记录） | 磁盘的前512字节，包含引导代码和分区表；MBR引导套件用恶意加载程序替换此代码 |
| UEFI（统一可扩展固件接口） | 取代BIOS的现代固件接口；UEFI引导套件将恶意模块植入固件卷或修改ESP |
| 安全启动 | UEFI安全特性，验证引导组件的数字签名；像BlackLotus这样的引导套件利用漏洞绕过它 |
| SPI闪存 | 存储UEFI固件的闪存芯片；像LoJax和MoonBounce这样的高级引导套件修改SPI闪存以实现固件级持久化 |
| DKOM（直接内核对象操作） | Rootkit技术，修改内核结构以隐藏进程、文件和网络连接，而不挂钩函数 |
| 驱动程序签名强制（DSE） | Windows安全特性，要求内核驱动程序经过数字签名；引导套件在引导期间禁用DSE以加载未签名的Rootkit驱动程序 |
工具与系统
- UEFITool：开源UEFI固件映像编辑器和解析器，用于检查固件卷、驱动程序和模块
- chipsec：Intel硬件安全评估框架，用于验证SPI闪存保护、安全启动和UEFI配置
- Volatility：内存取证框架，拥有SSDT、IDT、回调和驱动程序分析插件，用于内核Rootkit检测
- GMER：Windows Rootkit检测工具，扫描SSDT钩子、IDT钩子、隐藏进程和修改过的内核模块
- Bootkits Analyzer：专门分析MBR/VBR代码的工具，包括反汇编并与已知干净基线进行比较
常见场景
场景：调查在OS重装后仍然存在的持久性入侵
上下文：某组织重新镜像了一台受感染的工作站，但相同的C2信标在几小时内恢复了。标准磁盘取证未发现恶意软件。怀疑是UEFI引导套件。
方法：
- 从Linux Live U盘引导，避免执行任何受感染的操作系统组件
- 使用chipsec或flashrom转储SPI闪存固件以供离线分析
- 使用dd转储MBR和VBR扇区以进行引导扇区分析
- 复制EFI系统分区以进行引导加载程序完整性验证
- 在UEFITool中打开SPI转储，并将模块GUID与供应商提供的固件进行比较
- 查找不应存在的新增或修改的DXE驱动程序
- 使用Ghidra（x86_64 UEFI模块格式）分析任何可疑模块
- 验证安全启动配置并检查基于漏洞的绕过
陷阱：
- 在受感染操作系统运行时分析系统（Rootkit可能对实时分析隐藏自身）
- 未检查SPI闪存（仅分析基于磁盘的引导组件会遗漏固件级植入）
- 假设安全启动能阻止所有引导套件（存在已知的绕过方式，例如CVE-2022-21894）
- 在重新刷新前未保存原始固件转储（这是归因的关键证据）
输出格式
引导套件 / ROOTKIT 分析报告
====================================
系统： Dell OptiPlex 7090 (UEFI, TPM 2.0)
固件版本： 1.15.0 (Dell)
安全启动： ENABLED (但已绕过)
捕获方法： Linux Live U盘 + chipsec SPI转储
MBR/VBR 分析
MBR签名： 有效 (0x55AA)
MBR代码： 匹配标准 Windows 10 MBR (干净)
VBR代码： 匹配标准 NTFS VBR (干净)
UEFI固件分析
模块总数： 287
供应商预期值： 285
额外模块： 2 个未经授权的模块
[!] DXE驱动程序 GUID: {ABCD1234-...} "SmmAccessDxe_mod" (已修改)
原始大小：12,288 字节
当前大小：45,056 字节 (新增32KB)
熵值：7.82 (高 - 加密载荷)
[!] DXE驱动程序 GUID: {EFGH5678-...} "UefiPayloadDxe" (新增 - 不在供应商固件中)
大小：28,672 字节
功能：在引导期间投放持久化代理
引导链完整性
bootmgfw.efi： 已修改 (哈希不匹配，通过CVE-2022-21894绕过安全启动)
winload.efi： 已修改 (加载时禁用DSE)
ntoskrnl.exe： 干净 (但在引导后加载了未签名驱动程序)
内核ROOTKIT组件
驱动程序： C:\Windows\System32\drivers\null_mod.sys (未签名，隐藏)
SSDT钩子： 3个 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
隐藏进程： 2个 (PID 6784: beacon.exe, PID 6812: keylog.exe)
隐藏文件： C:\Windows\System32\drivers\null_mod.sys
归因
家族： BlackLotus 变种
置信度： 高 (CVE-2022-21894 漏洞利用，ESP修改模式匹配)
补救措施
1. 通过硬件编程器使用干净的供应商映像重新刷新SPI固件
2. 从干净的Windows安装介质重建EFI系统分区
3. 从已验证的介质重装操作系统
4. 启用所有固件写保护
5. 更新固件至最新版本（修补CVE-2022-21894）