BTS #75 - Secure Boot Certificates Expiring: What You Need to Know
Transcript
Paul Asadoorian (02:10.178): Okay, good. Sweet. All right. Hey, we’re ready. Let’s do this. This week: Yellow Key BitLocker bypass update. Secure Boot certificates are expiring and what it actually means. The Verizon DBIR for 2026. Open Petya project. F5, SonicWall, and edge routers are under attack. Stay tuned. Below the Surface. Coming up next.
Paul Asadoorian (02:37.306): Welcome to Below the Surface. It’s episode number 75. We are recording on May 28th, 2026. I’m Paul Asadoorian, joined by Mr. Chase Snyder. Chase, welcome. Good to see you, my friend. Mr. Vlad Babkin is here. Vlad, welcome.
Chase Snyder (02:48.79): What’s up, Paul? Always pumped to be here.
Vlad Babkin (02:54.967): Hello.
Paul Asadoorian (02:56.614): Super excited to get started. Before we do, Below the Surface listeners can learn more about Eclypsium by visiting eclypsium.com/go. You can find the Ultimate Guide to Supply Chain Security. You can also find 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 DigitalOcean. If you’re interested in seeing our product in action, you can sign up for a demo. All that at eclypsium.com/go.
Paul Asadoorian (03:40.00): We got some awesome stories to talk about this week. I am super excited. You wanna start with Verizon DBIR? Because that was a new latest edition and will warm people up to talk about the Secure Boot thing. ‘Cause there’s so many articles published about Microsoft certificates expiring, and I think 98% of them leave out a whole ton of details that ourselves and the rest of the team here at Eclypsium can provide details on. So you’ll get those details in this episode, which is amazing. But let’s—yeah, now that I’ve teased that out, let’s talk about the Verizon DBIR before we jump into Secure Boot and other topics.
Chase Snyder (04:02.062): Kind of our wheelhouse.
Chase Snyder (04:08.578): Yeah man, let’s get into it. It’s my favorite, my favorite big deranged PDF that comes out every year. If you like reading 100-plus page PDFs, this one is for you. This one’s like 120; usually it hovers around 100, but it’s getting longer. Lots of good visuals, though. They know how to break up the text and it’s full of like little inside jokes and stuff.
Paul Asadoorian (04:20.271): Is it hundreds of pages?
Chase Snyder (04:35.212): I would assume that many listeners of this podcast also get excited for Verizon DBIR release day like I do, but who knows? But the big thing—across my long and storied career in cybersecurity, I’ve developed a habit of writing a blog post where I call out my like three favorite things from the DBIR report every year. And last year and this year, there was a big development. Last year it was like exploitation of vulnerabilities, as an activity or as an action that was a part of the breaches that they analyzed for the report, had caught up with credential abuse. So they were like, exploitation of vulnerabilities was on the way up, credential abuse was a little bit on the way down, and they were almost at the same frequency at that moment. And this year, exploitation of vulnerabilities is way, way higher than credential abuse. And that’s a crazy trend.
Paul Asadoorian (05:31.43): It is a crazy trend. I mean, I think the overall trend that we’re seeing in covering stories on both podcasts that I do almost every week, the general consensus is that AI is shifting this vulnerability landscape. That attackers and security researchers have these amazing tools that can be tuned to find and exploit vulnerabilities. And we’ve talked about examples on this show, so I don’t want to necessarily go into all the details of it. Now it’s, to me, an established fact. And we’re seeing evidence of that in things like the Verizon DBIR, right? But I think that the more interesting angle to that is: what do we do as defenders? You guys saw my relatively new role here at Eclypsium, providing direction for one of our research and engineering teams. And I’m kinda like—defense is the new sexy now. I mean, not taking anything away from security research; I still do that, I still think it’s fun, and a lot of respect to those that do, but it’s a harder problem now. How do we get our vulnerability management and visibility and remediation better using maybe the same or similar tools that are used in offense? How do we apply that to defense? How do we get smarter at detecting these attacks, detecting these vulnerabilities? Defense is the new sexy. I think now is the time.
Chase Snyder (07:15.992): I think something that is missing, or something that’ll have to happen for that to actually work, is to figure out what you can monitor or display that indicates that you as a security person, or that your security tool, did something. I think that something that worked out really well for the big security categories that have skyrocketed in the past decade or so, like EDR, is that they’re based on an event that’s super easy to report on and put on a dashboard, which is a detection and a response.
Paul Asadoorian (07:41.178): Yeah.
Chase Snyder (07:54.014): And if you’re moving towards a preventive model and sort of something that’s more like Attack Surface Management or preemptive prevention of attacks, it’s way harder to say “this attack didn’t happen to us because we did this work ahead of time.”
Paul Asadoorian (08:17.679): Yes. It’s harder to prove the value. Agreed.
Chase Snyder (08:20.364): Yeah, it’s way harder to make it sexy in that way. And I think that is gonna be really key. And that’s a product management and human factor, right? How can you make it reportable in a way that is appealing both to the individuals that have to do the work and also to the executives that they have to report up to, to be like, “look at this measurable positive impact that my thing made.” But I do think that organizations are getting tired of like—vulnerability management is like, “here’s a gazillion vulnerabilities.” Who knows if they’re reachable? It’s highly reportable, like “we found all these vulnerabilities,” but they are starting to recognize like, yeah, most of that’s not that useful. And alert fatigue is a cliché at this point. They get it that the reportability is actually becoming kind of an overwhelming problem. But one other tidbit I want to call out from the DBIR report though, the other thing that’s highly relevant to us, the thing that we talk about all the time: network asset breaches. Network assets being targeted went up enormously. And similarly to how exploitation volumes go up and credential abuse goes down, network asset targeting is going up and user device targeting is going down. So user device went down like 60% from where it was at before or something like that.
Paul Asadoorian (09:47.481): Yeah. It’s basically more data that backs up what we’ve been saying about the threat landscape recently. Which is great.
Chase Snyder (09:47.744): Yeah, double-digit percent. The number of breaches that they investigated for this report that had a network asset breach specifically as part of the flow went up almost 3x. More than 300 percent, actually. It’s still a comparatively low number at like 5% of the total breaches, but the growth trajectory is pretty bad.
Paul Asadoorian (10:13.741): Yeah, so—go ahead, Vlad.
Vlad Babkin (10:16.591): I’ll probably tell maybe a controversial opinion, but I don’t think that this growth is only due to AI. Like, we see the spike in 2023 for this growth, which is a little bit too early for anything relevant from AI. And then in 2025 it started growing while we didn’t know that AI really became useful in 2026, not 2025. So I think that part of this growth can be also attributed to attackers getting better tools in general, not just better AI models. Like, if you look at stuff like Nuclei templates, which didn’t exist a couple of years ago, Nmap, or, for example, better and better polished tools for Sliver, which is an open-source C2 implant, right? So they do advance the defense side of things, because now we can actually see an open-source implant and make at least some assumptions and some guesses at how an in-the-wild implant might look like. This tool should exist, but also it’s making it easier for attackers to actually just start exploiting stuff. And the shift here is that it’s no longer enough to just hunt vulnerabilities. What you should be doing is preventative measures like those which are really hard to report. And that’s the problem. Nobody really wants to do them because they don’t provide immediate value and require your time and effort to actually implement. But at the same time, if you don’t do them, your product becomes like a Swiss cheese of vulnerabilities eventually. And that happens very quickly, as we see with a lot of more legacy network devices. They were never designed with preventative measures in place, and they just patch holes every single week. And the AI will only accelerate them becoming a Swiss cheese. It’s not just your hardware; it’s also your software. Literally every piece of software is facing this right now.
Paul Asadoorian (12:11.673): Yeah, I also think there’s a lot of false negatives in vulnerability management and asset management today. ‘Cause everyone always says in cybersecurity, “you gotta know what you have.” And so when something’s vulnerable, you can go determine if you’ve got that vulnerable thing. Now, what I’ve been observing in the threat landscape—maybe I’m looking harder for it—but I’m observing things that I believe traditional VM and asset management’s gonna miss because they’re relying on a version number. And Vlad, you and I have had these conversations a lot, right? But there’s been a few very specific cases of vulnerabilities. One was with F5 and one was with Arista, both network-edge devices. And what happens is the vendor says, “This is a critical vulnerability.” So if you have it in your network, you need to pay attention to it. Let’s put aside the fact that attackers are probably doing reconnaissance and attacking your stuff even before you know about the vulnerability. But when the vulnerability comes out, you still have to go determine if you, in fact, have an exposure to that. And in both cases with F5 and Arista, you had to have a specific version, but also you had to have a specific feature enabled, and you have to have a specific configuration that either makes that feature vulnerable or not vulnerable. So now when you do vulnerability management—and I’m fairly certain that traditional VM and asset management certainly does not do this—you have to correlate between the version you’re running and accurately pinpoint that. Then, do you have this feature enabled or not? And then, is it configured to be vulnerable or not vulnerable? Like, do you have a mitigating control in your configuration? That’s some of what the team here at Eclypsium is working on when we find these specific things. I’m pretty sure there’s not a lot on the market that truly helps you with that and automates that discovery process, because that’s going to shape your response as to whether or not you need to push out a patch to these things that live on the edge, which could carry some operational risk. And just relying on a version number is certainly in my mind not enough. I also think we have the same problem with Copy Fail and Dirty Frag and all those vulnerabilities. If you’re relying on just the kernel version…
Paul Asadoorian (14:46.627): Well, that could lead to a false positive or false negative. Whoever is making that Linux distribution—’cause Linux runs on all these network edge devices—they could have said that they fixed it, right? They could have a version number that says it’s fixed. However, in their custom Linux distro, they never took on the patch to actually remediate the vulnerability because everyone’s loosey-goosey with their kernel version numbers. So if your checker or VM is just relying on a kernel version, did you actually check that that kernel took the patch to remediate that vulnerability? And that’s some of the other things that I’m researching is: how do we do that? Because these checks have to be accurate today.
Vlad Babkin (15:32.126): It gets even better. Like if you look at all of the “oh hey, your container image contains a ton of CVEs.” Well, if you analyze the 400 CVEs that you have, 399 of them are actually completely irrelevant because they’re like disk partitioning tools. How often does your container run disk partitioning tools at all? It takes a lot of effort to actually try to clean those containers up. It sucks out a lot of money just to comply with the requirements to have a zero-CVE container without bringing any tangible benefit whatsoever. And like, yeah, we do know that it doesn’t have a vulnerability in the partitioning image, but did it improve your security posture? No, because it didn’t add any preventative measures to your web application and the actual initial attack vector, which is usually just your stupid code injection bug somewhere in the web app or shell injection. That is still present because we never fixed it. And better yet, your router still has all of the CVEs inside of it. So like, you eliminated them in your container but not everywhere else in your infrastructure because there is no requirement to do this and because there is no device which does this. So all of these measures should just be re-evaluated and potentially just removed from compliance requirements because it’s just sucking away time and money from companies instead of letting them focus on something that’s useful.
Paul Asadoorian (16:54.371): Yeah. I mean, also that being said, if you’re building an application on Docker containers, I highly recommend the containers that are already pre-hardened. You can get those for free from multiple sources. They come with as few CVEs as possible, right? And that’s just good practice. It’s easy, it doesn’t cause me any pain. If you get it from a good source that’s actually paying attention to CVEs and fixing it, that’s a good thing. But like you said, Vlad, then you’ve got the application-level problem, and that is—if it’s a Python application like I have on Docker, what libraries am I relying on and how am I managing those dependencies? And that’s a double-edged sword, because I could say, “well, always build with the latest version of that library.” But one, I have to fix the things that that breaks in my application. Also, the latest version could be the one that’s poisoned, right? And the older version is not poisoned, so I’m not really protecting against a supply chain attack by bouncing around between versions. I could bounce back to a vulnerable or backdoored version or vice versa.
Vlad Babkin (18:21.967): And better yet, not all of the vulnerabilities in the library are even relevant. So for example, like…
Paul Asadoorian (18:26.444): Yeah, does my code even use the part of that library that contains the vulnerability, right? That’s where you’re like—I forget what the category of tool, but there’s tools that will tell you that in source code analysis.
Vlad Babkin (18:40.183): Yup. And better yet as well, if you look at how you structure your API, potentially even if you’re using a vulnerable part of the library, because of your API input controls, you might not be getting attacked from this vulnerability. For example, let’s say limiting passwords to 32 characters will eliminate most bcrypt library-related bugs for hashing. Yeah, it’s not a good practice to limit password lengths, but if the password length limit is high enough, like 30 or 40 characters, that’s fine. But it eliminates all concern of what happens when you put more than 64 characters. Bcrypt doesn’t like those inputs usually. You just eliminated the whole concern. There might even be mitigating controls even for core cryptographic stuff. Or like in this case also—99% of attacks come from anything that’s exposed to the outside, and that’s actually a minority of libraries and even a minority of your own internal source code. Like, okay, your function somewhere deep within the source code is vulnerable, but is this even reachable? And that’s a really hard question. AI companies are trying to come up with ways to answer it, but it’s not gonna give us deterministic answers. While it can help uncover vulnerabilities, it will not lead you to 100% coverage. So you cannot just rely on AI to replace your cybersecurity program. It’s a tool, not really a replacement for it. You need controls, you need much better API validations and whatnot. It’s not just “slap AI on it and it’s solved.” Even if you put AI on it, it’s still a big problem.
Paul Asadoorian (20:15.001): Yeah, 100%.
Paul Asadoorian (20:24.419): Yeah. I think it’s a tool, you know, and we’ve got problems that it might help and it might not. Microsoft Secure Boot certificates expiring is one such problem. I think the articles that I’ve read certainly don’t do this justice or explain it. And so we’re actually working on an article, so you get a little sneak preview to this. I talked about this last night; I actually updated one of my tools in my personal GitHub—that’s a supply chain checker tool that’s based on the Eclypsium Linux Supply Chain Cheat Sheet that I created—and I added some functionality to it to analyze the Secure Boot certificates and see if you have one that’s about to expire. And so what many will talk about is they’re like, “a Microsoft certificate is expiring,” which is technically not correct. There’s actually three certificates expiring this year. One is the big one that a lot of people are talking about. That one expires in about a month on June 27th. The “Microsoft Corporation KEK CA 2011″—that’s your Key Exchange Key—is expiring in about a month. What that does is it authorizes DB and DBX updates (your allow list and your revocation list) and allows Windows to push that via Windows Update.
Paul Asadoorian (22:00.798): So that one’s expiring. You have to make sure that—from what I understand, Vlad, is you can have both the 2011 and the 2023 Microsoft KEK key on your system. But as long as you have the 2023 one in there, you’re good, ’cause the 2011 one’s still gonna validate older entries. It’s only if you have the 2011 and not the 2023, correct?
Vlad Babkin (22:32.893): Yes, I think it is that way. From what I understood as how Secure Boot works, it is this. And also, what I have seen with Linux, you sometimes even have your own custom keys and you just sign your own drivers. So in this case, you also don’t quite care if you already use that kind of system. But in general, if you have both keys installed, you’re good.
Paul Asadoorian (23:03.897): Yeah, and now the other two certificates that are expiring are in the DB. So your DB and DBX can contain certificates or hashes that are representative of software that it’s been signed to be allowed to boot in Secure Boot or not. They’ve been revoked via the DBX. And the big one for Linux users especially is the “Microsoft Corporation UEFI CA 2011″—that’s the certificate that signs Linux Shim, third-party option ROMs, and non-Windows bootloaders. So if you’re running Linux, you’re affected by these Microsoft certs expiring. We’ve talked about that in the past a lot, and a lot of people in the Linux community were upset from day one when that happened. But what Microsoft is doing is they’re actually splitting that certificate into two different certificates. So one certificate will do OS bootloaders and the other one will do hardware option ROMs. I think they’re doing that for compatibility reasons. If they ever need to revoke this cert or expire it, they can treat the option ROMs for hardware separate from the OS bootloaders like Linux Shim. So it’s not a bad move by Microsoft to split these out. And of course your option ROMs are—if you have a piece of hardware in your system and UEFI goes, “well, I don’t quite know how to initialize or load this hardware,” the hardware can go, “here’s a piece of code in the form of an option ROM that should be signed” that gives UEFI instructions on how to initialize it. There was a Black Hat talk two years ago that talked about how to abuse option ROMs to gain code execution in UEFI, which was interesting.
Paul Asadoorian (25:39.939): That was a good one. There’s other weird things with option ROMs. If you find an option ROM that has a vulnerability that’s been signed but hasn’t been revoked, that gives you code execution. I want to say also this leads to gamers that want to bypass anti-cheat; they put hardware in their systems that uses an option ROM bypass. I’ve heard some stuff about that as well. Vlad, I don’t know if you’ve looked at any of that.
Vlad Babkin (26:09.963): I didn’t look at how hardware cheats work per se, but it’s definitely a hardware device which somehow needs to be validated with a Secure Boot certificate. Obviously, nobody is going to issue a signature for an obviously cheating device. If you can actually put your own key in the system, you don’t even care about bypassing anything, because now you have your own Secure Boot key. So in this case, I think it’s a mixture of approaches. And again, this is just to make it harder to detect. There was a recent noise about Valorant requiring you to enable IOMMU. In my opinion, that’s actually pretty darn funny. Valorant claims were very questionable when they started claiming that breaking hardware is great, and they got a lot of backlash for that. But I don’t think that enabling IOMMU is gonna break any legitimate hardware, at least that I know of.
Paul Asadoorian (27:03.076): Right. The third certificate is the “Microsoft Windows Production PCA 2011” certificate, which is expiring in October of 2026. That’s the one that signs the Windows bootloaders, and that will get an update to a “Windows UEFI CA 2023” for the Windows bootloaders. So those are the three certificates. Now they live in different places, right? The first one, the KEK, lives in the KEK variable and the others are in the DB. I think the articles have also done a bad job of describing what threats this could allow, and also not necessarily calling out that your DBX update specifically is independent almost of your KEK update. In other words, you could put the new Microsoft KEK key in, but if your DBX has not been updated, that still leaves you vulnerable to bootkits. So these are things that have to be done together. You need a way to check for systems that are running the 2011 certs and then the other check is: do I have the latest DBX update on those systems? Both those things have to be done.
Vlad Babkin (28:37.219): It gets a little bit more fun also if you start to consider some really old hardware. Like stuff that was sent with a 2011 key is not guaranteed to have been resigned with a 2023 key. So when you actually do this update, you need to leave yourself an emergency hash so that if it stops booting because hardware is no longer trusted, you don’t shoot yourself in the leg. It’s very important not to break your own device and allow yourself at least some wiggle room to actually boot it with the alt key or without Secure Boot, so you have at least the option to emergency sign using a local key.
Paul Asadoorian (29:22.722): Right. And that’s particularly important with bootloaders, too. I’ve seen a lot of user forum threads where if you’re applying an update to your DBX revocation list, and your existing bootloader is in that revocation list, that means when you reboot, Secure Boot is not going to load your bootloader, which is a bad day. Unless you can get in your BIOS and disable Secure Boot. A lot of the tools that do that will actually stop that workflow from happening so you don’t shoot yourself in the foot. But the point is: updating these things could lead to scenarios where systems don’t boot if you’re not careful. I would treat this like many other security controls where you’re doing controlled rollouts. You’re not rolling out new certificates or DBX updates to a hundred thousand workstations at once. You’re doing this in phases and stages.
Vlad Babkin (30:27.363): Yep. If you have a large enough enterprise, I hope you’re already doing this for like half a year by now and not just started because we told you today. You need a good chunk of time to actually validate everything because if you update 100,000 machines and 10,000 of them just die, your poor IT team is gonna kill you.
Paul Asadoorian (30:57.677): Right. Cool. And we have a whole article coming out about this to help people understand and manage this in their various environments, as well as some of our own product capabilities to help you out that identify these expiring certs on your systems. And like Vlad said, you should already have been doing this. If not, you’re gonna be in a vulnerable state until you get it sorted out.
Vlad Babkin (31:24.685): The best state to be is to have been doing this for a while. The next best is to literally start planning this today. Start at the very least checking what’s up with your environment if you didn’t start yet. Because if you wait for longer, you will have nasty surprises.
Paul Asadoorian (31:47.139): Yeah. Start with the KEK key, ’cause that’s the one that’s expiring soon. The other ones in the DB aren’t till later. The third-party Linux one is June 27th. The one that signs the Microsoft bootloader is October 2026. All that’ll be in the blog post.
Vlad Babkin (32:10.691): Yep. And it gets better because when Microsoft starts rolling out Windows updates which are not signed with the old key, your systems will be left without updates. Either that or they will update and not boot afterwards.
Paul Asadoorian (32:27.368): Right. There’s a lot to Secure Boot and all these certificates. I hope when this article comes out it clears the air. I read one or two other articles that actually got it right and went into all the details.
Paul Asadoorian (33:05.00): Vlad, what’d you think of this Open Petya project?
Vlad Babkin (33:05.027): Well, for me—I don’t know how much we told viewers about where I’m from, but I’m from Ukraine, so I have seen NotPetya with my own two eyes. I have not PTSD, but I remember what went down in Ukraine with NotPetya and how fun that was. So for me, it’s extra fun to see an open version of this malware to try to construct something similar for research purposes, not for evil, which is super interesting. I would be very interested in digging in once I get a little bit of time.
Paul Asadoorian (33:47.235): Yeah, it’s interesting they do something with the Master Boot Record (MBR) booting, but that’s like wicked old school. I’m curious as to why they’re doing something in the MBR. I haven’t gone through it, but I’m not sure that works to boot on modern systems.
Vlad Babkin (34:14.293): That’s actually a good question. I think they were targeting Windows 7 and apparently they were inspired by NotPetya and Petya, which I think both had MBR things in them. Plus, I presume this is some student’s project or at least some researcher who wants to learn stuff. Starting with MBR things is probably a good way to start because that’s historic. This technology—it’s very interesting to go in the historic route. Like if you want to learn Python for real, start with Python 2.7 even though it’s dead, because it’s going to give you a lot of historic perspective. Same here; this is pretty interesting. If it is a student project made for learning, this makes perfect sense to me.
Paul Asadoorian (35:32.866): Yeah. And that’s what it looked like. I wanted to call it out as that as well.
Paul Asadoorian (35:42.585): The updates to Yellow Key. I don’t remember what we disclosed on the last show about Yellow Key. We do have a blog post about it. The details were emerging as we were writing that post. I do wanna call out that there was a misunderstanding about the BIOS password as a protection mechanism for that. And that’s more what we’re calling the administrator password. That’s what prevents you from getting into your BIOS, right? There’s a credential password before you can get into your BIOS. That doesn’t actually mitigate the Yellow Key attack, because the Yellow Key attack preys upon WinRE (Windows Recovery Environment), and you don’t need to change the bootloader boot order in order to do that. So I’m not sure why or how this BIOS password—maybe they’re getting it confused with the startup or storage password, which means before your system will boot, you enter a password. But again, operationally that’s super hard to implement.
Paul Asadoorian (37:08.728): The other thing about Yellow Key that I thought was interesting is that there is a 404 in our blog post right now. I’m not sure if we’ve gone back and updated it yet.
Chase Snyder (37:08.728): Yeah. We put a little editorial note in there.
Paul Asadoorian (37:10.658): We did. Because the original author’s GitHub account was yanked. I guess this is what happens when you piss off Microsoft. They go, “you have a GitHub account? Guess what? We own GitHub, so we’re just gonna pluck your GitHub account,” because they feel it shouldn’t be distributed due to disclosure. My understanding is the author then went to GitLab, but then his GitLab account was yanked as well, which is not owned by Microsoft, but still they pulled it. If you haven’t cloned the repository by now, I don’t know where it lives currently.
Vlad Babkin (37:59.497): Microsoft, you’re not handling this right. If somebody from Microsoft is listening—where do you think “Nightmare Eclipse” will go next? He is not going to start communicating with you, especially considering you pissed him off. He’s probably going to sell this to much worse people than just putting it on GitHub. Now you will have no visibility into what he just sold. Apparently, he has a whole stash of stuff. In the end, you will find out that it has been sold to China later down the line. That’s just a logical conclusion. Where do you go next? It’s not gonna be Microsoft.
Chase Snyder (38:45.346): We’ve had Evan from Desired Effect on the podcast before. We note that there is, in fact, an anonymous brokered marketplace for buyers and sellers of such research.
Paul Asadoorian (39:02.018): Yeah, there’s very legitimate places to sell exploits or malicious tradecraft. And you’re right, Vlad. Microsoft is just forcing the researcher’s hand to go down those other paths. We had bug bounties as a path, responsible disclosure, coordinated disclosure. This is a case where it’s not a good situation for anyone.
Vlad Babkin (39:34.08): Most independent researchers right now are looking at Microsoft and like, “okay, should they report to them or should they go straight to the black market?” If I were an independent researcher and I had some Microsoft related stuff, and I had seen the whole story of Nightmare Eclipse, I would probably not go to Microsoft right now. Corporate guys like us—yeah, we can go through the company—but independent researchers… they probably have a pretty good question if they even should disclose something to Microsoft.
Paul Asadoorian (40:10.751): I’m sure independent researchers can also use US-CERT. I don’t know if it carries as much weight as a company. I really like working with CERT/CC or US-CERT. You create a VINCE ticket, and US-CERT helps you. We might have talked about this a little bit with the KVM disclosure. US-CERT will pull in all the responsible parties and broker that discussion. I like that process personally. My experiences have been very positive using US-CERT in the VINCE system. You get a chat, everyone can communicate, and folks from US-CERT actually help both parties get on the same page. Obviously, that doesn’t always work for every scenario. I don’t know if independent researchers know that exists.
Chase Snyder (41:34.604): You mentioned bug bounty programs and that makes me interested in how the current landscape and technology landscape is gonna change how bug bounties work. I think already some companies are getting rid of their bug bounty programs because AI fundamentally makes it just untenable for them to offer any sort of volume. They would either have to create way more restrictive rules around it or diminish the rewards.
Paul Asadoorian (41:53.323): Isn’t that crazy?
Paul Asadoorian (42:17.163): Yeah. I mean, hopefully bug bounties will evolve with time. One of the big indicators for me is my good friend Casey Ellis stepped down from Bugcrowd. To me, that was telling. I don’t think Casey or folks in that position would ever come out and say “bug bounties are dead.” I think you’re right, Chase. It’s gotta morph and change. I think there’s still value in having a bug bounty program. However, in my opinion, those programs will be more highly specialized, more along the lines of invite-only. Your mass discovery of vulnerabilities in your properties will be discovered by AI. If it’s my company, I’m gonna be like, “well, we’re gonna spend this much on AI and find our own bugs,” and bug bounty programs are gonna be a different beast and be more specialized.
Chase Snyder (43:29.484): Yeah, it’ll have to. This reminds me of something that we didn’t quite touch on on the Verizon DBIR report that was related to the volume of vulnerabilities and the pace of patching. Something that really stuck out to me was—they compared all their data going all the way back to 2020, and they noted that for a while patching timelines were on a positive trajectory. Critical vulnerabilities or vulnerabilities that were on the KEV (Known Exploited Vulnerabilities) were getting patched faster and faster. And then that peaked in 2024 and then has gotten substantially worse since then. And now from this report, they said that only 26% of critical vulnerabilities (those on the KEV) were fully remediated by organizations in 2025. A drop from the previous year’s 38%. So the ones that got remediated fully at all went down 12% over the past year. And the median time for resolution went up to 43 days from 32 days. So it’s taking longer and they’re getting less of them actually done over time. And part of that is due to just the sheer volume. The number of vulnerabilities represented across all of those breaches went up from 68.7 million in 2022 to 527 million in 2025. So in three years, the number 9xed or something.
Chase Snyder (45:56.15): It’s a totally unsustainable volume. Of course, companies can’t patch those. In this current report, only 12% of vulnerabilities were remediated before being added to the KEV, which means that the majority of vulnerabilities don’t get patched until they’re already known to be exploited. It’s getting worse on every front. And I think it’s gonna have to lead to a total transformation in how we approach that kind of defense or active defense.
Paul Asadoorian (47:09.207): Right. And it’s funny, we have three examples of this threat landscape trend. One is GreyNoise observed that once CVE-2026-0400 came out, which is a vulnerability in SonicWall, that was preceded by scanning. That backs up a couple of different points: one, network edge devices still are the target. Number two, they either know about the vulnerability before it’s disclosed and patched, or they’re just pre-scanning the internet knowing that someone’s gonna find and disclose a vulnerability. Maybe they’ve already got an exploit for it. Maybe someone found a vulnerability, did not disclose it to SonicWall, and used it to exploit a SonicWall device. I think the point is you’re already owned. And that’s scary today. GreyNoise is doing great work in pointing this out.
Chase Snyder (48:32.61): Yeah, they got a shout out in the DBIR. Good work. They became referenced in the report for their reporting on the ability to detect scanning in advance of the exploitation of a previously undisclosed vulnerability.
Paul Asadoorian (48:56.385): Yeah, and what do you do if there’s no patch? The recommendation from GreyNoise is to harden your devices. That’s one thing, but again we come back to that lack of visibility on these platforms.
Chase Snyder (49:13.708): It’s like the amount of friction that you have to introduce into your own environment to have really effective segmentation and access controls. Any of that stuff that you do adds friction for your own teams as well. And it’s really hard to strike that balance when there’s a spectrum of unknown vulnerabilities out there.
Paul Asadoorian (49:37.038): We need prevention. Yeah. We need prevention, but no matter how much prevention we try and put in place, someone’s still gonna get in. And so then we need detection. And that’s where a lack of visibility is killing us on these network edge devices—how do I go in and discover when there’s something that’s compromised my SonicWall device? That’s where we’re putting a lot of efforts here at Eclypsium to help on various platforms. The problem is there’s a lot of platforms and as Vlad knows, each one of those platforms is its own unique snowflake. Each product line has different ways the product can be deployed. It can be virtual, physical, or part of some hypervisor system. Navigating this and trying to give folks visibility into these devices is a huge challenge.
Chase Snyder (50:58.466): Yeah, 100%. This was like the central topic of this keynote that the Global CISO of JPMorgan Chase gave at RSA, this most recent RSA. Pat O’Pete—we’ve talked about him before probably—but he talked about the network vulnerability of network devices. He said in the presentation that they are now proactively reaching out to their device vendors twice a day to tell them about a vulnerability that they need them to fix. So who’s doing the threat research? It’s JPMorgan calling up the network vendors! But yeah, he said the devices we put on the edge of our network to separate us and create trust—the very devices that are supposed to be our frontline defense—are becoming our greatest weakness. He used this awesome phrase, “mean time to adapt.” He argued that the mean time to adapt those devices is on a potentially decade scale versus the speed of the attacker, which is on a daily scale. If you were to look inside of it, the level of old and busted, outdated underlying Linux and firmware and miscellaneous stuff in there—it’s an archaeological dig inside of these black box network devices.
Paul Asadoorian (52:49.568): Yeah, and every Linux is its own custom snowflake too, which makes it extremely difficult to have great visibility. F5 was also the latest target of campaigns. The article I have here says threat actors are exploiting end-of-life F5 BIG-IP appliances to gain unauthorized SSH access, using that to pivot into the Active Directory infrastructure. This article is pretty good. There’s also a link to Microsoft’s analysis. We get some IOCs (Indicators of Compromise). I really want to have better information sharing around this. I want the malware samples. Why are we just sharing the indicators? Can we also share the samples? ‘Cause that’d be super helpful too. And it would allow people to build better defenses. In F5, it’s just the latest example. In this one, though, it’s going after end-of-life appliances, which are a perfectly fine target because you can’t patch them. Make sure to read the Microsoft article on this topic.
Paul Asadoorian (54:55.168): I also had one—I don’t know which routers this campaign is targeting. It’s a company called Qiita. They identify the intrusion and noted the campaign reflects a clear strategic decision to target network infrastructure rather than individual computers. They tie it back to China and they give a bunch of IOCs. The malware that they analyzed is for Linux x86-64. So I don’t know what routers they’re targeting that are x86 based; typically they’re ARM. It’s like we’re always missing information. When we want information about a threat in IOCs, we seem to always be missing something. Can’t we just share all the things? I don’t get it.
Vlad Babkin (56:16.407): I understand if you don’t want to share them widely, but at the very least, there are companies like us who try to do defense against it and we are well known. It’s known that we’re not going to just publish this if you don’t want it.
Paul Asadoorian (56:29.524): Or use it maliciously, right? Maybe that’s why they don’t want to share the malware ’cause they don’t want other people using it maliciously, which I get, but there needs to be a better way to share without being public.
Vlad Babkin (56:42.061): Yep. If somebody knows of this, just contact us. We promise we will not tell on the podcast.
Paul Asadoorian (56:46.828): Please contact us. Yeah. I haven’t started reaching out to my network and asking people how we do this, but I will. And then I won’t be able to share any details on the show about how we’re getting malware samples, but you know, there’s that.
Paul Asadoorian (57:11.8): So yeah, this is just evidence that the threat landscape is tracking with what we’ve been saying. Covered a lot of ground. I thought we were actually going to be pressed for time, but we ended within the time marker. I want to thank Chase and Vlad for appearing on the show today. Thank everyone for listening and watching this edition of Below the Surface. That’ll conclude the show. We’ll see you next time.
Chase Snyder (57:28.332): Yeah. Really went places.“`
