2026 年 5 月 12 日一位使用 Chaotic Eclipse 和 Nightmare-Eclipse 为代号的研究人员在 GitHub 上发布了一个针对 Windows 零日漏洞的概念验证PoC该漏洞被命名为YellowKey。简而言之它允许任何能短暂物理接触一台受 BitLocker 保护的 Windows 11、Windows Server 2022 或 Windows Server 2025 机器的人弹出一个命令提示符并对加密卷拥有完全的读取权限。无需密码。无需恢复密钥。无需 TPM 嗅探设备。只需一个 U 盘并在重启时按下一个组合键。安全媒体立刻跟进报道。黑客社区迅速传播。奇怪的是取证领域对此几乎无动于衷。这是一个错误。如果你有一台被扣押的、受 BitLocker 保护的笔记本电脑一直搁置在物证室被视为无价值的证据那么这份披露信息本周就该出现在你的办公桌上而不是等到下个季度。在撰写本文时微软尚未发布补丁而该研究人员公开承诺将在下一个“补丁星期二”前后披露更多漏洞。现在机会窗口正大开着。本文将通过以下内容带你了解 BitLocker 实际保护了什么YellowKey 如何打破了该模型取证检验人员如何利用该漏洞以及该研究人员关于 TMPPIN 配置的额外说法可能真正意味着什么。快速回顾BitLocker 和设备加密BitLocker 是微软的全卷加密功能。它使用 AES现代安装中默认为 XTS 模式对驱动器内容进行加密加密密钥为全卷加密密钥FVEK而 FVEK 本身又由卷主密钥VMK保护。VMK 是所有保护器最终要解锁的对象无论是密码、恢复密钥、智能卡、USB 密钥文件还是 TPM单独使用或与 PIN、启动密钥或两者结合使用。改变现代 Windows 取证格局的并非管理员在企业笔记本电脑上启用的那种经典、手动配置的 BitLocker而是设备加密—— 微软在任何满足要求的现代硬件上包括家庭版在内的任何 Windows 版本自动静默启用的一种变体。用户无需主动要求。他们甚至可能不知道它的存在。如果设备预装了 Windows 11并且用户使用微软账户登录那么系统盘几乎肯定已被加密。在这种情况下恢复密钥会上传到在该设备上登录的第一个管理员级微软账户。如果用户对加密一无所知他们肯定对恢复密钥也一无所知。如果他们之后切换到本地账户更改了微软账户或者根本不知道安装时用了哪个 Outlook/Hotmail 地址那么从他们的角度来看这个密钥实际上就丢失了。这种静默启用一直是数据恢复行业长期以来的痛点。客户带着主板损坏的笔记本电脑上门不知道自己的驱动器已被加密也没有恢复密钥。恢复是不可能的。YellowKey 并不能解决这个问题的所有变种但对于任何原始加密驱动器可以放回到运行受影响 Windows 版本的工作硬件上的情况整个局面已经发生了根本性的转变。TPM 保护本应如何工作要理解 YellowKey 实际上破坏了什么值得回顾一下信任模型。在默认的仅 TPM 配置下这也是设备加密开箱即用的配置卷主密钥VMK被密封在 TPM 内部并与一组平台配置寄存器PCR绑定。在启动过程中每个阶段都会度量下一个阶段并扩展这些 PCR 值固件度量引导加载程序引导加载程序度量 OS 加载程序以此类推建立一条信任链。如果信任链与 BitLocker 初始化时的值匹配TPM 就会将 VMK 释放给启动管理器。如果信任链中的任何环节被篡改TPM 就会拒绝释放用户将看到恢复密钥提示。这是与 YellowKey 相关的关键部分当信任链验证通过时VMK 会被自动释放无需用户交互。设备加密的全部意义就在于合法用户永远不会看到任何提示。TPM 交出密钥Windows 挂载加密卷一切照常。其隐含假设是受信任的启动链内部没有任何东西可以被用来将卷暴露给未授权的第三方。我们稍后会再谈到的 TPMPIN 模式改变了一点TPM 额外要求必须输入正确的 PIN 才会释放 VMK。信任链仍然重要但用户还必须进行身份验证。这是任何处理敏感数据的设备的标准建议也是大多数威胁模型在认真对待 BitLocker 时所假设用户正在使用的配置。YellowKey 漏洞利用它是什么YellowKey 是 Windows 恢复环境WinRE中的一个漏洞允许攻击者进入一个不受限制的命令提示符而此时受 BitLocker 保护的系统卷已经被解锁并可访问。该缺陷存在于 WinRE 镜像内部的一个组件中研究人员指出同名的组件在正常 Windows 安装中也存在但不具备触发绕过机制的具体功能。这种不对称性使得这个发现感觉不像是意外更像是被故意放在那里的。这种判断是否正确我们将在文末进行推测。受影响的平台是 Windows 11 和 Windows Server 2022/2025。Windows 10 当前不受影响。包括 Will DormannTharros Labs和 Kevin Beaumont 在内的多位独立研究人员已公开证实已发布的 PoC 对默认的仅 TPM 配置有效正如其声称的那样。工作原理略去技术细节该漏洞滥用了 WinRE 内部的一条代码路径该路径会在特定文件夹System Volume Information\FsTx下扫描附加存储中的 NTFS 事务日志数据并重放其找到的任何内容。Will Dormann 指出的有趣之处在于这种重放可以修改与日志来源不同的卷上的内容。通过准备特定的日志内容攻击者可以使用 U 盘或者直接写入设备 EFI 系统分区的文件让 WinRE 在早期启动过程中重写其自身恢复镜像的部分内容。已记录的 PoC 的最终效果是WinRE 镜像中的 winpeshl.ini 文件被删除。winpeshl.ini 通常告诉 WinRE 启动恢复 UI没有它WinRE 就会直接生成 cmd.exe。在启动过程中按住一组特定的组合键就会触发该路径。屏幕上出现的 shell 可以访问受 BitLocker 保护的系统卷因为当通过合法的恢复路径进入 WinRE 时TPM 已经以正常方式将 VMK 释放给了启动链。从 TPM 的角度来看信任链没有任何部分被破坏。恢复环境本应被允许为执行修复任务而合法访问该卷。漏洞在于这种访问可以被轻而易举地重定向到一个完全自由的 shell。我们有意保持概念性的描述。已发布的代码仓库包含了将该漏洞武器化所需的一切并且已有多个独立验证。我们不会在此复述字节级的细节这是一个取证博客不是给对方的教程。在取证工作流程中使用 YellowKey对于正在检验台上处理一台被扣押设备的检验人员来说该流程分为三个阶段重启进入 Windows 恢复环境进入不受限制的 shell以及提取 BitLocker 恢复密钥。首先有一些预备说明。第一该过程会修改设备。FsTx 重放会改变 WinRE 镜像中的内容一旦恢复分区中的 winpeshl.ini 被删除设备就不再处于原始状态。请先使用硬件只读写 blocker 或 Elcomsoft System Recovery 等工具对驱动器进行镜像并记录操作前后的哈希值。该漏洞利用在运行中的硬件上操作但手头有一份干净的取证镜像意味着如果日后对证据保管链产生质疑可以用漏洞利用前的镜像作为参照。第二确认目标在范围内。Windows 10 当前不受影响。在围绕 YellowKey 制定计划之前请验证被扣押设备上的操作系统版本。Server 2022 和 Server 2025 与 Windows 11 一同都在范围内。第三该流程比较棘手。特别是按键时机要求严格独立测试者指出通常需要多次尝试才能成功命中。除了时机问题该漏洞利用也并非在所有范围内的设备上都能成功——请参阅本节末尾关于“可信 WIM 启动”的注意事项。请做好重试的准备并预期存在不可忽略的假阴性率。阶段 1重启进入 Windows 恢复环境准备一个 U 盘将已发布的 FsTx 文件夹放置在 System Volume Information 下的正确路径中然后在启动重启之前将其连接到被扣押的机器。如何进入 WinRE 取决于设备的状态。如果设备已锁定但已经过身份验证例如在开机、睡眠或休眠状态下被扣押并显示锁屏界面最快的方法是Shift 重启技巧。在锁屏界面点击右下角的电源按钮按住 Shift 键然后点击“重启”。设备将直接重启进入 WinRE。这在大多数消费级 Windows 安装中默认启用。在以下企业环境中可能被禁用组策略隐藏了锁屏界面的电源选项最常见的是通过“删除并阻止访问关机、重启、睡眠和休眠命令”策略分配访问权限或展台模式配置通过 Intune 或其他 MDM 管理的设备管理员禁用了屏幕上的电源按钮或任何本地策略手动隐藏了电源按钮的地方。如果锁屏界面缺少电源按钮或者 Shift重启仍然执行正常重启而不是进入恢复环境请回退使用下面的冷启动方法。如果设备是完全关机状态任何在物证室搁置了一段时间的设备的默认状态通过触发 Windows 的自动修复流程来强制进入 WinRE。微软在其 Windows 恢复环境文章中记录了该过程启动设备然后在 Windows 完成加载之前按住电源按钮强制硬关机。执行两次。在第三次开机时Windows 会识别到之前的启动失败并自动启动恢复环境。这个路径是可靠的但并非取证中立——强制关机更改了 BCD 中的启动计数器向事件日志中写入了非正常关机条目并且在极少数情况下可能导致文件系统不一致。请在操作前后对驱动器进行哈希记录并精确记录执行的过程。阶段 2进入 Shell当通过任一方法触发 WinRE 入口时松开所有其他按键立即按住 Ctrl 键。不要松开。一直按住 Ctrl直到出现命令提示符窗口。如果时机准确生成的 shell 将直接拥有对受 BitLocker 保护的系统卷的读取权限。按键时机窗口很窄。多名测试者报告说成功命中需要多次尝试所以不要因为一次失败就放弃。每次重试意味着重新执行阶段 1在冷设备上这涉及另一轮中断启动的序列——速度慢但流程是可行的。一个重要注意事项该漏洞利用并非在受影响版本范围内的所有设备上都能成功。微软自 WinRE 添加 BitLocker 恢复支持以来就一直设有一个名为可信 WIM 启动 (Trusted WIM Boot)的机制。该机制在 BitLocker FVE 元数据块中存储 WinRE.wim 镜像的哈希值该元数据块本身通过 AES-CCM 进行完整性保护并在恢复启动期间验证该哈希值。当 YellowKey 的 FsTx 重放修改 WinRE 镜像中的内容时这个哈希校验本应失败在这种情况下OS 卷将保持锁定状态生成的 shell 将无法访问加密数据。可信 WIM 启动是否实际触发取决于设备的 BitLocker 元数据最初是否包含预期的 WIM 哈希条目。根据一位社区研究人员在漏洞利用讨论帖中发布的分析在现实中大量笔记本电脑的元数据中——据他估计大约一半——并不包含该 WIM 哈希这意味着 YellowKey 对这些设备有效但对其余设备无效。该估计尚未经过独立验证但底层机制是真实存在的并且微软有相关文档记录。请将其视为一个命中率问题而不是一个硬性门槛对每个范围内的被扣押设备都尝试该流程但预计在相当一部分设备上shell 会出现但无法访问加密卷并据此制定计划。阶段 3使用 manage-bde 提取恢复密钥一旦 shell 可用且 BitLocker 卷可访问实际的操作不是简单地从卷中读取文件而是提取能够让你离线解密原始取证镜像的材料。在 cmd 提示符下使用 manage-bde 来枚举卷上的保护器并读出恢复信息。请注意在 WinRE 中驱动器号会被重新分配因为 WinRE 自身运行在 X: 盘。OS 卷通常是 C:但也可能根据分区布局变为 D: 或其他盘符。因此执行以下步骤manage-bde -status检查输出找出哪个卷显示保护状态: 保护已启用且BitLocker 版本: 2.0。那就是你的目标驱动器号。然后执行manage-bde -protectors -get C:将 C: 替换为实际识别的盘符。在输出中查找数字密码保护器。它将显示为一个 48 位的密钥分为八组六位数字以连字符分隔——这就是BitLocker 恢复密钥。请逐字复制下来它既可以作为手动解锁密码也可以作为 Elcomsoft Forensic Disk Decryptor 离线解密镜像时的输入。需要注意一点数字密码保护器在 BitLocker 首次初始化时就会生成并存储无论卷使用哪种主保护器仅 TPM、TPMPIN、密码等。因此即使在用户从未看到恢复密钥提示的仅 TPM 设备加密设置下该保护器也存在——它只是被静默备份到了他们的微软账户中。在此处提取它你将获得一个持久密钥不受后续任何补丁或硬件更改的影响这对于长期进行的调查非常有用。你后续的工作流程真正需要的就是这个数字密码。有了它Elcomsoft Forensic Disk Decryptor 就可以解密你之前捕获的原始取证镜像或者将其挂载为虚拟驱动器进行实时分析而无需再次触碰被扣押的硬件。这是最稳妥的路径仅将 YellowKey 用作获取密钥的手段对离线镜像进行实际的分析。还有一种变体无需任何外部存储通过将相同的 payload 写入设备自身驱动器的 EFI 系统分区来实现。当设备的 USB 端口不便使用或被禁用时这种方式很方便但通常需要短暂拆卸驱动器这本身会带来证据处理方面的其他影响。为何这对取证来说比能想到的更为重要这份披露之所以值得更多关注是因为它解除了检验人员多年来一直束手无策的一类案件。考虑一个典型场景。在一次调查中一台笔记本电脑作为证据被扣押。它运行的是 Windows 11。用户账户是本地账户或者微软账户凭据未知或者恢复密钥从未同步过。理论上在没有用户配合的情况下受 BitLocker 保护的驱动器是无法恢复的。直到现在现实的选择只有试图胁迫或协商让用户交出恢复密钥希望内存取证能从仍在运行的设备中获取 VMK对于关机状态下扣押的设备是不可能的或者将设备束之高阁。有了 YellowKey同样的设备在同样的关机状态下今天就能被处理。设备加密极大地扩大了影响范围。市面上大量消费级笔记本电脑静默启用了 BitLocker其所有者不知道它已被启用其恢复密钥与遗忘的微软账户绑定。涉及此类设备的案件一直是反复出现的痛点。在这个漏洞存续期间这些问题将不复存在。还有一个值得指出的维度受影响的版本。Windows 10 至少在目前仍然安全。任何 Windows 11 或 Server 2022/2025 都在范围内。花一个下午的时间快速清查你的物证室按操作系统排序可能是值得的。被扣押的设备顾名思义是“冷的”——它们在存储期间不会收到任何补丁所以今天物证中的受影响设备明年仍然会受影响无论微软在此期间发布了什么。机会窗口也适用于未来的扣押一旦打了补丁的版本广泛部署从那之后获取的设备可能就不再能被利用了。对于已经在货架上的所有设备来说这与其说是与时间赛跑不如说是一批积压的工作悄然变得可行了。关于 TPMPIN 说法的说明该研究人员在其后续博文中声称该漏洞在配置了 TPMPIN 的设备上同样可以被利用并且他们有一个可用的 PoC但暂时不公布。他们的原话是“第二件事是不TPMPIN 没用问题仍然可以被利用我问过自己这个问题它在 TPMPIN 环境下还能工作吗是的能。我只是不发布 PoC我认为已经公开的东西已经够糟糕了。”这个说法需要谨慎对待。根据设计TPMPIN 要求必须先输入用户 PINTPM 才会释放 VMK。一台被盗的笔记本电脑在关机后重新启动当进入 WinRE 时加密卷本应还未被挂载因为 TPM 没有什么可以释放的。使 YellowKey 在仅 TPM 情况下起作用的机制——即当 WinRE 继承系统时卷已经解锁——显然并不适用。尽管如此认真对待这个说法而不是直接忽略它是值得的。已公开的仅 TPM 绕过路径已经暗示了 WinRE 内部存在一条代码路径其行为与公开文档所暗示的不同。如果正如该研究人员所认为的那样这是一个故意引入的通道而不是一个意外缺陷那么就没有什么能阻止该通道包含其自身的、独立于用户 PIN 的访问加密卷的路径。WinRE 在执行某些修复操作时确实需要能够与受保护的卷进行通信而其具体机制并未在公开文档中得到详细说明。测试了公开 PoC 的 JaGoTu 指出TPMPIN 的行为似乎取决于具体的 WinRE 实现这表明正在发生的事情远不止简单的“PIN 控制一切”。在微软逆向分析该组件并做出解释或者该研究人员发布第二个 PoC 之前诚实的立场是这个说法是可能的但尚未得到独立证实。那么微软这到底是怎么回事抛开流程性的东西整件事确实令人感到真正的困惑。该研究人员的论点是YellowKey 看起来像一个后门。不一定是在阴谋论的意义上而是在结构上易受攻击的组件仅存在于 WinRE 镜像内部。同名的组件在正常的 Windows 安装中也存在但不具备产生绕过机制的具体功能。这不是正常漏洞的形态。正常的漏洞是统一的它们存在于代码需要被部署的任何地方。一个镜像中存在而另一个镜像中不存在的功能且差异恰恰在于产生对加密数据未授权访问的部分这种不对称性自然会引发人们的疑问。基本上有两种解读方式。善意的解读是这是一个遗留的维护或调试路径是微软内部某个人多年前为某个合法的修复场景构建的从未被正确设限然后被遗忘了。恢复环境是 Windows 中一个奇怪的角落充满了历史遗留的积累“我们需要能在现场修复东西”是一个真实的工程压力。这种解读将结论导向了严重的疏忽一个功能实际上完全破坏了默认安装下 BitLocker 的整个承诺在生产代码中存在多年没有文档未被内部审查发现。不那么善意的解读是有人故意让它留在那里。无论是为了微软内部的工具为了与特定合作伙伴的合作还是为了那些房间外的人永远不需要知道的原因一条访问路径被构建出来并悄悄地保留着。公开的证据并没有强制要求采用这种解读而非疏忽的解读而且对故意后门的指控不应轻易提出。但结构上的怪异是真实存在的该研究人员不是唯一注意到这一点的人微软到目前为止还没有提供任何解释。无论哪种解读对 BitLocker 品牌来说都是坏消息。TPM 绑定加密的整个卖点是用户可以不再担心。驱动器被盗驱动器保持加密状态就这么简单。这个承诺支撑了很多政策政府将 BitLocker 标准化用于敏感终端企业用它来勾选合规复选框消费者认为他们落在出租车里的笔记本电脑不会造成数据泄露。YellowKey 在这承诺上捅了一个干净的洞。不是一个“只要有足够专业的设备和一把烙铁就能搞定”的洞——有经验的读者一直知道这种洞在仅 TPM 设置下是存在的。这是一个U盘加键盘快捷键的洞任何能阅读 README 的人都可以利用。这一切本不该发生。一个严重性如此之高的漏洞存在于一个其全部工作就是在未经身份验证的状态下由不受信任的用户调用的组件中本应在发布之前很久就被内部审查发现。事实并非如此——而且根据该研究人员自己的说法微软对他们之前披露的漏洞的回应包括静默打补丁而不发布公告——这将对“被微软加密”意味着“安全加密”的假设造成真正的损害。对于取证人员来说这是一份礼物而且是一份暂时的礼物。对于微软客户来说这是一个警钟提醒他们需要更认真地思考仅 TPM 的设备加密是否真的足以应对其威胁模型。对于我们其他人来说这再次提醒我们最具影响力的漏洞通常不是那些巧妙的漏洞而是那些因为没人想到要去看而没人注意到的漏洞。