Rairii :win3_progman: :win3: <p>I’ve updated my bitlocker attacks list <a href="https://github.com/Wack0/bitlocker-attacks" rel="nofollow noopener noreferrer" target="_blank">https://github.com/Wack0/bitlocker-attacks</a></p><p>The main addition here is documentation of “break out in hives” (CVE-2024-20666, nice) and its variant (CVE-2025-21213).</p><p>The most interesting thing here is that it’s <em>technically</em> <strong>still not fixed</strong> - the fix was only applied to the PCA2023-signed <code>bootmgr_ex</code>, so <strong>without the KB5025885 mitigations applied (and other default settings which nobody ever changes), you’re still vulnerable</strong> without even needing a downgrade attack for <code>bootmgr</code>.</p><p>(If you’re using TPM-only bitlocker, you really should be using legacy integrity validation - that is, <a href="https://admx.help/?Category=Windows_10_2016&amp;Policy=Microsoft.Policies.VolumeEncryption::AllowSecureBootForIntegrity_Name" rel="nofollow noopener noreferrer" target="_blank">Allow Secure Boot for integrity validation policy DISABLED</a> with <a href="https://admx.help/?Category=Windows_10_2016&amp;Policy=Microsoft.Policies.VolumeEncryption::PlatformValidation_UEFI_Name" rel="nofollow noopener noreferrer" target="_blank">PCRs 0,2,4,7,11 set</a> - legacy integrity validation was never vulnerable to these issues in the first place! This would imply bitlocker potentially going into recovery more often with windows updates, but it’s a choice between that and currently broken bitlocker vulnerable to various boot-time <em>software</em> issues combined with downgrade attacks)</p><p>The main issue here is that starting from Windows 10 (th1), the <code>systemdatadevice</code> element was added to winload; if present the SYSTEM hive is loaded from this block device instead of the (bitlocker encrypted) OS partition.</p><p>Therefore, the first (easiest) exploitation method was to pull a SYSTEM hive from <code>boot.wim</code>, modify it to set <code>SYSTEM\Setup!CmdLine</code> to <code>cmd.exe</code>, and set up the WinRE boot entry to use it; booting WinRE would then pop a SYSTEM shell with bitlocker keys derived and in memory.</p><p>The original fix just removed the <code>systemdatadevice</code> support from winload, but (at least in some cases) the older revisions of winload (for the same major Windows version) would still boot Windows successfully; thus the second exploitation method: configure BCD to load winload from somewhere else (downgrade attack), booting the bitlocker-encrypted OS with custom SYSTEM hive taken from <code>install.wim</code> - it turned out that without <code>winpe</code> also set, this corrupted the SYSTEM hive on the bitlocker-encrypted OS partition; also the Win32 subsystem would fail to load, but native code execution would still work when setting <code>SYSTEM\ControlSet001\Control\Session Manager!SetupExecute</code>. Therefore, I took the old <a href="https://github.com/amdf/NativeShell" rel="nofollow noopener noreferrer" target="_blank">Native Shell</a> codebase, ported it to AMD64, and modified it to acquire <code>SeRestorePrivilege</code> and open files with <code>FILE_OPEN_FOR_BACKUP_INTENT</code> (so permission checks would be ignored, so it’s possible to do the sethc trick at this point).</p><p><a class="hashtag" href="https://labyrinth.zone/tag/windows" rel="nofollow noopener noreferrer" target="_blank">#Windows</a> <a class="hashtag" href="https://labyrinth.zone/tag/bitlocker" rel="nofollow noopener noreferrer" target="_blank">#BitLocker</a> <a class="hashtag" href="https://labyrinth.zone/tag/cve_2024_20666" rel="nofollow noopener noreferrer" target="_blank">#CVE_2024_20666</a> <a class="hashtag" href="https://labyrinth.zone/tag/cve_2025_21213" rel="nofollow noopener noreferrer" target="_blank">#CVE_2025_21213</a></p>