BitLocker YellowKey 零日漏洞：密钥派生路径、信任模型绕过与磁盘加密防护失效的根因分析

漏洞概述

2026 年 5 月，安全研究者以 Chaotic Eclipse（GitHub 账号 Nightmare-Eclipse）为化名披露了名为 YellowKey 的 BitLocker 绕过漏洞。该漏洞允许攻击者在无需恢复密钥的情况下，通过特制的 FsTx 文件触发 Windows Recovery Environment（WinRE）的异常行为，从而获得对 BitLocker 加密卷的完全访问权限。与此同时披露的还有 GreenPlasma 特权提升漏洞，二者共同构成了针对 Windows 系统的完整攻击链。

据安全专家 Kevin Beaumont 与 Tharros Labs 首席漏洞分析师 Will Dormann 的独立验证，YellowKey 的利用机制涉及 Windows 内核中 NTFS 事务日志的处理逻辑缺陷，以及 WinRE 启动流程中的信任边界突破问题。

技术机制解析

NTFS 事务日志回放的信任滥用

YellowKey 的核心攻击向量利用了 Windows 在启动恢复环境时的文件系统行为。当系统进入 WinRE 时，Windows 会扫描所有附加存储设备上 \System Volume Information\FsTx 目录中的 NTFS 事务日志（NTFS Transaction Logs），并自动重放这些日志以恢复文件系统一致性。

攻击者通过将特制的 FsTx 文件放置于 USB 驱动器或目标设备的 EFI 系统分区，可在 WinRE 启动过程中触发以下连锁反应：

1. 日志注入：恶意 FsTx 文件包含删除 X:\Windows\System32\winpeshl.ini 的事务记录
2. 配置清除：winpeshl.ini 是 WinRE 的启动配置文件，定义了恢复环境应加载的 Shell 程序
3. Shell 降级：配置缺失后，WinRE 回退至默认行为，直接启动 cmd.exe 而非正常的恢复界面
4. 磁盘状态保持：由于 BitLocker 的自动解锁机制已在系统引导早期完成，此时加密卷仍处于解锁状态

密钥派生路径的断裂

BitLocker 的密钥派生遵循以下信任链：

TPM (存储 VMK) → 平台完整性验证 → VMK 解密 → FVEK 解密 → 数据访问

在 TPM-only 配置下，系统启动时自动从 TPM 获取卷主密钥（VMK），无需用户交互即可完成解密。YellowKey 并未直接攻击加密算法本身，而是利用了密钥已派生完成后的信任窗口期—— 当 WinRE 接管系统时，磁盘已处于透明解密状态，而 WinRE 的 Shell 替换使攻击者获得了对这一状态的完全控制。

Will Dormann 指出："YellowKey 利用的是自动解锁的便利特性。如果系统能够在无需用户干预的情况下透明解密磁盘，那么攻击者终将找到滥用这一机制的方法。"

攻击向量的物理边界

当前公开的 PoC 要求攻击者具备以下前提条件：

• 物理访问：需要在目标设备上插入 USB 驱动器或修改 EFI 分区
• 设备绑定：利用必须在原始设备上进行，因为 TPM 中存储的加密密钥与特定硬件绑定
• 启动控制：需要能够触发系统重启并进入 WinRE（可通过强制关机或系统故障实现）

这意味着 YellowKey 目前无法直接用于离线攻击（如窃取硬盘后在其他设备上解密），但其对设备丢失 / 被盗场景下的数据保护构成了实质性威胁。

信任模型的系统性绕过

WinRE 的特权边界缺陷

WinRE 作为 Windows 的恢复环境，设计上应具备与完整系统同等的安全边界。然而 YellowKey 揭示了其启动流程中的关键弱点：

• 外部输入信任：WinRE 无条件处理来自外部存储的 NTFS 事务日志
• 配置回退机制：缺失启动配置时未实施安全锁定，而是降级至命令行 Shell
• 磁盘状态保持：恢复环境与主系统共享相同的磁盘解锁状态

这种设计使得 WinRE 成为了攻击者眼中的 "高价值目标"—— 一旦控制恢复环境，即可获得对系统的完全访问权限。

TPM+PIN 的防御有效性争议

研究者 Chaotic Eclipse 声称 YellowKey 在 TPM+PIN 配置下同样可利用，但未公开相应 PoC。Will Dormann 的分析表明，当前公开的利用方式在 TPM+PIN 环境中确实无法工作，因为 PIN 验证发生在 WinRE 进入之前：

"PIN 提示出现在进入 Windows Recovery 之前。要启动 Windows Recovery，系统必须已通过 PIN 验证。"

然而，研究者暗示存在更深层的根因尚未公开，这使得 TPM+PIN 作为缓解措施的长期有效性存疑。

防护失效的根因分析

便利性与安全性的失衡

YellowKey 的本质是 BitLocker TPM-only 模式设计取舍的必然结果。该模式旨在提供无缝的用户体验 —— 用户无需输入密码或 PIN 即可启动系统，加密在后台透明完成。但这种便利性建立在以下假设之上：

• 物理访问控制足以防止攻击
• 恢复环境的安全边界与主系统等同
• 外部输入在预启动阶段可被安全处理

YellowKey 证明了当攻击者能够操控预启动环境的外部输入（如 USB 设备）时，这些假设均告失效。

NTFS 事务机制的暴露面

NTFS 事务日志（TxF）的设计初衷是提供原子性文件操作，确保系统崩溃后的数据一致性。然而，其在 WinRE 中的自动重放机制暴露了过大的攻击面：

• 隐式行为：系统主动查找并重放外部日志对用户不可见
• 无验证机制：WinRE 未对 FsTx 文件的来源或完整性进行校验
• 高权限上下文：日志重放在系统级权限下执行

可落地的加固参数

即时缓解措施

针对 YellowKey 的已知攻击向量，建议立即实施以下配置：

1. 启用 BitLocker PIN 保护

# 检查当前保护状态
manage-bde -status C:

# 添加 PIN 保护（需管理员权限）
manage-bde -protectors -add C: -tpmandpin

配置要求：

• PIN 长度：至少 6-8 位数字（建议混合字母）
• 允许增强 PIN：通过组策略启用 Require additional authentication at startup

2. BIOS/UEFI 级防护

• 禁用 USB 启动：在 UEFI 设置中关闭外部设备启动选项
• 设置 BIOS 密码：防止未授权修改启动顺序
• 启用 Secure Boot：确保仅加载签名的启动组件

3. WinRE 加固

# 禁用 WinRE（谨慎操作，影响系统恢复能力）
reagentc /disable

# 重新启用时确保使用最新镜像
reagentc /enable
reagentc /info

长期安全策略

1. 分层加密架构

对于高敏感数据，考虑实施：

• 预启动认证（PBA）：使用第三方全盘加密方案，要求启动前认证
• 应用级加密：对关键数据实施独立于磁盘加密的应用层加密
• 硬件安全模块（HSM）：将密钥派生与硬件绑定，增加攻击成本

2. 监控与检测

部署以下检测点：

3. 补丁管理

• 监控微软安全公告，及时应用 WinRE 相关补丁
• 关注 CVE-2026 系列中与 BitLocker/WinRE 相关的更新
• 建立零日漏洞响应预案，包括临时缓解措施与长期修复计划

GreenPlasma 的协同风险

与 YellowKey 同期披露的 GreenPlasma 漏洞（Windows CTFMON 任意内存段创建特权提升）进一步扩大了攻击面。该漏洞允许非特权用户在 SYSTEM 可写的目录对象中创建任意内存段对象，可能操纵特权服务或驱动程序的信任路径。

虽然当前公开的 PoC 不完整，但安全社区评估认为具备技术能力的攻击者可以将其武器化为完整的 SYSTEM 权限获取。该漏洞与 YellowKey 的潜在组合威胁在于：

1. 通过 YellowKey 获得物理设备上的 Shell 访问
2. 利用 GreenPlasma 从受限 Shell 提升至 SYSTEM 权限
3. 植入持久化后门或提取敏感凭证

结论

YellowKey 漏洞揭示了现代磁盘加密方案在便利性与安全性之间的深层张力。其技术根因并非加密算法本身的缺陷，而是密钥派生完成后信任窗口期的管理失当——WinRE 的设计未能充分隔离外部输入的影响，导致攻击者可通过文件系统层面的操控绕过整个加密保护机制。

对于企业安全团队而言，立即启用 BitLocker PIN 保护并收紧物理访问控制是必要的缓解措施，但更应从长远角度审视预启动环境的安全架构。在微软发布官方补丁之前，将 BitLocker 视为 "延迟访问控制" 而非 "绝对防护"，并辅以分层加密和持续监控，是应对此类零日漏洞的务实策略。

参考来源

• BleepingComputer: "Windows BitLocker zero-day gives access to protected drives, PoC released" (2026-05-13)
• The Register: "Mystery Microsoft bug leaker keeps the zero-days coming" (2026-05-13)
• GitHub/Nightmare-Eclipse: YellowKey & GreenPlasma PoC repositories
• Will Dormann (Tharros Labs) technical analysis via Infosec Exchange

security