分析開機套件與 Rootkit 樣本
使用時機
- 系統顯示受入侵跡象，且即使重新安裝作業系統仍持續存在
- 儘管有明確的入侵證據，防毒軟體和 EDR 仍無法偵測到惡意軟體
- UEFI Secure Boot 已被停用或顯示完整性違規
- 記憶體鑑識揭示 rootkit 行為（隱藏程序、系統呼叫劫持）
- 調查已知會部署開機套件的國家級威脅（APT28、APT41、Equation Group）
請勿用於標準的使用者模式惡意軟體；開機套件和 rootkit 在根本不同的層級運作，需要專門的分析技術。
先決條件
- 磁碟成像工具（dd、FTK Imager），用於擷取 MBR/VBR 磁區
- UEFITool，用於 UEFI 韌體卷分析與模組萃取
- chipsec，用於硬體層級的韌體安全評估
- Ghidra（含 x86 真實模式與 16 位元支援），用於 MBR 程式碼分析
- Volatility 3，用於核心級 rootkit 特徵檢測
- 可啟動的 Linux Live USB，用於離線系統分析
工作流程
步驟 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 - 與供應商基準比較
# 驗證 Secure Boot 配置
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
- 即使重新安裝作業系統和更換磁碟仍能持續存在
BlackLotus：
- 利用 CVE-2022-21894 繞過 Secure Boot
- 修改 EFI 系統分割區的開機載入器
- 在開機期間安裝核心驅動程式
CosmicStrand：
- 修改 CORE_DXE 韌體模組
- 在開機期間劫持核心初始化
- 將 shellcode 投放至 Windows 核心記憶體
MoonBounce：
- SPI 快閃記憶體植入物存在於 CORE_DXE 模組中
- 修改 GetVariable() 函數
- 透過開機鏈部署使用者模式植入
ESPecter：
- 修改 ESP 上的 Windows Boot Manager
- 修補 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
# 比對以找出隱藏程序
# 核心回呼註冊（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 Boot Manager 簽名
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
# 檢查 Measured Boot 記錄（如果 TPM 可用）
# Windows：BCDEdit /enum firmware
bcdedit /enum firmware
# 驗證 Secure Boot 狀態
Confirm-SecureBootUEFI # PowerShell cmdlet
# 檢查開機配置是否被篡改
bcdedit /v
# 尋找開機配置的變更
# testsigning：應為 No
# nointegritychecks：應為 No
# debug：應為 No
bcdedit | findstr /i "testsigning nointegritychecks debug"
步驟 6：記錄開機套件/Rootkit 分析
編譯全面的分析發現：
分析應記錄：
- 開機磁區 (MBR/VBR) 完整性狀態（含十六進位比較）
- UEFI 韌體模組清單與完整性驗證
- Secure Boot 狀態及檢測到的任何繞過機制
- 已識別的核心級劫持（SSDT、IDT、IRP、內聯）
- 發現的隱藏程序、驅動程式和檔案
- 持久性機制（SPI 快閃記憶體、ESP、MBR、核心驅動程式）
- 開機鏈完整性驗證結果
- 可能的話，歸屬於已知的開機套件家族
- 補救步驟（重新刷新韌體、重建 MBR、更換硬體）
關鍵概念
| 術語 | 定義 |
|---|---|
| 開機套件 | 感染開機程序（MBR、VBR、UEFI）的惡意軟體，使其在作業系統載入之前執行，從而獲得持續的低階控制 |
| MBR (Master Boot Record) | 磁碟的前 512 位元組，包含開機程式碼和分割表；MBR 開機套件會用惡意載入器取代此程式碼 |
| UEFI (Unified Extensible Firmware Interface) | 取代 BIOS 的現代韌體介面；UEFI 開機套件會在韌體卷中植入惡意模組或修改 ESP |
| Secure Boot | UEFI 安全功能，驗證開機元件的數位簽章；BlackLotus 等開機套件會利用漏洞繞過它 |
| SPI 快閃記憶體 | 儲存 UEFI 韌體的快閃記憶體晶片；LoJax 和 MoonBounce 等高階開機套件會修改 SPI 快閃記憶體以實現韌體層級的持久性 |
| DKOM (Direct Kernel Object Manipulation) | Rootkit 技術，修改核心結構以隱藏程序、檔案和網路連線，而不需要劫持函數 |
| 驅動程式簽章強制執行 (DSE) | Windows 安全功能，要求核心驅動程式必須經數位簽章；開機套件會在開機期間停用 DSE，以載入未簽署的 rootkit 驅動程式 |
工具與系統
- UEFITool：開源的 UEFI 韌體映像編輯器和解析器，用於檢查韌體卷、驅動程式和模組
- chipsec：Intel 硬體安全評估框架，用於驗證 SPI 快閃記憶體保護、Secure Boot 和 UEFI 配置
- Volatility：記憶體鑑識框架，具有 SSDT、IDT、回呼和驅動程式分析外掛，適用於核心 rootkit 偵測
- GMER：Windows rootkit 偵測工具，可掃描 SSDT 劫持、IDT 劫持、隱藏程序和修改過的核心模組
- Bootkits Analyzer：專用於分析 MBR/VBR 程式碼的工具，包括反組譯和與已知良好基準的比較
常見情境
情境：調查在作業系統重新安裝後仍持續存在的入侵
背景：某組織重新映像了一台受入侵的工作站，但相同的 C2 通訊在幾小時內就恢復了。標準磁碟鑑識找不到惡意軟體。懷疑是 UEFI 開機套件。
方法：
- 從 Linux Live USB 啟動，以避免執行任何受入侵的作業系統元件
- 使用 chipsec 或 flashrom 傾印 SPI 快閃記憶體韌體以進行離線分析
- 使用 dd 傾印 MBR 和 VBR 磁區以進行開機磁區分析
- 複製 EFI 系統分割區以進行開機載入器完整性驗證
- 在 UEFITool 中開啟 SPI 傾印，並將模組 GUID 與供應商提供的韌體進行比較
- 尋找不應存在的額外或修改過的 DXE 驅動程式
- 使用 Ghidra（x86_64 UEFI 模組格式）分析任何可疑模組
- 驗證 Secure Boot 配置，並檢查是否存在基於漏洞的繞過方式
陷阱：
- 在受入侵的作業系統正在執行時分析系統（rootkit 可能對即時分析隱藏）
- 未檢查 SPI 快閃記憶體（僅分析基於磁碟的開機元件會遺漏韌體層級的植入物）
- 假設 Secure Boot 能防止所有開機套件（存在已知的繞過方式，例如 CVE-2022-21894）
- 在重新刷新之前未保留原始的韌體傾印（這對於歸因是關鍵證據）
輸出格式
開機套件 / ROOTKIT 分析報告
====================================
系統： Dell OptiPlex 7090 (UEFI, TPM 2.0)
韌體版本： 1.15.0 (Dell)
Secure Boot： 已啟用（但已被繞過）
擷取方式： Linux Live USB + 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 繞過 Secure Boot）
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）