In this episode, we explore recent vulnerabilities, the YellowKey BitLocker bypass, supply chain security, CVE data analysis, and the implications of hardware breaches like the one at Foxconn. We also delve into AI’s role in vulnerability research and the evolving landscape of cybersecurity threats. Topics https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth https://github.com/Nightmare-Eclipse/YellowKey https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack https://x.com/AlvieriD/status/2053835732658143416 Transcript Paul Asadoorian (01:45.686): Welcome to Below the Surface. This is episode number 74. We’re recording on May 14th, 2026. I’m Paul Isidorean, joined by Mr. Chase Snyder. Chase, welcome. Chase Snyder (01:54.072): Hey Paul, hey Vlad, long time no see. Paul Asadoorian (01:59.277): Vlad Babkin’s here with us. We just come in fresh off of a webinar. Maybe we’ll recap that in just a moment. I want to remind everyone that below the surface listeners can learn more about Eclipseum by visiting eclipseum.com forward slash go. You can find the ultimate guide to supply chain security, an on demand webinar I presented called Unraveling Digital Supply Chain Threats and Risk, a paper on the relationship between ransomware and the supply chain, and a customer case study with Digital Ocean. If you’re interested in seeing our product in action, you can sign up for a demo. You can do all that at Eclipseum.com forward slash go. Great webinar. just wrapped up on using AI to find vulnerabilities. That was great. It was a lot of like not our research that was published this week that I observed where various people, I didn’t even talk about Neil’s provost work on I can’t remember the name of his tool now I’m blanking on it but he has a harness that’s publicly available on GitHub for finding vulnerabilities we didn’t talk about about that something to check out I can actually put a link to that in our show notes I talked about it briefly on another podcast I did this week but a lot of I think examples of how researchers are using AI to find vulnerabilities. And spoiler alert, you don’t need mythos to find vulnerabilities. That’s kind of what I gleaned this week by talking with you guys and reading a lot of those articles. Vlad Babkin (03:33.939): Mm-mm. Yup. Paul Asadoorian (03:42.644): And speaking of vulnerabilities… I thought this was new. Do we talk about this? But this is still a problem. NIST has updated the operations to address the record CVE growth. And I thought there was new conversations about this, but it’s still a lingering problem that we’re dealing with. Chase Snyder (04:04.053): Yeah, I think, I mean the… Vlad Babkin (04:07.154): Yep. Chase Snyder (04:08.654): The number of CVEs that got issued in 2025 massively eclipsed the number from previous years. was like 40, between 40 and 50,000. And… They said it’s been like a month ago since they made the announcement about the new prioritization criteria. But NIST used they used to basically try to enrich all CVEs. Did they try to do them all? Was the previous policy was they do them all? And now it’s just been a massive trim down of they’re going to do known exploited ones. So if something’s on the CISA kev, they’ll enrich that within one business day of receipt, they say. Paul Asadoorian (04:47.276): Yes. Chase Snyder (04:56.384): and then CVEs for software used within the federal government and CVEs used for critical software. So that’s a pretty big, that’s a pretty tight filter. That’s gonna be way, way fewer CVEs that get enriched. Paul Asadoorian (05:11.533): Yeah. But now that you put it that way though, I think that’s actually smart because there’s CVEs issued for all kinds of things that you would just kind of spin your wheels enriching that stuff. There’s like so much esoteric software out there that, like WordPress plugins. Do we need to spend a lot of time enriching WordPress plugins? Chase Snyder (05:19.831): Mm-hmm. Chase Snyder (05:37.25): Yeah. Paul Asadoorian (05:41.08): I see also ones that have exploits is what I look at because I have a tool. Hopefully someday I’ll be able to release the tool, but I have a tool for analyzing vulnerabilities. And so I wanted to take some time to talk about the challenges and get some of you guys feedback on it. And so one thing when I run queries against the CVE databases, because so I wrote this tool because the other tools sucked. And or we’re not being maintained, right? So if I found one that I liked for analyzing CVE data They would stop maintaining it and then it would break because the back-end, you know APIs or they were scraping websites in some cases So I was like YOLO. I’m writing my own tool because I need to analyze CVE data so Chase Snyder (06:27.448): What’s the root data source for that? Like when you say they were scraping websites, where were the websites getting the data? Does NVD publish like a database or a CSV file or something? Like how does, what is the original data source, the fountain of CVE data? Paul Asadoorian (06:34.519): I wish I could… Yeah. Paul Asadoorian (06:46.271): Yeah. So one of the tools I was using was scraping like OpenCVE.io and they’re getting it from, my two, my primary data source. So what I did when I wrote the tool, and this has been several iterations that I keep this tool actually maintained. I Vibe coded it a while ago and I keep it maintained. Right now I’m vibing it with Opus 47. Chase Snyder (06:49.262): But where are they getting it from? Paul Asadoorian (07:12.759): adding some functionality for some stuff that you, the listeners and the public will learn about soon. The primary database is I have local NVD database. So I have code that goes out to NVD, pulls down, I think it’s in JSON format, pulls down the entire NVD database and stores it in a local SQLite database. I also do that for the actual CVE database. So it’s a separate data source. MITRE maintains the CVE database. I do it for that one as well. And so that’s the database that I’m querying. to kind of speak to, so I see a lot of fluff, because I can search it for ones that have exploits. And I have actually multiple sources that I pull exploits from, such as I not just look at the Sysachev. I also saw all these are SQLite databases that I build and maintain locally. I have a database of all Metasploit exploits. I have a couple of GitHub repositories that collect exploits that are in my sources. They also parse. And this is where the lack of enrichment will come in, because not all CVE records are created equal. I will parse this CVE record and look for evidence of an exploit available. If … Whoever is creating and or enriching the CVE record does it right, and they put references and resources section, and that section can have tags, there’s a tag for exploit. And so I’ll parse that as well as an additional source. And so you get into all kinds of problematic things now. If NVD is not enriching the data, that means they’re not assigning a CVSS score to all the records. I don’t think they were assigning it for all the records before, but now they’re assigning it to less records. And typically what I observe, different people have different philosophies on this, but when I was writing the tool, I’m like, there’s more than one CVSS score for like ACVE can have many CVSS scores. And it can have… Paul Asadoorian (09:34.648): So it’s even more complicated than that. It can have more of different version. So someone may score it in CVSS version 4.0, someone may score it in CVSS 3.1, and then multiple ADPs, authorized data providers, can provide multiple scores. So typically what I’m observing happening, and I’m looking mostly at enterprise edge vendors data that exists in the CVE database today, is that the CNA, that’s, I think I was looking at Cisco, Fortinet, and Avanti as a test, they all create CVE records differently because they’re a CNA. They can create the record themselves, but it’s different. Cisco, for example, doesn’t put the CPE information when they create a CVE record. Fortinet, however, bravo, props Fortinet, puts the CPE record. I feel like I had to find a way to say something nice about Fortinet on the show because we’ve talked about a lot of the vulnerabilities that they had. So here I am giving Fortinet praise on the show because they’re filling out the CPE record, which is extremely helpful for me when I’m parsing the data and I want to go for the past 30 days, show me all the Fortinet CPEs and tell me which product they’re associated with because I care more about some than others. Chase Snyder (10:42.676): Mark the day. Vlad Babkin (10:48.039): Yep. By the way. I will raise a hand and cry out, guys, fill out CPA data. Like right now it’s not usable. And even if you fill it out, in many cases, vendors fill it out in such a way that it’s still not usable. as a vendor, if you’re filling out CPA data, make sure it’s standard format. And the same model is named the same exact way across your CPA and the cross-over that actual device returns the information about its model. Because otherwise, your CPA data is de facto useless. Paul Asadoorian (11:10.537): Yes, agreed. Paul Asadoorian (11:28.055): Yep. Now, there are, yes, for sure. Yeah, parsing this data is not easy at all because of these problems that we’ve already surfaced, right? And so back to CVSS, let’s just take 3.1 as an example. Typically what happens is the CNA for Netsysko Avanti, and that was just a sample data set I was working with, will provide a 3.1 score and… Vlad Babkin (11:29.253): And there are a lot of errors in it. Paul Asadoorian (11:56.854): when NVD enriches it, they will also provide a 3.1 CVSS score. Typically, what you’ll see in that data is NVD scores it higher than the CNA. And I think that’s just biased. I think that the vendors don’t want as critical of a score to protect their brand reputation. Like there’s a lot of motivations that would go behind like, this isn’t a big of a deal. but when a third party independent organization scores it, it tends to be higher. Now, this is somewhat controversial internally here at Eclipseum and I think with everyone in the community too. So what I do is regardless of who scored it, regardless of which version, I just take the highest score. And so I base a lot of my analytics on whatever the highest score was. I don’t know. That’s my strategy. I mean, you could say maybe there’s some flaws in that strategy, but I’m like, if someone spent the time to score this vulnerability and thought about it and plugged in all the fields, and they feel it’s more severe than someone else, I’m like, I’m erring on the side of caution. I’m just gonna take the high score. Chase Snyder (13:09.646): Yeah, you’re not alone in struggling to parse that data either. We talked a while back about the new OWASP top 10. You know, they did a reissue that the first ones and they update that thing like every four years maybe. So I think the last one was in 2021. And since then, CVSS version four scoring has. Not not really taken off, but is more in usage. Vlad Babkin (13:13.042): Yeah. Chase Snyder (13:38.178): than it was then, I’m not even sure when it came out, whether it was used at all then. it’s so like CVSS v4 is so different than CVSS v3. And specifically in that it no longer provides exploit or impact scores that are like consistent and compatible with CVSS v2 or v3. And so they couldn’t incorporate CVSS four risk scores into they do a lot of math for the OWASP top 10, you know, it’s a very rigorously analytical process to like try to discern what to include on that list. And they basically were just like. CVSS V4 is too complicated and too big of a difference from the prior ones for us to be able to like rigorously incorporate it into their scoring. And so they just disclose that upfront, like we’re sticking with V3 for now. And I think out of the like 175,000 CVEs that they mapped to CWEs for it, only 6,000 of them had CVSSV4 scores. So it’s like. Not that not that many, but I don’t know. It kind of reminds me of like IPV four versus IPV six. It’s like, oh, there’s this new standard. Maybe in 25 years, we’ll fully move over it to to it just in time for it to be obsolete. Paul Asadoorian (15:00.703): Yeah, yeah, it does. Paul Asadoorian (15:08.203): Yeah, it’s yeah, I don’t remember all the differences between 3-1 and 4-0, but you know, there are differences and a lot of people don’t like 4-0 because it it asks questions like my recollection when we’ve debated it is it asked questions that are somewhat ambiguous that the result and just different scores and I’m not sure 3-1 is kind of I think more cuts to the chase is my general assessment. So But back to NVD in the article now, so if they’re not enriching it, who else is enriching it? CISA has the VOL enrichment project, which again is one of my sources in the tool that I’m maintaining and provides great, I think, enrichment data that I use. So CISA will also provide an exploitation indicator. And a lot of sources don’t take into account all of the different ways in which an exploit could exist for a given vulnerability. Because maybe it’s not on the kev, but CISA says, no, there’s an exploit for it. And maybe I missed it in my other data sources. So by having all of the data sources looking for exploits, I can really key in on, there’s an exploit that exists for this particular vulnerability. Now, could it be a proof of concept? My tool also kind of arrows on the side of caution. If there’s a GitHub repo that has a test tool, or a description of the vulnerability that gives you all the information you need to create an exploit. I call that an exploit. I need to refine that a little bit, I think, but it’s still different from something that has no public information about exploitation or an exploit for a given vulnerability. But SIS’s vulnerability enrichment is really good. They also indicate whether the vulnerability exploitation is automatable. and they also give a technical impact status on it as well. And so I pull all that, I mean, that’s all good information. think if you’re trying to make decisions about how to prioritize vulnerabilities, well, one, as we’ve talked about on show in the past, it’s kind of a losing battle. You know, if trying to play whack-a-mole with vulnerabilities today, you’re probably already owned, right? Because of a lot of reasons we’ve talked about. Paul Asadoorian (17:33.942): But having this extra enrichment information above and beyond what NVD is providing can be good, but also comes with caveats, right? So we may now have to rely on the CNA score for a given vulnerability. And oftentimes that CNA is the vendor who creates that software product. So there’s inherent incentives there that could effectively lower that score. So yeah. That’s my take on it. spent too much time. CWE is another thing too. The CWE descriptions are way too long. Even the title of them are long and there’s way too many of them. And I’m now parsing the CWE data to kind of come down to like an exploit vector. Like is it command injection? Is it a buffer overflow? Is it an authentication bypass? Like just a generic class. But when you look at CWE, Common Weakness and Numeration, there’s probably six or seven or more of them, just guessing. Let’s just say there’s six or seven that deal with authentication bypass. I’m kind of less concerned at a glance the type of authentication bypass it is. What I care about is, is it an authentication bypass, or is it a command injection, or is it a buffer overflow? Those are the kind of things I need for decision points. And again, later you can go dig into the data all you want. But when you’re querying and you just want a summary, I like that higher level stuff. So I actually just built into the tool today the ability to assign CWEs and have it kind of shorten. It uses some method to shorten it so it’s not as long of a title. It’s just authentication bypass. It’s pretty cool. Chase Snyder (19:25.942): Nice. We keep that character countdown. Yeah. We were talking, I mean, this is only going to get worse, not better, right? Because we were talking about how the proliferation of AI, vuln research and discovery of CVEs. Like the number of CVEs that the number of people doing vuln research, the number of people disclosing new CVEs, the number of new CVEs that have already been disclosed like Paul Asadoorian (19:32.246): Yes. Chase Snyder (19:55.286): I think that NVD drastically limiting their number of CVs they’re going to enrich is just the first domino. like, there’s going to be a whole sweeping set of changes that has to happen throughout all of threat research and like cybersecurity land to deal with the just totally undigestible amount of vulnerability research that’s happening. Paul Asadoorian (20:08.694): Right. Paul Asadoorian (20:28.759): Yeah, certainly, certainly interesting. I wish that. we could one, be more consistent on how CVE records are created. I kind of feel like more fields should be required, like CPE for example, to be filled out in a CVE record. And I wish we had perhaps some additional fields because right now I’m trying to figure out, like if I query the database, for a subset of CVEs and I want specific information. So for example, give me all critical vulnerabilities from this list of network edge appliance vendors that have exploits available and give me that list. And then I’m like, now tell me, is that an appliance? Is that software? Or is that a SaaS solution that lives in the cloud? So you can use Cisco as an example, because those are basically three different groups or three different problems in my enterprise. If I’m using Cisco products in any capacity, I might have some, might have some of them or more than one or whatever. But I want to know critical Cisco vulnerabilities. Well, if it’s a network appliance or a switch or a router, that I know goes to one team, right? If it’s software, That might be a different team that manages that software. Like if it’s, you know, whatever, they’ve got a million different software products, right? Is it a VPN client, right? Then it needs to go to like a different IT team because we need to update 100,000 workstations because their VPN client has a vulnerability. That’s a different team, different process from you need to go update these 10,000 switches because they have a critical vulnerability. The other one I saw this week, Paul Asadoorian (22:32.629): was Cisco related came up in my search and it was a fix for Cisco WebEx, but that’s only a SaaS product. So they actually fixed the vulnerability in their SaaS product. That means I don’t have to do anything. Right? And so I need to know that. So I think there should be a better indicator of what software product it is. One, CPE data, right? And like two, like what is it? Is it a cloud service? Is it a software? Is it an operating system? Is it an appliance? Is it an IoT device? There should be. Vlad Babkin (22:57.426): Yeah. Paul Asadoorian (23:02.335): I think some kind of categorization built into it. Vlad Babkin (23:05.923): And to be honest, CWE data is not as useful. Yeah, you can have it, but there are so many overlaps between CWEs, and it’s so complex to actually come up with a good list of CWEs, that you will not ever be able to rely on it as a vendor. And this is the reason why it’s not required, it’s incredibly complex to come up with it. So ultimately, what we are… Paul Asadoorian (23:24.425): also not required when you create a CVE record. Paul Asadoorian (23:31.297): Mm-hmm. Vlad Babkin (23:34.097): Clawing at is CWC, CPE precision. right now every single vendor who deals with vulnerability detection ultimately just builds their own way to identify devices other than CPE. And CPE also ultimately lacks information about how versioning is built. example is Cisco. Cisco loves non-standard versioning schema. Paul Asadoorian (23:47.191): Mm-hmm. Vlad Babkin (24:01.905): I don’t know why they picked the version in schema as they did, but it’s not somewhere, it’s not anything standard. So you cannot just compare them with standard operations. Ultimately, if the vendors could provide information on how to basically compare versions, it would make checking for vulnerabilities many times faster than just trying to check against a huge set of known vulnerable versions. Paul Asadoorian (24:24.437): Yeah. Well, it sparked a thought because there’s also the component, right? So I’ll use F5 as an example here because I think, Vlad, you and I were testing this. So you have a version of F5. It’s 15.1 or whatever. And that could have a vulnerability, right? Maybe that version is vulnerable. But it’s only vulnerable if it has a specific component. Vlad Babkin (24:32.242): Yeah. Paul Asadoorian (24:53.847): would kind of be nice, I don’t know how you would define this, but it would be nice if there was some way to disclose, other than in the description, which component is affected. Because then it would know, like, wait, I have F5, I have that version. But the vulnerability I’m thinking of, I don’t know the CV off top of my head, you had to have the APM, what was APM, Vlad? It was like some identity management kind of feature in F5 had to be enabled. and then you’re vulnerable. I think we just saw this with Arista as well. Arista was like, actually, this one’s being exploited in the wild. This version’s vulnerable, but it’s only vulnerable if you have this specific configuration. And by the way, if you have this other configuration, that’s a mitigating control and it’s not vulnerable. But there’s no way to glean that unless you go read the vendor advisory from top to bottom and understand it. Vlad Babkin (25:34.867): Mm-hmm. Yep. Yep, it’s not very obvious how to even verify that. You cannot… Okay, how do you verify if this configuration is on? And this task is like… Yeah, that’s literally engineering problem, and vendors don’t usually provide those. So, vendors say, hey, if this is enabled, great. But you don’t provide instructions on how to check this. So, like… Paul Asadoorian (25:58.244): Well, that’s our problem, right? That’s our engineering problem currently. Yeah. Paul Asadoorian (26:11.703): Yeah, so then you’re go read their documentation, or I use Claude, right, or an AI to go, and then we’re gonna go read their documentation, hope the AI’s not hallucinating, because I can’t be an expert on 30 different vendors and all of the platforms that they have. I need some way to easily go figure out what is the configuration that would represent a good, we talked about input, output, and outcomes, right? What’s the good configuration, what’s the insecure configuration, and how do I test for it? Vlad Babkin (26:20.2): Yup. Mm-hmm. Yup, and even worse is that with the growing number of CVs which will be discovered, the more AI gets better, and the more specifically attackers get better at using AI, there will be a lot more of CVs coming in, and this is whether we can handle it or not. So vendors have to cooperate. If vendors don’t, then we are basically stuck. Paul Asadoorian (26:50.273): yeah, we’re already seeing that. Paul Asadoorian (27:01.333): Yep. 100%. Vlad Babkin (27:10.627): There will be an insane number of vulnerabilities that you will have to come up with a checks manual. Paul Asadoorian (27:18.391): One of my favorite vulnerabilities that, ironically enough, we talked about CVE, this one doesn’t have a CVE. This is the conversation that I had within the community 10 plus years ago that not every vulnerability has a CVE. And here’s a pretty major one. It’s called Yellow Key. It’s BitLocker Bypass. It was published by Nightmare Eclipse, who has had a… a recent run, an impressive run of vulnerability disclosures to Microsoft. This person is very frustrated with the disclosure process at Microsoft. And I don’t want to take sides there. I mean, there’s people at MSRC that are doing great work. I’ve spoken with them, I’ve interviewed them. But we still run into these cases where there are disagreements between a security researcher and a major vendor. about whether this is a vulnerability or not, whether or not this should have a CVE, whether or not the vendor’s going to fix it. We still have those discussions today. I don’t have any insights as to what the negotiations were, how they went. So I can’t, I don’t really want to weigh in and start pointing fingers, right, at Microsoft or the researcher. Like, I just don’t. Just know that this is a situation where those negotiations in the disclosure process did not have a very good outcome for really anyone, right? So what ends up happening is the researcher got frustrated and published their findings to GitHub. And this is a bypass that requires either a USB stick or a modification to the EFI partition. It also requires that you reboot the system or change the power state. I’m assuming you could push the… There’s lots of ways to get into what we call WinRE or Windows Recovery Environment. You have to be in a Windows Recovery Environment. You have to have it read specific files. These deal with the file system, NTFS file system that then trick, basically trick Windows and various subsystems, trick the TPM into going, by the way, here’s the key to unlock the drive. Because it’s part of that Windows Recovery. Paul Asadoorian (29:42.892): process. I’m glossing over a whole bunch of technical details. You should totally go read about it. I had to do research on my own to understand it. If you plug in the FSTX is the specific feature that is being abused. I don’t know if it’s abused is the right way, right? But basically that’s what’s triggering the bypass to trick the TPM going, sure, I’ll unlock the drive like you’re in recovery mode. Why wouldn’t I unlock the drive? the public version that’s available would still require a TPM pin. The author claims to have a version that does not require a pin. Effectively, this means there is a working bypass for BitLocker. This has been verified by third parties. I think Kevin Beaumont and Will Dorman, Windows prolific vulnerability hunters, Vlad Babkin (30:25.697): my… Paul Asadoorian (30:42.167): have verified this and validated that this does in fact work. So, I think what we’re saying is BitLocker is not effective any longer, given this bug, this feature. Some conspiracy theorists say it’s a back door. Did Microsoft put it there purposely? I don’t think that’s true. think one of my other friends said it’s more likely this was like an engineering workaround, like in testing that got accidentally left in. That’s the theory that I think is more plausible, but maybe you guys feel differently. Vlad Babkin (31:01.725): you Paul Asadoorian (31:16.843): Maybe when he wants to put on tinfoil hats and say Microsoft built a bitlocker back door in for governments or something. Vlad Babkin (31:25.735): Yeah, it does like I have been looking at this. I love a good conspiracy, but on this one, it does feel a lot like a backdoor would feel. Like, let’s create a very specific file on a very specific location, and suddenly you have BitLocker bypass, which only triggers in one specific condition, and in normal conditions, it’s removed for mysterious reasons. Paul Asadoorian (31:51.029): Isn’t that crazy? When you put it like that, Vlad, now I’m on the conspiracy theory bandwagon. Vlad Babkin (31:51.549): Tasty? Isn’t that like… I wonder how that works. Like, I cannot, of course I cannot know for sure, and I will probably never know for sure, but if there ever was a backdoor, that smells a lot like one. Paul Asadoorian (32:11.669): Yeah, yeah, no, it’s a great point. I like this. I know we were talking internally. I like this coupled with the KVM research because that gives you physical access. And through an IP-based KVM, you can remotely mount a USB drive and boot the system off of it. You could also do this with a BMC. So now, an attacker that wants to, well, I guess if an attacker had access, to the system while it was running, BitLocker wouldn’t matter anyway, right? Chase Snyder (32:51.552): I mean, okay, what is it? Hanlon’s razor. Never attribute to malice that which you could attribute to stupidity. But what’s Paul Asadoorian (32:53.067): There’s that. Paul Asadoorian (32:58.55): Yes. Paul Asadoorian (33:02.391): Dude, so funny. I had to look that quote up yesterday because I’m like, I know that there’s a name for that phrase and I don’t remember the exact wording. And I was like, oh yeah, Hanlon’s razor. That’s what I was looking for. Hanlon’s razor, yep. Vlad Babkin (33:05.875): Yeah. Uh-huh. And it’s just a cumbraser. Chase Snyder (33:10.604): Hanlon’s razor, yeah. So what’s the stupidity case for this one? I guess that it was an engineering around. Vlad Babkin (33:20.485): That’s the whole point. I cannot come up with a stupidity case. Why would you have such a complicated feature which triggers only on specific files and have it only in one place but not the other? And you have journals on this fix in both versions, so it doesn’t sound like a feature that would suddenly be implemented differently in WinRE and normal Windows. Chase Snyder (33:23.448): Okay. Mm-hmm. Vlad Babkin (33:48.379): Then there is also a very specific feature which only works in Windows for Cover environment and the author claims to have a full bypass of pin in there. come on. How much stupidity can you even survive? This doesn’t sound like stupidity. And that’s why I’m little bit more leaning towards conspiracy bandwagon. Chase Snyder (34:08.046): Ha Paul Asadoorian (34:08.311): I’m with you now, Vlad You converted me. Now I’m on the conspiracy bandwagon. Vlad Babkin (34:11.411): So like, but again, disclaimer to the viewers, there is no hard evidence or hard data. So we can only speculate. This is only speculation. Paul Asadoorian (34:18.762): Yeah, right. It’s the beauty of a podcast, man. That’s what we do. We can speculate. Chase Snyder (34:23.886): plausible deniability. Vlad Babkin (34:25.521): Yep, we speculate and we don’t… There is no hard proof that we can present you with of either stupidity case or conspiracy case. For stupidity case you would need to commit logs from Microsoft which would explain the stupidity. For conspiracy case you need some government agency to come out and say yes, that’s us. You’re probably getting neither, ever. Paul Asadoorian (34:31.969): Yeah. Paul Asadoorian (34:49.739): Yeah, I guess the attack scenario with the KVM could be that I’m an attacker, I gain access to the KVM, but the workstation’s locked. And now I need to reboot it to gain access to the data. But if it’s protected by BitLocker, I need a BitLocker bypass to access the data. That’s a really kind of obscure use case, but plausible nonetheless. Paul Asadoorian (35:21.141): I’m curious to see how the story unfolds. And what will be interesting, let’s say Microsoft does release a fix for it. Are they going to patch Windows 10 or just Windows 11? Vlad Babkin (35:34.899): This is how Microsoft are, they’re probably gonna patch on Windows 11. Microsoft did the biggest service to Linux migration they ever could, forcing people to install Linux on their outdated devices, and suddenly people are starting to finding out that Linux is not that bad. Paul Asadoorian (35:39.147): Right, I think they did patch a different bug in BitLocker, right, and they only did it for 11. I thought I saw that this week too. Paul Asadoorian (35:57.972): Yeah, I am. I’m on that. I’m on that bandwagon, dude. As you guys know, I use arch, by the way. So there’s that. I thought I had, so one of the last thing on this one. One of the mitigations recommended is to apply a BIOS password. And then I think, Vlad, we’ve talked about this on the show before and you spent some time with BIOS password bypasses. think we covered one that was like a really roundabout way to break the BIOS password. Of course, you know, there’s the I removed the CMOS battery is one, but that doesn’t always work. What were some of the other bios? There was another bio. if you want to swap the spy flash chip out, you can potentially bypass the the password. You’re not really bypass it, but you just if you got a laptop and it’s protected with a BIOS password, you go by that same model laptop and you pull the spy flash chip out of the one you bought. from eBay and hope that it isn’t password protected, and you just put it in the one that is password protected and magically it longer asks for the password. And there’s other techniques I know as well. But Vlad, is a BIOS password a good mitigation? Where does that fall on the scale of mitigation for this particular attack? Vlad Babkin (37:33.265): You mean for the yellow key, right? So it depends a lot on, like, first of all, does resetting CMOS also reset your BitLocker key or not? And just how good is your attacker? Because, like… Paul Asadoorian (37:37.687): for the BitLocker, like I can’t use yellow key if there’s a BIOS password. Paul Asadoorian (37:52.054): Yeah. Great question. Vlad Babkin (37:56.435): Ultimately, depending on the device, I presume there can be extra issues where you can just present the BIOS password and be done with it, and suddenly you can use the full attack again. Or there can be password bypasses, and then there is a password for access to laptop, and there is a password for access to BIOS, which are two different passwords. And if it is just the second password for access to BIOS, then you don’t care. Paul Asadoorian (38:03.671): Mm-hmm. Paul Asadoorian (38:16.833): Mm-hmm. Vlad Babkin (38:23.451): There is a whole slew of questions that can be asked here. Like, I didn’t research if like, reseting BIOS password will also reset BitLocker. And also, there might be more than one way to actually reset it. Right? So… Ultimately, it’s very hard question to answer. Maybe it will help. It for sure will make the attack more complex, but will it it? Probably depends on the device. Paul Asadoorian (38:36.588): Right. Paul Asadoorian (38:45.27): Yeah. Paul Asadoorian (38:48.779): Well, you got me thinking now, if you swap the Spy Flash chip out, does BitLocker recognize a hardware change? I don’t know the answer to that. I mean, I could look it up, but if I find something, I’ll put it in the show notes. about that? Chase, did you have a couple of stories you wanted to hit during this episode? Or did these come from Vlad? I don’t know who put them in here. We had one about the… Chase Snyder (39:12.992): I mean, the other, one of the other ones we got in the notes is the Foxconn breach, we can get into. Paul Asadoorian (39:19.637): Yes. Chase Snyder (39:21.652): No, I didn’t have any other stories immediately off the top of the dome to talk about, but there is just constantly stuff happening and, you know, happy to throw stuff in the hopper. But we should definitely talk about the Foxconn breach. That’s a big deal. A volume of data being claimed in that one. I feel like every time I hear about a big new ransomware, the amount of data that’s being claimed to have been like exfiltrated or whatever for ransom is. Paul Asadoorian (39:38.186): Yeah. Chase Snyder (39:48.394): Enormous and unprecedented this one was like eight terabytes or something like that Wasn’t there one that was in the petabytes recently? What was the reason with the ransomware that would thing that happened that was like? Some number of petabytes of data had been exfiltrated. I was like how how much data these business even have that’s so much Paul Asadoorian (40:09.623): Yeah, it’s crazy. Companies have a lot of data. mean, this is the MO of groups today. They’re not just ransomware, right? They’re stealing everything. In a lot of cases, they’re just stealing it, not even encrypting it as part of a ransomware campaign, but they’re just stealing the data and then sifting through it later. Chase Snyder (40:16.577): Yo. Yeah. Chase Snyder (40:23.607): Yeah. Chase Snyder (40:33.442): And then when you, you know, it doesn’t really, once it’s gone, it’s gone. Like there’s no, there’s no world in which the ransom group. deletes that data when you pay the ransom and doesn’t keep using it for something or leaking it in some other way. So you’re just, I don’t know. I think there’s been, there’s been some efforts to make it illegal to pay ransom ransoms. I mean, Foxconn’s in China, right? So it’s like, you know, law different over there, but. Paul Asadoorian (41:13.879): Oh, this is, it’s impacting, it does have factory, North American factories. I don’t know if that was hallucinated or not. Chase Snyder (41:16.059): okay. I need to read more. need to read the story before I, shoot my mouth off. Paul Asadoorian (41:26.773): Yeah, so Foxconn makes components for Apple, Google, Nvidia, and Sony. Apple being the most notable one. It’s a double extortion ransomware group. So they did encrypt the files. Well, they’re known for encrypting the files, but also stealing them first and threatening to leak it, is, you know, that’s common these days. Chase Snyder (41:49.42): I’m flipping through the responses on Twitter to the original tweet from Dominic Alviari that we pulled up and I’m loving this one that says, Foxconn breaches such a perfect example of why hardware supply chain sovereignty matters. Eight terabytes of Google and Intel topology specs exfiltrated from Apple’s number one supplier. Paul Asadoorian (42:01.24): Mmm. Chase Snyder (42:11.5): When your entire infrastructure ultimately sits on components from a handful of manufacturers, you don’t have sovereignty. You have rented trust. Love that phrase, rented trust, hardware roots of trust can’t be outsourced forever. These incidents are going to keep accelerating that ties it. That couldn’t be more of a tee up for our sort of conversations about this type of thing. Like the hardware supply chain. When I like. Paul Asadoorian (42:22.057): Rented trust. Yeah, I like that a lot. Chase Snyder (42:39.308): We talked about on numerous recent episodes and other other things, the router ban and how the question of like, does manufacturing those does on shoring the manufacturing of routers actually help with our cybersecurity at all? And it’s very questionable. And this is a way more salient sort of example of a situation where having these Paul Asadoorian (42:48.535): Mmm. Chase Snyder (43:07.692): Yeah. The hardware supply chain, the hardware supply chain conversation around this type of device feels more interesting to me than the router one. Paul Asadoorian (43:29.451): Yeah, it makes me wonder like, could there have been keys that were in that eight terabytes that could lead to future supply chain attacks? I mean, if you look at Apple’s infrastructure in their hardware, it’s a very tightly closed ecosystem that relies on their own hardware root of trust, but it requires a manufacturer like Foxconn to actually build and test and do all that. It wouldn’t surprise me if there’s at least test keys. Vlad Babkin (43:40.339): That’s a very good question. Paul Asadoorian (43:57.802): in that eight terabytes of data? I mean, maybe not, but there could be. Vlad, thoughts on that? Vlad Babkin (44:07.251): It could be. It depends a lot on how exactly they manage keys, but as we know, large organizations are not well known to manage keys well on all levels. So chances of there being surprise keys in 8TB of data are pretty darn high, even though Apple might have a whole corporate process around it. But… I never viewed the 8TB of data. By the way, this is a good use case for AI, ask AI to find keys in that. Paul Asadoorian (44:15.851): Mmm. Paul Asadoorian (44:27.285): Right. Paul Asadoorian (44:32.023): It’d be interesting. Paul Asadoorian (44:36.757): Right, well that’s the problem that these groups are having that I learned a couple weeks ago is, like I think it’s leaked bizarre, like there’s groups that the service they provide to other threat actors will go through the data that you stole and tell you what you have and what the value is of it. Because going through eight terabytes of data is a lot of work and you have to know what you’re looking for. And so there’s groups that specialize in that. Vlad Babkin (44:36.834): if you have the leak. Paul Asadoorian (45:06.711): Which is crazy. Paul Asadoorian (45:11.381): So we’ll see. 11 million files. Yeah, you’re right. That’s a job for AI. I don’t want to go through 11 million files. Could you use grep? Vlad Babkin (45:21.469): Probably you can grab for common stuff and also truthful hog. It’s like collection of rag access for grab. Paul Asadoorian (45:29.267): Mm. Take some time, certainly. So we’ll see what comes out of it. what are they, I wonder what their goal, like are they gonna just release all of it? Vlad Babkin (45:48.165): is good question. Paul Asadoorian (45:50.785): They did release samples and it looks like lot of schematics. Vlad Babkin (45:51.333): sink him. Vlad Babkin (45:55.379): There is a very good question of what’s even released. Unless you have all 8 terabytes here and cannot really run all of this. Attackers probably can scan, like, whomever has 8 terabytes can scan it with Truffle Hog and come out to us with the answer. But like… Paul Asadoorian (46:01.559): Yep. Paul Asadoorian (46:13.973): It’s interesting. It’s interesting to see if it impacts the manufacturers like Apple and Nvidia, right? I’m sure the security researchers are jumping at the bit for this data to be able to analyze it, right? For some kind of flaw or vulnerability. Vlad Babkin (46:32.435): Yeah, but like we as researchers don’t have… Paul Asadoorian (46:45.483): Yeah, we don’t have access to the data. Vlad Babkin (46:46.227): So we don’t have access, it’s just speculation. If with yellow key we at least see the evidence and can speculate better, in this case it’s like, does it have keys, does it not have keys? What’s in the black box? Guess it right now! Like TokTok shows. We don’t know, and there is no evidence to point us either way. Paul Asadoorian (46:54.252): Yeah. Vlad Babkin (47:14.991): There is high chance there is something, so I wouldn’t just sit on my behind and not do anything. If I would be Foxconn and Apple, I would be like rushing to reset as many keys as I can. With this deeper reset. Paul Asadoorian (47:25.899): Yeah, agreed. Vlad, I think you also had the story about a mini shy, hallowed supply chain attack on NPM. Vlad Babkin (47:34.843): Hmm… Yup, it’s not just NPM, by the way. So, like, supply chain attacks on package managers continues. Yet another time we see the attack of Shaykho loot style and where multiple packages were compromised. This time it’s multiple package managers and we know of Pype packages, which also were compromised, specifically Mistral.ai, which is, by the way, a relatively popular package. Chase Snyder (48:01.174): What does shy Hulu style mean? What are the characteristics of a shy Hulu style attack? Vlad Babkin (48:01.619): So, yeah. So, this is fun. So, when one, like, one package gets compromised and then it gets deployed on developer machines and then suddenly attackers have a lot more npm tokens and pypy tokens and they publish yet another package into pypy and npm. That package gets downloaded and they get even more tokens and the attack continues to spread this way. So this is pretty much how the original Shai Kulud worm worked, and they just pretty much did it again. And this will continue, by the way. This attack will not keep stopping. So your only approach to this is to lock your dependencies behind by two weeks at least, and let people notice the Shai Kulud thing first, and fix it before it gets to you. So this is most effective defense you can make right now. Paul Asadoorian (48:58.966): That’s interesting. So you put a delay in your updating your dependencies in two weeks is a yeah, because usually we discover these within two weeks, usually. Vlad Babkin (49:06.577): Yeah, it’s usual and like the two weeks delay is very good approach and some kind of proactive package scanning is a good approach and you need to lock all of your dependencies by hash because nobody is stopping attackers from publishing the package with an older version. You can retarget packages in this package managers. Paul Asadoorian (49:22.954): Mmm. Paul Asadoorian (49:27.222): I see. And so you can lock them in by hash. Vlad Babkin (49:28.371): So like, yup, there are tools. Like for example, for Python, you don’t want to use raw pip. You want to use poetry or more modern alternative is UV by the way. UV will produce a log file which lists package hashes for everything. And NPM also does create a log file which logs package hashes for everything. Rely on that. Besides just delaying the updates. So like, instead of getting infected, you can do this. Paul Asadoorian (49:53.034): interesting. Yeah, I never considered that supply chain attack path. Yeah, I’m going to go poison a previous version of the library. Vlad Babkin (50:03.771): It’s the most obvious one and I believe ShyHoolood even did this. At least either mini-ShayHoolood or new-ShayHoolood. You can retag stuff in these package managers. like, there is some need to actually start creating signatures for all of this so that developers actually have to sign their packages. Which would make the attack a little bit harder. But like, right now this is very open problem. Like, it’s very not obvious how to solve it beyond delaying the updates, etc. etc. And like, no. Paul Asadoorian (50:07.051): Mm. Chase Snyder (50:29.166): Which is already kind of a best practice in enterprise technology, right? Like places will say like we, we don’t, we don’t take, bring on the new we’re in minus one at most for firmware versions. We don’t update to the very newest one. We, we have like, you know, one or two versions back. Cause who knows what kind of garbage is in the new version. Vlad Babkin (50:36.413): Yup. Vlad Babkin (50:47.4): Yup. Vlad Babkin (50:54.023): And you want S-bombs for everything, so that if a shy Hulu happens, you can quickly check if your entire fleet has a surprise. At the very least, this way you protect production systems. It can still get on developer machines, but that’s a whole different beast, which has EDRs and whatnot already looking at it. Chase Snyder (51:13.23): This one had two really funny slash dirty wrinkles to it that I feel like we should talk about one I saw a great take from Twitter user at Lori wired It was a great that’s a great account that the most low effort slash high reward thing you can do for security is installing the Russian language pack because apparently the info stealer that being dropped by this shy hoolude compromised packages avoids executing in Russian language environments. So like what’s stopping you from just installing the Russian language pack? Which mileage may vary, but it’s a funny bit. Vlad Babkin (51:57.459): It was just the original Shyhulu. And there is also a project which is called Digital Scarecrow. Don’t remember the link, let me google for that. But the whole point is that it runs processes which looks a hell of a lot like you are running in an emulated environment. Like, actually let me post the link. Chase Snyder (52:18.787): Mm-hmm. Vlad Babkin (52:24.879): I’m sure how that will be shared to viewers, but it’s a release, we can talk about it on the same page. And I don’t have access to chat, great. Chase Snyder (52:28.13): The other funny tidbit about it was that in this is. Vlad Babkin (52:35.281): Chase, please pose this to people. And the whole idea behind this is that if your environment looks a lot like it’s emulated and being a research environment, there is a chance that malware will look at it and get scared and not run. Chase Snyder (52:46.766): Yeah, that’s fun. Deception techniques. Paul Asadoorian (52:52.232): there was a cybersecurity company that did that. Yeah, they put deception techniques on the system to trick malware into thinking it was in a virtual environment. So they’d load fake virtual drivers as an example. And then the malware go, I’m not doing anything on this system. And so they would do that on your production Windows or Mac systems. They would put basically evidence or markers in there that would basically turn the malware off. Chase Snyder (53:19.98): Dude, inception. Paul Asadoorian (53:20.756): based on what it was checking for. I don’t know what happened to that company if they got bought or something like that, but that was a like, whole claim to fame. Yeah, I don’t think they were in deception category, but it was, was malware deception. Like locally in every workstation. It was pretty wild. I don’t know why it ever happened to them. I think they got bought would be my guess, but. Chase Snyder (53:23.778): That was a whole, mean, deception was the whole category. don’t remember what all, what all counts as that. Chase Snyder (53:42.83): The other dirty little like tidbit about this one though was that According to the bleeping computer article about it a destructive secondary routine is also present in the infostealer In environments that appear to originate from Israel or Iran the malware introduces a probabilistic sabotage mechanism with a one in six chance of running a recursive wipe command So it’s gonna run our MRF Paul Asadoorian (53:45.558): Cool. Chase Snyder (54:10.926): It’s rolling a D6 on whether it tries to wipe your whole system if it looks like you’re from Israel or Iran which is Just just nasty work, man Vlad Babkin (54:27.304): Yep. It’s like very very evil. And like, I don’t know, joke about Russian roulette in terminal, just like two guys running a 1 in 6 chance to wipe the hard drive from their production servers is like… Yeah. It’s top BNW meme. Chase Snyder (54:44.59): Everything is becoming a casino, right? Even the malware internals. Vlad Babkin (54:57.137): I mean why the hell not? It’s funny. As a malware author I would do that, make me little bit more stealthy. Chase Snyder (55:04.214): introduce a feature where you can do side bets on whether or not it is gonna run the recursive wipe on your system or not before it actually does it. Put it up on Polymarket. Vlad Babkin (55:24.273): Yeah, like I’m waiting for attackers to actually run a polymarket themselves, like how many Israeli systems they will wipe and produce some live statistics where you can actually bet on how many are wiped in five minutes. In five more minutes. Like, if I would be an attacker, I would totally do that at one point. This is how you know that I’m not an attacker, by the way. Chase Snyder (55:34.219): my gosh. It has to be happening. Paul Asadoorian (55:50.401): Cool. Anything else this week? Chase Snyder (55:53.496): Thank you Vlad Babkin (55:55.635): I think we have enough for this week. What else will happen this week? Paul Asadoorian (55:58.017): We did, covered a lot of covered a lot of ground. Well, Vlad Chase, thanks for joining today. Thanks everyone for listening and watching to this edition of Below the Surface. We’ll see you next time. The post BTS #74 - YellowKey, CVE Enrichment, Chipmaker Breach appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise .