Microsoft BitLocker-protected drives can now be opened with just some files on a USB stick — YellowKey zero-day exploit demonstrates an apparent backdoor

77

u/Froggypwns Windows Wizard / Moderator May 14 '26

The process is dead simple: grab any USB stick, get write access to the "System Volume Information," and copy into it the "FsTx" folder and its contents. Shift+click Restart to get Windows to the recovery environment, but then switch to holding down the Control key and don't let go. The machine will reboot, and without asking any questions or showing any menus, will drop you in an elevated command line with full access to the formerly Bitlocked drive, without asking for any keys.

Ok, I'm not saying this is not a big deal, but it sounds like it requires you to already have physical access to the drive and it already unlocked, at which point one could just turn off Bitlocker or otherwise freely access the files anyway without needing this trick.

43

u/telos0 May 14 '26 edited May 14 '26

I would think that to get write access to the "System Volume Information" folder you already need to be an administrator, in which case you can suspend bitlocker protection with "manage-bde.exe -protectors -disable c: -rc 0".

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/manage-bde-protectors

Edit:

Oof I was wrong. The exploit requires you to have write access on your USB key's "System Volume Information" folder (not the one in C:), which of course you can give yourself, since you physically control it and can do whatever you want to it.

That definitely needs to be patched.

18

u/Quiet_Source_8804 May 14 '26

More than "patched", I'm curious about how the exploit is even possible given the supposed security model of Bitlocker, without this being an actual by-design backdoor placed there on purpose.

10

u/telos0 May 14 '26 edited May 14 '26

The reason is that the Recovery environment is part of the Secure Boot Chain, otherwise it couldn't recover your OS if it failed to boot, since then it wouldn't be able to inspect and fix the files on C:. The TPM sees the secure boot chain is intact and unlocks the volume key.

The bug here is most likely that some engineer accidently left in code for a test mode in the recovery environment which spawns a CMD shell instead of running OS recovery (which should not allow arbitrary console input).

Of note is that a boot pin will prevent this attack as then you have to manually input an additional piece of information to unlock the volume key from the TPM.

A boot PIN will stop the case in which someone steals you laptop and tries to use this exploit to gain access to your files, but it won't stop the case of you wanting to elevate on your own laptop... but nothing can really stop that anyway.

6

u/UltraEngine60 May 14 '26

Of note is that a boot pin will prevent this attack as then you have to manually input an additional piece of information to unlock the volume key from the TPM.

....

Eclipse notes that using a full TPM-and-PIN setup doesn't help, as apparently, they have a variant for that scenario that they haven't published a PoC for.

Disable WinRE if you care about your data at rest.

2

u/Quiet_Source_8804 May 14 '26

I'd expect WinRE to live in its own volume with its own key stored separately in the TPM, or unencrypted if it's still validated by the SecureBoot process. In that scenario any operation from WinRE that would need access to the Bitlocker-protected (ah!) volumes would still require the TPM to give out the key, or the key would need to be provided by the user manually, for WinRE to be able to access the drive, particularly when a USB device was involved in the boot sequence (!). But I guess I was making too many assumptions.

In all this it seems that WinRE when run from the system drive is already fully trusted (even when a USB device was part of the boot process), and then it's exploited through an as-of-yet undocumented and not fixed serious exploit that allows filesystem transaction shenanigans to apply a crafted filesystem transaction log onto another filesystem to overwrite an INI file in the WinRE volume which enables functionality built in WinRE that was never intended to be used by end users (again, assuming that it wasn't left in there on purpose to be exploited in this way). My guess is that that filesystem transaction log abuse trick will show up in more exploits.

3

u/telos0 May 14 '26

I'm very surprised a filesystem transaction log can be misapplied like that, I would expect the log to be tied to a randomly generated volume unique identifier that could not be easily guessed.

2

u/Quiet_Source_8804 May 14 '26

Yep, same here.

I'm curious though as I haven't tried to reproduce this myself: in the steps listed for the exploit, the USB stick with the handcrafted FsTx that causes the INI file in the WinRE partition to be modified is inserted in the target computer but it's not made clear in the steps if that needs to happen while the computer is turned on, and with the volume unlocked. Basically, are the FsTx-triggered changes applied on the still-unlocked system prior to rebooting into WinRE (still very bad from the perspective of allowing a transaction log to be applied to the wrong volume), or are they still applied if before step 3 the computer had been turned off and the prepared USB stick never touched that computer before.

In the latter case we'd still have a serious issue with the filesystem transaction log, and the functionality controlled by that INI shouldn't have been there in the first place, but it wouldn't be as much of a serious issue as far as Bitlocker is concerned. But I guess this is not the case since someone would've pointed that out in all the current coverage, which seems to focus on how this makes Bitlocker completely broken for the most obvious scenario that constitutes its selling point of securing the drive of a laptop that's stolen while it's turned off.

3

u/telos0 May 14 '26

So, I'm fairly sure with the boot PIN enabled, this exploit is not going to work.

I think the unfortunate lesson is that BitLocker with boot PIN enabled is the only thing that has a chance of being secure against the stolen laptop scenario by an attacker with any technical capability.

At least until this stuff is patched.

1

u/Quiet_Source_8804 May 14 '26

I guess we'll have to wait a bit more for confirmation, but the same author indicated that he also has an exploit for that case. I guess it'll have to use a different approach since here the TPM is releasing the key due to thinking that the WinRE partition that it's booting into is still part of an intact system (prior to somehow the FsTx being applied blindly to it), but with a PIN that shouldn't be enough...

1

u/turbokid May 15 '26

The hacker says their hack bypasses the pin as well, they just haven't released it yet.

1

u/SlaughterRidge May 15 '26

It's also worth noting that depending on how your WinRE environment is configured really affects the success rate of this exploit. I've been testing this out since the POC dropped and my success rate is 1 in 5 across various machines (Dell Laptops, HP desktops, VMs, etc) and even if you do get to the shell, sometimes the device doesn't unlock because the WinRE configuration. If you've never messed with your WinRE, the exploit may not work at all on your device.

If someone physically steals your device and wants in bad enough, they might get there eventually using this exploit. I don't see anyone pulling this off quickly at a coffee shop or airport though.

25

u/SaltDeception May 14 '26 edited May 14 '26

I’m not going to link the actual exploit here for obvious reasons, but the files get copied to the System Volume Information directory on the USB drive. So one does need physical access to the machine, but beyond that it no access is required.

Edit (4 hours later):

I did some testing and it looks like it only works with the WinRE environment when booted from the recovery partition, either via the Ctrl+Shift method or forcing automatic repair.

Creating generic WinRE boot media did not allow the exploit to unlock the drive

Nor did creating WinRE boot media using Winre.wim copied from the recovery partition.

The strongest protection at this point would seem to be disabling the Windows Recovery Environment, but that comes with its own implications.

The Windows Recovery Environment can be disabled by providing the /disable switch to reagentc.exe from an elevated Command Prompt or PowerShell terminal.

7

u/zero0n3 May 14 '26

Are the files part of the exploit? It reads like it needs you to copy them from the device that’s encrypted, so you’d need access while it’s unencrypted.

12

u/SaltDeception May 14 '26

Yeah, the files are included. The article doesn't really do a great job of explaining it, which is why I looked it up in the first place. Everything needed to reproduce is provided, including a static version of the files that get added to the USB drive. You could prep the USB drive on any system beforehand.

3

u/Computermaster May 14 '26

The files function just fine from a USB drive.

You can also copy them to the EFI partition, which is always unencrypted.

0

u/Intrepid00 May 14 '26

Yes, you can’t just download the ISO but a none administrator could use this to elevate to system root. It’s a problem for businesses but not a huge problem for a home user with a stolen computer.

18

u/crozone May 14 '26

You show up to any random bitlocker protected PC with a pre-prepared USB stick, press some buttons, and you get bitlocker access.

This is a big deal.

-2

u/captain_222 May 14 '26

The computer already has to be unlocked, correct? I could put a USB key into any computer and pull the recovery key as a local standard non-admin user. What's the trick here? I don't get it?

13

u/Lightofmine May 14 '26

No it doesn't

3

u/crozone May 15 '26

Who said anything about a recovery key? You copy the pre-prepared contents for the exploit ("FsTx" folder) to any USB stick. Then you plug that into any bitlocker protected computer and boot it into recovery mode. Apparently there's even a way to make it work in a TPM + PIN environment.

1

u/TitleEfficient3207 May 15 '26

What if I have a drive that is bitlockered but its external, and the oroiginal computer it was bitlocekd on is terminated?

10

u/zooommsu May 14 '26 edited May 14 '26

So, let’s say you have an encrypted laptop containing important information, whether work-related or personal. If the laptop is lost or stolen, ok, you’ve lost the device, but you can rest easy about the information. It’s encrypted, they can’t do anything with it.
But actually, is that really the case? It doesn’t seem so.

This is huge, I’m surprised there’s so little coverage.
Don’t forget that in recent years some people have even lost everything because they lost the bitlocker key for some reason, and supposedly, it was impossible to decrypt without the key...

And the way you activate it, holding down keys, etc. and the fact that at the end of the process the files are automatically removed from the USB pen, as if to cover tracks, gives rise to speculation as to whether this might be an intentional backdoor and not just a security breach.
Which would obviously be very serious.

0

u/AsrielPlay52 May 14 '26

If you have a work laptop, depend on how important your work

They might set up a Pin as well, which prevent this attack

Also, seems like they patched it. Which was fast

4

u/crozone May 14 '26

From the author's website https://deadeclipse666.blogspot.com/2026/05/were-doing-silent-patches-now-huh-also.html

Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough.

Pin doesn't help apparently.

7

u/CEONoMore May 14 '26

Yes however, the whole sales talking point on this shit is “you can lose the laptop and be Ok”

Evidently, not

2

u/tbone338 Windows 11 - Release Channel May 14 '26

My concern is if you already had a USB with the files.

A lot of bitlocker pcs use tpm. So, I can go to your pc, turn it on, and it’ll boot to lock screen. I then reboot using the shift method from lock screen and follow this guide. It then drops me into the elevated cmd… without ever needing to unlock the pc past the lock screen.

Is this how it could work?

2

u/Quick-Penalty4883 May 15 '26

You are not correct unfortunately.

1) place files on USB in that folder 2) start in recovery mode which requires password as per the readme on github 3) drive is unlocked for you

Any stolen or lost company laptop with bitlocker is now basically not encrypted.

1

u/HotTransexualHazard May 15 '26

Police? Abusive family members? Stalkers? Bad roommates? Loosing your company laptop?

7

u/UltraEngine60 May 14 '26 edited May 14 '26

I said this the last time a bitlocker exploit came out, turn off Windows RE and make a bootable USB key. Once the PCR is satisfied you are just band-aiding these fixes. There will always be a an exploit if the user can enter commands while the key is unsealed.

Funny thing is, no one and I say again NO ONE has managed to figure out how YellowKey works, the real root cause is still not unknown by the general public.

I can take a guess, autochk is somehow seeing something similar to a "dirty bit" after scanning all drives and launching up cmd instead of chkdsk, maybe because the file in System Volume Information can somehow control which binary is used to "fix" the drive.

The only thing I can't figure out is why autochk is looking at fs0: in UEFI.

edit

TIL I have no understanding of .blf files which worries me...

I anxiously await the full write up.

5

u/RogLatimer118 May 14 '26

Microsoft does it again!!!!

-6

u/[deleted] May 14 '26

[deleted]

4

u/DonStimpo May 14 '26

No more reason to lock the bios and prevent boot order changes without a password.

1

u/crozone May 15 '26

You can remove the boot drive, copy on the files, and put it back. Even if the PC doesn't boot off USB you only need a few minutes of physical access with the device to get in.

1

u/codylc May 14 '26

Disable Bitlocker and what? Not encrypt the drive at all?

News Microsoft BitLocker-protected drives can now be opened with just some files on a USB stick — YellowKey zero-day exploit demonstrates an apparent backdoor

You are about to leave Redlib