分析 UEFI 開機工具持久化 是做什麼的？
使用時機
- 系統在 OS 重裝或更換硬碟後重新建立 C2 通訊
- Secure Boot 被篡改、停用，或出現未預期的機器擁有者金鑰 (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，用於離線分析（避免執行受感染的 OS）
- Volatility 3，用於啟動階段元件的記憶體取證
- YARA 搭配 UEFI 惡意軟體規則集，進行模式比對偵測
- 可取得廠商韌體基準值，用於完整性比對
工作流程
步驟 1：傾印 SPI 快閃韌體
從 SPI 快閃晶片取得 UEFI 韌體，以供離線分析：
# 使用 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
# 讀取特定 Secure Boot 變數
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
# 檢查 Secure Boot 配置模組
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：偵測 Secure Boot 繞過機制
檢查已知的 Secure Boot 繞過技術：
# 檢查 Secure Boot 是否啟用
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（Hypervisor 強制程式碼完整性）未被停用
# BlackLotus 設定 HKLM:\...\DeviceGuard\...\HypervisorEnforcedCodeIntegrity Enabled=0
reg query "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled
# 透過 PowerShell 檢查 Secure Boot 狀態
# 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 快閃保護狀態（寫入保護、鎖定位元、存取控制）
- Secure Boot 配置及偵測到的繞過指標
- UEFI 變數異常（未授權金鑰、修改的 db/dbx、MOK 註冊）
- ESP 內容清單，包含與已知正確基準值的雜湊驗證結果
- 與廠商白名單的韌體模組比對結果（新增、修改、刪除）
- 已知開機工具家族歸屬及信心水準
- 每個元件的開機鏈完整性驗證結果
- 補救步驟（重新刷寫、金鑰輪換、硬體更換）
- MITRE ATT&CK 對應（T1542.001 - 系統韌體、T1542.003 - 開機工具）
關鍵概念
| 術語 | 定義 |
|---|---|
| UEFI 開機工具 | 持續存在於 UEFI 韌體或開機程序中的惡意軟體，在作業系統載入前執行，且能在 OS 重裝後倖存 |
| SPI 快閃 | 主機板上的序列周邊介面快閃記憶體晶片，儲存 UEFI 韌體；LoJax 和 MoonBounce 等韌體層級開機工具會修改 SPI 快閃內容 |
| EFI 系統分割區 (ESP) | 包含 EFI 開機載入程式和驅動程式的 FAT32 分割區；BlackLotus 和 ESPecter 等開機工具會修改 ESP 上的檔案以達成持久化 |
| Secure Boot | UEFI 安全功能，驗證開機元件的數位簽章；可透過漏洞（CVE-2022-21894）或 MOK 註冊繞過 |
| DXE 驅動程式 | 在 UEFI 開機期間載入的驅動程式執行環境驅動程式；韌體植入會注入惡意的 DXE 驅動程式，使其在 OS 之前執行 |
| 機器擁有者金鑰 (MOK) | 使用者可安裝的 Secure Boot 金鑰；BlackLotus 會註冊攻擊者控制的 MOK，以簽署惡意開機載入程式 |
| chipsec | Intel 平台安全評估框架，用於分析 SPI 快閃、UEFI 變數、Secure Boot 及硬體安全配置 |
| HVCI | Hypervisor 強制程式碼完整性，是一項 Windows 安全功能；開機工具會將其停用以載入未簽署的核心驅動程式 |
工具與系統
- chipsec：Intel 框架，用於傾印 SPI 快閃、讀取 UEFI 變數、驗證韌體寫入保護及稽核 Secure Boot 配置
- UEFITool：開源 UEFI 韌體映像解析器，用於檢查韌體區塊、提取 DXE 驅動程式及比對模組 GUID
- sigcheck：Sysinternals 公用程式，用於驗證 EFI 二進位檔及開機鏈元件的數位簽章
- flashrom：開源 SPI 快閃程式設計器，用於在支援的平台上讀寫韌體晶片
- YARA：模式比對引擎，搭配 UEFI 專用規則集，可在韌體傾印中偵測已知開機工具特徵
常見案例
案例：調查 OS 重裝後仍持續存在的入侵
背景：企業端點在確認遭到入侵後重新安裝映像，但數小時內相同的 C2 通訊恢復。端點使用 UEFI 韌體且 Secure Boot 已啟用，並配備 TPM 2.0 晶片。安全團隊懷疑存在類似 BlackLotus 或 LoJax 的 UEFI 層級植入。
方法：
- 從可信的 Linux live USB 開機，避免執行任何受感染的 OS 元件
- 使用
chipsec_util.py spi dump傾印 SPI 快閃韌體以供離線分析 - 掛載 ESP 並對所有
.efi檔案進行雜湊，與相同硬體的已知正確值比對 - 檢查
ESP:/system32/目錄（BlackLotus 指標）及未經授權的grubx64.efi - 使用 UEFIExtract 提取韌體模組，並將 GUID 清單與廠商基準值比對
- 驗證 Secure Boot 變數——檢查未授權的 MOK 註冊或修改的 db/dbx
- 使用 chipsec 模組檢查 SPI 快閃寫入保護及鎖定位元
- 使用 UEFI 專用 YARA 規則掃描韌體傾印及提取的模組
- 若懷疑是 BlackLotus，請檢查登錄中 HVCI 是否停用，以及 MeasuredBoot 記錄中是否有異常項目
陷阱：
- 從受感染的 OS 執行分析（Rootkit 元件會對即時分析隱藏）
- 僅檢查 ESP 而未檢查 SPI 快閃韌體（遺漏 LoJax、MoonBounce 等韌體層級植入）
- 假設 Secure Boot 可防止所有開機工具（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)
Secure Boot： 已啟用（已透過 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 stage-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. 將 Secure Boot 金鑰重設為出廠預設值（清除 MOK、還原 PK/KEK/db）
4. 啟用 BIOS 寫入保護並確認 SPI 快閃鎖定位元
5. 套用最新版本的韌體更新（修補 CVE-2022-21894）
6. 啟用 HVCI 並透過群組原則確認
7. 僅將受信任的憑證重新匯入 Secure Boot db
8. 監控 MeasuredBoot 記錄中是否有異常的開機元件載入