一份针对 BitLocker 的公开攻击列表。任何可能攻击 BitLocker、但具体方法尚未公开的公开攻击（如 baton drop）不在范围内。
大多数攻击针对的是 VMK 仅由 TPM 封存的情况，这是默认设置，也是 自动 BitLocker 在将恢复密钥托管到 Microsoft 帐户时所使用的方案。
默认情况下，从 Windows 8 开始，如果启用了 Secure Boot，则会使用 Secure Boot 完整性验证。
如果必须仅由 TPM 封存 VMK，最安全的配置是使用 PCR 0、2、4、7、11 的旧式完整性验证（并保持系统完全更新）。
请注意，这只能防御软件攻击。
硬件攻击通常仅在攻击者能够物理接触系统，且该系统 VMK 仅由 TPM 封存时才有用。
| 摘要 | 描述 | 已修复 | 公开披露时间 | 发现者 |
|---|---|---|---|---|
| TPM 嗅探：bootmgr 与 TPM 之间以明文通信 | Windows 引导管理器与 TPM 之间以明文通信，因此如果使用的是 LPC 总线上的独立 TPM 芯片（即非 fTPM，也非 "Pluton"/HSP），则可以通过该总线上的逻辑分析仪转储 VMK。 另见 Pulse Security 的博客文章、LPC 嗅探器 Verilog 代码。 | 无，但固件 TPM 本来就不受影响 | 2019 年 1 月 | marcan |
| 硬件调试器：某些系统在启用硬件调试器之前不会将其度量到 PCR7 | 适用于 TPM 的 TCG EFI 平台规范（第 6.4 节）包含以下内容： "如果平台提供了可在 UEFI 环境之前使用的固件调试器模式，或者平台为 UEFI 环境提供了调试器，则平台应在允许使用调试器之前将 EV_EFI_ACTION 事件扩展到 PCR[7]" 某些系统在启用某些硬件调试器（如 Intel DCI）之前不会执行此度量。 因此，在这样存在漏洞的系统上，可以利用 Secure Boot 绕过（物理访问至少可提供两种在 Secure Boot 仍启用状态下的绕过方式）或硬件攻击（直接写入 SPI 闪存）来启用硬件调试器；随后可在 bootmgr!FvebUnsealCallback 内设置断点（例如）以转储 VMK。另见 2023 年欧洲数字取证研究会议上的这篇文章。 | 对于存在漏洞的系统，无修复方案。 存在漏洞系统的确切列表未知。 | 2023 年 3 月 | 巴西联邦警察 |
| fTPM 毛刺攻击：通过毛刺攻击获得代码执行以完全破坏 fTPM 状态 | 如果实现 fTPM 的片上处理器/微控制器容易受到毛刺攻击，从而可在引导早期获得代码执行，则整个 fTPM 状态都可能被破坏，进而导致 VMK 转储等。另见 研究文章、适用于 AMD PSP 的载荷等 | IntelME：2021 年 11 月 / Alder Lake AMD：未知，没有？ 其他（ARM64、ARMv7 等）：未知 | 2023 年 4 月 | 柏林工业大学 SecT 的 Hans Niklas Jacob、Christian Werling、Robert Buhren、Jean-Pierre Seifert |
| 引导时禁用 IOMMU：通过闪存转储/重写修改 UEFI 非易失性变量存储可在引导时禁用 IOMMU | 某些 UEFI 固件会根据变量数据决定是否在引导时启用 IOMMU。通过转储闪存、修改这些变量并重新写入，IOMMU 将在引导时被禁用，而 TPM 非易失性状态仍然有效。此时，攻击者可以在 bootmgr 启动之前通过 PCI DMA 覆盖 DMAR ACPI 表，进入安全模式，然后再次使用 PCI DMA 获得 SYSTEM shell。见 相关文章。 该问题属于哪个组件尚不清楚；该文章使用 Intel 系统，相关代码由 Intel Firmware Support Package 提供。AMD 对应的组件（AGESA/CBS）是否也受影响未知。 | Intel Firmware Support Package：未知 AMD AGESA/CBS：未知 | 2026 年 3 月 | MDSec 的 Craig S. Blackie |
软件攻击通常是 bootmgr 或其他引导应用程序中的漏洞，攻击者可以在内存中获取任意卷的派生 BitLocker 密钥后进行利用。
如果可以在引导应用程序中获得代码执行，那么"邪恶清理者"攻击者就有可能安装一个引导套件，该套件本身会在内存中存在派生密钥时运行（或在仍可派生密钥时运行），从而危及使用密码或启动密钥（代替 TPM 或作为 TPM 的补充）的系统。
存在漏洞的系统将安装 2022 年 5 月或 2022 年 6 月的更新，但未安装任何后续更新。
关联选项 GUID 是哈希数据的一部分，因此所使用的设备元素必须标记为未验证。
在 Windows 7 及以下版本中，没有可用的元素（尽管使用自定义的非默认设置时仍有可能）。
在 Windows 8 及以上版本中，osloader!osdevice 默认不被验证，因此可以使用。
最简单的利用方式是使用 BCD 原始设备编辑器 bcdeditmod，不过手动编辑 BCD 注册表配置单元也是可行的（请自行摸索）。
利用步骤包括：
{default} 中的 osdevice 复制到第一个设备元素{default}!osdevice 中的关联选项 GUID 设置为第一个设备元素{first}!osdevice 中的关联选项 GUID 设置为第二个设备元素debug）bootmgfw 二进制文件引导目标设备此漏洞已存在超过 17 年，已知引入该漏洞的最早版本是 2005 年 10 月的 6.0.5231.2 (winmain_idx03.051004-2120)。
如果使用 Secure Boot 完整性验证，降级攻击仍可用来利用此漏洞。Set up a PXE boot server with a vulnerable bootmgfw.efi (where legacy integrity validation is used, this must be the bootmgfw.efi from the target device) renamed correctly for EFI booting.
For the BCD, set up one default entry where device is the BitLocker encrypted osdevice; path is "\"; and a recovery sequence.
The recovery sequence should point to a single startup entry, where device is boot, path points to an EFI application to run (from the PXE server); and pxesoftreboot is enabled.
When Secure Boot is disabled, that EFI application can just be an application to scan physical memory looking for a BitLocker keytable to dump.
When Secure Boot is enabled, that EFI application can use a known Secure Boot bypass (where physical access is required if needed).
For exploiting a Windows boot application in this way, you will need to replace the BCD with your second one on the PXE server.
This means pressing an arrow key during bootmgr startup to force the boot menu to show; and then replacing the BCD on the PXE server at that point.
Exploitation involves:
manage-bde -pause C: followed by manage-bde -protectors -delete C:At this point, the on-disk BitLocker metadata will contain a plaintext VMK.
Dump it, and use that VMK to decrypt the FVEK.
The decrypted FVEK can be used on the disk image made previously to decrypt the partition.
Please note: I only successfully exploited this issue on Windows 10 in very specific circumstances (TPM-only BitLocker with no recovery key). However, others have successfully exploited this issue using a vulnerable WinRE on Windows 11 (Nickel).
As far as I am aware, this vulnerability has existed as long as the boot manager has - it appears to be present as early as 6.0.5098.0 (winmain_beta1.050628-1740) from June 2005, although that pre-dates the BCD so exploitation would be different in builds that early. Relevant code seems to also exist earlier too (the ramdisk-related code appears to be the same in build 5048 from April 2005), but build 5098 is the earliest dumped build with BitLocker present in some form.
To exploit this, you need to set up a default entry and a recovery sequence like in bitpixie. This is so the keys are derived for the OS device when the file is loaded.
The recovery sequence must have an additional device entry to set up the ramdisk. Use bcdeditmod for this. Use a custom element here like custom:21100000. An example of a device entry to use here would be !raw:block[ram[part2[hd[gpt[{D2E23617-2338-4685-A2D7-F3133312E12E}]],gptsig[{1B85332B-AD73-4D9A-BFC3-B39443D3DFE4}]],:\hiberfil.sys:]] - you'd want to replace the part2 block device here with the one from your target system's BCD.
The file can then be dumped out of memory using whatever method that works for you. I prefer to use older winload into self-signed mcupdate via advanced options menu, but other options are available (PXE soft reboot into a third party operating system for example; memory dumping from WinPE by using a bugcheck or a known vulnerable driver is possible, but winload will mark the memory area as free in the NT memory map so it might get overwritten without some other settings to mark that memory as bad/etc in winload).
A proof of concept implementation of my preferred method is included in this repository as ramleak.zip. Read the included readme for usage instructions.
Shout out to Maxim Suhanov, this was inspired by reading CrashXTS writeup and figuring out some other way to possibly dump hiberfil.sys.
And now for my own thoughts, about this bug and about yellowkey:
This was the first time I had a real issue with submitting to MSRC, and was mainly a misunderstanding from their side related to Secure Boot. Given that other bitlocker 0day being dropped I decided to release this now, I've been sitting on this for almost a year now wondering what to do with it.
Unlike yellowkey, I won't make overblown calls about this being a "backdoor", in my opinion I don't think yellowkey is a backdoor, the related component is to do with WinPE (not WinRE-specific), and the main "vuln" there is getting winpeshl.ini deleted to reach that codepath, I can totally understand why MS thought deleting it in a WinRE+bitlocker scenario wasn't possible.
Given that loading a ramdisk from a bitlocker encrypted partition is actually a feature in the boot environment, although I had to use an existing trick to actually get it to work, other people could also say this was a backdoor if they wanted, but I'm not going to go that far. The boot environment is complex (and keeps getting bigger, latest bootmgfw_ex.efi no longer fits in a 2.88MB image - end of an era), several vulns have been discovered because of how certain features interact with each other.
| 摘要 | 描述 | 已修复 | 公开披露时间 | 发现者 |
|---|
| 引导环境在创建新密钥表时不会清除之前的密钥表 | 引导库初始化函数会接收一组标志。 如果设置了第 7 位（至少 bootmgr 就是如此），任何现有的密钥表都会被忽略，并创建新的密钥表。 现有密钥表不会被清除，而是保留在内存中。 这使得攻击者可以使用任意的 osdevice 加载 bootmgr，然后利用 bootmgr 漏洞获得代码执行，或使用 RS2+ bootmgr（以确保只有一个 Secure Boot 策略存在）加载 WinPE 并使用已知的易受攻击驱动程序来查找并转储密钥表。使用旧式完整性验证可以阻止此攻击，因为 BitLocker 分区元数据中包含引导应用程序允许列表。 | 2022 年 1 月缓解（在大多数情况下阻止加载 bootmgr）。 2023 年 3 月通过 build 25330 修复（创建新密钥表之前会映射并清除现有密钥表）。 降级攻击仍可用来利用此漏洞。 | 2022 年 8 月（与 baton drop 一起）；2022 年 1 月发现。 | Rairii |
| 旧式完整性验证对关联选项的实现不正确 | 受影响的是旧式完整性验证（使用存在漏洞的 bootmgr 时），Secure Boot 完整性验证完全不受影响 BitLocker 旧式完整性验证会遍历所有引导选项，并确保它们存在、确保任何未知选项不存在，或通过对它们进行哈希来确保它们未被更改。 原始实现也曾尝试遍历关联选项，但使用了错误的偏移量。 这允许构造一个包含对 BitLocker 旧式完整性验证不可见的引导选项的 BCD。 这里有许多危险选项，尤其是 debug，可能导致 BitLocker 密钥表转储。通过在使用正确偏移量遍历关联选项来修复。此漏洞编号为 CVE-2022-29127。 | 2022 年 5 月 | 2022 年 6 月（在 emfcamp 上，感谢 bindiff） | 微软（WDG）的 Matt Wesemann |
| 危险关联：旧式完整性验证对关联选项的实现不正确（第 2 部分） | 受影响的是旧式完整性验证（使用存在漏洞的 bootmgr 时），Secure Boot 完整性验证完全不受影响 对上一个漏洞的修复不正确，只检查了一级关联选项，而使用引导选项的代码会进行递归。 这允许构造一个包含对 BitLocker 旧式完整性验证不可见的引导选项的 BCD。 另见公开披露。 通过像其他代码一样递归进入关联选项来修复。此漏洞编号为 CVE-2022-22048。 | 2022 年 7 月 | 2022 年 12 月；2022 年 5 月在 bindiff 上一个补丁时发现 | Rairii |
| bitpixie：PXE 软重启不会清除内存中派生的 BitLocker 密钥 | 仅在 UEFI 系统上可利用（旧式 BIOS 或 CSM 不行）。受影响的是旧式完整性验证（使用存在漏洞的 bootmgr 时），Secure Boot 完整性验证受影响 从网络引导时允许 PXE 软重启，它只是执行 BS->LoadImage() 和 BS->StartImage()。在调用 BS->StartImage 时，派生的 BitLocker 密钥仍留在内存中。随后可以从内存中将其转储。 此外：BitLocker 密钥在加载引导应用程序的非常早期阶段就会派生。如果从磁盘加载 PE 失败，则不会执行完整性验证，派生的密钥会保留在内存中。 此时可以执行 PXE 软重启，因此这也绕过了旧式完整性验证。 另见公开披露。 通过在调用 bootmgr!PxeSoftReboot 之前在 bootmgr!BlNetSoftReboot 中清除 BitLocker 密钥表来修复。此漏洞编号为 CVE-2023-21563。 | 2022 年 11 月（build 25236）；2023 年 1 月（反向移植） 如果使用 Secure Boot 完整性验证，降级攻击仍可用来利用此漏洞。 | 2023 年 2 月，2022 年 8 月发现 | Rairii |
| 按钮解密：WinRE 中的重置可在解密过程中被中断，使攻击者获得 shell 以移除密钥保护器 | Windows Server 不支持重置功能，因此不受影响。受影响的是旧式完整性验证和 Secure Boot 完整性验证（使用存在漏洞的 winre 镜像时） 当引导到系统的 WinRE 时，会为关联的 osvolume 派生密钥。在执行按钮重置（含数据清除）时，这些密钥允许保留在内存中。 启动"仅删除我的文件"重置后，驱动器将在约 98% 完成时开始解密。 此时重新启动将导致再次引导到 winre，并显示错误和一个重新启动按钮。 重新启动后，Windows 安装程序会启动到升级界面。在这里可以按 Shift+F10 获得 shell。在这个 shell 中足以暂停解密并移除所有密钥保护器，然后可以使用明文 VMK 解密 FVEK，并配合先前制作的磁盘映像使用。 通过要求在进行重置前提供 BitLocker 恢复密钥来修复。此漏洞编号为 CVE-2022-41099。 | 2022 年 11 月（winre 镜像必须手动修补） | 2023 年 5 月 | 未知 |
| dubious disk：在引导环境上下文中执行任意代码 | 利用此漏洞或其变体可以在引导环境上下文中执行任意代码，因此可以派生 BitLocker 密钥（在 bootmgr 中执行任意代码时）或转储 BitLocker 密钥表（在其他引导应用程序中执行任意代码时）。 此漏洞及其变体编号为 CVE-2022-30203、CVE-2023-21560、CVE-2023-28269、CVE-2023-28249、（未知）和 CVE-2024-38065。 | 2022 年 7 月至 2024 年 7 月之间的多次修复。降级攻击仍可用来利用这些漏洞。 | 2024 年 6 月（公开文章，缺少 2024 年 7 月修复的变体）；最初于 2021 年 8 月发现，并于 2022 年 1 月至 3 月期间被利用 | Rairii |
| CrashXTS：密码学攻击，可精确破坏 SYSTEM 配置单元，导致休眠文件以明文写入 | BitLocker 使用 AES-XTS。通过对加密分区拍摄多份映像，可以找到 SYSTEM 配置单元的偏移量，从而找到 SYSTEM\ControlSet001\Control\CrashControl 键的偏移量，并以某种方式破坏该配置单元，使得用于在将休眠文件写出到磁盘时对其进行加密的筛选器驱动程序不会被加载。因此，攻击者随后可以让系统休眠，再次转储分区，并获得包含卷密钥的完整明文（压缩）内存转储。另见公开文章。 通过在需要时检测到该筛选器驱动程序不存在而触发 bugcheck 来修复。此漏洞编号为 CVE-2025-21210。 | 2025 年 1 月 | 2025 年 1 月 | Maxim Suhanov |
| break out in hives：systemdatadevice 元素导致 winload 使用攻击者指定的 SYSTEM 配置单元 | 从 Windows 10（th1）开始，winload 增加了对 systemdatadevice 元素的支持。如果存在该元素，winload 会从此设备读取 SYSTEM 配置单元，而不是从 osdevice 读取。因此，攻击者可以从 WinPE 获取 SYSTEM 配置单元，修改 Setup!CmdLine 为 cmd.exe，并让 winload 在引导 WinRE 时使用此配置单元。 此后引导 WinRE 时，如果已派生了 osvolume 的 BitLocker 密钥，就会打开一个 SYSTEM shell，其内存中包含这些密钥；从而实现 BitLocker 绕过。 通过移除从 systemdatadevice 加载 SYSTEM 配置单元的能力来修复。此漏洞编号为 CVE-2024-20666。 | 2024 年 1 月（winre 镜像必须手动修补） | 2025 年 2 月；2023 年 3 月发现 | Rairii |
| break out in hives 2：利用 systemdatadevice 元素的替代方法，可与降级攻击配合使用 | 对 break out in hives 的修复更新了 winload。 然而，较早（未修复）版本的 winload 可能仍然可以运行以引导其对应主版本的 Windows（实际上并非对每个版本都有效）。 因此，攻击者可以引入一个旧版 winload，修改 BCD 以从该版本引导，然后重复该攻击，但必须使用不同的利用方法。 必须在 BCD 中设置 winpe 元素（如果未设置，BitLocker 加密的 osvolume 中的 SYSTEM 配置单元将被破坏！）这里可用的 SYSTEM 配置单元来自同一主版本 Windows 的 install.wim 映像（而非 WinPE/WinRE）。Win32 子系统将无法完全初始化，但可以在 ControlSet001\Control\Session Manager!SetupExecute 中配置 smss，从而在内存中存在派生密钥的情况下以 SYSTEM 身份执行任意的本机子系统代码。通过在执行 Secure Boot 时于 bootmgr 中清除 systemdatadevice 元素来修复，但该修复仅应用于 PCA 2023 签名的 bootmgr_ex，因此在没有启用 KB5025885 缓解措施的情况下，此漏洞仍然存在且未修复。 此漏洞编号为 CVE-2025-21213。 | 2025 年 1 月，仅限 PCA2023 签名的 bootmgr_ex | 2025 年 2 月；2024 年 1 月发现（在原始修复之后） | Rairii |
| 引导环境在加载 ramdisk 时不检查 SDI，而 SDI 包含所用 WIM 的偏移量 | 加载 ramdisk 时，引导环境（以及 NT wimfsf.sys）会从 SDI 文件（如果存在）中获取所用 WIM 的偏移量，且对所使用 SDI 文件没有验证。因此，可以在恢复序列中使用构造的 SDI 文件引导任意的 WinPE WIM，同时 osdevice 的 BitLocker 密钥已派生。通过检查计算出的 WIM 偏移量是否等于 WIM 的实际加载偏移量，如果不相等则返回 STATUS_INVALID_IMAGE_FORMAT 来修复。此漏洞编号为 CVE-2025-48804。 | 2025 年 7 月 | 2025 年 8 月（在 Black Hat 上） | 微软（MORSE）的 Alon Leviev 和 Netanel Ben Simon |
YellowKey 又称 trans writes（镜像，密码：bitlocker）：位于一个卷上的文件系统事务文件可以影响另一个卷上的文件 | Germanium 引入了一项新的文件系统事务功能（与 NTFS 事务无关）。其日志存储在磁盘上，由 fstx.dll（服务堆栈的一部分）解析，并且在 WinPE 中仅由新的本机可执行文件 autofstx.exe（"Boot-time FsTx Update Recovery Utility" - "此工具可在引导时恢复失败的 FsTx 更新。"）加载，smss 会由于注册表项而运行该程序。这些日志包含完整的 NT 路径，因此可以影响另一个卷上的文件。 这可以在连接了可移动驱动器（NTFS 格式）引导 WinRE 时使用，以删除 ramdisk 上的 winpeshl.ini。删除此文件后，如果按住 Ctrl 键，winpeshl.exe 将启动一个 SYSTEM shell，其内存中包含已派生的 osdevice BitLocker 密钥。另见 Will Dormann 的补充文章。此漏洞编号为 CVE-2026-45585。 | 2026 年 6 月 | 2026 年 5 月 | Nightmare-Eclipse |
| ram leak：引导环境对 ramdisk 创建设备没有限制 | 当配置为创建 ramdisk 时，要加载的文件和从哪个设备加载都由 BCD 提供。 引导环境对传入的设备没有检查，因此，假设密钥可以派生，则允许使用 BitLocker 加密的分区。 因此，攻击者可以设置一个 ramdisk，从 BitLocker 加密的分区加载任意文件，即使派生的 BitLocker 密钥被清除，文件内容仍会留在 RAM 中，之后可以被转储。 此外，攻击者可以利用这一点来确定某个文件是否存在于 BitLocker 加密的 OS 分区上。 有价值的攻击目标包括：休眠文件（包含派生的 BitLocker 密钥，且经过压缩，因此应能完全装入 RAM，尤其是在登录屏幕上"关机"（即注销后休眠）的情况下）、页面文件、SYSTEM 和 SAM 配置单元、任何第三方服务或驱动程序（从 SYSTEM 配置单元识别）以检查漏洞。 | 无。MSRC 因误解而将其按低优先级关闭。 | 2026 年 5 月，最初于 2025 年 3 月发现。 | Rairii |
| bitskrieg：WinRE 引导不禁止紧急管理服务 | 紧急管理服务允许通过串行端口使用特殊管理控制台控制正在运行的 Windows 系统，其中包括运行 SYSTEM shell 的能力。这在 WinRE 中是允许的，因此可以用来打开一个 SYSTEM shell，其内存中包含已派生的 osdevice BitLocker 密钥。 | 无，作为 0day 被放弃。 | 2026 年 6 月 | Jonas Lyk |