Black Hat USA 2025 | BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets
三句話摘要
微軟安全研究員在 Black Hat 揭露四個 WinRE（Windows 復原環境）中的 BitLocker 繞過漏洞，並示範如何在不知道密碼或金鑰的情況下完整解密受保護的磁碟。 WinRE 因架構上必須駐留於未加密磁碟區並在解鎖狀態下解析外部檔案，天然形成 BitLocker 的攻擊入口——啟用 TPM + PIN 預啟動驗證是目前唯一能完整封堵此類攻擊路徑的防禦手段。 WinRE 是 BitLocker 攻擊面的核心盲點
重點整理
重點- 1
WinRE 是 BitLocker 攻擊面的核心盲點
- 2
WinRE 本就在 BitLocker 的威脅模型範圍內（實體存取即可觸發），卻長期缺乏安全研究關注。它運行於獨立的復原 OS，並因支援 BitLocker 復原功能而設計了自動解鎖機制，形成高風險攻擊面。
- 3
「信任的 WIM」驗證機制存在結構性缺陷
- 4
Trusted WinRE 設計透過比對 WIM 雜湊來決定是否自動解鎖 OS 磁碟區，但雜湊驗證與實際執行的 WIM 之間缺乏綁定，攻擊者可在 SDI 檔案中附加惡意 WIM 並調整偏移量，使系統執行未受信任的 WIM 同時保持 OS 磁碟區解鎖狀態。
- 5
受信任的合法應用程式本身即可成為攻擊跳板
- 6
SetupPlatform 作為 Windows 升級殘留的已信任 App，在啟動時會查找復原磁碟區上的 INI 設定檔。攻擊者可偽造該 INI 觸發訊息框使應用程式無限期阻塞，從而有足夠時間透過 Shift+F10 熱鍵在 OS 解鎖狀態下啟動命令提示字元。
- 7
BCD 磁碟區迭代順序錯誤導致 OS 身份混淆，進而觸發任意磁碟區解密
- 8
`FindFirstVolume`/`FindNextVolume` API 的排序與實際磁碟順序不一致，復原磁碟區會先於 EFI 磁碟區被掃描。攻擊者在復原磁碟區放置偽造 BCD，可讓 WinRE 的 PBR（Push Button Reset）把復原磁碟區誤認為 OS 磁碟區，繼而載入攻擊者提供的 `reset-session.xml`，指示 PBR 解密真正的 BitLocker 加密磁碟區，最終完全停用 BitLocker。
實用技巧與重點
乾貨- 統計數字
- 每 53 秒有一台筆電遭竊
- 筆電被竊機率：1/10
- 平均損失成本：$49,000 美元（含更換、生產力損失、法律費用、資料洩漏）
- 漏洞與 CVE
- 所有漏洞於 2024 年 7 月 Patch Tuesday 修補（CVE 編號顯示於演講投影片）
- 漏洞一：Boot SDI WIM 偏移劫持
- 目標檔案：`boot.sdi`（位於復原磁碟區）
- 手法：附加未受信任 WIM，修改 SDI 中的 WIM offset 指向惡意 WIM
- 效果：Trusted WIM 雜湊驗證通過，但執行的是惡意 WIM；OS 磁碟區維持解鎖
- 漏洞二：TTTracer 離線掃描濫用
- 目標檔案：`reagent.xml`（位於復原磁碟區）
- 工具：`TTTracer.exe`（時間旅行除錯器，Microsoft 簽署，約 30 個符合條件的應用程式中唯一可利用者）
- 手法：設定離線掃描排程，指定 TTTracer 追蹤 `cmd.exe`
- 效果：在自動解鎖狀態下獲得命令列 Shell
- 漏洞三：SetupPlatform 熱鍵時間差 + INI 阻塞
- 目標檔案：`reagent.xml` + `SetupPlatform.ini`（放於復原磁碟區）
- 手法：排程 SetupPlatform 為信任 App → 偽造 INI 觸發 MessageBox 阻塞程序 → 按 Shift+F10 啟動 cmd
- 效果：繞過熱鍵觸發的極短時間窗口，在解鎖狀態獲得 Shell
- 漏洞四：BCD 混淆 + PBR 任意磁碟區解密
- 目標檔案：`reagent.xml`、復原磁碟區上的偽造 `BCD`、`reset-session.xml`
- 關鍵 API 問題：`FindFirstVolume`/`FindNextVolume` 返回順序為 OS → 復原 → EFI，而非預期的 OS → EFI → 復原
- 手法：在復原磁碟區放置偽造 BCD（OS device 指向復原磁碟區）→ 配置 `reset-session.xml` 含 `decrypt volume` 指令針對真實 OS 磁碟區
- 效果：PBR 自動解密 BitLocker 加密磁碟區，Protection 變 OFF，資料完全暴露
- 防禦建議
- 啟用 TPM + PIN 預啟動驗證（可完全阻斷 WinRE 層所有 BitLocker 繞過）
- 啟用 Secure Boot 版本強制機制（防止降級攻擊重新引入已修補漏洞）
結論
結論“WinRE 因架構上必須駐留於未加密磁碟區並在解鎖狀態下解析外部檔案，天然形成 BitLocker 的攻擊入口——啟用 TPM + PIN 預啟動驗證是目前唯一能完整封堵此類攻擊路徑的防禦手段。”
完整解析
詳細BitLocker 是 Windows 的全磁碟加密功能，其威脅模型假設攻擊者具備完整實體存取能力，但缺乏系統憑證（如使用者密碼）。來自微軟 STORM 團隊的兩位研究員 Alon 與 Netanel 在 Black Hat 發表研究，聚焦於一個長期被忽略的攻擊面：Windows 復原環境（WinRE）。WinRE 本就設計為可在無密碼情況下啟動（按住 Shift 鍵再點選「重新啟動」即可進入），理論上不應讓攻擊者獲得更多權限——然而研究發現，現實中的設計細節與安全假設之間存在多個裂縫。
WinRE 架構上以獨立復原 OS 運行，整個系統壓縮為 `winre.wim` 並儲存於未加密的復原磁碟區（因為若 OS 磁碟區解密失敗，WinRE 必須仍能啟動）。為防止攻擊者竄改 WIM 後仍能自動解鎖 OS，微軟引入「Trusted WinRE」機制，透過雜湊比對確認 WIM 完整性，若雜湊不符則 OS 磁碟區維持上鎖。此外，每當使用者選擇「命令提示字元」等高風險工具時，系統會主動重新上鎖 OS 磁碟區，迫使使用者輸入 BitLocker 復原金鑰才能繼續操作。這套設計看似嚴密，研究員卻在三個外部解析的檔案中發現漏洞：`boot.sdi`、`reagent.xml` 以及儲存於 EFI 磁碟區的 BCD 設定檔。
第一個漏洞利用 `boot.sdi` 格式的結構特性。`boot.sdi` 負責定義 RAM Disk 中 WIM 的位置，但系統只驗證緊接在 SDI 後方的那份 WIM 雜湊，卻不驗證最終執行的 WIM 是否就是那份。攻擊者可在 SDI 後附加一份惡意 WIM，並修改 SDI 內的偏移量使其指向惡意版本，雜湊驗證通過（因受信任的 WIM 仍在原位），但系統實際載入並執行的卻是攻擊者的 WIM，同時 OS 磁碟區維持自動解鎖。第二與第三個漏洞則利用 `reagent.xml` 的排程操作功能：離線掃描排程可指定由 TTTracer（微軟簽署的時間旅行除錯器）執行並追蹤任意程序，攻擊者藉此讓它追蹤 `cmd.exe`，在解鎖狀態下取得 Shell；另一條路徑則濫用 SetupPlatform 這個 Windows 升級後殘留的已信任 App，透過偽造 INI 設定觸發訊息框使其無限等待，再按 Shift+F10 熱鍵喚出命令提示字元。
最複雜的第四個漏洞來自 BCD 解析邏輯。WinRE 在啟動時會呼叫 `FindFirstVolume`/`FindNextVolume` API 逐一掃描磁碟區尋找 BCD 設定檔，但這兩個 API 的返回順序（OS → 復原 → EFI）與實際磁碟順序（OS → EFI → 復原）不一致，導致復原磁碟區在 EFI 磁碟區之前被掃描。攻擊者只需在復原磁碟區放置一份偽造 BCD（將 OS 裝置指向復原磁碟區），WinRE 就會把攻擊者控制的復原磁碟區誤認為受信任的 OS 磁碟區，進而從該處讀取 PBR（Push Button Reset）設定。攻擊者預先在復原磁碟區放置包含 `decrypt volume` 指令的 `reset-session.xml`，指向真實的加密 OS 磁碟區，PBR 執行後便完整解密 BitLocker，讓 OS 磁碟區在不需要任何密碼或金鑰的情況下全面暴露。所有四個漏洞均已於 2024 年 7 月 Patch Tuesday 修補。防禦建議為啟用 TPM + PIN 預啟動驗證，以及開啟 Secure Boot 版本強制機制以防降級攻擊。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
