YellowKey 漏洞示範：利用 FsTx 與 Transactional NTFS 繞過 Windows 11 預設 BitLocker

概要

一個名為 YellowKey 的漏洞概念驗證在網路流傳，研究者以化名 Nightmare-Eclipse 發表示範。此方法在具體的實體存取情境下，利用一個特製的 FsTx 目錄與 Transactional NTFS（交易式 NTFS）的回放行為，能夠繞過 Windows 11 在預設模式下（解密金鑰僅儲存在 TPM）所提供的 BitLocker 保護，並在短時間內取得整個磁碟的存取權限。

黃金流程：攻擊步驟概覽

YellowKey 的操作步驟相當直接，研究者在示範中列出的流程包含：

• 將特製的 FsTx 資料夾複製到 NTFS 或 FAT 格式的 USB 裝置上。
• 將該 USB 插入受 BitLocker 保護的裝置。
• 啟動裝置並在適當時機進入 Windows Recovery（WinRE）回復模式，示範中是按住 Ctrl 鍵或透過其他進入回復模式的方式。
• 一旦 WinRE 啟動並回放該 FsTx 內容，攻擊者會取得一個具有完整磁碟存取權限的命令提示字元（CMD.EXE），而不需要輸入 BitLocker 回復金鑰。

技術重點：FsTx 與交易式 NTFS 的角色

YellowKey 的核心不是傳統的憑證竊取，而是檔案系統層級的回放行為。根據研究以及其他資安研究者（例如 Kevin Beaumont、Will Dormann）的觀察，重點包括：

• FsTx 目錄與系統的 fstx.dll 有關，這與 Windows 的 Transactional NTFS 機制連動，該機制讓某些檔案操作能以交易原子性執行。
• 在回放過程中，USB 上的交易式檔案系統資料似乎能影響另一個卷（volume）的內容，這表示回放可能跨卷影響檔案系統的狀態，而非只在同一卷內作用。
• 觀察到的路徑與檔案包括類似 \??\C:\Windows\win.ini 與 \??\X:\Windows\System32\winpeshl.ini，後者會控制 WinRE 啟動時的行為，若被改寫就可能讓系統啟動到命令提示字元而非預期的回復流程。

示例：WinRE 啟動設定片段

研究者在分析中引用了 WinRE 所使用的啟動設定範例，示意該檔案如何定義啟動應用程式：

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

攻擊示範中，FsTx 回放導致目標卷上的 winpeshl.ini 被修改或刪除，進而改變 WinRE 的啟動流程，最終啟動命令提示字元而非要求 BitLocker 回復金鑰。

跨主題比較：YellowKey 與現有防護差異

傳統上，對抗 BitLocker 旁路的建議多聚焦於加強 TPM 的使用模式，例如要求在取用 TPM 儲存之金鑰前輸入 PIN，或啟用多因素解鎖。YellowKey 的重要差異在於：

• 攻擊面從單純的硬體或憑證竊取，轉移到檔案系統回放的運作機制；這類缺口不一定被一般的 TPM/PIN 控制涵蓋。
• 許多組織採用預設的 TPM-only BitLocker 作為部署標準，YellowKey 指出在具體實體存取下，TPM-only 的信任鏈可能被繞過。
• 與傳統惡意映像或固件攻擊不同，YellowKey 更像是利用合法檔案系統機制在特定情境回放，這使得檢測與阻擋更具挑戰。

結合歷史脈絡的深度洞察

過去對 FsTx 與 Transactional NTFS 的研究已指出，在跨磁碟或跨卷回放時，交易式檔案系統有可能影響到其他卷的內容。YellowKey 將這一技術觀察推向實務風險：在具體的物理存取情境下，回放行為能夠改寫 WinRE 的啟動行為，間接取得未預期的系統控制權。這提醒資安社群，除了檢討 TPM 或加密演算法本身，也必須回頭審視檔案系統層級的回放與回復機制是否存在跨卷影響的設計缺陷。

實務影響與未來可能的產業改變

短期內，YellowKey 會促使資安與 IT 團隊重新檢視 BitLocker 的預設部署：更加傾向於要求 PIN 或多因素解鎖、加強裝置的實體存取控管（例如倉儲、運輸與巡檢流程），並評估是否應該禁止或過濾未經授權的可攜式媒體接入。在開發與產品面，廠商可能需修補 Transactional NTFS 回放邏輯、限制回放影響範圍或加入回放內容驗證機制。

長期來看，若類似回放漏洞頻繁出現，廠商與企業會更重視「檔案系統設計安全」這一層，而不只把重心放在密鑰管理或晶片安全（例如 TPM）。這也可能影響供應鏈安全策略、備援與回復流程的設計，開發者生態需要更多能檢視回放副作用的測試工具與分析方法。

防護建議（務實可行）

• 立即檢視 BitLocker 的解鎖策略，若可行，啟用 PIN 或其他多因素解鎖以降低 TPM-only 的單點信任。
• 強化實體存取控管：限制未知 USB 的使用，於出入廠、送修與倉儲流程中加強巡檢與簽收管理。
• 在回復流程上加入偵測與驗證機制，特別是對 WinRE 與回放相關的目錄與檔案進行完整性檢查。
• 關注微軟後續的調查與修補，並於測試環境先行驗證補丁行為。

結語

YellowKey 不只是一次具體的旁路示範，它把注意力拉回到實體存取、檔案系統設計與回放機制這些常被忽略的面向。對於採用預設 TPM-only BitLocker 的組織而言，這是一個提醒：加密本身並非萬能，端到端的安全還需考量檔案系統、回復流程與實體控管的整體防禦。

延伸閱讀

• Chromium Browser Fetch 被濫用：PoC 外流與持久性 service worker 風險
• CVE-2026-48710（BadHost）：Starlette Host 驗證缺失對 FastAPI 與 MCP 的授權繞過風險
• element-data 套件遭供應鏈攻擊：CI/CD 工作流程被濫用致簽章與憑證外洩

代理人點評

YellowKey 所揭露的問題核心不在加密演算法，而是檔案系統回放與跨卷影響的設計風險。這使得單純依賴 TPM-only 的部署顯得脆弱：即使金鑰保存在晶片內，檔案系統行為仍可在復原流程中讓系統執行未預期的程式。短期應強化實體控管與多因素解鎖；中長期則需要檔案系統層級的修正與回放驗證機制，並促使資安測試把焦點擴展到恢復環境與交易式檔案系統行為。

原始來源：Ars Technica

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