YellowKey Mitigation
Posted by Titanium125@reddit | sysadmin | View on Reddit | 66 comments
I was curious if anyone has tested any YellowKey mitigations? I read a post last week that looked like if you used Microsoft Intune to store the key and decrypt the Bitlocker volume rather than the TPM on the computer that seemed to defeat YellowKey as it had no way to extract that key.
I'm curious if anyone knows if using Network Unlock in Active Directory would do the same thing? I believe it would as it works very much the same way, but I am not 100% sure as I have not tested it.
Let me know your thoughts.
sheep5555@reddit
I dont believe there is any current mitigation, the unlock works with TPM + PIN but the author did not publish that PoC (yet), so that may be the best action if or until MS decides to remove their backdoor
PigeonRipper@reddit
Yeah many seem to have missed this part. We have to assume they'll release the TPM+PIN bypass too
gripe_and_complain@reddit
My assumption is that the TPM+PIN bypass does not exist.
Valdaraak@reddit
Yea. They apparently have a vendetta against MS from what I was reading so they're likely going to wait until the current one is patched, check if the PIN bypass still works, then release it just so MS can't fix them both at once.
SaltDeception@reddit
Disabling booting into recovery mitigates the exploit, but obviously raises its own issues. The exploit can only be used when booted from the recovery partition (i.e. not removable media).
reagentc.exe /disablewill disable recovery boot./enablewill revert/infowill show the current statusNo reboot is required for these commands
sheep5555@reddit
The PoC author stated in another post that disabling WinRE doesnt mitigate the exploit
https://deadeclipse666.blogspot.com/2026/05/important-updates-regarding-yellowkey.html
SaltDeception@reddit
Their comments make absolutely no sense. You must be in WinRE for the execution to work.
I did pretty extensive testing with this last week. The only way to enter WinRE with recovery boot disabled is to boot from removable media. When you boot from removable media, the exploit does not function. The filesystem transactions still take place in the WinRE RAM disk WinRE loads, but the bitlockered drive will not unlock.
I even went so far as to build removable media that utilizes a known vulnerable version of WinRE pulled directly off the recovery partition and it would not unlock the drive.
I also have my doubts as to the honesty of the author on some of this. I think they're actively trying to make this seem worse than it actually is because of their emotional stake here. For instance, TPM+PIN bypass they claim to have does not make sense either.
So for both, I'll believe it when I see it.
VexingRaven@reddit
You mean the person who claims Microsoft made them homeless and took their family and friends might not be entirely truthful?!
Hangikjot@reddit
oh boy, some of the best security researchers and analyst I know are wack in the head. Had one employee, amazing. Kept a log of what trash was in the nearest trash cans and who parked where in the parking lot, how many cars and probably. I'm sure i could ask him people pee schedules and he would know. We once had a utility van parked across the street for a few days, he had to work from home it was too much for him. But man, he was amazing at his job.
iB83gbRo@reddit
They said that they're not sure if disabling WinRE is a solution.
lebean@reddit
Seems many are (reasonably) doubting the veracity of the claim that it works with TPM+PIN, except in cases where you know the PIN (which, duh, obviously it still works there). The PIN allows release of the key from the TPM, so if their exploit works for TPM+PIN when you have no knowledge of the PIN, they haven't just broken Bitlocker, they've broken all TPM functionality universally.
gripe_and_complain@reddit
This. Thank you.
dreniarb@reddit
I've yet to see any proof that yellowkey is real. I've tried numerous methods to get it to work and they all fail - i'm always asked for the bitlocker recovery key.
everything i find about it online is just articles or videos talking about the exploit, but no one has shown it to actually work.
as others have said i'll believe it when i see it.
gripe_and_complain@reddit
Will Dorrmann at infosec dot com claims to have used it successfully. My skepticism is about the claim it also works on TPM + PIN systems. aka reboot PIN.
ccatlett1984@reddit
The mitigation is to disable winRE
Kardinal@reddit
This is what we are evaluating and we don't like it. Significant other impacts. But it may be necessary.
jamesaepp@reddit
What impacts? Do you expect end users to use the RE? Do you expect your helpdesk/admins aren't capable of putting together a Windows boot USB?
warpedgeoid@reddit
My experience has been that the level of skill is very asymmetrical.
jamesaepp@reddit
Only after thinking on this more today, it occurred to me that some of the reset operations Intune uses almost certainly rely on the Windows RE being in good health.
I rarely use those operations, but losing remote reset would certainly be .... unfortunate if the device is stolen.
Which in a round-about way brings me back to the original question of "just what the hell are we doing here?".
CaesarOfSalads@reddit
We have been removing the windows recovery partition from our systems for the last 5-6 years with no negative effects. This coupled with requiring the bios password to boot from USB hopefully leaves our systems in good standing from this "exploit"
warpedgeoid@reddit
It makes them look good on paper, but if the malicious actor has physical access to the PC, it’s only a matter of time before they have access.
chrusic@reddit
I'd be grateful if you could expand a bit on that and answer some questions I have:
mcholbe2@reddit
If someone has physical access this doesn't provide any protection.
ScoobyGDSTi@reddit
It does for all but the most advanced adversaries.
mcholbe2@reddit
Unless your drive is integrated all it takes is a screwdriver.
ScoobyGDSTi@reddit
How's a screwdriver going to decrypt it?
ribsboi@reddit
The GitHub says "Funny thing is, the vulnerability is extremely convenient, you don't even need to plug an external storage device, you can just pull out the disk, copy the files in the EFI partition, put it back and it will still work. That's how bad it is."
Have not tried it myself, but curious. I'll delete WinRM from a device and see what copying the FsTx to EFI does.
mcholbe2@reddit
I was referring to a BIOS password providing protection against this exploit. It was already mentioned in the comments here that the exploit can be run from recovery media.
Kuipyr@reddit
We’ve decided to only do laptops and other portables and accepted the risk on fixed workstations.
Kardinal@reddit
Yeah we are 100% laptops so not really much help there.
We also lock down hard what can be on them so we are evaluating if the juice is worth the squeeze.
Kuipyr@reddit
https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/personal-data-encryption/
Haven’t tested it, but it might keep user files safe at least.
Kardinal@reddit
I spoke to my endpoint team this morning about exactly that. Apparently it's already in place I just didn't remember the name offhand.
So that's a big mitigation too.
ccatlett1984@reddit
You can still get to the system files, and SAM database, so I wouldn't consider that a mitigation.
Kardinal@reddit
Mitigation not solution.
ccatlett1984@reddit
Can still do things to affect a cached credential. Or put something in place that will run when the user logs back in. (Yes, not exactly a common scenario).
VexingRaven@reddit
Is this actually a mitigation? IIRC the person who originally found it said they could make this work without WinRE being on the device but they weren't going to post that one.
Mrh592@reddit
Not really, can just boot winre from an external disk. Just seems to be a stop gap to using the existing disk with it. Possible to lock down with motherboard boot restrictions i guess.
Icolan@reddit
From what I have read of that vulnerable it is a bypass and is not extracting the key so it should not matter where the key is stored.
BoringLime@reddit
Looks to be a backdoor to me. The file they created flips all the backdoor enable switches to let it bypass and keep the bitlocker drive unlocked. They reversed engineered the conditions from the dll file with the checks. Some will say it's a leftover debugging code but it really looks like a backdoor. Also the people that released it says it can also work with drives that have a tpm and a pin as well but did not release that one to the public. I think at this point this researcher has proven they are good at finding these types of issues. So I have to believe them.
Rawme9@reddit
As far as I can tell this is correct. It is queuing Windows Recovery to unlock the disc but not actually extracting the key. So key storage doesn't matter at all for this.
MoutonNoireu@reddit
BIOS password 👍
picklednull@reddit
As always, the mitigation is to use a PIN, as Microsoft has always recommended.
cspotme2@reddit
That is, until he releases the poc/exploit which can bypass pin too.
picklednull@reddit
I suspect we will be kept waiting.
The TPM literally does not unseal the Volume Master Key without the correct PIN being presented.
DefectiveLP@reddit
As far as i understand, the master key is not being touched in this exploit, but instead the unlock is triggered directly.
picklednull@reddit
Without a PIN, the TPM releases the VMK based on PCR measurements alone to the Windows bootloader. The bootloader passes it to Windows (or WinRE) so that the system can be booted (WinRE resides on an unencrypted partition, but the bootloader verifies the image by hash before accepting it). WinRE boots with the OS drive initially decrypted i.e. ”unlocked”, the drive is only locked for security when certain operations are initiated, e.g. opening a command prompt. The YellowKey bypass just prevents the automatic locking from occurring due to some glitch.
It’s set up this way so that the PCR measurements remain the same while both environments can be booted into and also some recovery actions can be initiated without entering the recovery key.
ScoobyGDSTi@reddit
^This.
The exploit uses a NTFS transaction playback file to manipulate the WinRE environment to keep the OS volume unlocked.
This is why TPM only Bitlocker protection is explicitly prohibited in Defence and secure environments. The TPM will handout the Bitlocker decryption key as long as the PCR registers and measured boot remain unchanged.
That's why a passphrase, start up key or network unlock in addition TPM should always be used when protecting highly sensitive data.
mbhmirc@reddit
That’s not quite true ;)
picklednull@reddit
Dying to hear more ;)
mbhmirc@reddit
The pin attack in theory will only work on certain hardware. Like everyone else I will have to wait and see if it’s a similar bug if they decide to release. I imagine they might try and get bug bounty…
lebean@reddit
I think everyone has pretty much realized at this point that the author is likely lying about it working with TPM+PIN, except in cases where the PIN is known which shouldn't be surprising to anyone at all. The PIN is directly used by the TPM to release the key, not by Bitlocker, so if TPM+PIN is working w/o knowledge of the PIN then the author has broken all TPM functionality period, regardless of OS.
kerubi@reddit
PIN should be used anyways, it mitigates many other Bitlocker attacks, and we have not yet seen the PoC for PIN so it might even not exist.
cspotme2@reddit
I'm not doubting that Nightmare Eclipse has a pin exploit for this too.
Mafamaticks@reddit
I’d love to know who actually has pre-boot PINs implemented in their environment. After blowing up patching numbers, calls to the help desk ‘cause users forgot their PIN, and manual intervention to encrypt devices, I know those admins feel vindicated right now.
ScoobyGDSTi@reddit
Any organisation that takes their endpoint security seriously does. It's the norm in most defence and military organisations to require starup key or passphrass in addition to TPM on endpoints.
christurnbull@reddit
I have seen some defence companies using pin
bfodder@reddit
I guarantee you those telling you they have no problems have tens of thousands of sticky notes stuck to machines with the PIN.
Adziboy@reddit
40,000 devices here, all with pre-boot PINs and have done for years. Really no issue. Almost never get calls for resets because it becomes second nature for people and they often keep the PIN the same
Olafthehorrible@reddit
70,000 devices in my org. About half of them are pre-boot pin locked. We have occasional issues but we drill it into them to make the PIN easy to remember.
Tall_Significance294@reddit
LUKS
gripe_and_complain@reddit
The silence from Microsoft concerning this exploit is deafening.
Mountain-eagle-xray@reddit
People in this thread must be cyber employees because you all have no idea what mitigation actually means.
Mitigate does not mean to eliminate the vulnerability, or even to make it not feasible to attack. It really means additional protections and ways to reduce the severity.
With that definition, there are plenty of ok mitigation mentioned in the thread.
noOneCaresOnTheWeb@reddit
Move to ReFS?
sgt_Berbatov@reddit
It's a difficult one.
Sure, ReFS has it's benefits but it's proprietary to Microsoft. As is, really, Bitlocker. Couple this with the fact this YellowKey thing smells a bit like a backdoor, I would not put too much faith in to ReFS being any more resilient than what we have now.
ddBuddha@reddit
Idk, from what I’ve seen it seems to be a straight up backdoor. Interesting situation for sure, curious to see what everyone else says.
MuthaPlucka@reddit
Turn off all USB drive access and lock BIOS behind a password (to start with).