Mastodawn

@wdormann, @jagotu, @GossiTheDog: still, it has some security relevance in the "disk = network" case (explicit network boot like PXE or implicit network boot like on an ESX host with a network-attached datastore*) and also in the "confidential VM" case (an admin on the virtualization host can't break into a VM). Planting something into the unencrypted part of the disk must never inject (replace) anything in the encrypted volume.

* — most cloud providers are doing exactly this or something similar, especially those who run on the VMware stack.

In the YellowKey, this can be achieved by planting malformed transaction log files and then corrupting the encrypted NTFS header at a well-known location (to force booting into the WinRE and launching the startup recovery phase). Here, an attacker is capable of doing this by intercepting network communications during the network-based boot. This allows code execution in an encrypted VM without executing code on the host (and no need to bypass Secure Boot and TPM measurements). Which is CVE-worthy, according to Microsoft (I had a similar MSRC case resolved).

Maxim Suhanov 8h ago

Most FDE vendors/projects don't consider vectors requiring repeated physical access as a vulnerability.

But there is another side to this: an HDD/SSD firmware backdoor (or a network attacker injecting arbitrary data into a disk image booted over the network) has a way to inject attacker-controlled data into an encrypted volume despite code integrity controls like Secure Boot and TPM-based unlocks (the "Implementation and Implications of a Stealth Hard-Drive Backdoor" paper told us the opposite).

In one MSRC case, Microsoft agreed to treat the data-only attack against BitLocker from the storage path as a vulnerability.

Show thread

Maxim Suhanov 9h ago

@wdormann, the whole issue was a cold boot attack without "cold" and "boot" (you don't need to freeze something and (re)boot to dump the memory containing secrets).

Show thread

Maxim Suhanov 9h ago

@wdormann, the reboot is for CVE-2026-20928.

Maxim Suhanov May 29

CVE-2024-13745 in EDK II (likely, "WONTFIX"): "what you measure is not what you use".

The story about firmware measuring bytes different from ones being used. It affects PCR[5], so the severity is low (nobody cares about PCR[5] by default).

https://www.openwall.com/lists/oss-security/2026/05/29/2

oss-security - CVE-2024-13745, EDK II: several issues with partition table measurements

Maxim Suhanov May 18

Rairii

May 18

hi everyone

given one #bitlocker #0day is already out there, here's my own bitlocker 0day, I added it to my repo listing bitlocker attacks.

Introducing "ram leak": https://github.com/Wack0/bitlocker-attacks#ram-leak

As we all know, the boot environment allows booting from a ramdisk. This involves loading a file from disk into RAM, as expected.

However, "file" and "disk" can be arbitrarily chosen, and "disk" being a BitLocker encrypted partition is a supported scenario. Using another trick (same one used with bitpixie earlier) it's possible to get the keys derived without going through the legacy integrity validation checks too if relevant.

You can see where this is going. It's possible to leak any file from a bitlocker encrypted OS partition into RAM as long as you can get the keys derived (ie, TPM-only scenario).

The catch is that booting into the NT kernel marks that memory area as free so it could get overwritten there, but there are other ways to dump the memory area, and a PoC is included with my preferred method (it's only a PoC so just displays a hexdump of the first sector of the file)

The video shows successful exploitation in my test VM, it has secure boot enabled (you can tell because VMware shows an efi shell option on the boot menu when secure boot is disabled).

#infosec #windows

Show thread

Maxim Suhanov May 14

@wdormann,

P.S.

> The YellowKey author disagrees that PIN is a protection

Since early WinRE bypasses, Microsoft treats the "my PIN is known to the attacker, in the TPM+PIN configuration" situation as within the threat model. (IMO, this is not 2FA with one factor known to the attacker, but something similar.)

Show thread

Maxim Suhanov May 13

@wdormann, these bypasses are very close to login/lock screen bypasses (after the usual boot) and kiosk mode escapes (in WinRE).

Show thread

Maxim Suhanov May 13

@wdormann,

> TPM-only bitlocker is known to not be very secure, and if you have TPM+PIN, then you can't get to Windows Recovery Environment Agent without the PIN. So again, where's the bypass?

The TPM-only mode works well to lock employees out of their corporate laptops (users can't mount the drive on another computer or in another OS using a user password) and with no requirement to create another strong password.

Also, all WinRE bypasses affect the TPM plus Network Key mode (seamless boot when the computer is in the trusted wired network: both the network server and TPM unwrap the encryption key).

---

It's interesting that Microsoft disguises some vulnerability descriptions as EoP, not as SfB.

Show thread

Maxim Suhanov Apr 27

@wdormann, recently, Microsoft acknowledged me for a vulnerability I never reported (CVE-2026-26175). I told them to double-check the case numbers and they silently removed the acknowledgment.

Also, there is no code change that is somehow related to the CVE's description. I believe this is "a technical CVE" that is going be used to block boot loaders that don't have enough defense-in-depth features (none of them is a vulnerability fix) implemented.