As long as Microsoft will continue to use dark patterns to convert local accounts to online accounts and automatically, without user consent, encrypt the storage drives preventing any computer use until the user goes to aka.ms and through the hoops, this is a good thing.
No one should have their data encrypted and kept from them without consent unless they do something. Microsoft does that now. They may not be requring a monetary ransom like others, but it is a ransom nevertheless.
I know this is controversial. Bitlocker helps protect one's property and information when used intentionally. And that being impacted is a shame.
Maybe I’m an outlier but I don’t want my drives encrypted at all. I rather have all my data be accessible if things go catastrophic, I.E. having to pull the drive out of a broken computer and put it in another computer to access the files. I just want it to be plug and play.
Seems this traces back almost a week, from Nightmare-Eclipse who is the researcher who found this:
Tuesday, 12 May 2026 - "Here are the links, yes, two vulnerabilities this time [YellowKey] [GreenPlasma] [...] Next patch tuesday will have a big surprise for you Microsoft"
Wednesday, 13 May 2026 - "I can't wait when I will be allowed to disclose the full story, I think people will find my crashout very reasonable and it definitely won't be a good look for Microsoft."
First post in March 2026 is "[...] someone violated our agreement and left me homeless with nothing. They knew this will happen and they still stabbed me in the back anyways, this is their decision not mine."
I'm not sure what to make of it, is this someone essentially "leaking" things from the inside? Sure sounds like it, and others are able to reproduce the results.
Whether this is a backdoor or not boils down to whatever your usual proclivities about "bug or backdoor" are; it's not like "if microsoft = 1 hack bitlocker" like the tech press seem to love to report.
This is a bug in the NTFS transaction log replay functionality in the Windows Recovery Environment WinRE, where it will read NTFS transaction logs from an external volume and apply them to the mounted filesystem. This allows the attacker to perform an authentication bypass against WinRE. With BitLocker without PIN or Password, _any_ authentication bypass becomes a disk encryption bypass, since the disk is unsealed by the bootloader (this architectural "flaw" is true for Linux with the same configuration, as well, like Ubuntu installed with their newish Hardware Disk Encryption checkbox in the installer).
In lieu of additional evidence, whether you think the NTFS transaction log issue is a planted backdoor or a simple enumeration bug depends on your conspiracy theory level, like most things in exploit development. To me, it seems like a plausible bug. The weaknesses in boot-time unseal are well known and obvious and this is just one of many, so I don't see it as an earth-shattering revelation, although it is a fun bug.
Title sounds conspiratorial, but it lines up well with the controversy around TrueCrypt's discontinuation which, I believe, specifically called out BitLocker as an alternative to use in future.
"Security professionals generally recommend avoiding reliance on any single encryption system and instead evaluating well-reviewed full-disk encryption alternatives such as VeraCrypt".
If they put a backdoor into FDE it would make more sense to advise people to stop using windows at all and using Linux instead. If they put a backdoor in FDE you can be sure there is not just one backdoor in the operating system itself. You shouldn't trust proprietary software at all. You shouldn't even trust open source if it isn't properly audited.
This doesn't surprise me at all. Microsoft is a Chinese company and Chinese companies have to work with the government on such matters. Oh sorry, I meant an US company, whatever..
This doesn't sound bitlocker specific, sounds more like a login bypass. If you rely on TPM without PIN then it gets decrypted automatically. This should be fine normally as attackers shouldn't be able to get past login screen. But this exploit shows a way allegedly to get a unrestricted shell in the recovery environment.
The researcher claims a way to bypass PIN too but hasn't revealed it.
Well I doubt anyone would be surprised with a backdoor in MS product, there have been many of them already, I frankly doubt anyone with "disk encryption" on Windows would think that it's NSA-proof (or script-kiddy clever, as shown in this article :))
> The vulnerability may also work without a USB drive if the FsTx files are copied to the Windows EFI partition and the encrypted disk is temporarily disconnected from the system. After placing the FsTx folder, an attacker would need to reboot a BitLocker-protected machine, enter the Windows Recovery Environment, and follow a specific sequence of inputs.
At the point where you're able to mount the EFI partition and effectively modifying the bootloader, it's game over anyway - just run `manage-bde -unlock`, you already have to be root to mount the EFI partition.
I just digged into the exploit a little bit more and what it does it targets BitLocker in TPM only mode. That means that there is no preboot authentication or anything. What happens is secure boot validates the boot chain and the TPM gives out the encryption keys by itself. When you have physical access, it doesn't really make a difference. If there is a stick you can boot from and drop into an emergency shell or if you have to buy a $5 microcontroller and solder it to certain pins on the main board to sniff the TPM keys. What Microsoft is doing here in general they are selling something that is not secure. They are selling it as as full disk encryption but it's not. Someone who can flash a flash drive with an exploit and drop to a shell and use it to browse and copy files. Can also just buy that microcontroller and watch your YouTube with you How to solder. So the "exploit" isn't The problem here the problem is the false sense of security that Microsoft is selling.
> What Microsoft is doing here in general they are selling something that is not secure. They are selling it as as full disk encryption but it's not.
But you can configure Linux LUKS in the exact same way.
This doesn't seem an attack on BitLocker so much as it is an attack on the secure boot chain.
The value of PIN-less unlock is if your threat model is limited to the disk being disposed of or removed from the machine or otherwise separated from the TPM.
Entering a PIN is inconvenient or impossible if more than one user regularly uses the device. Hence, control to validate access is transferred to a trusted OS component.
> Security professionals generally recommend avoiding reliance on any single encryption system and instead evaluating well-reviewed full-disk encryption alternatives such as VeraCrypt.
What does this even mean? Nobody is using multiple encryption schemes on top of each other, are they?
>In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it
>However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE
Interesting. I dont know about this environment - some kind of naive file handle contructing/passing? But then, why require a key press during winre reboot?
I wonder how patachable this is. The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc?
The published exploit doesn’t affect Bitlocker with a PIN, without which Bitlocker isn’t secure anyway. The original author claims they have an exploit that also works with a PIN, but hasn’t provided any proof of that.
And there is a level above PIN with Bitlocker too, you can have a USB stick with a key on it which you use only during boot. I would imagine that is secure from this attack as the data isn't even stored on the device (I hope).
The real problem with a Bitlocker backdoor or weakness is that when a laptop gets stolen or lost, in most regulated organizations, the criteria for legally declaring and disclosing a breach pivots on whether it was protected by disk encryption.
If it's a backdoor, that's a serious fraud against their customers.
Seems bullshit, apparently it only works with TPM-only mode, which is obviously insecure (it relies on neither the OS nor the hardware being exploitable, on a random Windows PC...), and not worth building a backdoor for.
The way one would backdoor something like Bitlocker is to encrypt the disk encryption key with a (post-quantum) public key for which only the backdoor owner has the private key for, and then put it on a place on disk that is unused by the filesystem.
You should always assume that US/european corporate protections are backdoored, now MS, a couple days ago we knew about whatsapp, and I would also include all corporate “secure or encrypted” promises, so I would warn against signal, proton, and the likes. This is the work of NSA, providing a “secure” platforms and push it everywhere to get adopted, providing false sense of security, while depreciating the none bugged ones, few weeks ago verascript developer -Mounir Idrassi- complained about having their account blocked, same with wireguard facing similar issues, and if you find it hard to believe, GPG author -Zimmerman- was harassed by the gov because he wrote the encryption and encryption was considered munition, so he was exporting munition!
Lots and lots of smattering around here. If anything, this is a secure boot flaw (and partially TPM), but that is a separate conversation. Also, it's been known for years that TPM based encryption should always be protected with a PIN for truly sensitive data:
https://learn.microsoft.com/en-us/windows/security/operating...
The author claims to be able to bypass TPM + PIN protection, but I seriously doubt it because that would require breaking or exploiting the TPM itself. Perhaps the author was referring to existing fTPM flaws but even then, brute-forcing the PIN would still be required because on BitLocker, the wrapped VMEK depends on the PIN, which brings me to the "backdoor" topic.
As I have already mentioned, exploits have been found in AMD fTPMs in the past (https://arxiv.org/abs/2304.14717). This flaw is particularly severe on Linux/cryptenroll because the TPM returns the actual FVEK, unlike BitLocker, where the VMEK itself depends on the PIN. This cryptenroll flaw has been known for years and remains unfixed on cryptenroll (https://github.com/systemd/systemd/pull/27502). Yet, I see no one yelling and crying "backdoor", or accusing Lennart of being compromised. Cryptography, especially when combined with hardware security, is inherently not easy — and people make mistakes.
This is why I have trust issues with anything Microsoft. They keep burning bridges... And well, lots of Corporations keep trusting them. I guess they deserve each other.
43 comments
[ 2.9 ms ] story [ 71.7 ms ] threadNo one should have their data encrypted and kept from them without consent unless they do something. Microsoft does that now. They may not be requring a monetary ransom like others, but it is a ransom nevertheless.
I know this is controversial. Bitlocker helps protect one's property and information when used intentionally. And that being impacted is a shame.
Securing Microsoft products is busy work while waiting to have it undercut by the next wave of MS’s insane tech debt and greed. And now backdoors!
Tuesday, 12 May 2026 - "Here are the links, yes, two vulnerabilities this time [YellowKey] [GreenPlasma] [...] Next patch tuesday will have a big surprise for you Microsoft"
Wednesday, 13 May 2026 - "I can't wait when I will be allowed to disclose the full story, I think people will find my crashout very reasonable and it definitely won't be a good look for Microsoft."
Author's blog: https://deadeclipse666.blogspot.com/
First post in March 2026 is "[...] someone violated our agreement and left me homeless with nothing. They knew this will happen and they still stabbed me in the back anyways, this is their decision not mine."
I'm not sure what to make of it, is this someone essentially "leaking" things from the inside? Sure sounds like it, and others are able to reproduce the results.
Whether this is a backdoor or not boils down to whatever your usual proclivities about "bug or backdoor" are; it's not like "if microsoft = 1 hack bitlocker" like the tech press seem to love to report.
This is a bug in the NTFS transaction log replay functionality in the Windows Recovery Environment WinRE, where it will read NTFS transaction logs from an external volume and apply them to the mounted filesystem. This allows the attacker to perform an authentication bypass against WinRE. With BitLocker without PIN or Password, _any_ authentication bypass becomes a disk encryption bypass, since the disk is unsealed by the bootloader (this architectural "flaw" is true for Linux with the same configuration, as well, like Ubuntu installed with their newish Hardware Disk Encryption checkbox in the installer).
In lieu of additional evidence, whether you think the NTFS transaction log issue is a planted backdoor or a simple enumeration bug depends on your conspiracy theory level, like most things in exploit development. To me, it seems like a plausible bug. The weaknesses in boot-time unseal are well known and obvious and this is just one of many, so I don't see it as an earth-shattering revelation, although it is a fun bug.
If they put a backdoor into FDE it would make more sense to advise people to stop using windows at all and using Linux instead. If they put a backdoor in FDE you can be sure there is not just one backdoor in the operating system itself. You shouldn't trust proprietary software at all. You shouldn't even trust open source if it isn't properly audited.
The researcher claims a way to bypass PIN too but hasn't revealed it.
source: trust me bro
At the point where you're able to mount the EFI partition and effectively modifying the bootloader, it's game over anyway - just run `manage-bde -unlock`, you already have to be root to mount the EFI partition.
But you can configure Linux LUKS in the exact same way.
This doesn't seem an attack on BitLocker so much as it is an attack on the secure boot chain.
The value of PIN-less unlock is if your threat model is limited to the disk being disposed of or removed from the machine or otherwise separated from the TPM.
Entering a PIN is inconvenient or impossible if more than one user regularly uses the device. Hence, control to validate access is transferred to a trusted OS component.
What does this even mean? Nobody is using multiple encryption schemes on top of each other, are they?
>In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it
>However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE
Interesting. I dont know about this environment - some kind of naive file handle contructing/passing? But then, why require a key press during winre reboot?
I wonder how patachable this is. The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc?
Seems like lots more to follow
The published exploit doesn’t affect Bitlocker with a PIN, without which Bitlocker isn’t secure anyway. The original author claims they have an exploit that also works with a PIN, but hasn’t provided any proof of that.
I have never seen a company where they require the pin for bitlocker.
If it's a backdoor, that's a serious fraud against their customers.
The way one would backdoor something like Bitlocker is to encrypt the disk encryption key with a (post-quantum) public key for which only the backdoor owner has the private key for, and then put it on a place on disk that is unused by the filesystem.
The author claims to be able to bypass TPM + PIN protection, but I seriously doubt it because that would require breaking or exploiting the TPM itself. Perhaps the author was referring to existing fTPM flaws but even then, brute-forcing the PIN would still be required because on BitLocker, the wrapped VMEK depends on the PIN, which brings me to the "backdoor" topic. As I have already mentioned, exploits have been found in AMD fTPMs in the past (https://arxiv.org/abs/2304.14717). This flaw is particularly severe on Linux/cryptenroll because the TPM returns the actual FVEK, unlike BitLocker, where the VMEK itself depends on the PIN. This cryptenroll flaw has been known for years and remains unfixed on cryptenroll (https://github.com/systemd/systemd/pull/27502). Yet, I see no one yelling and crying "backdoor", or accusing Lennart of being compromised. Cryptography, especially when combined with hardware security, is inherently not easy — and people make mistakes.