Heads-up : YellowKey - Bitlocker Bypass Vulnerability

Another "vulnerability" published regarding bitlocker working as designed. TPM only mode is the digital equivalent of leaving the key to your front door under the door mat... it's pretty easily bypassed as a result.

Seriously, if you have the TPM module, and a bitlocker volume encrypted with the key stored in TPM... then you can just read the TPM and use the provided key to decrypt the volume.

The lock and the key are never separated unless you take the drive out of the computer in question.

The only exception to this is when you set a boot password, this locks the key in the TPM itself with another layer, and prevents this "exploit" from working too. But you have to be willing to suffer through the second unlock of the platform. There are many ways to get into Windows PE and access the TPM and subsequently the associated disk. This code isn't new, or particularly novel.

Here's the AI list of Bitlocker escalations:

1. TPM‑only mode (weakest)

  • The TPM automatically releases the decryption key if it detects the system booting normally.
  • This protects against offline attacks (e.g., someone stealing the drive), but notagainst:
    • Cold boot attacks
    • DMA attacks (e.g., Thunderbolt, PCIe)
    • Evil Maid attacks
    • TPM key extraction via hardware attacks
This is the scenario exploited in the above link

2. TPM + PIN (much stronger)

  • The TPM will not release the key without a user‑entered PIN.
  • Physical possession alone is not enough.

3. TPM + USB startup key

  • Requires a removable key at boot.
  • Again, physical possession of the drive alone is insufficient.

4. Password‑only or key‑only (no TPM)

  • Strong against hardware attacks but less convenient.
 
Last edited:
This security guy is talking about a backdoor in BitLocker, not just another vulnerability...
It's a serious lost of trust in MS products!

Anyway, this one is so easy to use it can be used to help some customers...
 
This security guy is talking about a backdoor in BitLocker, not just another vulnerability...
It's a serious lost of trust in MS products!

Anyway, this one is so easy to use it can be used to help some customers...
It’s not a “back door” not really. What’s happening is simply how TPM‑only BitLocker is designed to work.

If an attacker has physical access to the device, they also have physical access to the TPM. With older discrete TPMs, that meant the attacker could probe the external bus or intercept the key material as it was released during boot. This is one of the reasons modern systems use integrated TPMs (Intel PTT, AMD fTPM): by embedding the TPM inside the CPU package, you eliminate the external bus and remove a major physical attack surface.

But the core issue remains: if BitLocker is configured in TPM‑only mode and the device is stolen, the attacker now possesses both the encrypted drive and the TPM that automatically unseals the key. BitLocker will unlock as long as the boot chain matches the expected measurements.

And that boot chain includes WinPE. WinPE is part of the measured boot environment, and its hash contributes to the Platform Configuration Registers (PCRs) inside the TPM. As long as the firmware, bootloader, Secure Boot policy, and WinPE image match the PCR values BitLocker was sealed to, the TPM will release the Volume Master Key with no user authentication required.

That’s the real weakness not BitLocker’s cryptography, but the convenience‑first configuration. TPM‑only mode creates the appearance of strong security while silently relying on the assumption that attackers will never gain physical access to the device. It satisfies compliance checkboxes and insurance requirements, but it does not meaningfully protect a stolen machine.

If you want actual resistance to physical access, you need pre‑boot authentication TPM + PIN, TPM + USB key, or similar. Without that, TPM‑only BitLocker is secure against offline tampering, but not against someone holding the hardware in their hands.

So given this context, you can expect over time TPM-Only configurations to be broken in various ways, the design is simply technically fragile, and it always will be.
 
Is Veracrypt immune? Requires a pre-boot password.
Not from what I can see, but it also doesn't leverage the TPM at all... and that's very bad.

From what Copilot is telling me Veracrypt has its own process to use a boot password to algorithmically unlock the real keys and then decrypt the volume. This would appear to emulate TPM based unlock processes.

But here's the rub...

The TPM is the tool that stops brute force attempts on that relatively weak local password. VeraCrypt apparently keeps all that in the partition header, so a threat actor can just hammer on it, with feedback, until it cracks. And the time required boils down to how long that password winds up being. (Lock and key are in the hard disk)

Keys inside the TPM are not supposed to provide feedback, if the entire process doesn't line up perfectly, it simply doesn't release the data. This is the entire reason why Windows Updates can at times eat bitlocker's lunch. (Lock is hard disk, key is TPM)

So no, Veracrypt is by design not vulnerable to the same TPM based bypass we've been talking about in this thread. But it is vulnerable to a larger comparable weakness.

Crypto is hard... and people are really devious.
 
Crypto is hard... and people are really devious.

Yep. Computer security as an arena has been like MAD Magazine's Spy vs. Spy since the first day I stepped into the world of computing.

If quantum computing ever comes to pass (and it will, but not likely during my lifetime) everything about cryptography will have to change, and in ways I doubt anyone can yet anticipate in any real way.
 
TPM‑only mode creates the appearance of strong security while silently relying on the assumption that attackers will never gain physical access to the device. It satisfies compliance checkboxes and insurance requirements, but it does not meaningfully protect a stolen machine.
Isn't TPM-only mode the default when drive encryption is activated automatically by Windows including Home edition? This begs the question, what is the point of TPM-only encryption and what is the point of activating it automatically? I thought the point was protection of data if the machine is stolen...
Anyway, this one is so easy to use it can be used to help some customers...
I've had a couple of customers that have lost their data due to Windows automatic drive encryption and Microsoft account login issues. Maybe Yellowkey could have been used, or could be used next time I have a customer with this!
 
I thought the point was protection of data if the machine is stolen...

And it does in 99.999% of cases. Most stolen devices do not land in the hands of tech geniuses or anything near to such.

Also, it has always been foundational to computer security that if physical control of a device is lost, all bets are off. Just having a PIN requirement or password requirement (as comes with a Microsoft Account linked Windows user account) adds a big roadblock to the amateur thief or random person who finds a device. If BitLocker is in place, it's orders of magnitude more difficult to get at the data.

The above comes from someone who has very intentionally disabled BitLocker on my Win11 Pro instance. I have encountered enough "accidental security" in the form of someone who should be able to access a drive that's been BitLockered be unable to do so. I've also not had any client in all my years that has had their unencrypted data stolen (to my knowledge, anyway, and had that crisis arisen, I would have been called).

No security measure, alone, is foolproof. And, as someone I respect quite a bit on BleepingComputer once said: Security is about layers. I've posted this material in more places than I can count at this point. Even if some of it is dated, it's still worth a read because "the big picture" remains largely unchanged from an end user perspective:
Quietman7, a security expert who is an active contributor on Bleeping Computer, has written extensively on what you (any you) need to do to develop safe interaction habits with cyberspace. The following four are, in my opinion, must-reads:
 
@fincoder What @britechguy said. It's not worthless, it just doesn't quite provide the value that people think it does. And you are correct, Device Encryption is TPM backed bitlocker volume encryption.

What it does primarily, is lock the C volume into a state where the OS can detect if it's been modified outside of itself. We have entire categories of malware that use weaknesses in EFI to modify C drive contents on reboot. That simply cannot happen anymore. The process is less about preventing illegal data access on device theft (which it does do in many cases) as it is about authenticating the boot process and ensuring the kernel isn't modified outside of the user's knowledge.
 
The process is less about preventing illegal data access on device theft (which it does do in many cases) as it is about authenticating the boot process and ensuring the kernel isn't modified outside of the user's knowledge.
OK, I get it now. Thanks for that explanation.

Now that a tool (YellowKey) is freely available to enable copying files from a stolen computer with default encryption, it should be assumed that data is now likely to be obtained.
 
OK, I get it now. Thanks for that explanation.

Now that a tool (YellowKey) is freely available to enable copying files from a stolen computer with default encryption, it should be assumed that data is now likely to be obtained.
I always have done so, again if you aren't using a boot password to unlock the TPM, you've never separated the lock and the key sufficiently to prevent this risk.

However, I also do not expect this tool to work for much longer. I expect Microsoft to patch something to resolve the WinPE hole, and in the process we're going to have more bitlocker failures requiring recovery keys.
 
However, I also do not expect this tool to work for much longer. I expect Microsoft to patch something to resolve the WinPE hole, and in the process we're going to have more bitlocker failures requiring recovery keys.

This is what I'm afraid will happen.

What it does primarily, is lock the C volume into a state where the OS can detect if it's been modified outside of itself. We have entire categories of malware that use weaknesses in EFI to modify C drive contents on reboot. That simply cannot happen anymore.
and THIS is my main takeaway from this thread. I've always thought that the oh-so-narrow case that bitlocker protects against barely justified its existance. I'm embarassed to say I never dug into it enough to recognize its anti-malware value.
 
A very great deal of "common practice" in basic computer security is really only effective at keeping "clumsy amateurs" locked out who may be trying to get in.

If it's not abundantly clear, just based on history, that "where there's a will, and a sufficient intellect to act on it, there's a way," to break into virtually anything then it never will be. This does not mean, however, that one just throws up one's hands and does nothing. But it should cause one never to believe that anything on a computer, and definitely not on one connected to cyberspace, is ever 100% secure. But if it were 100% secure, it would be hellish to use if it could be effectively used at all.

The stuff I posted earlier from Quietman7 applied when he wrote it and it still applies on the whole. Security is about layers and the weakest layer, always, is the person sitting in front of the screen. How many layers, and how complicated those various layers need to be, is directly dependent on what one is trying to secure. There is no one-size fits all circumstances. They range from, "eh, who really cares," to, "matters of national security," levels of security.
 
Back
Top