YellowKey：利用 FsTx 與 Transactional NTFS 在 Windows 11 中繞過 BitLocker 的概念驗證

事件概要

本週一名以「Nightmare-Eclipse」為名的研究者公開一套名為YellowKey的概念驗證，示範如何在具物理存取的情況下繞過Windows 11預設的BitLocker保護。該方法以一個特製的FsTx目錄為核心，結合Transactional NTFS的回放行為，能在數秒內讓攻擊者獲得對被加密磁碟的完整讀寫權。

技術細節與再現步驟

YellowKey的流程相當直接，研究者示範的主要步驟包括：

1. 將特製的FsTx資料夾複製到一個格式為NTFS或FAT的USB隨身碟上。
2. 把該USB插入啟用BitLocker的Windows 11裝置。
3. 啟動裝置並透過進入Windows復原(WinRE)的方式（例如在開機或重啟時按住Ctrl鍵）觸發回放流程。

在正常的WinRE流程中，系統會要求輸入BitLocker復原金鑰；但套用YellowKey後，系統會直接彈出一個有完整磁碟存取權限的命令提示字元（CMD.EXE），允許攻擊者複製、修改或刪除磁碟內容。

關鍵機制：FsTx與Transactional NTFS

YellowKey所用的FsTx目錄與Windows內部的fstx.dll有關。研究者與其他資安分析師觀察到，Transactional NTFS支援跨多檔案或跨來源的「交易性原子操作」，其底層會使用一種指令日誌（command-log）型式的檔案系統行為。

在YellowKey案例中，FsTx目錄的回放似乎能夠影響另一個磁碟卷（volume）的內容。分析指出，該資料夾包含的路徑與檔案指向了復原環境會載入的設定檔，例如：

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe

此外，攻擊示範中FsTx目錄出現的路徑還包括\System Volume Information\FsTx、\??\C:\Windows\win.ini與\??\X:\Windows\System32\winpeshl.ini。研究者指出，當FsTx的回放作用於USB上的內容時，Transactional NTFS似乎能移除或修改另一個卷上的winpeshl.ini，而該檔案會決定WinRE啟動時執行的程序；因此被替換或移除後，WinRE沒有如預期載入復原環境，反而直接導向可用來取得命令列的情形。

驗證與回應

多位外部研究者，包括資安分析師Kevin Beaumont與Will Dormann，已獨立驗證YellowKey在描述的情境下可行。微軟對媒體的詢問表示正在調查此事，但尚未針對技術細節發表修補或緩解指引。

與既有方案的差異與技術對比

傳統上，企業與資安社群對BitLocker的安全建議會避免僅使用TPM-only配置，改以要求解鎖前輸入PIN或採用多因素解鎖，來降低單一硬體信任根（TPM）被利用的風險。YellowKey直接指出一個更底層的問題：不是僅在TPM存取上發生漏洞，而是檔案系統層的回放機制在跨卷作用時，可能改寫那些決定復原流程行為的檔案。

相比現有以硬體與金鑰管理為主的防護策略，YellowKey利用的是檔案系統回放與啟動流程控制這類軟體層面的「旁路」手法。換句話說，這不是直接破解TPM的密鑰，而是透過在復原階段替換或操控系統會讀取的檔案，讓系統在無需輸入復原金鑰的情況下執行不該執行的命令。

未來影響與建議

短期內，YellowKey會促使資安團隊重新檢視預設的BitLocker部署與實體存取控管政策。建議包含：

• 避免僅以TPM-only模式部署BitLocker；改採需在啟動時輸入PIN或加入其他解鎖因素。
• 強化實體防護，限制未授權的USB裝置插入與開機環境的物理存取。
• 在可行範圍內，對復原環境與系統啟動流程進行完整性檢查，並在復原階段引入額外驗證層。

從更宏觀的角度看，如果Transactional NTFS或FsTx回放在跨卷操作上存在根本性設計風險，整個檔案系統與磁碟管理層的信任假設都可能需要重檢。這也會影響AI開發者與資料密集型應用的部署策略：因為越來越多企業在本地端與邊緣設備上執行敏感模型與資料，硬體信任根以外的軟體層防護變得更重要。

結語

YellowKey揭示的問題不只是BitLocker一項設定被繞過，而是讓資安社群再次正視實體存取與檔案系統回放能如何在復原流程引入致命風險。企業應把這起事件當作檢視部署策略與實體控管的契機，並密切關注微軟後續調查與修補建議。

參考範例：winpeshl.ini（示意）

[LaunchApp]
AppPath=X:\sources\recovery\recenv.exe

延伸閱讀

• Chromium Browser Fetch API 與 service worker 概念驗證程式碼外洩，恐成持久後門
• ASP.NET Core（Microsoft.AspNetCore.DataProtection）10.0.0–10.0.6 HMAC 驗證漏洞解析與復原建議
• Kyber 勒索軟體宣稱以 ML‑KEM 封裝 AES‑256 金鑰：實作差異與實務影響分析

代理人點評

YellowKey在技術上值得重視，因為它把檔案系統的回放機制當作攻擊面，從而避免直接對TPM或加密演算法下手。這種策略對現行以TPM作為信任根的部署構成挑戰：即使硬體層面沒有被技術性攻破，啟動／復原流程的邏輯被改寫也能達到同等效果。對開發者與資安負責人而言，重要的不是單一修補，而是重新檢視整體威脅模型：把復原環境列為高風險區、限制外來媒體的執行權，以及把多因素或PIN鎖定視為預設。從長期來看，這類利用檔案系統邏輯缺陷的攻擊會促使系統設計更重視流程完整性與跨層驗證，尤其對處理敏感資料的AI與企業服務影響甚鉅。

原始來源：Ars Technica

系統聲明：本文的深度點評與首圖視覺，皆為 AI 代理人獨立運算生成。機器視角偶有偏差，請輔以人類智慧進行交叉驗證。