analyzing-bootkit-and-rootkit-samples

分析 Bootkit 与 Rootkit 样本

何时使用

• 系统出现即使重装操作系统后仍然存在的入侵迹象
• 尽管有明确的入侵证据，杀毒软件和 EDR 仍无法检测到恶意软件
• UEFI Secure Boot 已被禁用或显示完整性违规
• 内存取证揭示 rootkit 行为（隐藏进程、被挂钩的系统调用）
• 调查已知会部署 bootkit 的国家级威胁（APT28、APT41、Equation Group）

不要使用于标准用户态恶意软件；bootkit 和 rootkit 运行在根本不同的层级，需要专门的分析技术。

前提条件

• 用于获取 MBR/VBR 扇区的磁盘映像工具（dd、FTK Imager）
• 用于 UEFI 固件卷分析和模块提取的 UEFITool
• 用于硬件级固件安全评估的 chipsec
• 支持 x86 实模式和 16 位、用于 MBR 代码分析的 Ghidra
• 用于内核级 rootkit 痕迹检测的 Volatility 3
• 用于离线系统分析的可启动 Linux live USB

工作流

步骤 1：获取引导扇区和固件

提取 MBR、VBR 和 UEFI 固件以进行离线分析：

# Acquire MBR (first 512 bytes of disk)
dd if=/dev/sda of=mbr.bin bs=512 count=1

# Acquire first track (usually contains bootkit code beyond MBR)
dd if=/dev/sda of=first_track.bin bs=512 count=63

# Acquire VBR (Volume Boot Record - first sector of partition)
dd if=/dev/sda1 of=vbr.bin bs=512 count=1

# Acquire UEFI System Partition
mkdir /mnt/efi
mount /dev/sda1 /mnt/efi
cp -r /mnt/efi/EFI /analysis/efi_backup/

# Dump UEFI firmware (requires chipsec or flashrom)
# Using chipsec:
python chipsec_util.py spi dump firmware.rom

# Using flashrom:
flashrom -p internal -r firmware.rom

# Verify firmware dump integrity
sha256sum firmware.rom

步骤 2：分析 MBR/VBR 中的 Bootkit 代码

检查引导扇区代码是否存在恶意修改：

# Disassemble MBR code (16-bit real mode)
ndisasm -b16 mbr.bin > mbr_disasm.txt

# Compare MBR with known-good Windows MBR
# Standard Windows MBR begins with: EB 5A 90 (JMP 0x5C, NOP)
# Standard 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()

# Check MBR signature (bytes 510-511 should be 0x55AA)
if mbr[510:512] == b'\x55\xAA':
    print("[*] Valid MBR signature (0x55AA)")
else:
    print("[!] Invalid MBR signature")

# Check for known bootkit signatures
bootkit_sigs = {
    b'\xE8\x00\x00\x5E\x81\xEE': "TDL4/Alureon bootkit",
    b'\xFA\x33\xC0\x8E\xD0\xBC\x00\x7C\x8B\xF4\x50\x07': "Standard Windows MBR (clean)",
    b'\xEB\x5A\x90\x4E\x54\x46\x53': "Standard NTFS VBR (clean)",
}

for sig, name in bootkit_sigs.items():
    if sig in mbr:
        print(f"[{'!' if 'clean' not in name else '*'}] Signature match: {name}")

# Check partition table entries
print("\nPartition Table:")
for i in range(4):
    offset = 446 + (i * 16)
    entry = mbr[offset:offset+16]
    if entry != b'\x00' * 16:
        boot_flag = "Active" if entry[0] == 0x80 else "Inactive"
        part_type = entry[4]
        start_lba = int.from_bytes(entry[8:12], 'little')
        size_lba = int.from_bytes(entry[12:16], 'little')
        print(f"  Partition {i+1}: Type=0x{part_type:02X} {boot_flag} Start=LBA {start_lba} Size={size_lba} sectors")
PYEOF

步骤 3：分析 UEFI 固件中的植入物

检查 UEFI 固件卷中是否存在未授权模块：

# Extract UEFI firmware components with UEFITool
# GUI: Open firmware.rom -> Inspect firmware volumes
# CLI:
UEFIExtract firmware.rom all

# List all DXE drivers (most common target for UEFI implants)
find firmware.rom.dump -name "*.efi" -exec file {} \;

# Compare against known-good firmware module list
# Each UEFI module has a GUID - compare against vendor baseline

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

# Check SPI flash write protection
python chipsec_main.py -m common.bios_wp

# Check for known UEFI malware patterns
yara -r uefi_malware.yar firmware.rom

Known UEFI Bootkit Detection Points:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax (APT28):
  - Modified SPI flash
  - Added DXE driver that drops agent to Windows
  - Persists through OS reinstall and disk replacement

BlackLotus:
  - Exploits CVE-2022-21894 to bypass Secure Boot
  - Modifies EFI System Partition bootloader
  - Installs kernel driver during boot

CosmicStrand:
  - Modifies CORE_DXE firmware module
  - Hooks kernel initialization during boot
  - Drops shellcode into Windows kernel memory

MoonBounce:
  - SPI flash implant in CORE_DXE module
  - Modified GetVariable() function
  - Deploys user-mode implant through boot chain

ESPecter:
  - Modifies Windows Boot Manager on ESP
  - Patches winload.efi to disable DSE
  - Loads unsigned kernel driver

步骤 4：检测内核级 Rootkit 行为

分析正在运行的系统中的 rootkit 痕迹：

# Memory forensics for rootkit detection
# SSDT hook detection
vol3 -f memory.dmp windows.ssdt | grep -v "ntoskrnl\|win32k"

# Hidden processes (DKOM)
vol3 -f memory.dmp windows.psscan > psscan.txt
vol3 -f memory.dmp windows.pslist > pslist.txt
# Diff to find hidden processes

# Kernel callback registration (rootkits register callbacks for filtering)
vol3 -f memory.dmp windows.callbacks

# Driver analysis
vol3 -f memory.dmp windows.driverscan
vol3 -f memory.dmp windows.modules

# Check for unsigned drivers
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 hook detection
vol3 -f memory.dmp windows.idt

步骤 5：引导过程完整性验证

验证整个引导链的完整性：

# Verify Windows Boot Manager signature
sigcheck -a C:\Windows\Boot\EFI\bootmgfw.efi

# Verify winload.efi
sigcheck -a C:\Windows\System32\winload.efi

# Verify ntoskrnl.exe
sigcheck -a C:\Windows\System32\ntoskrnl.exe

# Check Measured Boot logs (if TPM is available)
# Windows: BCDEdit /enum firmware
bcdedit /enum firmware

# Verify Secure Boot state
Confirm-SecureBootUEFI  # PowerShell cmdlet

# Check boot configuration for tampering
bcdedit /v

# Look for boot configuration changes
# testsigning: should be No
# nointegritychecks: should be No
# debug: should be No
bcdedit | findstr /i "testsigning nointegritychecks debug"

步骤 6：记录 Bootkit/Rootkit 分析

汇总全面的分析发现：

Analysis should document:
- Boot sector (MBR/VBR) integrity status with hex comparison
- UEFI firmware module inventory and integrity verification
- Secure Boot status and any bypass mechanisms detected
- Kernel-level hooks (SSDT, IDT, IRP, inline) identified
- Hidden processes, drivers, and files discovered
- Persistence mechanism (SPI flash, ESP, MBR, kernel driver)
- Boot chain integrity verification results
- Attribution to known bootkit families if possible
- Remediation steps (reflash firmware, rebuild MBR, replace hardware)

关键概念

术语	定义
Bootkit	感染引导过程（MBR、VBR、UEFI）以在操作系统加载之前执行的恶意软件，从而获得持久的低级控制权
MBR（主引导记录）	磁盘的前 512 字节，包含引导代码和分区表；MBR bootkit 会将该代码替换为恶意加载器
UEFI（统一可扩展固件接口）	取代 BIOS 的现代固件接口；UEFI bootkit 会在固件卷中植入恶意模块或修改 ESP
Secure Boot	UEFI 安全功能，用于验证引导组件的数字签名；BlackLotus 等 bootkit 利用漏洞绕过它
SPI Flash	存储 UEFI 固件的闪存芯片；LoJax 和 MoonBounce 等高级 bootkit 会修改 SPI flash 以实现固件级持久化
DKOM（直接内核对象操作）	一种 rootkit 技术，通过修改内核结构来隐藏进程、文件和网络连接，而无需挂钩函数
驱动程序签名强制（DSE）	Windows 安全功能，要求内核驱动程序经过数字签名；bootkit 会在引导期间禁用 DSE 以加载未签名的 rootkit 驱动程序

工具与系统

• UEFITool：开源 UEFI 固件映像编辑器和解析器，用于检查固件卷、驱动程序和模块
• chipsec：Intel 硬件安全评估框架，用于验证 SPI flash 保护、Secure Boot 和 UEFI 配置
• Volatility：内存取证框架，带有 SSDT、IDT、回调和驱动程序分析插件，用于内核 rootkit 检测
• GMER：Windows rootkit 检测工具，用于扫描 SSDT 挂钩、IDT 挂钩、隐藏进程和被修改的内核模块
• Bootkits Analyzer：用于分析 MBR/VBR 代码的专用工具，包括反汇编以及与已知良好基线进行对比

常见场景

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

背景：某组织对一台已遭入侵的工作站重新进行了镜像部署，但数小时内相同的 C2 信标通信又恢复了。标准磁盘取证未发现任何恶意软件。怀疑存在 UEFI bootkit。

方法：

1. 从 Linux 启动 U 盘引导，以避免执行任何已遭入侵的操作系统组件
2. 使用 chipsec 或 flashrom 转储 SPI 闪存固件，以便进行离线分析
3. 使用 dd 转储 MBR 和 VBR 扇区，以便进行引导扇区分析
4. 复制 EFI 系统分区，以便验证引导加载程序完整性
5. 在 UEFITool 中打开 SPI 转储文件，并将模块 GUID 与厂商提供的固件进行比对
6. 查找本不应存在的额外或已修改的 DXE 驱动程序
7. 使用 Ghidra 分析任何可疑模块（x86_64 UEFI 模块格式）
8. 验证 Secure Boot 配置，并检查是否存在基于漏洞利用的绕过方式

陷阱：

• 在已遭入侵的操作系统运行时分析系统（rootkit 可能会躲避实时分析）
• 未检查 SPI 闪存（仅分析基于磁盘的引导组件会遗漏固件级植入物）
• 假设 Secure Boot 能阻止所有 bootkit（已知存在绕过方式，例如 CVE-2022-21894）
• 在重新刷写前未保留原始固件转储（用于归因的关键证据）

输出格式

BOOTKIT / ROOTKIT ANALYSIS REPORT
====================================
System:           Dell OptiPlex 7090 (UEFI, TPM 2.0)
Firmware Version: 1.15.0 (Dell)
Secure Boot:      ENABLED (but bypassed)
Capture Method:   Linux Live USB + chipsec SPI dump

MBR/VBR ANALYSIS
MBR Signature:    Valid (0x55AA)
MBR Code:         MATCHES standard Windows 10 MBR (clean)
VBR Code:         MATCHES standard NTFS VBR (clean)

UEFI FIRMWARE ANALYSIS
Total Modules:    287
Vendor Expected:  285
Extra Modules:    2 UNAUTHORIZED
  [!] DXE Driver GUID: {ABCD1234-...} "SmmAccessDxe_mod" (MODIFIED)
      Original Size: 12,288 bytes
      Current Size:  45,056 bytes (32KB ADDED)
      Entropy: 7.82 (HIGH - encrypted payload)

  [!] DXE Driver GUID: {EFGH5678-...} "UefiPayloadDxe" (NEW - not in vendor firmware)
      Size: 28,672 bytes
      Function: Drops persistence agent during boot

BOOT CHAIN INTEGRITY
bootmgfw.efi:     MODIFIED (hash mismatch, Secure Boot bypass via CVE-2022-21894)
winload.efi:      MODIFIED (DSE disabled at load time)
ntoskrnl.exe:     CLEAN (but unsigned driver loaded after boot)

KERNEL ROOTKIT COMPONENTS
Driver:           C:\Windows\System32\drivers\null_mod.sys (unsigned, hidden)
SSDT Hooks:       3 (NtQuerySystemInformation, NtQueryDirectoryFile, NtDeviceIoControlFile)
Hidden Processes: 2 (PID 6784: beacon.exe, PID 6812: keylog.exe)
Hidden Files:     C:\Windows\System32\drivers\null_mod.sys

ATTRIBUTION
Family:           BlackLotus variant
Confidence:       HIGH (CVE-2022-21894 exploit, ESP modification pattern matches)

REMEDIATION
1. Reflash SPI firmware with clean vendor image via hardware programmer
2. Rebuild EFI System Partition from clean Windows installation media
3. Reinstall OS from verified media
4. Enable all firmware write protections
5. Update firmware to latest version (patches CVE-2022-21894)