bitlocker is generally useless unless the hardware is secure to begin with and while we have tons of 'boot guard' implementations which fuse the certificate into hardware meaning that only the OEM can create firmware that will boot there have been at least 2 instances of these certificates leaking exposing all hardware with that signature and other bypass methods (some boot guards are 'flash' guards were you can only flash signed firmware, but doesn't stop you from directly flashing the spi bios chip).
I had someone demo me preserving PCR values by patching SMM module in firmware without triggering any bitlocker lockout, this also means that you can externally write bios with the smm module as long as you have ~2 minutes to disassemble the laptop or desktop and flash firmware.
This hurts the most when you don't have PIN authentication which means you just need to steal the laptop to exfiltrate data, if you do then you have to have the user boot which then drops a payload exfiltrating data over network or just stealing the laptop again as you can write back decryption keys into non encrypted partition or corrupt some sectors at the end of the disk and write them there.
* modifying smm allows you to patch the boot process loading a malicious payload into hypervisor/kernel.
Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
we're not talking about the hdd/ssd here, those are not really encryption but data packing and compression algorithms, they added encryption because it's a single instruction for extra talking points.
you use veracrypt which doesn't have any hardware attestation (convenience) features, but it does still leave you vulnerable to the same surface PIN+TPM is vulnerable to. the real defense is making it so opening your laptop/desktop physically fuses something via latch and wipes the key off your system requiring re-entry.
of course, who wants to own a laptop/desktop that you can't open we have enough of that with our phones.
Though I am convinced this is intentional, i.e. a backdoor and not a bug, it should be noted that for goverment agencies there was already access anyway:
Access for those who used a Microsoft account and upload their encryption keys there. While I’m unhappy that most of the users end up using this (bad) mode, previously I was under the impression that there was a meaningful choice involved.
The BitLocker exploit seems simple and very dangerous. Companies and individuals have been relying on BitLocker to protect information if the device is lost. Despite promises, Microsoft doesn’t seem to be serious about security.
What will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?
Note that RedSun and Bluehammer were silently patched, with no response to the CVEs by Microsoft, and not accrediting the researcher's work.
That's what this is about. Microsoft doing bad security practices while trying to get away with it, leading to this outcome.
The researcher also claims to have another version ready which allows to also bypass TPM+PIN via a similar backdoor, which I'm inclined to believe.
Why do I believe that? 5 ring 0 zero days within 3 months are so statistically unlikely to be found, by the same person, in such a short time. Whoever this person is really knows their exploits, and must be in the league of Juan Sacco.
the only way to bypass PIN would be an actual backdoor in Bitlocker. no way around that. an actual backdoor in microsoft encryption was never documented, and there are Snowden documents showing FBI pressing Microsoft into introducing one and Microsoft refusing
Along with other facets of this, what are the odds a "bug" would also automatically erase evidence of itself from the bootable USB stick when it activates?
That’s the most puzzling part to me. What’s the point of the PIN then? I was assuming it was mixed with the TPM secret somehow but if it can be bypassed then it shows it just an IF statement somewhere. Dang…
God I hate this stupid design of burying the decryption key in the TPM and hoping the software does not get fooled to reveal it.
Microsoft always sucks. Why don’t you ask for the password at boot time and derive the key from it. So much simpler and makes this kind of attacks impossible. Nobody is going to bypass LUKS or FileVault like this.
I think anybody who has been paying attention has assumed for at least 20 years that all of Microsoft’s shit is backdoored anyway. I mean, the original Snowden revelations made that abundantly clear if it wasn’t before then.
Businesses use Microsoft because they figure if it’s backdoored it doesn’t matter and won’t affect them (because they aren’t terrorists or child pornographers or whatever, and they’d comply with a subpoena regardless of if Bitlocker is backdoored or not) and individuals who care about security and privacy put their shit on a Veracrypt drive somewhere else.
I guess that most people who use security features of Microsoft products only do so to tick compliance checkboxes and they really don't give a fuck about actual security.
Which makes me think, it's becoming more and more urgent to make an open source mobile OS happen.
It's not an actual backdoor. An attacker found a way to exploit Windows after booting it up in this recovery mode. The security of files on the device depends on it being impossible for Windows to be pwned by an attacker on any surface exposed before the user is unlocked.
This is why operating systems like GrapheneOS disable the USB port on the initial boot to limit the attack surface that an attacker has.
Having a specific file name trigger the decryption to happen automatically, while also removing said files after this is achieved, is an extremely unlikely bug. I think for most people evaluating this, the onus is now on anyone thinking this is not a backdoor to prove how a mistake in the code can trigger this very specific scenario.
This is like finding out that an OS accepts an SSH private key circulating online that the sysadmin for those OS boxes never authorized, and saying "wait, we don't know that this is a backdoor into that system, the attackers just found a bug".
What would you require to feel confident it is a backdoor?
Nadella gives a press release, "Alright guys, you got us fair and square. Backdoor on Bootlocker. Various versions of it for years on behalf of the spooks."
You are unlikely to ever get a confirmation of wrong doing. That being said, for a first line security posture, there is no way external media should have anything to do with the encryption process. Even if the OS chose to read a USB drive, to also delete the magical files is ridiculously suspect.
It could always be plain old incompetence, but that is a damning level of technical ineptitude assigned to such critical infrastructure. This is not a project you assign to the intern, but paranoid security experts. Multiple levels of code review and red-teaming.
Properly secure symmetric encryption needs a key with at least 128 bits of entropy. In the "device lost/stolen" scenario, that key must not be on the device. Key inside a TPM on the device itself is DRM, nothing more. There's better and worse DRM, I think the iPhone bootloader one is one of the better ones, but it's still just DRM.
You either need to enter a 128-bit entropy password on every boot (good luck with that) or you need to hold it on some external device, with some variant of USB / smartcard / NFC / Bluetooth to transmit it. NB. this is one of the cases where the usual "key for signing only, never leaves device, ephemeral DH and ZK protocols" like for SSH will not work on its own; you need the high-entropy key physically separate from the device.
So much this. Security information should simply never reside on-device in the first place.
That said, I think this is a thing with BitLocker? I remember coming across YubiKeys being able to do this via something called PIV (Personal Identity Verification). Found this guide now after giving it a quick search: https://gist.github.com/daemonhorn/03301a66da7d1f4de6cdc8c8b...
Not sure how sound of a design it is though, didn't dig into it much at all.
This looking so much like an intentional backdoor just makes me wonder even more about TrueCrypt's sudden recommendation in 2014 that everyone switch to BitLocker. This particular backdoor didn't exist then (it's only Win11 apparently) but this sure makes it seem more plausible that another one might have.
Though if TrueCrypt was killed to try and get people to switch to encryption that could be backdoored, then why allow its successor VeraCrypt to exist? It's open source and independently audited, so it really shouldn't be backdoored.
How is this even possible, backdoor or no? Isn't the whole point of this type of encryption that even a compromised machine can't decrypt without the passphrase? If this works it means that the key is stored unencrypted somewhere?
1) These systems are set up for automatic decryption. It's super obvious that if you can successfully attack windows between unlock and user login, you can get to the files. If this is such an attack, it's not a flaw with bitlocker itself.
2) Is it unreasonable to say "show it"?
3) Correct, we shouldn't jump to conclusions.
4) It's not known-insecure but it is known-enormous-attack-surface.
1) Except that the entire premise behind BitLocker TPM's security relies on the login screen as a hard security boundary, and thus any attack on the login screen is an attack on BitLocker. It is semantics to dispute this and certainly fits "downplaying."
2) I'm sure many organizations are thankful that the researcher has decided not to release that exploit chain at this time. I am hopeful that Microsoft will not be as dismissive and will resolve it before it is publicly released.
3) It distracts from the point. The point is that Microsoft's security record is so bad that many of the vulnerabilities appear deliberate and obvious enough to be backdoors.
4) Yes, this also fits the definition of downplaying.
For those who use password (not PIN) based pre-boot authentication with BitLocker... do we know if that setup is safe?
I can't imagine there would be a way to bypass that if a password is required, unless it was a situation where like, there was originally some secret secondary key made that needs no password... or the password was never tied to the key in the first place.
Here's the primary source: https://deadeclipse666.blogspot.com/2026/05/two-more-public-...
Other links:
https://github.com/Nightmare-Eclipse/YellowKey
https://github.com/Nightmare-Eclipse/GreenPlasma
bitlocker is generally useless unless the hardware is secure to begin with and while we have tons of 'boot guard' implementations which fuse the certificate into hardware meaning that only the OEM can create firmware that will boot there have been at least 2 instances of these certificates leaking exposing all hardware with that signature and other bypass methods (some boot guards are 'flash' guards were you can only flash signed firmware, but doesn't stop you from directly flashing the spi bios chip).
I had someone demo me preserving PCR values by patching SMM module in firmware without triggering any bitlocker lockout, this also means that you can externally write bios with the smm module as long as you have ~2 minutes to disassemble the laptop or desktop and flash firmware.
This hurts the most when you don't have PIN authentication which means you just need to steal the laptop to exfiltrate data, if you do then you have to have the user boot which then drops a payload exfiltrating data over network or just stealing the laptop again as you can write back decryption keys into non encrypted partition or corrupt some sectors at the end of the disk and write them there.
* modifying smm allows you to patch the boot process loading a malicious payload into hypervisor/kernel.
> unless the hardware is secure to begin
Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
we're not talking about the hdd/ssd here, those are not really encryption but data packing and compression algorithms, they added encryption because it's a single instruction for extra talking points.
you use veracrypt which doesn't have any hardware attestation (convenience) features, but it does still leave you vulnerable to the same surface PIN+TPM is vulnerable to. the real defense is making it so opening your laptop/desktop physically fuses something via latch and wipes the key off your system requiring re-entry.
of course, who wants to own a laptop/desktop that you can't open we have enough of that with our phones.
Do you have any citation about that on SSDs built after 2020?
Crikey, it seems that the big news - a backdoor is somewhat burried.
It also strikes me that these are several very high value (all but one complete) exploits.
Surely the value of these on the market would be astronomical and best suited to law enforcement agencies using unlock as a service businesses.
So I have to say I applaud the open disclosure
Though I am convinced this is intentional, i.e. a backdoor and not a bug, it should be noted that for goverment agencies there was already access anyway:
https://news.ycombinator.com/item?id=46735545
Access for those who used a Microsoft account and upload their encryption keys there. While I’m unhappy that most of the users end up using this (bad) mode, previously I was under the impression that there was a meaningful choice involved.
The BitLocker exploit seems simple and very dangerous. Companies and individuals have been relying on BitLocker to protect information if the device is lost. Despite promises, Microsoft doesn’t seem to be serious about security.
What will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?
Note that RedSun and Bluehammer were silently patched, with no response to the CVEs by Microsoft, and not accrediting the researcher's work.
That's what this is about. Microsoft doing bad security practices while trying to get away with it, leading to this outcome.
The researcher also claims to have another version ready which allows to also bypass TPM+PIN via a similar backdoor, which I'm inclined to believe.
Why do I believe that? 5 ring 0 zero days within 3 months are so statistically unlikely to be found, by the same person, in such a short time. Whoever this person is really knows their exploits, and must be in the league of Juan Sacco.
the only way to bypass PIN would be an actual backdoor in Bitlocker. no way around that. an actual backdoor in microsoft encryption was never documented, and there are Snowden documents showing FBI pressing Microsoft into introducing one and Microsoft refusing
so I call bullshit on the PIN bypass
6 replies →
How does a bug equate to "not serious about security"?
There's no way this is not a backdoor
Along with other facets of this, what are the odds a "bug" would also automatically erase evidence of itself from the bootable USB stick when it activates?
The blog author calls it that but given there’s no root cause yet it’s foolish to jump to conclusions.
[flagged]
3 replies →
https://infosec.exchange/@wdormann/116565129854382214
> Mitigation: Use Bitlocker with a PIN.
> (Note: The YellowKey author disagrees that PIN is a protection
That’s the most puzzling part to me. What’s the point of the PIN then? I was assuming it was mixed with the TPM secret somehow but if it can be bypassed then it shows it just an IF statement somewhere. Dang…
God I hate this stupid design of burying the decryption key in the TPM and hoping the software does not get fooled to reveal it.
Microsoft always sucks. Why don’t you ask for the password at boot time and derive the key from it. So much simpler and makes this kind of attacks impossible. Nobody is going to bypass LUKS or FileVault like this.
11 replies →
Remarkable. Does MS take a huge reputational hit for having a backdoor, or are they so essential to most places this won’t matter?
I’m assuming the EU speeds up the uncoupling cause of some of this.
I think anybody who has been paying attention has assumed for at least 20 years that all of Microsoft’s shit is backdoored anyway. I mean, the original Snowden revelations made that abundantly clear if it wasn’t before then.
Businesses use Microsoft because they figure if it’s backdoored it doesn’t matter and won’t affect them (because they aren’t terrorists or child pornographers or whatever, and they’d comply with a subpoena regardless of if Bitlocker is backdoored or not) and individuals who care about security and privacy put their shit on a Veracrypt drive somewhere else.
I guess that most people who use security features of Microsoft products only do so to tick compliance checkboxes and they really don't give a fuck about actual security.
Which makes me think, it's becoming more and more urgent to make an open source mobile OS happen.
It's not an actual backdoor. An attacker found a way to exploit Windows after booting it up in this recovery mode. The security of files on the device depends on it being impossible for Windows to be pwned by an attacker on any surface exposed before the user is unlocked.
This is why operating systems like GrapheneOS disable the USB port on the initial boot to limit the attack surface that an attacker has.
Having a specific file name trigger the decryption to happen automatically, while also removing said files after this is achieved, is an extremely unlikely bug. I think for most people evaluating this, the onus is now on anyone thinking this is not a backdoor to prove how a mistake in the code can trigger this very specific scenario.
This is like finding out that an OS accepts an SSH private key circulating online that the sysadmin for those OS boxes never authorized, and saying "wait, we don't know that this is a backdoor into that system, the attackers just found a bug".
1 reply →
This is 1000% a backdoor if you understand how the BitLocker process works.
1 reply →
As far as I can tell, there's no concrete evidence that it is actually an intentional "backdoor."
What would you require to feel confident it is a backdoor?
Nadella gives a press release, "Alright guys, you got us fair and square. Backdoor on Bootlocker. Various versions of it for years on behalf of the spooks."
You are unlikely to ever get a confirmation of wrong doing. That being said, for a first line security posture, there is no way external media should have anything to do with the encryption process. Even if the OS chose to read a USB drive, to also delete the magical files is ridiculously suspect.
It could always be plain old incompetence, but that is a damning level of technical ineptitude assigned to such critical infrastructure. This is not a project you assign to the intern, but paranoid security experts. Multiple levels of code review and red-teaming.
1 reply →
[flagged]
1 reply →
I don’t think anyone is using Windows for privacy, so I’d say nobody will care.
But almost every business is using Windows and depending on its security.
2 replies →
It's used at every bank, every government institution, even carriers and nuclear submarines.
Properly secure symmetric encryption needs a key with at least 128 bits of entropy. In the "device lost/stolen" scenario, that key must not be on the device. Key inside a TPM on the device itself is DRM, nothing more. There's better and worse DRM, I think the iPhone bootloader one is one of the better ones, but it's still just DRM.
You either need to enter a 128-bit entropy password on every boot (good luck with that) or you need to hold it on some external device, with some variant of USB / smartcard / NFC / Bluetooth to transmit it. NB. this is one of the cases where the usual "key for signing only, never leaves device, ephemeral DH and ZK protocols" like for SSH will not work on its own; you need the high-entropy key physically separate from the device.
The NSA realised this a while ago: https://en.wikipedia.org/wiki/KSD-64
Linux/LUKS etc. doesn't change any of this, by the way.
P.S. If Eclipse really has beef with Microsoft, he could always make an exploit that lets you set up a PC without making a Microsoft account.
So much this. Security information should simply never reside on-device in the first place.
That said, I think this is a thing with BitLocker? I remember coming across YubiKeys being able to do this via something called PIV (Personal Identity Verification). Found this guide now after giving it a quick search: https://gist.github.com/daemonhorn/03301a66da7d1f4de6cdc8c8b...
Not sure how sound of a design it is though, didn't dig into it much at all.
This looking so much like an intentional backdoor just makes me wonder even more about TrueCrypt's sudden recommendation in 2014 that everyone switch to BitLocker. This particular backdoor didn't exist then (it's only Win11 apparently) but this sure makes it seem more plausible that another one might have.
Though if TrueCrypt was killed to try and get people to switch to encryption that could be backdoored, then why allow its successor VeraCrypt to exist? It's open source and independently audited, so it really shouldn't be backdoored.
Funny you should say that... https://news.ycombinator.com/item?id=47690977
Earlier thread: https://news.ycombinator.com/item?id=48114997
How is this even possible, backdoor or no? Isn't the whole point of this type of encryption that even a compromised machine can't decrypt without the passphrase? If this works it means that the key is stored unencrypted somewhere?
Most setups only have the key stored in the TPM, so all you need to get it back is a signed/trusted bootloader.
Ideally you'd want that key to be further protected with a password or some other mechanism because it's not impossible to extract TPM keys.
Presumably the key is stored in the TPM
When I see a bug that walks like a backdoor and swims like a backdoor and quacks like a backdoor I call that bug a backdoor.
[dupe] https://news.ycombinator.com/item?id=48114997
.
What's with all the replies on these threads downplaying this? Why is it mainly brand new accounts? What's going on here?
I've seen every variant of:
1) "this is an authentication/privilege escalation bug, not a bitlocker exploit" (? what are you even trying to say)
2) "even though the attacker explicitly warns that this is capable of bypassing TPM+PIN, that isn't actually true or what he meant"
3) "we shouldn't jump to conclusions that this is a backdoor"
4) "we already knew BitLocker with just TPM isn't secure" (? except many organizations depend on it to be)
1) These systems are set up for automatic decryption. It's super obvious that if you can successfully attack windows between unlock and user login, you can get to the files. If this is such an attack, it's not a flaw with bitlocker itself.
2) Is it unreasonable to say "show it"?
3) Correct, we shouldn't jump to conclusions.
4) It's not known-insecure but it is known-enormous-attack-surface.
1) Except that the entire premise behind BitLocker TPM's security relies on the login screen as a hard security boundary, and thus any attack on the login screen is an attack on BitLocker. It is semantics to dispute this and certainly fits "downplaying."
2) I'm sure many organizations are thankful that the researcher has decided not to release that exploit chain at this time. I am hopeful that Microsoft will not be as dismissive and will resolve it before it is publicly released.
3) It distracts from the point. The point is that Microsoft's security record is so bad that many of the vulnerabilities appear deliberate and obvious enough to be backdoors.
4) Yes, this also fits the definition of downplaying.
4 replies →
Most submissions involving criticism of big tech gets those kind of replies. Par for the course here.
You just have to skip reading them because it seems there's no stopping those 100% genuine replies
So is bitlocker not using TPM vulnerable? Bitlocker at rest? It is not really clear.
What's with these two new accounts, `aiscoming` and `forestry`, being weirdly aggressive in their defense of bitlocker?
I get paid to defend AI and MSFT online. quite lucrative business. DM me if you are interested
For those who use password (not PIN) based pre-boot authentication with BitLocker... do we know if that setup is safe?
I can't imagine there would be a way to bypass that if a password is required, unless it was a situation where like, there was originally some secret secondary key made that needs no password... or the password was never tied to the key in the first place.
The exploit developer themselves say [1] TPM+PIN is vulnerable, though no public PoC.
[1]: https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
I’m skeptical of that claim. The key material presumably is inaccessible even to the OS without the passcode.
4 replies →