They’re at it again..

Hinzugefügt: 2026-05-28

[00:00:00]Nightmare Eclipse is at it again.

[00:00:02]Nightmare Eclipse. You don't know who Nightmare Eclipse is? Okay, Nightmare Eclipse is, first of all, a security researcher with an anime profile picture, which means things are about to get really serious. Now, anime researchers like this, like Nightmare Eclipse, uh, tend to be really good at their jobs. And in doing this, uh, Nightmare Eclipse found not one, not two, but I think at this time six zero days in Microsoft products that they disclosed publicly. they just kind of dropped him on the internet and as a result uh recently got kicked off of GitHub. Now, why would Nightmare Eclipse be mad at Microsoft? Well, I know I have had grievances Microsoft. Everyone has had one or two grievances Microsoft, but Nightmare Eclipse in particular had a grievance with the uh Microsoft Security Response Center. Okay. In particular, Microsoft Security Response Center bug bounty program. Now, if you weren't aware, if you are just casually sitting on a Microsoft Hyperb Hypervisor Zero Day, for example, uh you can submit it to MSRC and potentially get paid up to 250 G's. And if you don't want that money, send it to your boy and I will turn it in for you. Okay? Uh now, so this is a common thing. A lot of programs are are ran by companies like this, like Microsoft, Apple, Google, all of their own various bug bounty programs. But in classic bug bounty fashion, sometimes the security researcher and the company don't agree.

[00:01:19]For example, on Hacker News from about two years ago, um Microsoft security criteria have long asserted that administrator to kernel being an admin on the computer and being able to get system is not a security boundary. Okay, this is something you may disagree with as a security researcher, but Microsoft will not pay you for an admin to Colonel Prives. So, disagreements like this have pissed off researchers for a long time.

[00:01:42]And Nightmare Eclipse being one of the pissed-off researchers. Uh, April of this year, I was not bluffing Microsoft and I'm doing it again. They link a GitHub repo that again has now been removed and moved to GitLab. Link down in the description below. Uh, unlike previous times, I'm not explaining how this works. Y'all geniuses can figure it out. Oh, and also huge thanks to MSRC leadership for making this possible.

[00:02:02]While Nightmare Eclipse did get their start on GitHub, Microsoft has actually kicked off Nightmare Eclipse off of GitHub and so they've moved all their stuff over to GitLab. Again, I'll put the link to their repo in the description below. Hey guys, it's um Lowle from the future. So, in the time this video was getting edited, uh Nightmare Eclipse has been also banned from GitLab. So, uh when I figure out where their stuff is located, I'll link it in the description below. But for right now, I'm pretty sure it's just gone. So, uh more to follow. Okay, goodbye. Microsoft didn't like this person uh putting zero days for their products on GitHub and kick them off.

[00:02:37]They had enough uptime to actually kick them off, which is pretty crazy. Um, but that being said, you know, dropping zero days on GitLab or GitHub, maybe not the greatest thing, but you know, here they are. Now, the topic of this video is Yellow Key. Yellow key is kind of a hot topic of discussion from about a week ago. That is supposedly an exploit that takes advantage of a backdoor in Bit Locker. Now, whether or not this exploit takes advantage of an actual backdoor, a back door being an intentionally placed vulnerability or a key or, you know, password that allows you to do something nefarious, right? Whether or not that's intentional, I'll let you decide. But I want to go over how this works and why it's actually a pretty magical exploit that bypasses a really important security feature in Microsoft products.

[00:03:16]And before we learn more about Nightmare Eclipse's shenanigans, let's learn more about today's sponsor. Guys, with all this talk about vulnerabilities and supply chain attacks, it's really important to protect ourselves with the tools available for not if our network gets compromised, but for when. And that's why today's video is sponsored by Flare. Flare is a threat exposure management platform that allows you to see if your company's data has been compromised and is being sold or talked about on the dark web. Through a variety of sources, Flare collects events from stealer logs to Telegram channels where hackers are talking about the data that they've compromised, and they can use that collection to alert you if your data has been stolen. All you have to do is enter an identifier about yourself into the Flare system, like an email address or a domain name, not a password, not a cookie, and then if Flare sees that domain name or that email address pop up in its data set, it'll send you an email immediately. The average organization takes around 36 hours to even recognize that a credential has been compromised. But with Flare, you can reduce that time from 36 hours to a couple minutes. And on top of credentials and sensitive data, Flare also has their threat intelligence flow. If you want to know generally what hackers have been up to, you can use Flair's threat intelligence flow to see if the business or the niche that you're in is being targeted by hackers. Like for example, here we have a report on critical infrastructure and defense contractors being targeted by Iranian hackers. Very interesting, guys.

[00:04:27]The best way to help the channel out is to go interact with the sponsor. Go try Flare out for free at this URL and see if Flare is the right fit for your organization to keep your organization's data secure. So, Bit Locker is this, you know, technology that basically makes your hard drive encrypted at rest. When you go to access files through the file system, it decrypts them into RAM on the fly. What this allows you to do is basically rest assured in the fact that your files are encrypted on your disc.

[00:04:50]So if somebody steals your laptop, if someone steals your hard drive, an evil maid walks into your house and your computer is off, they can't just look into your files, they can't steal your files. They can keep your identity safe.

[00:05:00]It's important to note too that the key to do the decryption and encryption of Bit Locker is either a password that you maintain yourself or it is a key derived from a trusted platform module TPM which is basically just a chip that can cryptographically attest the state of a CPU. Right? So the way that this works is you have a disk that is encrypted via Bit Locker and the key associated with that Bit Locker is bound sealed against this TPM. So, if I take this hard drive out and I put it into a different computer, you can't decrypt it because you don't have the key that lives inside of this TPM. This is another feature of Bit Locker that's supposed to keep it secure until now. So, enter yellow key.

[00:05:36]Again, yellow key is the exploit that Nightmare Eclipse is dropping. It takes advantage of a vulnerability in the uh Windows recovery environment. And basically, all you have to do is make a USB stick, create a system volume information folder with FSTX inside of it. We'll go into what that means here in a minute. and then put their FSTX folder onto the USB stick. You have to boot the computer into the Windows recovery environment with the USB stick in your computer and bada bing, bada boom, you will get dropped into a shell and the shell will have access to the encrypted Bit Locker partition. Sounds bad. Is bad. However, there are a couple things that have to be true about your environment for this to work. And it kind of goes into my conversation about is this a back door? Is this a vulnerability? I'm not really sure. We report you decide. Okay. So what yellow key does is takes advantage of this thing called a transactional NTFS. NTFS being the file system that Windows uses.

[00:06:26]It's like one of the many options but like kind of like the recommended option for for Windows file systems. Okay. Uh it's transactional in the sense that the FSTX from the yellow key repository is literally just a file system transactions. What's going on here is there is a log that occurs inside of this FSTX folder that in the Windows recovery environment, what they're trying to do is give you the opportunity to be able to undo changes to your file system that may have irreparably corrupted your your install, right? So, let's say, for example, you're halfway through installing a program and your NTFS and bada bing bada boom, you know, something exploded, something something broke. Uh, and so the program is half installed. Maybe you need to recover this, right? And so the transactional NTFS allows you to undo some of these transactions in the recovery environment. Now the vulnerability here is that the contents of one volume can impact the contents of another volume.

[00:07:19]So what this file system transaction does is it actually shows a transaction for the deletion of a particular file.

[00:07:27]In particular, it's a transaction to delete the winpell.ini file. So when you plug in this malicious USB stick into your computer and you go through the recovery environment, the recovery environment will temporarily replay all of the uh NTFS transactions that are on that USB stick. Right? So what you're doing is deleting this INI file which tells the recovery environment which application to load when the system boots. And because you've replayed a transaction that deletes this INI file, there is no record of what program to run. And so by default, it drops you into the command shell. The question is like wait how does that decrypt the file system? Well, because we are now in an active Windows environment, we're in an active partition of Windows that has already gone through the boot environment, the bootloadader, right? And so because the TPM has already given the key up to the OS, the OS is now able to use that key to decrypt your Bit Locker partition on demand. Now, this is kind of the question that I had. You may be having this now as you're watching. Is this a vulnerability in Bit Locker? Is this a vulnerability in the recovery image?

[00:08:29]Like where is the actual bug? In my opinion, this isn't really a bug with Bit Locker, right? It is a Bit Locker bypass, but we're just using the TPM as ex as designed, right? Because we've gone through the bootloadader and we've attested the state of the boot. We know we're doing secure boot or we're booting into assigned bootloader. The TPM gives up the key to the environment and the environment can use that key to decrypt the contents as it needs. This is not a vulnerability with Bit Locker. What this is is a vulnerability in the recovery environment where because we're now doing the auto FSTX, the file system transactions binary. This is running the transactions that are on that malicious USB stick that is removing this INI file and dropping us directly to a command shell. Without doing this, we wouldn't be given a command shell. We' be given the regular recovery environment that we're used to seeing. There are some questions online about why is Windows 11 vulnerable to this but not Windows 10. I think the reason for this is in Windows 10's recovery environment, they didn't run the auto FSTX uh binary that automatically runs through those transactions, but they enabled that back in Windows 11. So now when your CPU boots up, it runs those malicious transactions on the USB stick, which causes this file to get removed, but that did not occur in Windows 10. So for this particular exploit, there are two ways to mitigate it. The first way is to go into your registry editor here, the you know computer, HKLM, Win Rehive. I'm not going to read the whole thing. Uh but there's a boot exec flag that has the name of the file system transactions binary that runs that automatically in the uh recovery environment. You remove this key, it doesn't run the FSTX and this will not trigger the vulnerability as described. Uh and also like I said before, this isn't necessarily a vulnerability in like the cryptographic implementation of TPM or Bit Locker because in this scenario, if you had a TPM PIN, right? So, a physical PIN that goes into the TPM before you get the file system decrypted or the file system key. If you had a TPM PIN, you could not do this because you would have to know the PIN first before you can even boot into the recovery environment, right?

[00:10:25]That's kind of why this has been a weird conversation about Bit Locker for a long time. Like the Bit Locker key is only given up by the TPM if the TPM allows it. When would the TPM allow it? if it measures that you're in the correct environment. It measures the bootloadader, it measures secure boot, and it measures that you're on the same CPU as before, which because it's the same TPM. And then also, additionally, but optionally, if you also give it something, you know, a pin, a password, etc. If you are in a scenario where you're using TPM without a PIN, an easy way to mitigate this exploit in particular is just enable TPM PIN.

[00:10:57]Obviously in enterprise deployments, right, that makes, you know, uh, Bit Locker a little more complicated because if your users forget their PIN, you have to go through the whole recovery process, which was just a little more complicated. But that being said, it's an easy way to mitigate this. However, I want to highlight in a blog post from 13 days ago, uh, Nightmare Eclipse did say, second thing is no, TPM plus 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 PAC. So, what this implies to me is that there is a separate vulnerability that gives you access to the TPM kek or the TPM uh the file system encryption key that does not require access to the PIN. Now, how this could work, I don't really understand because again, for the TPM to release a sealed key, if it's in a PIN mode, you have to give it the PIN. Maybe there's like a a a backup or having to do with the recovery key how it's derived the way you could break this. So, this scenario is kind of scary, but for the current knowledge on yellow key, enabling TPM pin mode is a way to bypass this or fix this. Is this a back door? I don't know. Like, it's obviously a bug.

[00:12:01]It's obviously a way for you to get around Bit Locker in the event that you have a computer you want to get into that does use Bit Locker without TPM pin mode. And that being said, I don't know if this feature feels like a backdoor because all it's doing, and it's been around since Windows Vista, by the way, is replaying uh transactions in NTFS that allows you to uh remove a file from a different environment or a different volume, right? That is not good. That is not correct, but that feels more like a bug than a back door to me. I don't know. You make up your own decision and we'll see where it goes. That being said, if they do drop a pock on the TPM plus pin mode, that feels a little more cryptographically bypassy that I'm I'm curious to see how that works. But anyway, guys, that's it for now. Thanks for watching. I appreciate it. Go check out the sponsor, hit that sub button, and then check out this video, which I think you will also enjoy probably about as much as this one. We'll see you there.