**CPS supply chain security is an operational resilience issue**

Eclypsium | Supply Chain Security for the Modern Enterprisehttps://eclypsium.com/home/ Supply Chain Security for the Modern EnterpriseFri, 12 Jun 2026 22:03:20 +0000en-US hourly 1 https://wordpress.org/?v=6.9.4You Need to Verify the Hardware Supply Chain Behind Cyber-Physical Systemshttps://eclypsium.com/blog/cyber-physical-systems-security-hardware-supply-chain-trust/

Tue, 09 Jun 2026 13:00:00 +0000https://eclypsium.com/?p=16809Eclypsium was recently named in the Gartner® Hype Cycle™ for CPS Security, 2026 in the category of CPS Supply Chain Security. We view this recognition as further evidence that organizations are expanding how they think about cyber-physical systems security. CPS risk is not limited to industrial controllers, sensors, OT protocols, or production networks. Modern CPS […]

The post You Need to Verify the Hardware Supply Chain Behind Cyber-Physical Systems appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>Eclypsium was recently named in the Gartner® Hype Cycle™ for CPS Security, 2026 in the category of CPS Supply Chain Security.

We view this recognition as further evidence that organizations are expanding how they think about cyber-physical systems security. CPS risk is not limited to industrial controllers, sensors, OT protocols, or production networks. Modern CPS environments depend on a broad set of supporting infrastructure, including network devices, edge systems, remote access appliances, embedded firmware, supplier-provided components, and other hardware that traditional security tools often cannot fully validate.

In many cases, that infrastructure serves as the control plane that connects and supports physical operations. As the Hype Cycle states:

“CPS underpin safety-critical operations where cyber compromise can trigger physical,environmental and human harm. Supply chain weaknesses, such as counterfeit hardware, insecure firmware, hardcoded credentials and uncontrolled remote access, are individually dangerous and collectively create systemic risks. These and other exposures bypass perimeter defenses and persist across decades-long life cycles. CPS supply chain security is therefore foundational to operational resilience and integrity.“

CPS supply chain security is an operational resilience issue

Cyber-physical systems connect digital processes to physical outcomes. They support manufacturing operations, energy systems, water utilities, transportation networks, healthcare environments, smart buildings, and other systems where disruption can affect both operations and safety.

In these environments, supply chain security extends beyond procurement reviews, supplier questionnaires, and compliance assessments. CPS environments rely on hardware, firmware, software, services, and third-party components that often remain deployed for years. Vulnerabilities, misconfigurations, counterfeit components, unauthorized modifications, or insecure remote access paths can introduce risk that persists long after deployment.

The challenge is compounded by increasing connectivity. Systems that were once isolated now connect to enterprise networks, cloud platforms, remote support workflows, wireless infrastructure, and external supplier ecosystems. These connections improve operational efficiency and visibility, but they also expand the attack surface.

For security teams, the implication is straightforward: CPS supply chain security must be treated as a lifecycle discipline. Organizations need to understand what they acquire, verify what is deployed, monitor changes over time, and detect drift from approved device and firmware baselines.

Network infrastructure is part of the CPS attack surface

CPS environments depend heavily on network infrastructure. Routers, switches, firewalls, VPNs, wireless controllers, remote access systems, and edge devices provide the pathways that connect physical operations to users, vendors, applications, and data.

These devices occupy positions of trust. They route traffic, enforce segmentation policies, broker remote access, and connect IT, OT, cloud, and third-party environments. When compromised, they can provide attackers with persistence, visibility into communications, opportunities to manipulate traffic, and access to operational systems.

They are also among the most difficult assets to validate. Traditional endpoint security tools are designed for managed operating systems and applications, not firmware-centric infrastructure devices. Many network devices rely on specialized firmware and embedded operating environments that do not support standard EDR agents. Vulnerability scanners may identify exposed services or known CVEs, but they often cannot verify firmware integrity, inspect low-level components, or determine whether a device has been modified below the OS.

As a result, the infrastructure that supports CPS operations may also be the infrastructure security teams have the least visibility into.

Moving from supplier trust to infrastructure verification

Organizations have historically relied on assumptions of trust: trust that devices are authentic, trust that firmware is legitimate, trust that updates are valid, trust that configurations remain secure, and trust that suppliers maintain effective controls.

Those assumptions increasingly require verification.

CPS supply chain security depends on evidence. Security teams need to identify the devices operating in their environments, understand the hardware and firmware components those devices contain, verify firmware against known-good versions, monitor for unauthorized modifications, detect vulnerable or outdated components, and prioritize remediation based on operational exposure.

Organizations need a way to verify the infrastructure that supports modern enterprises and CPS environments.

Eclypsium provides visibility into hardware and firmware components across network devices, servers, endpoints, and other infrastructure systems that traditional security tools often cannot inspect directly. The platform helps teams establish known-good baselines, verify firmware integrity, detect drift, identify vulnerable or misconfigured components, and investigate signs of tampering or compromise below the OS. By validating underlying infrastructure rather than relying solely on version strings or OS-level signals, security teams gain evidence they can use to assess exposure and prioritize remediation.

For CPS environments, these capabilities matter because infrastructure compromise can have operational consequences. A compromised network device is more than an IT issue. It may provide access to production systems. A vulnerable remote access appliance can expose critical operational environments. An unauthorized firmware modification can undermine the trust assumptions that segmentation, monitoring, and incident response depend upon.

CPS security depends on infrastructure trust

Effective CPS security programs require visibility into industrial assets, operational processes, communications protocols, and safety requirements. They also require confidence in the infrastructure those systems depend on.

That means being able to answer questions such as:

What network and infrastructure devices support CPS operations?
What firmware and hardware components are running on those devices?
Do those components match approved and known-good baselines?
Are any components vulnerable, outdated, or modified?
Have device configurations drifted from approved standards?
Are unnecessary services, interfaces, or radios enabled?
Can device integrity be verified after procurement, after updates, and during ongoing operations?

Conventional IT and OT security tools often struggle to answer these questions because they lack visibility into the hardware and firmware layers. Addressing them requires the ability to inspect and validate infrastructure below the OS, where attackers increasingly seek persistence and evasion.

Recognition in a broader security shift

We believe Eclypsium’s inclusion as a Sample Vendor in Gartner’s Hype Cycle for CPS Security, 2026 reflects growing attention to a challenge many organizations are already confronting.

Cyber-physical systems depend on infrastructure that is distributed, supplier-driven, firmware-heavy, and often difficult to assess using traditional security tooling. Verifying the integrity of that infrastructure, from network devices and embedded firmware to hardware components and configuration state, is becoming a foundational part of operational resilience.

Protecting CPS environments is not only about securing the physical process. It also requires validating the infrastructure that connects, manages, updates, and supports those processes.

As organizations continue to connect operational environments with enterprise systems, cloud services, AI infrastructure, and remote support ecosystems, infrastructure verification becomes increasingly important. Security teams need the ability to verify what is deployed, detect unauthorized changes, monitor device and firmware posture, and prioritize remediation based on actual exposure.

Eclypsium was built to address that challenge by helping organizations establish trust in the hardware and firmware foundations of their infrastructure, from edge systems and network devices to servers and other critical assets that support CPS operations.

Assess Infrastructure Trust Across Your Environment

Discover how Eclypsium helps security teams verify firmware integrity, detect unauthorized modifications, identify vulnerable components, and establish trusted baselines across network devices, servers, endpoints, and other critical infrastructure.

Learn More About the Eclypsium Platform

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

GARTNER and HYPE CYCLE are trademarks of Gartner, Inc. and/or its affiliates.

Frequently Asked Questions

What is CPS supply chain security?+

CPS supply chain security focuses on validating the hardware, firmware, software, services, and third-party components that support cyber-physical systems. This includes not only industrial assets, but also the network devices, remote access systems, edge infrastructure, and embedded firmware that connect and manage physical operations.

Why does infrastructure trust matter for cyber-physical systems?+

Cyber-physical systems depend on infrastructure that routes traffic, enforces segmentation, enables remote access, and connects operational environments to enterprise systems, cloud services, and suppliers. If that infrastructure is compromised, attackers may gain persistence, visibility, or access to systems that affect physical operations.

What do traditional security tools miss in CPS environments?+

Many traditional IT and OT security tools focus on operating systems, applications, network traffic, or known vulnerabilities. They often cannot verify firmware integrity, inspect hardware-level components, or detect unauthorized modifications below the OS, where infrastructure compromise can persist.

How does firmware verification support CPS security?+

Firmware verification helps security teams determine whether device firmware matches known-good versions, whether components are vulnerable or outdated, and whether unauthorized changes have occurred. This gives teams evidence they can use to validate device and firmware posture across critical infrastructure.

What should organizations verify across CPS-supporting infrastructure?+

Organizations should identify the network and infrastructure devices that support CPS operations, validate hardware and firmware components, establish known-good baselines, monitor configuration drift, detect vulnerable components, and prioritize remediation based on operational exposure.

How does Eclypsium help with CPS supply chain security?+

Eclypsium helps organizations verify infrastructure trust across network devices, servers, endpoints, and other critical assets. The platform provides hardware-level visibility, validates firmware integrity, detects unauthorized modifications, identifies vulnerable components, and helps teams monitor drift from approved baselines over time.

]]>BTS #75 - Secure Boot Certificates Expiring: What You Need to Knowhttps://eclypsium.com/podcasts/bts-75-secure-boot-certificates-expiring-what-you-need-to-know/

Wed, 03 Jun 2026 17:59:12 +0000https://eclypsium.com/?p=16742Paul Asadoorian is joined by Chase Snyder and Vlad Babkin for a wide-ranging discussion on vulnerability exploitation, Secure Boot certificate expiration, BitLocker bypasses, and the growing pressure on network-edge infrastructure. The episode starts with the 2026 Verizon DBIR and its clearest signal: exploitation of vulnerabilities has moved ahead of credential abuse as a driver of breaches. For […]

The post BTS #75 - Secure Boot Certificates Expiring: What You Need to Know appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>

iframe

Paul Asadoorian is joined by Chase Snyder and Vlad Babkin for a wide-ranging discussion on vulnerability exploitation, Secure Boot certificate expiration, BitLocker bypasses, and the growing pressure on network-edge infrastructure.

The episode starts with the 2026 Verizon DBIR and its clearest signal: exploitation of vulnerabilities has moved ahead of credential abuse as a driver of breaches. For Paul, Chase, and Vlad, that trend reinforces a broader shift. Security teams are dealing with more vulnerability volume, more attacker automation, and more cases where traditional asset and vulnerability management miss the real exposure.

From there, the conversation moves into Secure Boot certificates, YellowKey, OpenPetya, SonicWall scanning, F5 BIG-IP compromise activity, and router-focused malware campaigns. The connecting thread is trust below the operating system: firmware, bootloaders, edge appliances, and infrastructure devices that defenders often depend on but cannot always inspect. For more on this infrastructure layer, see Eclypsium’s work on firmware security and network devices.

Key Topics Covered

The Verizon DBIR and the vulnerability exploitation trend: Chase highlights one of the most important findings from the 2026 DBIR: exploitation of vulnerabilities has overtaken credential abuse in the breach data. The discussion frames this as evidence that vulnerability management must become more precise, contextual, and defensive.
Why “defense is the new sexy”: Paul argues that security research remains important, but the harder problem now is applying better tools, automation, and intelligence to defense. The real challenge is not just finding bugs, but improving visibility, remediation, and detection before attackers arrive.
The reporting problem with prevention: Chase points out that preventive security is harder to measure than detection and response. EDR produces visible events, alerts, and dashboards; prevention often means proving that something did not happen, which is much harder to communicate to executives.
Network assets are becoming a larger breach category: The DBIR discussion turns to the rise in attacks against network assets and the decline in user-device targeting. That trend aligns with Eclypsium’s broader focus on securing network infrastructure, including VPNs, firewalls, routers, switches, and other edge devices.
AI is not the only reason vulnerability exploitation is rising: Vlad pushes back on the idea that AI alone explains the spike. He points to better attacker tooling, open-source templates, C2 frameworks, and maturing offensive infrastructure as contributors that predate the most recent AI wave.
Why version-based vulnerability management creates false confidence: Paul explains that knowing a device version is no longer enough. Some vulnerabilities depend on whether a feature is enabled, whether a configuration is exposed, or whether a custom Linux distribution actually incorporated a patch.
Container CVEs versus meaningful exposure: Vlad criticizes compliance-driven zero-CVE work that removes vulnerabilities from container images without improving the real attack surface. The team contrasts irrelevant package findings with reachable application bugs, vulnerable libraries, and unpatched devices elsewhere in the environment.
Secure Boot certificate expiration and operational risk: Paul walks through three Microsoft Secure Boot certificates expiring in 2026, including the KEK certificate and DB certificates used for Linux shim, third-party option ROMs, and Windows bootloaders. The conversation stresses that Secure Boot certificate updates require phased rollout, testing, and visibility into DBX revocation state.
Why DBX updates and KEK updates are separate problems: Updating the new Microsoft KEK is not the same as having a current DBX revocation list. Paul emphasizes that systems may remain exposed to bootkits if revocation data is stale, even if new certificates are present. Eclypsium has additional background on Secure Boot and DBX.
Option ROMs, hardware trust, and Secure Boot complexity: The team discusses how option ROMs allow hardware to provide code that UEFI can execute during boot. That design creates compatibility benefits, but it also raises questions about signed vulnerable code, hardware-based attacks, and the boundary between firmware and operating system controls.
Open Petya as a research project: Vlad, who is from Ukraine, reflects on NotPetya from personal experience and explains why an open research implementation inspired by Petya and NotPetya is interesting. Paul notes that the MBR focus feels historically useful, even if it may not map cleanly to modern boot environments. The project is available as OpenPetya.
YellowKey and the limits of BIOS passwords: Paul revisits YellowKey, the BitLocker bypass involving Windows Recovery Environment, and clarifies why an administrator password for BIOS setup does not mitigate the attack path.
Disclosure incentives and researcher trust: The takedown of the YellowKey researcher’s repositories leads to a broader discussion about coordinated disclosure, bug bounties, US-CERT/CERT/CC, and how heavy-handed responses can push independent researchers away from vendors and toward private exploit markets.
Bug bounties in the age of AI: Chase and Paul speculate that broad public bug bounty programs may need to change as AI increases submission volume. They expect more specialized, invite-only, or targeted programs while companies use automation to find more of their own issues.
F5, SonicWall, routers, and edge-device exploitation: The final section returns to network infrastructure. The team discusses scanning ahead of SonicWall vulnerability disclosure, exploitation of end-of-life F5 BIG-IP appliances, and router-focused malware campaigns. Eclypsium’s F5 coverage provides additional context for this class of risk.

Timestamps

00:00 Pre-show setup, streaming issues, and tools
02:10 Episode introduction: YellowKey, Secure Boot certificates, Verizon DBIR, Open Petya, F5, SonicWall, and edge routers
02:37 Welcome to Below the Surface episode 75
02:56 Eclypsium resources and episode framing
03:40 Verizon DBIR discussion begins
04:08 Chase on the DBIR and vulnerability exploitation surpassing credential abuse
05:31 Paul on AI, attacker tooling, and why defense needs renewed attention
07:15 Measuring prevention versus detection and response
08:20 The product and human-factor problem of making prevention reportable
09:47 Network asset breaches rise as user-device targeting declines
10:16 Vlad on attacker tooling beyond AI, including Nuclei, Nmap, and Sliver
12:11 Paul on false negatives in vulnerability and asset management
14:46 Kernel versions, custom Linux distributions, and unreliable patch assumptions
15:32 Vlad on container CVEs and compliance work that does not improve security
16:54 Paul on hardened containers, dependency risk, and poisoned library versions
18:21 Vlad on exploitability, library reachability, and input controls
20:24 Secure Boot certificate expiration discussion begins
21:00 Microsoft KEK CA 2011 expiration and DB/DBX update authorization
23:03 Microsoft UEFI CA 2011, Linux shim, option ROMs, and non-Windows bootloaders
27:03 Microsoft Windows Production PCA 2011 and Windows bootloader signing
28:37 Old hardware, emergency boot paths, and local signing considerations
29:22 DBX revocation updates and the risk of making systems unbootable
30:57 Planning, inventory, and phased rollout for certificate updates
33:05 Open Petya, NotPetya memories, and MBR-based research
35:42 YellowKey update and why BIOS administrator passwords do not mitigate the attack
37:08 Repository takedowns and the consequences for vulnerability disclosure
38:45 Exploit markets, bug bounties, and coordinated disclosure alternatives
41:34 How AI may change bug bounty programs
43:29 DBIR data on patching timelines, KEV remediation, and vulnerability volume
47:09 SonicWall scanning, GreyNoise observations, and pre-disclosure reconnaissance
49:37 Prevention, detection, and visibility gaps on network edge devices
50:58 Network devices as frontline defenses and long “mean time to adapt”
52:49 F5 BIG-IP appliances, end-of-life exposure, SSH access, and Active Directory pivots
54:55 Router-focused malware campaigns and incomplete IOC sharing
56:16 The need for better malware sample sharing among defenders
57:11 Closing thoughts

Links & References

Core References

Concepts & Frameworks

Secure Boot, DB, and DBX
CISA Known Exploited Vulnerabilities Catalog
Bootloaders, bootkits, and Secure Boot threat detection
Coordinated vulnerability disclosure
Mean time to adapt

Tools, Platforms & Organizations

About the Hosts / Guests

Paul Asadoorian hosts Below the Surface and leads the conversation across vulnerability research, Secure Boot, BitLocker, and network infrastructure risk.

Chase Snyder joins Paul for analysis of the Verizon DBIR, vulnerability exploitation trends, prevention metrics, patching data, and network-device risk.

Vlad Babkin joins the discussion with technical perspective on attacker tooling, Secure Boot, Linux and firmware complexity, container CVEs, NotPetya, and vulnerability disclosure incentives.

Connect

Below the Surface listeners can learn more about Eclypsium at eclypsium.com/go, including the Ultimate Guide to Supply Chain Security, an on-demand webinar on digital supply chain threats and risk, a paper on ransomware and the supply chain, a DigitalOcean customer case study, and product demo information.

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.“`

]]>Microsoft Secure Boot Certificates Expiring in 2026: Enterprise Impacthttps://eclypsium.com/blog/microsoft-secure-boot-certificates-expire-2026/

Tue, 02 Jun 2026 13:00:00 +0000https://eclypsium.com/?p=16715Three certificates expire, two UEFI stores are affected, and one permanent gap opens if you miss the deadline. You can use Eclypsium’s solution to identify these gaps that will inevitably affect your Windows fleet. Expiring Keys and Immediate Impacts On June 27, 2026, the Microsoft Corporation KEK CA 2011 expires. This is not a normal […]

The post Microsoft Secure Boot Certificates Expiring in 2026: Enterprise Impact appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>Three certificates expire, two UEFI stores are affected, and one permanent gap opens if you miss the deadline. You can use Eclypsium’s solution to identify these gaps that will inevitably affect your Windows fleet.

Expiring Keys and Immediate Impacts

On June 27, 2026, the Microsoft Corporation KEK CA 2011expires. This is not a normal certificate rotation as the key itself is expiring. Specifically, the KEK (Key Exchange Key) will reach expiration and is the credential that authorizes Windows Update to push new entries to your devices’ Secure Boot allow list (DB) and deny list (DBX). When that authorization pathway collapses, no new revocation can reach the device. For example, past revocations have added entries to the DBX for attacks such as BlackLotus and BootHole. Even with Secure Boot enabled, the system keeps booting, allowing attackers to deploy malicious software in the boot process.

Devices that have not been migrated to the 2023 certificate family before the deadline retain whatever DB and DBX state they had at the moment the KEK expires, and they hold that state forever, or until an OEM firmware update embeds the new certificates. Every future bootkit campaign targeting a known-revoked component will succeed on those devices because their DBX is frozen.

Microsoft is calling this transition an “act now” event. The fwupd project, NSA, Red Hat, Dell, and HP have all published guidance. The story you are not hearing enough is what this means operationally for the enterprises that have to actually execute it.

What Is Actually Expiring

There are actually three certificates expiring, two in June 2026 and one in October 2026, with three distinct functions:


Certificate	UEFI Store	Expires	What It Does	2023 Replacement
`Microsoft Corporation KEK CA 2011`	KEK	June 27, 2026	Authorizes every DB and DBX update Windows pushes via Windows Update	`Microsoft Corporation KEK CA 2023`
`Microsoft Corporation UEFI CA 2011`	DB	June 27, 2026	Signs Linux shim, third-party option ROMs, non-Windows bootloaders	Split into `Microsoft UEFI CA 2023`(OS bootloaders) and `Microsoft Option ROM UEFI CA 2023` (hardware option ROMs)
`Microsoft Windows Production PCA 2011`	DB	October 2026	Signs the Windows Boot Manager (`bootmgfw.efi`) and every Windows pre-OS component	`Windows UEFI CA 2023`

A point of confusion worth addressing up front: none of these are Platform Keys. The PK is the OEM-owned root of trust at the top of the Secure Boot hierarchy, and Microsoft does not control it on shipping hardware. Lenovo, Dell, HP, and Supermicro own their respective PKs. The 2026 expiration does not touch the PK. It also does not destroy the chain of trust. What it destroys is the ability to update the chain of trust through Windows Update.

The architectural change worth calling out is the split of the old monolithic Microsoft UEFI CA 2011 into two distinct 2023 certificates. One signs OS bootloaders (Linux shim). The other signs are third-party option ROMs (PCIe cards, NICs, GPUs, RAID controllers). The split is a real security improvement, as environments that have no business trusting arbitrary hardware vendor option ROMs can now exclude the option ROM CA without breaking the Linux shim. That option did not exist with the monolithic 2011 cert.

What This Means for Your Enterprise

For most security and IT teams, the practical questions are not about UEFI cryptography. They are about scope, exposure, and what breaks.

Every Windows device shipped since 2012 is affected. Windows 10 (from 1607), Windows 11, Windows Server 2012 through 2025, every LTSC release. If a system shipped with Windows or advertised Secure Boot compatibility, it has these certificates in its DB and KEK stores, and it needs to be migrated. The Copilot+ PCs released in 2025 are the exception: they shipped with the 2023 certificate family already provisioned.
Your Linux systems are part of this, too. Every modern Linux distribution that supports Secure Boot relies on the shim bootloader, and shim is signed by Microsoft Corporation UEFI CA 2011. When that cert is gone or revoked, the old shim stops verifying. Until the distribution publishes a shim re-signed against the 2023 CA, systems with only the 2023 DB entry and the 2011 entry removed will not boot. Red Hat has published RHEL-specific guidance. Debian, Ubuntu, Fedora, SUSE, and Arch are tracking the transition through their own release cycles.
Your virtualization infrastructure is also affected. Hyper-V, VMware ESXi, KVM/QEMU with OVMF, and Proxmox all maintain their virtual UEFI firmware separately from the host. Secure Boot-enabled VMs carry their own DB, DBX, and KEK state in OVMF or EDK2-based virtual firmware. Updating the host does not update the guest. Each VM needs its own certificate transition. In air-gapped environments where Windows Update is unavailable, this process must be performed manually for each virtual machine.
OEM coverage is uneven. For example, Dell PowerEdge 14th through 16th generation servers received the necessary BIOS updates by the end of 2025. Dell PowerEdge 12th- and 13th-generation systems will not receive them at all because they are end of service. Your asset inventory needs to identify those EOL platforms specifically, because they are the systems where Windows Update is the only delivery mechanism, with no firmware-level fallback if the certificate state is wiped.
The recovery scenario is dangerous. If a system loses its certificate state (motherboard RMA, CMOS clear, or some BIOS updates that revert to defaults) and the OEM never shipped a firmware update that embeds the 2023 certificates, the system can become unbootable. Microsoft provides C:\Windows\Boot\EFI\SecureBootRecovery.efi as a recovery mechanism, but users must know it exists. BitLocker sealed to PCR7 will demand its recovery key in this scenario. Have you tested this on a representative device? Most organizations have not.
Your existing tools cannot see this state. No conventional vulnerability scanner enumerates UEFI variable contents. No EDR product compares DBX entries against the UEFI Forum’s published revocation list. Most enterprises cannot answer the basic question: “Which devices in my fleet still have the 2011 KEK?” That visibility gap is the operational core of the problem, and it is what the NSA’s December 2025 UEFI Secure Boot guidance is trying to push enterprises to address.

The Threat Landscape Below the OS

The 2026 deadline arrives amid a measurable surge in research and exploitation of bootkits and firmware implants. The DBX exists specifically to revoke vulnerable boot components upon discovery. Recent vulnerabilities make the case for why DBX currency matters.

CVE-2020-10713 (BootHole, CVSS 8.2) . A buffer overflow in GRUB2 was originally discovered and disclosed by Eclypsium researchers Mickey Shkatov and Jesse Michael. Because GRUB2 is signed by the Microsoft UEFI CA and verified via the DB, virtually every Linux distribution is affected, as is every Windows device that trusts third-party UEFI components. Remediation depends on adding vulnerable GRUB2 signatures to the DBX. Without a valid KEK, no future BootHole-class remediation can be applied.
CVE-2023-24932 (BlackLotus, CVSS 6.7) . A Secure Boot bypass in Windows Boot Manager. The BlackLotus bootkit exploits this to replace the current boot manager with a signed-but-vulnerable older version, then loads unsigned kernel drivers, disables BitLocker and HVCI, and persists below the OS. Microsoft patched the underlying vulnerability in May 2023, but the patch alone is not enough. Administrators must manually trigger DBX revocations to blacklist the vulnerable boot managers. Devices with an expired KEK cannot accept future DBX additions, which means this vulnerability class is permanently exploitable on those systems.
CVE-2024-8105 (PKfail, CVSS 8.2 High) . Discovered by Binarly. A supply chain failure in which hundreds of OEM devices shipped with AMI test Platform Keys explicitly marked “DO NOT TRUST” were left in production firmware and eventually leaked on GitHub. Over 813 device models across Dell, Acer, Gigabyte, Intel, Supermicro, Lenovo, HP, and others are affected. An attacker with the leaked PK can sign malicious firmware and walk the entire PK → KEK → DB chain. PKfail is a reminder that the operational management of Secure Boot trust anchors is as important as the cryptography. The same is true for the 2026 transition.
Bombshell (Framework Secure Boot bypass) . In October 2025, Eclypsium researchers found that over 200,000 Framework laptops and desktops shipped with legitimately signed UEFI diagnostic shells containing a memory modify (mm) command. That command provides direct read and write access to system memory and can be used to overwrite the gSecurity2 UEFI variable (the pointer to the Security Architectural Protocol that performs LoadImage signature verification) with NULL. Secure Boot signature checks are silently disabled. Windows continues to report Secure Boot as enabled. Framework has issued firmware and DBX updates. Once again, the revocations are only useful on devices that can still accept DBX updates.

The pattern is clear. The threats live below the OS, where EDR cannot see them, where reinstalling Windows does not remove them, and where the only meaningful remediation is a DBX update. Lose the ability to receive DBX updates, and you lose the only remediation path for an entire class of attacks.

What Happens If You Miss the Deadline

Contrary to early panic reporting, devices do not stop booting on June 27, 2026. The already-installed 2011 certificates remain present in the firmware. The Windows Boot Manager continues to validate. Linux shim continues to load. What you lose is everything forward of that moment:

Secure Boot Updates cannot be installed. Windows Update that pushes a new trusted CA or revokes a compromised key would either be signed by a key after it has expired (and therefore should not be a valid signature) or be signed by the new CA that isn’t installed on the system (and therefore also invalid).
CVE-2023-24932 remediation is permanently incomplete. BlackLotus-class boot managers are still trusted on devices that never received the DBX entry.
Newer bootloaders are not trusted. Anything signed only against the new CA fails verification on devices that still have only the 2011 entries.
BitLocker hardening and boot-level integrity workflows degrade when they depend on updated Secure Boot trust entries.
Default-reset scenarios become high-risk. A motherboard swap, a CMOS clear, or certain BIOS updates can wipe the certificate state back to factory defaults. If the OEM never shipped a firmware update embedding the 2023 certificates, the device can become unbootable, requiring the SecureBootRecovery.efi process and a BitLocker recovery key.

The compounding factor is that the threat landscape does not freeze. As new bootkit vulnerabilities are discovered after June 2026, devices that were not migrated will face increased exposure. That exposure is irreversible without an OEM firmware update or manual recovery.

Remediation Paths

The path forward depends on the environment. Microsoft has announced a phased rollout through cumulative Windows Update cycles, but most organizations need to do more than just wait.

Consumer and Microsoft-managed devices

For devices receiving Windows Update with diagnostic data enabled, no manual action is required. Microsoft is using telemetry to group systems by OEM and firmware profile and is deploying the new certificates in waves. Status is visible in Windows Security → Device Security → Secure Boot.

Enterprise IT-managed devices (Intune, GPO, MECM)

The opt-in registry key tells Windows Update to proceed with the certificate transition:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot
Value: MicrosoftUpdateManagedOptIn
Type:  DWORD
Data:  0x5944

This triggers the deployment of the Windows UEFI CA 2023-signed Boot Manager. Distribute via Group Policy (Computer Configuration → Administrative Templates → Windows Components → Secure Boot), Intune (Microsoft has published a dedicated Settings Catalog profile), or Microsoft Configuration Manager (formerly SCCM).

Apply OEM firmware updates before applying Windows Update certificate changes. This is the single most important sequencing decision in the entire rollout. OEM BIOS updates embed the 2023 certificates in the firmware image itself. That gives you a durable recovery path if the certificate state is reset for any reason. If you only push the certificates through Windows Update without the OEM firmware update, a BIOS default reset wipes them. Dell PowerEdge 14th through 16th gen platforms have updates available. 12th and 13th-gen platforms will not. Identify EOL platforms specifically in your inventory.

Air-gapped and offline systems

Microsoft cannot reach these devices through Windows Update. Hyper-V and other virtualization environments must update their virtual UEFI variable stores independently from the host, using the SecureBootRecovery.efi mechanism or hypervisor-specific tooling. Microsoft has published offline deployment tooling at aka.ms/GetSecureBoot. For pure air-gapped environments, build a tested offline workflow now rather than waiting for the deadline.

Recovery

If a device fails to boot after a certificate transition (typically after a BIOS default reset), C:\Windows\Boot\EFI\SecureBootRecovery.efi adds the Windows UEFI CA 2023 certificate back to the DB. BitLocker sealed to PCR7 will demand its recovery key. Test this process on representative hardware before deploying broadly, especially on systems with BitLocker enforced via Group Policy and TPM with PCR7 sealing.

Linux and dual-boot

For dual-boot Windows and Linux systems, the Windows Update deployment will update the DB certificates that the Linux shim depends on. For pure Linux systems with no Windows installation, the distribution maintainers must publish shim binaries re-signed against Microsoft UEFI CA 2023. Verify your distribution has shipped that update before you remove the 2011 DB entry. The same applies to PXE network boot infrastructure: any boot images you serve must be re-signed against 2023 keys before the corresponding 2011 entries are revoked.

Operational Visibility at Scale

The remediation paths are well-documented. The operational problem is that most organizations cannot see the state of their UEFI variables to begin with.

Vulnerability scanners do not enumerate the contents of DB and DBX files. EDR agents do not inspect the KEK store. The Windows Security app surfaces a binary “Secure Boot is on” indicator that says nothing about which certificates are present, whether the DBX has current revocations, or whether the firmware-level and OS-level certificate state are aligned. Without that visibility, you cannot answer the questions that matter for this transition:

Which devices in my fleet still have the 2011 KEK and have not received the 2023 update?
Which devices have a DBX that is missing the BlackLotus, BootHole, or Bombshell-class entries?
Which devices have received the certificate update via Windows Update but not the corresponding OEM firmware update, leaving them exposed to a CMOS-reset failure mode?
Which devices report Secure Boot as enabled at the OS level but have firmware-level configuration that contradicts that claim, as Bombshell demonstrated?

Eclypsium’s platform was built to answer exactly these questions. It provides continuous visibility into PK, KEK, DB, and DBX state across the device fleet, including PCs, servers, network appliances, and cloud infrastructure. It monitors firmware against known-good baselines and detects when certificate stores or boot components change unexpectedly, including:

Detection of systems still on 2011 certs. Eclypsium’s product will detect devices that still have Microsoft Corporation KEK CA 2011, Microsoft Corporation UEFI CA 2011, or Microsoft Windows Production PCA 2011 in their UEFI variable state. Examples include:

Detection of the expiring Microsoft Corporation UEFI CA 2011 certificate in the DB that also affects Linux systems using Secure Boot.

Detection of the Microsoft Corporation KEK CA 2011 certificate set to expire in June 2026.

DBX comparison to the current revocation baseline. Eclypsium’s platform will compare each device’s DBX against the current published UEFI revocation list and flag missing entries (BlackLotus, BootHole, Bombshell, etc.). Example:

The broader context for this transition is the December 2025 NSA cybersecurity information sheet on UEFI Secure Boot, which makes the same observation: TPM presence and BitLocker enrollment do not imply correct Secure Boot configuration, and the vast majority of enterprise environments still run on outdated or default configurations. The 2026 deadline is the forcing function. Visibility determines whether you are forcing the transition or being forced by it.

Timeline and Action Checklist


Date	Event
2011	Original Microsoft Secure Boot certificate family issued
May 2023	CVE-2023-24932 (BlackLotus) patched; DBX revocations required
June 2025	Microsoft publishes a formal “Act Now” advisory
October 2025	Registry monitoring keys deployed; Bombshell (Framework UEFI shell) disclosed by Eclypsium
December 2025	NSA releases UEFI Secure Boot guidance; Eclypsium publishes operationalization guide
Early 2026	Microsoft begins phased certificate deployment via cumulative updates
June 27, 2026	KEK CA 2011 and UEFI CA 2011 expire
October 2026	Windows Production PCA 2011 expires

Pre-deadline checklist:

Audit Secure Boot status across the fleet at the UEFI variable level, not just OS reporting
Identify devices still on 2011 KEK, UEFI CA, or Windows Production PCA
Compare DBX state against the current Microsoft revocation baseline
Apply OEM BIOS firmware updates before applying Windows Update certificate changes
Set MicrosoftUpdateManagedOptIn registry key via GPO, Intune, or MECM
Identify EOL hardware that will not receive OEM updates and treat it as elevated risk
Test the certificate transition on representative hardware, especially BitLocker with PCR7 sealed systems
Update PXE boot images and network boot infrastructure to 2023-signed boot managers before pushing DBX revocations
For hypervisors, plan to update virtual machine EFI variable stores independently of host OS updates
For Linux environments, verify your distribution’s shim is signed by UEFI CA 2023 before removing the 2011 DB entry
For air-gapped environments, build and test an offline deployment procedure now

Frequently Asked Questions

Will my devices stop booting on June 27, 2026?+

No. The existing certificates do not vanish. Already-trusted components keep working. What stops is forward security.

Is the Platform Key affected?+

No. The PK is OEM-owned. Microsoft does not control it. The expiration does not touch it.

Can I ignore this if I run only Linux?+

No. Shim depends on Microsoft UEFI CA 2011. When that cert is revoked or removed without a 2023-signed shim, Secure Boot Linux stops booting.

Will Windows Update handle everything automatically?+

For most consumer and Microsoft-managed devices, yes. For enterprise, air-gapped, and OEM-EOL devices, no. Plan accordingly.

What is the worst-case scenario?+

A device misses the transition. The KEK expires. A bootkit drops with a known DBX entry. That device is permanently exposed because no revocation can reach it.

Why is the DBX so important?+

The DBX is the only mechanism for revoking vulnerable boot components in the field. Patches do not revoke. DBX entries do. No KEK, no DBX updates. No DBX updates, no bootkit remediation.

Are my virtual machines covered when I update the host?+

No. Each VM carries its own UEFI variable store. Update them independently.

What about devices behind air gaps?+

Use Microsoft’s offline tooling at aka.ms/GetSecureBoot. Build the workflow now, not in June.

Should I worry about PCR7 and BitLocker?+

Yes, if BitLocker is sealed to PCR7. Certificate changes will require the BitLocker recovery key on first boot. Have the keys ready and the process tested.

What is the single most important sequencing decision?+

Apply OEM firmware updates before applying Windows Update certificate changes. The OEM update embeds the new certificates in the firmware image itself, providing a durable recovery path if the certificate state is ever reset.

Sources and Further Reading

Microsoft documentation

NSA and government guidance

Eclypsium research

Vendor guidance

Technical analysis and community resources

Related vulnerabilities and research

]]>Device Trust and the 2027 DOW Zero Trust Deadlinehttps://eclypsium.com/events/device-trust-and-the-2027-dow-zero-trust-deadline/

Fri, 22 May 2026 16:33:04 +0000https://eclypsium.com/?p=16564The post Device Trust and the 2027 DOW Zero Trust Deadline appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>The post Device Trust and the 2027 DOW Zero Trust Deadline appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>DBIR 2026: Network Asset Breaches Up 3x as Vulnerability Exploitation Accelerateshttps://eclypsium.com/blog/verizon-dbir-2026/

Thu, 21 May 2026 16:50:36 +0000https://eclypsium.com/?p=16524The Verizon Data Breach Investigations Report remains one of the most useful annual sources for understanding how real-world breaches are changing. The 2026 report analyzes more than 31,000 security incidents, including more than 22,000 confirmed data breaches, and shows a clear shift in attacker focus: exploitation of vulnerabilities is now the leading known initial access […]

The post DBIR 2026: Network Asset Breaches Up 3x as Vulnerability Exploitation Accelerates appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>The Verizon Data Breach Investigations Report remains one of the most useful annual sources for understanding how real-world breaches are changing. The 2026 report analyzes more than 31,000 security incidents, including more than 22,000 confirmed data breaches, and shows a clear shift in attacker focus: exploitation of vulnerabilities is now the leading known initial access vector.

For security teams responsible for enterprise infrastructure, the most important finding is the growth in attacks involving network assets. Leading organizations are already feeling the pain, and sounding the alarm about this urgent threat. Pat Opet, Global CISO of JPMorganChase, gave a keynote about network edge risk at RSAC 2026. He summed it up perfectly:

“The devices that we put on the edge of our network…The very devices that are supposed to be our frontline defense are becoming our greatest weakness…All of this is due to the legacy architecture that exists in these opaque devices that are provided from network companies and security companies to defenders.”

Opet noted that half of the critical vulnerabilities addressed by JPMC in the last year were on perimeter devices.

Exploitation of Vulnerabilities Became the Leading Initial Access Vector

Last year, exploitation of vulnerabilities had nearly caught up with credential abuse. This year, it moved ahead.

According to the 2026 DBIR, exploitation of vulnerabilities is now the highest known initial access vector. That matters because exploitation puts direct pressure on teams that already struggle to identify, prioritize, and remediate exposed infrastructure before attackers act.

Network Asset Breaches Increased 3x Since 2025

Network assets have been under increasing pressure for years. In the 2026 DBIR, they reached roughly the same targeting frequency as user devices.

VPNs, firewalls, routers, and switches accounted for 1.5% of breaches in last year’s report and now account for 5%. Over the same period, user device targeting dropped from 8% to slightly below 5%. The DBIR notes that part of the increase reflects a change in how Verizon codes remote access cases, from Server to Network asset, but still characterizes the trend as a significant rise in targeting.

These devices often sit outside the coverage of traditional endpoint tools, yet they provide critical access paths into enterprise environments. Read Eclypsium’s report on Eradicating Hidden Risks in Network Edge Devices.

Vulnerability Volume Is Outpacing Patch Programs

Until 2025, defenders were making steady progress in remediating vulnerabilities faster. In 2025, that changed. The number of vulnerabilities in the DBIR dataset increased, while the percentage of CISA Known Exploited Vulnerabilities that organizations fully remediated declined.

From the report:

“Only 26% of critical vulnerabilities, defined as being in the Cybersecurity Infrastructure and Security Agency Known Exploited Vulnerabilities (CISA KEV) catalog, were fully remediated by organizations in 2025, a drop from the previous year’s 38%. The median time for full resolution went up to 43 days, almost two weeks more than the previous year’s 32 days. In the median case, organizations had 50% more critical vulnerabilities to patch in this year’s reporting dataset compared to the previous year.”

The trend is not just slower patching. Vulnerability volume is growing faster than remediation capacity. Instances of vulnerabilities in the DBIR dataset grew from 68.7 million records in 2022 to more than 527 million in 2025.

The gap between patching and exploitation is widening too. Only 12% of vulnerabilities were remediated before being added to the KEV, down from 17% in 2024. Attackers have more time to exploit known issues before defenders have prioritized and remediated them.

AI-Driven Vulnerability Discovery Is Increasing the Pressure

AI-assisted vulnerability research is adding more findings to an already overloaded remediation pipeline.

Anthropic’s Claude Mythos, a cybersecurity-focused model distributed to vetted partners through Project Glasswing, found 271 vulnerabilities in Firefox during internal testing with Mozilla. Microsoft is also on pace to exceed its annual record for vulnerabilities patched, with more than 500 addressed in the first five months of 2026. Microsoft has attributed part of that increase to AI-assisted analysis by internal teams and the broader security community.

The volume increase is unlikely to slow. NIST announced in April 2026 that it would stop enriching the majority of CVEs in the National Vulnerability Database, citing a 263% surge in submissions between 2020 and 2025. NIST will prioritize full enrichment for CVEs in the CISA KEV catalog, software used by the federal government, and software designated as critical under Executive Order 14028. Other CVEs may be labeled “Not Scheduled.”

That creates a triage problem. KEV is a critical source, but it is a floor, not a complete picture of exploited risk. Teams that relied on NVD enrichment now face more CVEs without CVSS scores or CPE mappings.

What This Means for Security Teams

The DBIR data describes a vulnerability management system under strain. Defenders are patching more vulnerability instances in absolute terms, but the number of vulnerabilities entering the pipeline is growing faster than process improvements can absorb.

For security teams, the priority is clear: focus on internet-facing network infrastructure, treat CISA KEV as a minimum baseline, and assume the window between disclosure and active exploitation is shorter than the current patch cycle.

Network assets now sit in the same targeting tier as user devices, but they often lack the same level of detection and verification coverage. Security teams need visibility into the firmware, hardware, and device posture of the infrastructure attackers are increasingly targeting.

Read Eclypsium’s Guide to Eradicating Hidden Threats In Network Edge Devices to learn how to proactively protect against this rapidly growing threat.

]]>YellowKey: The Unpatched BitLocker Bypass Hidden in Windows Recoveryhttps://eclypsium.com/blog/yellowkey-bitlocker-bypass-windows-recovery-environment/

Wed, 20 May 2026 18:00:00 +0000https://eclypsium.com/?p=16508A stolen Windows 11 laptop and a USB stick are enough to read a BitLocker-encrypted drive using nothing but Microsoft’s own recovery tools, and the researcher is holding back a follow-on attack that also defeats the startup PIN defenders are scrambling to enable in response. Updated 5/27/2026: Microsoft GitHub and Gitlab have both removed the […]

The post YellowKey: The Unpatched BitLocker Bypass Hidden in Windows Recovery appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>A stolen Windows 11 laptop and a USB stick are enough to read a BitLocker-encrypted drive using nothing but Microsoft’s own recovery tools, and the researcher is holding back a follow-on attack that also defeats the startup PIN defenders are scrambling to enable in response.

Updated 5/27/2026: Microsoft GitHub and Gitlab have both removed the accounts where the original YellowKey research was published. We have removed the links to those pages from this post.

Special thanks to Stas Lyakhov and John Loucaides for contributions

What is the vulnerability?

YellowKey is a BitLocker bypass disclosed in May 2026 by a researcher operating under the handle Chaotic Eclipse (Nightmare-Eclipse on GitHub), and it abuses behavior built into the Windows Recovery Environment to grant a fully unlocked command shell against drives that the operating system continues to treat as encrypted. The exploit primitive is the System Volume Information\FsTx directory that WinRE looks for on attached storage, because Windows will replay NTFS transaction logs found there during recovery boot, and the supplied logs delete winpeshl.ini, causing the recovery environment to fall back to spawning cmd.exe instead of the locked-down recovery UI. By the time the shell appears, the operating volume has already been transparently decrypted by the TPM, meaning the attacker inherits a fully readable filesystem with administrative tooling in hand. The researcher publicly frames this as backdoor-shaped behavior because the responsible component exists in WinRE with the exploitable functionality intact. In contrast, the equivalent component in the running Windows installation does not carry the same surface, and independent researchers, including Kevin Beaumont and Will Dormann, have publicly validated that the proof of concept behaves exactly as advertised.

Has it been patched?

At the time of disclosure, the issue was unpatched, and no CVE has been assigned. On May 19, 2025, Microsoft published recognition of the vulnerability with remediation guidance and issued CVE-2026-45585. Previously, only a generic statement about its commitment to coordinated disclosure, rather than a fix timeline, although the README credits MORSE, MSTIC, and Microsoft GHOST teams in a way that suggests at least some internal awareness before publication. Defenders should plan on the assumption that mitigation, not remediation, is the operating posture for the foreseeable future, as even after issuing a CVE, Microsoft has not issued a patch at the time of this publication.

What systems are affected?

The exploit affects Windows 11 across all builds tested by the researcher, as well as Windows Server 2022 and Windows Server 2025, while Windows 10 is reported as unaffected because the responsible WinRE component behaves differently in that codebase. The vulnerable filesystems on the attacker-supplied media include NTFS, FAT32, and exFAT, which removes any meaningful constraint on how the payload is staged.

How does the attack work, and what are the attack paths?

The attack requires physical access to the device, but the definition of physical access here is broader than most teams account for in their threat models, as the researcher demonstrated three distinct delivery paths that all lead to the same outcome. The first path is a USB stick prepared with the malicious FsTx folder inside System Volume Information, inserted into a running or powered-off target, with the attacker then forcing entry into WinRE via SHIFT+Restart followed by holding CTRL during reboot. The second path skips removable media entirely and writes the same payload directly to the EFI System Partition on the target’s internal disk, which is accessible to any user with administrative rights or any attacker with brief unattended console access through a recovery medium. The third path, and the one most relevant to evil-maid scenarios and lost-or-stolen-device assumptions, is simply to remove the storage device from the chassis, mount it on attacker-controlled hardware, write the payload to the EFI partition, and return the drive to the original system. Once any of these paths are complete and the system boots into WinRE, the NTFS log replay deletes winpeshl.ini, the recovery shell drops to cmd.exe, and the attacker now has interactive access to a volume that BitLocker still believes is protected.

The withheld PIN bypass changes the risk calculus

The public release defeats only the default TPM-only BitLocker configuration that ships on most consumer and many enterprise Windows 11 deployments, and TPM+PIN configurations are not exploitable by the published code because that mode requires user-supplied entropy at boot before the volume is unwrapped. The critical caveat defenders should not overlook is that the researcher explicitly stated they built and tested a variant that also neutralizes PIN protection and deliberately chose not to release it. That fact has two consequences worth internalizing. First, the threat model for any environment relying on TPM+PIN today should treat the PIN as raising the attacker’s cost rather than as an absolute control, because the underlying primitive is known to exist in working form in someone’s hands. Second, the timeline on which TPM+PIN remains an effective mitigation is bounded by whoever else independently rediscovers the same WinRE behavior or by the researcher’s future decision to publish, neither of which defenders control.

Recommendations for remediation

Organizations should consider the following remediation techniques:

Disable WinRE– Turning off the Windows Recovery Environment removes the attack outright (with some caveats; see the FAQ below) by eliminating the trusted recovery shell that YellowKey hijacks. However, it also removes the safety net that users and help desks rely on, which means no more F11 boot menu, no more “Reset this PC,” no more automatic startup repair after a failed update, and no more remote walk-through recovery option when the laptop cannot make it back to IT. For organizations with mature imaging and bare-metal recovery workflows, this is a reasonable trade-off. At the same time, a small business or a BYOD-heavy environment without that infrastructure should think hard before implementing it.
Microsoft has issued an advisory with new remediation instructions, including how to modify WinRE to remove the vulnerable functionality.
Enable a BitLocker startup PIN– Requiring a PIN at boot is the cleanest defense against the public bypass, and the cost is exactly what it sounds like, which is users typing a code every time the machine starts or wakes. This could result in a steady stream of helpdesk calls from people who forgot the PIN, and a real headache for the IT teams that rely on overnight reboots and remote wake-up for patching, because those machines now need a human in front of them to come back online. The control may be worth the friction in any environment where lost or stolen laptops are a realistic threat, and the rollout plan should include a self-service PIN reset workflow before the first user is enrolled, because without one, the helpdesk could pay the price.
Set a BIOS Password (a.ka. “BIOS Administrator Password”)– A BIOS or UEFI administrator password (Lenovo calls it “Supervisor Password,” Dell uses “Admin Password,” HP uses “BIOS Administrator Password”) puts the laptop’s pre-boot settings behind a lock, which prevents an attacker from changing the boot order and launching from their own USB removable media. This is not an effective mitigation for YellowKey, as the attacker is not required to change the boot order or boot from removable media. For YellowKey, an attacker must either alter the EFI partition on the current boot drive or insert a USB drive with the appropriate files. The attacker just needs to boot into WinRE, which can be done with keystrokes. Also note that a “BIOS Password” is different from a boot password (also referred to as a System or Storage password), which would require the user to enter a password before the system loads the bootloader. The NSA’s UEFI Lockdown guidance includes recommendations for these settings, such as avoiding system and storage passwords that could impact operations. Setting a “BIOS Password” is still a good security practice; however, the trade-off is that IT now owns a per-device secret that must be stored, rotated, and made available to whoever handles hardware repairs, firmware updates, and reimaging. If someone loses that password on a high-value device, it could become a paperweight (unless the vendor offers a recovery path).
Pros and cons of BIOS password as a defensive layer – Many OEMs continue to ship firmware with documented service codes, daily master passwords derived from displayed challenge strings, or trivial CMOS reset paths that allow a determined attacker with the chassis open to clear the supervisor password in well under an hour, and Eclypsium and others have published extensively on the inconsistent quality of BIOS password implementations across the vendor landscape. More importantly for the YellowKey scenario specifically, a BIOS password does nothing to prevent the attack, including the third attack path where the attacker simply pulls the drive, modifies the EFI partition on external hardware, and returns the drive to the chassis, because at no point in that workflow does the firmware password gate the storage. BIOS passwords should not be treated as a primary control against a motivated attacker who has the device in their possession overnight.
Monitor for the presence of “ System Volume Information\FsTx” directories – Monitoring can be applied to attached USB media and on the EFI System Partition through endpoint telemetry, since the directory has no legitimate reason to appear on those volumes outside of recovery scenarios, and treat its presence as a high-confidence indicator of staging or compromise.
Apply tamper-evident seals and physical-security controls to high-value laptops – For executives, engineers with code-signing keys, and any device storing regulated data, the realistic threat is not a movie-grade adversary but a laptop bag taken from an airport gate or a device left in a hotel room overnight. Tamper seals are cheap and let you know the device has been opened, and the companion policy controls (conditional access that requires a healthy device, remote attestation at sign-in, and short lifetimes on cached credentials and offline tokens) limit the value of anything an attacker extracts from the drive after they take physical possession, even in the case where they bypass BitLocker successfully.

Note: The above controls will likely not prevent the disk-removal path from being triggered on an unattended device.

Previous research on BitLocker bypasses

YellowKey does not arrive in a vacuum, and the value of treating it as a single news event rather than as the latest entry in a long-running research trajectory is exactly zero. The historical pattern should inform meaningful defensive decisions about BitLocker and how attackers have broken it across the last two decades. The list below presents the relevant prior works, in roughly chronological order, so that the trajectory becomes clear to anyone who has not been tracking it closely:

Cold boot attacks (Princeton, 2008) established the foundational observation that DRAM retains contents for seconds to minutes after power loss, and that an attacker with brief physical access could chill the modules, transplant them to attacker-controlled hardware, and recover BitLocker keys directly from memory, with the research published by J. Alex Halderman and colleagues remaining the canonical reference for why memory-resident key material is a persistent class of risk rather than a solved problem.
Windows 8 Secure Boot software bypass by Bulygin, Furtak, and Bazhaniuk (Black Hat USA 2013) – demonstrated that on platforms where the UEFI firmware in SPI flash and the EFI variable store in NVRAM were not adequately write-protected, a kernel-level attacker could corrupt a single bit of the Platform Key variable in NVRAM to force the firmware into SETUP_MODE at the next boot, which silently disables Secure Boot and allows a UEFI bootkit to install and persist beneath the operating system. The talk explicitly notes that TPM-based boot and full-disk encryption solutions, such as BitLocker, can be subverted by the same primitive because their boot-integrity measurements depend on Secure Boot being enforced in firmware rather than simply enabled in name. The talk also called out (NIST SP 800-147 BIOS Protection Guidelines and the Windows Hardware Certification UEFI Secure Boot requirements) are the same controls that still gate whether a 2026 Windows 11 laptop actually enforces the BitLocker measurements its TPM seals against.
DMA attacks via FireWire, Thunderbolt, and ExpressCard demonstrated across a decade of research that any host controller capable of issuing direct memory access reads against the running operating system could exfiltrate BitLocker keys from a locked but powered-on machine, with Björn Ruytenberg’s Thunderspy disclosures in 2020 confirming that the underlying class of attack remained viable on shipping hardware despite years of attempted mitigation through IOMMU and kernel DMA protection settings.
TPM bus sniffing by the Dolos Group (2021) showed that discrete TPM modules communicate the unwrapped Volume Master Key to the CPU over the LPC or SPI bus in plaintext during boot, and that a logic analyzer attached to the bus traces was sufficient to capture the key in under thirty minutes of physical access to a target laptop, with the published walkthrough establishing that TPM-only BitLocker on systems with discrete TPMs offered substantially weaker guarantees than the marketing implied.
Stacksmashing’s Raspberry Pi Pico TPM sniffer (2024) reduced the Dolos research to a four-dollar tool that captured BitLocker keys in roughly forty-three seconds using pogo pins on debug pads, removed the soldering requirement that had previously gated the attack to skilled hardware operators, and demonstrated on modern 2023 Windows 11 laptops that the underlying weakness had not been meaningfully addressed by vendor mitigations in the intervening three years.
CVE-2022-41099, the original WinRE BitLocker bypass, was a flaw in how the Windows Recovery Environment handled partition layout that allowed an attacker with physical access to bypass BitLocker on TPM-only configurations, with the itm4n blog publishing detailed analysis of the underlying root cause and Microsoft eventually shipping a PowerShell-script-based remediation (KB5025175) that required administrators to manually patch deployed WinRE images on every endpoint, an operational burden that resulted in widespread continued exposure long after the technical fix was available.
CVE-2023-21563, known publicly as bitpixie, was a Windows Boot Manager bug discovered by the researcher Rairii in 2022 and fully weaponized by Thomas Lambertz at Chaos Communication Congress 38C3 in late 2024 under the talk title “Windows BitLocker: Screwed without a Screwdriver,” exploiting a PXE soft reboot path where the bootloader failed to clear the Volume Master Key from RAM after a failed boot, allowing an attacker to load a Linux environment over network boot, scan memory for the FVE-FS metadata marker followed by the 03 20 01 00 VMK signature, and extract the key in approximately five minutes with no specialized hardware. Microsoft’s mitigation, KB5025885, replaced the vulnerable Microsoft Windows Production PCA 2011 certificate with a new Windows UEFI CA 2023 certificate to prevent downgrade attacks to the vulnerable boot manager, but the rollout required Secure Boot DBX updates that many organizations have not yet completed.
BitUnlocker (CVE-2025-48800, CVE-2025-48003, CVE-2025-48804, CVE-2025-48818) was a set of four WinRE zero-days disclosed by Microsoft’s own MORSE team in July 2025 and patched in that month’s Patch Tuesday cycle, exploiting weak validation and parsing logic in the recovery environment to allow arbitrary command execution, untrusted recovery image boot, and direct decryption of BitLocker volumes without authentication, with the vulnerabilities affecting the full supported Windows 10, Windows 11, and Windows Server 2016 through 2025 product range. BitUnlocker is the most direct ancestor of YellowKey in that both attacks weaponize the recovery environment rather than the cryptographic boundary, and the fact that two distinct WinRE-driven bypass families have surfaced within eleven months of each other is the signal worth focusing on.
BitUnlocker conference disclosure at 39C3 (Alon Leviev, December 2025) was the public technical walkthrough of the four July 2025 WinRE CVEs by the MORSE researcher who discovered them, with the Chaos Communication Congress presentation walking attendees through the WinRE architecture, the specific attack surfaces introduced by BitLocker recovery mechanisms, the research methodology used to surface the bugs, demonstration videos of each full-chain exploit, and an assessment of Microsoft’s hardening response, making it the definitive primary-source reference for understanding why WinRE has become the dominant BitLocker attack surface.
YellowKey (May 2026, this disclosure) Editorial note: Microsoft GitHub and Gitlab have removed the accounts of the researcher that disclosed this vulnerability, so we have removed links to those pages from this post.) continues the WinRE-as-bypass-primitive pattern, weaponizing NTFS transaction log replay against winpeshl.ini to drop the recovery shell to cmd.exe. The unreleased PIN-defeating variant claimed by the researcher should be read as a forward-looking indicator that the next entry in this list is already written and awaiting publication.

Every category of bypass that has been demonstrated remains operationally relevant on shipping Windows configurations; the mitigations are partial and operationally costly, and the trend over the past three years has been toward software-only attacks that require neither soldering nor specialized hardware. Treating BitLocker as a complete data-at-rest control without TPM+PIN, a UEFI/BIOS firmware password, tamper detection, and a working incident-response plan for stolen devices is no longer a defensible posture for any organization that has honestly reviewed the prior bypasses.

Frequently Asked Questions

Does this affect Linux, macOS, or anything other than Windows?+

No. YellowKey is a WinRE-specific bug. The primitive is NTFS transaction log replay inside the Windows Recovery Environment. Different OS, different problem.

Does Secure Boot stop the attack?+

No. Secure Boot validates what runs at boot. The attack happens after Secure Boot has already done its job. Trust chain intact. Drive unlocked anyway.

Does disabling WinRE mitigate this?+

Partially. Microsoft has documented how to remove or disable WinRE in managed fleets, which closes the published attack path. It also breaks legitimate recovery workflows. However, the researcher who discovered the vulnerability published this in a blog post: “a researcher (unsure if they want to be named) told me that this binary is also present in windows update WinRE images and I think they will definitely have the same vulnerability as well. However, I’m unsure if it’s possible to trigger the controlled file deletion when windows is updating. If it’s true, then it means disabling WinRE is not a solution for the problem”

Does Windows Hello, FIDO2, or biometrics help?+

No. Those protect the login. They do not protect the disk at rest. The attacker never logs in. The attacker reads the volume directly.

Is Microsoft’s BitLocker “Device Encryption” (the Home edition variant) affected?+

Yes. Same WinRE. Same primitive. Same outcome. Consumer Windows 11 users get the worst version of this story because TPM-only is the default, and most never set a PIN.

Can the attack be detected after the fact?+

Maybe, if you know where to look. The System Volume Information\FsTx directory on the EFI partition has no legitimate reason to exist there. Modified timestamps on winpeshl.ini in the WinRE image are another signal. However, if the attacker boots from removable USB media, these detections will not work.

Why didn’t Microsoft assign a CVE?+

Microsoft has historically treated attacks requiring physical access as out of scope for severity classification. That position has not aged well. YellowKey is exactly the kind of attack that breaks it.

The researcher seems sketchy. Is this actually real?+

Yes. Kevin Beaumont validated it. Will Dormann reverse-engineered the NTFS transaction mechanism and confirmed the root cause. The proof of concept works exactly as advertised. The handle is unusual. The bug is not.

Should I trust BitLocker at all going forward?+

Trust it for what it does. Distrust the marketing. BitLocker raises attacker cost. It is not a magic seal on your data. Layer it. Pair it with a PIN, a firmware password, and an incident-response plan for lost devices. That posture is defensible. Anything weaker is not.

Sources

]]>BTS #74 - YellowKey, CVE Enrichment, Chipmaker Breachhttps://eclypsium.com/podcasts/bts-74-yellowkey-cve-enrichment-chipmaker-breach/

Tue, 19 May 2026 18:25:53 +0000https://eclypsium.com/?p=16501Paul Asadoorian is joined by Chase Snyder and Vlad Babkin to discuss NVD’s new CVE enrichment model, the YellowKey BitLocker bypass, the Foxconn breach, and the continuing wave of package-manager supply chain attacks.Recorded: May 14, 2026 Welcome to episode 74 of Below the Surface. Paul Asadoorian, Chase Snyder, and Vlad Babkin start with a practical […]

The post BTS #74 - YellowKey, CVE Enrichment, Chipmaker Breach appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>

iframe

Paul Asadoorian is joined by Chase Snyder and Vlad Babkin to discuss NVD’s new CVE enrichment model, the YellowKey BitLocker bypass, the Foxconn breach, and the continuing wave of package-manager supply chain attacks.

Recorded: May 14, 2026

Welcome to episode 74 of Below the Surface. Paul Asadoorian, Chase Snyder, and Vlad Babkin start with a practical problem that keeps getting harder: how security teams are supposed to reason about vulnerabilities when the underlying data is incomplete, inconsistent, or delayed.

The conversation moves from NIST’s decision to prioritize enrichment for only certain CVEs into the messy realities of CVSS scoring, CPE data, CNA incentives, exploit indicators, and the engineering work required to turn vulnerability records into operational decisions. From there, the episode widens into several live security stories: YellowKey, a BitLocker bypass disclosed by Nightmare-Eclipse; the Foxconn ransomware breach and what it may mean for hardware supply chains; and the Mini Shai-Hulud campaign targeting npm and PyPI packages.

The throughline is trust. Trust in vulnerability records. Trust in firmware and device state. Trust in BitLocker’s recovery path. Trust in package managers and build systems. Trust in manufacturers that sit deep inside the technology supply chain. As the hosts point out, when the volume of vulnerabilities and supply chain compromises keeps growing, teams need better evidence, not just more alerts.

Key Topics Covered

NVD’s shift to prioritized enrichment: NIST is no longer treating every CVE as equally urgent for enrichment. The discussion explains why NVD will focus on CISA KEV entries, federal software, and critical software, and what that means for teams that have depended on NVD metadata for scoring, CPE mappings, and prioritization.
Why CVE records are uneven: Paul walks through the reality that CVE quality varies dramatically depending on the CNA, the vendor, and how much metadata is included. Some vendors provide useful CPE data; others omit it, making it harder to determine whether a vulnerable product is actually present.
The CPE problem: Vlad argues that CPE data is often either missing or filled out in ways that make it difficult to use reliably. This becomes especially painful for network appliances, where model names, version strings, and device-reported identity may not line up cleanly with vulnerability records.
CVSS scoring and vendor incentives: The hosts discuss why CNA-provided scores can differ from NVD scores, and why third-party scoring may sometimes produce a higher severity rating than the affected vendor. Paul explains his own strategy of using the highest available score when analyzing vulnerability data.
Exploit availability as a prioritization signal: The episode digs into how difficult it is to determine whether an exploit “exists.” A vulnerability may appear in CISA KEV, a GitHub proof of concept, a Metasploit module, a vendor advisory, or a loosely described technical writeup. Each source changes the prioritization picture.
CISA vulnerability enrichment: Paul highlights CISA’s vulnerability enrichment work as a useful supplement to NVD, especially when it adds signals such as exploitation status, automatable exploitation, and technical impact.
Why asset context matters: A critical Cisco vulnerability means different things depending on whether the affected product is a router, VPN client, SaaS product, or appliance. The group argues that vulnerability records need better ways to describe what kind of asset is affected and who inside an organization needs to act.
Configuration-dependent vulnerabilities: F5 and Arista examples come up as cases where a vulnerable version is not the whole story. A product may only be exploitable when a specific component or configuration is enabled, which forces defenders to read advisory details and translate them into actual checks.
AI and vulnerability volume: The hosts connect the growing use of AI in vulnerability research to the already overwhelming number of new CVEs. More discovery may be good for security in theory, but it creates operational pressure when enrichment, scoring, and detection logic cannot keep up.
YellowKey and BitLocker trust: Paul explains the YellowKey BitLocker bypass at a high level, including its relationship to Windows Recovery Environment, TPM behavior, and recovery workflows. The group also discusses whether the behavior looks like an engineering mistake, a forgotten workaround, or something more deliberate.
BIOS passwords as mitigation: Vlad and Paul unpack why applying a BIOS password may complicate the YellowKey attack but is not a universal answer. Device behavior, TPM state, CMOS reset behavior, and firmware implementation all affect whether that mitigation holds.
Foxconn and hardware supply chain risk: The reported Foxconn breach raises questions about what attackers might do with stolen schematics, topology data, or keys. The discussion connects the incident to digital supply chain security and the idea that organizations often depend on trust that is effectively rented from upstream manufacturers.
Ransomware and downstream exposure: The group notes that modern ransomware incidents are not just about encryption. Data theft, extortion, leaked technical files, and possible downstream compromise all matter, especially when the victim sits inside a major hardware manufacturing supply chain.
Mini Shai-Hulud and package-manager compromise: Vlad explains the worm-like pattern where compromised packages steal developer tokens, which are then used to publish more malicious packages. The attack spans npm and PyPI ecosystems and shows how package managers can become a delivery mechanism for credential theft.
Dependency delay and hash locking: A practical mitigation emerges: delay dependency updates long enough for malicious package versions to be discovered, and lock dependencies by hash where possible. Vlad points to tools such as npm lockfiles, Poetry, and uv as ways to reduce exposure to retagged or poisoned packages.

Timestamps

00:00 – Pre-show setup and webinar recap
01:25 – Episode introduction: NVD enrichment, YellowKey, npm compromise, and Foxconn
01:45 – Welcome to episode 74 with Paul Asadoorian, Chase Snyder, and Vlad Babkin
02:00 – Eclypsium resources and recap of the AI vulnerability research webinar
03:45 – NIST updates NVD operations in response to CVE growth
04:30 – What NVD will prioritize: CISA KEV, federal software, and critical software
05:40 – Paul’s CVE analysis tooling and why existing tools fell short
07:10 – NVD, MITRE CVE data, local databases, and exploit-source aggregation
09:30 – CVSS versions, CNA scoring, and why the highest score may matter operationally
10:30 – Fortinet, Cisco, Avanti, and inconsistent CPE data
11:00 – Vlad on why CPE precision is still not good enough
13:10 – OWASP Top 10, CVSS v4, and the difficulty of mixing scoring systems
15:10 – CISA vulnerability enrichment and exploitability indicators
17:30 – Why vendor-supplied CNA scores can understate practical risk
18:05 – CWE complexity and the need for simpler exploit-class summaries
19:25 – AI-driven vulnerability discovery and the coming pressure on vulnerability programs
20:30 – Why vulnerability records need better asset-type categorization
22:25 – SaaS, software, appliances, and routing the work to the right team
23:05 – Vlad on CWE, CPE, version comparison, and vendor cooperation
24:25 – Component-specific vulnerabilities and configuration-dependent exposure
27:20 – YellowKey: BitLocker bypass without a CVE
28:30 – Researcher disclosure friction and the Microsoft vulnerability process
29:20 – Windows Recovery Environment, TPM behavior, and the YellowKey technique
30:45 – Is YellowKey a bug, a workaround, or a backdoor?
32:10 – KVMs, BMCs, and physical-access-adjacent attack scenarios
35:20 – Windows 10, Windows 11, and questions about future fixes
36:15 – BIOS passwords, SPI flash swaps, and mitigation limits
39:10 – Foxconn breach and ransomware impact
41:25 – Hardware supply chain sovereignty and “rented trust”
43:25 – Schematics, keys, and what attackers might find in stolen manufacturing data
45:10 – The challenge of analyzing large stolen datasets
47:30 – Mini Shai-Hulud and package-manager supply chain compromise
48:05 – How token theft lets package compromise spread
49:00 – Delaying dependency updates as a defensive control
49:55 – Lockfiles, hashes, Poetry, uv, and npm package integrity
50:55 – SBOMs and checking fleets after package compromise
51:15 – Russian language checks, Digital Scarecrow, and malware deception
53:40 – Destructive malware routines targeting Israel or Iran environments
55:50 – Closing thoughts

Links & References

Core References

NIST update on NVD operations – The NIST announcement discussed in the episode.
CISA Known Exploited Vulnerabilities Catalog – One of the prioritization signals discussed around NVD enrichment.
CISA Vulnerability Enrichment – The enrichment project Paul references as a useful source of additional vulnerability context.
MITRE CVE – The core CVE database discussed in relation to NVD and CNA records.
Common Weakness Enumeration – The CWE system discussed during the section on exploit classes and vulnerability categorization.
Common Platform Enumeration – The CPE data source discussed throughout the vulnerability-management section.

Vulnerabilities, Incidents & Research

YellowKey GitHub repository – The BitLocker bypass proof of concept discussed in the episode.
BleepingComputer coverage of YellowKey – Coverage of the BitLocker bypass and related GreenPlasma issue.
Eclypsium: One Bootloader to Load Them All – Related Eclypsium material on bootloaders, TPM measurements, BitLocker, and Secure Boot.
MacRumors coverage of the Foxconn incident – Coverage of the reported Foxconn breach and alleged Apple-related files.
AppleInsider follow-up on Foxconn and Apple server schematics – Follow-up reporting on files allegedly exposed in the Foxconn incident.
BleepingComputer coverage of Shai-Hulud package compromise – Coverage of compromised npm and PyPI packages.
The Hacker News coverage of Mini Shai-Hulud – Coverage of the campaign’s spread through package ecosystems.

Eclypsium Resources Mentioned or Relevant

Eclypsium Firmware Security – Related to the episode’s discussion of firmware, TPMs, boot integrity, and below-the-OS trust.
Eclypsium for Network Devices – Relevant to the discussion of routers, switches, network appliances, and edge-device vulnerability exposure.
Eclypsium Digital Supply Chain Security – Relevant to the Foxconn and package-manager supply chain sections.
Ransomware and the Supply Chain – Related to the discussion of double extortion, data theft, and downstream supplier risk.
Eclypsium Supply Chain Security Toolkit – The resource hub Paul mentions at the beginning of the episode.
Eclypsium Go – The page Paul points listeners to for Eclypsium resources and demos.

Tools & Platforms

Metasploit – Mentioned as one of Paul’s exploit-data sources.
GitHub – Referenced as a source of proof-of-concept exploit information and package compromise activity.
npm – Discussed as a package ecosystem affected by Mini Shai-Hulud.
PyPI – Discussed as another affected package ecosystem.
Poetry – Mentioned by Vlad as a Python dependency-management option that can help with lockfiles and hashes.
uv – Mentioned as a more modern Python package-management option.
TruffleHog – Mentioned as a tool for finding secrets in large datasets.

About the Hosts

Paul Asadoorian hosts Below the Surface and guides the episode’s discussion across vulnerability data, exploitability, disclosure, and supply chain security.

Chase Snyder joins the conversation with a focus on vulnerability management, supply chain risk, and the broader implications of hardware manufacturing dependencies.

Vlad Babkin contributes technical analysis on CPE data, package-manager compromise, BitLocker mitigation questions, and the operational difficulty of validating device and dependency state.

Connect

Learn more about Eclypsium and related resources at eclypsium.com/go.

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.

]]>BTS #73 - Uncovering Firmware Risks: From Y2K to Modern Malwarehttps://eclypsium.com/podcasts/bts-73-uncovering-firmware-risks-from-y2k-to-modern-malware/

Thu, 07 May 2026 17:41:09 +0000https://eclypsium.com/?p=16394In this episode of Below the Surface, host Paul Asadoorian is joined by Chase Snyder and Brian Richardson for a conversation that moves from 1990s BIOS malware to modern network-edge compromise. Brian returns to the show in a new role as an Eclypsium employee, bringing a career that spans firmware development, sales engineering, firmware evangelism […]

The post BTS #73 - Uncovering Firmware Risks: From Y2K to Modern Malware appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>

iframe

In this episode of Below the Surface, host Paul Asadoorian is joined by Chase Snyder and Brian Richardson for a conversation that moves from 1990s BIOS malware to modern network-edge compromise. Brian returns to the show in a new role as an Eclypsium employee, bringing a career that spans firmware development, sales engineering, firmware evangelism at Intel, and early BIOS work at AMI.

The episode’s throughline is simple: the systems beneath the operating system have always mattered, but defenders have not always had the tools or habits to inspect them. Brian’s story about discovering CIH, also known as the Chernobyl virus, leads into a broader discussion of firmware protections, manufacturing defaults, flash descriptor lockdowns, and why mistakes in low-level configuration can still create risk decades later.

From there, the discussion turns to today’s network edge. Paul and Chase unpack FIRESTARTER, ArcaneDoor, Cisco ASA and FTD devices, LINA process hooking, and why firewalls and VPN appliances need to be treated as assets that require their own security controls. The episode closes with a discussion of Mythos, Anthropic, and the tension between AI-assisted vulnerability discovery and government reliance on commercial AI models.

Key Topics Covered

Brian Richardson’s path to Eclypsium: Brian explains how his career moved from firmware development to sales engineering and firmware evangelism at Intel before joining Eclypsium, where his background in firmware and security comes together.
The BIOS and Y2K connection: Brian revisits his early AMI work during the Y2K era, when BIOS updates, release processes, and low-level system behavior were all part of the same operational problem.
Finding CIH in the wild: The team discusses how Brian noticed mismatched executable files during BIOS release work and helped identify CIH before antivirus tools of the time had caught up.
Why CIH mattered: CIH was not just another file infector. It could overwrite the boot block on certain systems, creating a recovery problem that often required physical access to the flash chip.
The firmware protection problem: The episode connects old BIOS write-protect jumpers to modern firmware security challenges, including how systems need to be open enough for manufacturers to develop and debug, but locked down before they ship.
Reference designs and inherited risk: Brian explains how motherboard reference designs could be copied by ODMs, including design choices that were convenient for updates but dangerous if attackers learned how to manipulate them.
Manufacturing mode and platform defaults: Paul draws a line between early BIOS protection issues and today’s manufacturing mode problems, where OEMs must remember to lock down debug and update capabilities before production.
SPI flash, descriptors, and layered protections: The group discusses why protecting modern UEFI firmware is not a single setting. Flash descriptors, boot blocks, Intel ME/CSME, AMD PSP, option ROMs, and other regions can all introduce complexity.
Firmware updates as an ongoing risk surface: Brian emphasizes that firmware security is not a one-time shipping milestone. Systems receive updates for years, and a later update can accidentally undo a previously correct protection.
Bootkits, ransomware, and recovery risk: Paul connects firmware and bootloader compromise to destructive malware scenarios, including cases where ransomware can accidentally encrypt the ESP partition and prevent its own ransom message from appearing.
Why network appliances are now front-line targets: Chase explains that network devices and security appliances are increasingly targeted because they are exposed, valuable, and often opaque to defenders.
The firewall does not secure itself: The hosts challenge the assumption that firewalls and VPN appliances are inherently trustworthy because they are security products. As Chase puts it, defenders need to ask what they are doing to secure the firewall itself.
FIRESTARTER and the LINA process: Paul breaks down FIRESTARTER, explaining why hooking LINA on Cisco ASA and FTD devices is so significant: LINA is where core firewall and VPN functionality lives.
ArcaneDoor and related malware families: The episode maps the surrounding terminology, including ArcaneDoor, Line Dancer, Line Runner, Ray Initiator, Line Viper, and FIRESTARTER, showing how campaigns, threat actors, and malware names can quickly become confusing.
The operational cost of remediation: FIRESTARTER’s persistence creates a practical problem: soft reboots and patching may not be enough. Paul explains why physical power-off procedures and forensic validation may be required to fully clear affected systems.
Predictive scanning signals: Chase and Paul discuss GrayNoise reporting that showed major scanning spikes against Cisco ASA devices before public disclosure of related attacks, reinforcing the idea that reconnaissance often precedes known vulnerability disclosure.
Info stealers and vulnerability knowledge: Paul raises concern that large-scale data theft may include sensitive vulnerability or exploit information, giving attackers insight before defenders understand what has been exposed.
Mythos, Anthropic, and AI vulnerability discovery: Brian and Chase close by discussing Mythos, a source-level vulnerability discovery tool associated with Anthropic, and the tension between expanding commercial access and government dependence on AI models.

Timestamps

00:00 – Pre-show setup and episode teaser

00:51 – Welcome to Below the Surface episode 73

01:06 – Brian Richardson returns as an Eclypsium employee

01:28 – Eclypsium resources and supply chain security materials

02:20 – Brian’s path from Intel to Eclypsium

03:47 – Y2K, BIOS history, and early firmware work

04:23 – BIOS release processes in the late 1990s

05:33 – Discovering suspicious file mismatches

06:02 – CIH appears in executable free space

07:20 – How the CIH payload attached to executables

08:00 – CIH and its BIOS-level payload

09:08 – Flash ROM, boot blocks, and the Chernobyl name

10:12 – Physical jumpers and BIOS write protection

11:00 – Intel reference boards and copied design choices

12:54 – Why “this couldn’t happen today” is too simple

13:09 – Manufacturing mode and platform lockdown

14:10 – OEM defaults and “to be filled in by OEM” strings

14:37 – ChIPsec, boot guard, secure boot, and firmware checks

15:01 – SPI flash descriptors and layered protections

15:44 – Modern systems that are still not fully locked down

16:41 – Intel ME/CSME, disabling components, and hardware access

17:47 – Firmware security as continuous monitoring

18:58 – Bootkits, ransomware, ESP partitions, and recovery

20:16 – CIH as destructive proof-of-concept

21:14 – Targeted payloads against high-value systems

22:32 – Ransomware bugs and destructive side effects

24:22 – Physical recovery, SPI clips, and hardware handling

25:51 – FIRESTARTER and Cisco ASA/FTD targeting

26:50 – Network appliances as the new attack front

27:47 – Why security appliances are often opaque to defenders

28:21 – The firewall-does-not-secure-itself problem

29:13 – ASA, FTD, Linux internals, and limited manageability

31:25 – ArcaneDoor, Line Dancer, Line Runner, and FIRESTARTER taxonomy

33:24 – Why hooking LINA matters for VPN credential theft

35:21 – Cisco product history and the scale of the installed base

36:04 – Management planes and the complexity of multi-vendor environments

37:17 – Firmware management and the difficulty of staying current

38:02 – Enterprise migration friction and platform lock-in

39:52 – FIRESTARTER persistence and why power-off matters

41:13 – Why appliance reboots may not clear all persistence

43:02 – GrayNoise, scanning spikes, and vulnerability timing

43:31 – Zero-day exploitation and network-edge patch timelines

46:43 – Info stealers, data dumps, and vulnerability exposure

48:24 – F5 breach, key rotation, and cautious remediation

49:14 – Defending network edge devices

49:44 – Mythos, Anthropic, and AI-assisted exploit discovery

51:15 – Government reliance on Anthropic models

53:11 – AI supply chain risk and government system dependence

54:45 – Closing discussion and sign-off

Links & References

Core References

Eclypsium Supply Chain Security Toolkit – Mentioned by Paul as a resource for listeners, including the Ultimate Guide to Supply Chain Security, an on-demand webinar, a ransomware and supply chain paper, and a DigitalOcean customer case study.
Ransomware and the Supply Chain – Referenced in the episode announcement as part of the Eclypsium resource set.
FIRESTARTER: The Cisco Firewall Backdoor That Survives Reboots, Patches, and Your Incident Response Plan – Relevant Eclypsium research on the FIRESTARTER malware discussed in the episode.
Defending Against ArcaneDoor: How Eclypsium Protects Network Devices – Relevant background on ArcaneDoor and Cisco ASA device targeting.
Are Cisco ASA Devices About To Be Attacked? – Paul references Eclypsium and GrayNoise work around Cisco ASA scanning activity.

Concepts & Technical References

CIH / Chernobyl virus – Historical malware discussed by Brian, including its executable infection behavior and destructive BIOS payload.
BIOS and UEFI – The episode contrasts legacy BIOS-era attacks with modern UEFI firmware protections and boot processes.
SPI flash and flash descriptors – Discussed as part of modern firmware protection and misconfiguration risk.
Boot block protection – Central to the CIH discussion and modern firmware integrity controls.
Intel ME / CSME and AMD PSP – Mentioned as components that may share firmware storage regions with UEFI/BIOS code.
ESP partition – Discussed in Paul’s ransomware forensics example involving bootloader encryption.
Cisco ASA and Cisco FTD – The primary network security appliance families discussed in relation to FIRESTARTER and ArcaneDoor.
LINA – The Cisco ASA/FTD process Paul describes as responsible for firewall and VPN functionality.
GrayNoise – Referenced in the discussion of scanning signals and possible early indicators of future network-device exploitation.
Mythos – Discussed as an AI-assisted source-level vulnerability discovery tool associated with Anthropic.
Anthropic and Claude – Discussed in relation to Mythos, government use of AI models, and vulnerability discovery workflows.

Malware, Campaigns, and Threat Activity

ArcaneDoor – Described as a campaign name associated with targeting Cisco ASA and other edge devices.
UAT4356 / Storm-1849 – Threat actor naming referenced by Paul in relation to ArcaneDoor activity.
Line Dancer – Described as an in-memory shellcode loader.
Line Runner – Described as a persistent HTTP Lua implant on ASA devices.
Ray Initiator – Described as a multi-stage bootkit.
Line Viper – Described as a user-mode shellcode loader and post-exploitation implant.
FIRESTARTER – Described as a Linux backdoor that hooks LINA for long-term persistence.
HybridPetya / NotPetya – Mentioned in the broader discussion of bootkits, destructive malware, and bootloader-level impact.
UNC3886 – Referenced as a group associated with similar patterns of network device targeting and credential collection.

About the Hosts and Guest

Paul Asadoorian is the host of Below the Surface. In this episode, he leads the discussion across firmware history, Cisco ASA/FTD targeting, ransomware recovery, and network-edge security.

Chase Snyder joins as co-host and contributes analysis on network appliances, security product assumptions, vulnerability exploitation timelines, and the operational challenge of defending firewalls and VPNs.

Brian Richardson is an Eclypsium employee and returning guest on Below the Surface. His background includes firmware development, sales engineering, firmware evangelism at Intel, TianoCore community work, ChIPsec promotion, and early BIOS development work at AMI.

Connect

Eclypsium: eclypsium.com

Eclypsium resources for listeners: eclypsium.com/go

Transcript

Paul Asadoorian (00:51.999): Welcome to Below the Surface. This is episode number 73, being recorded on April 30th, 2026. I’m your host, Paul Asadoorian, joined by Mr. Chase Snyder. Chase, welcome.

Chase Snyder (01:04.45): Hey Paul, always a joy.

Paul Asadoorian (01:06.795): Returning guest who’s now an employee, Mr. Brian Richardson is here with us making his second appearance on Below the Surface, but his first time as an Eclypsium employee.

Brian Richardson (01:17.884): Yep. Yeah, that was episode like seven or something. That was single-digit stuff. Yeah. So I am your stunt Vlad today.

Chase Snyder (01:28.824): We got him, folks.

Paul Asadoorian (01:28.824): Yes, Vlad couldn’t join us, unfortunately, but we’re gonna party without him and hopefully he can make it next time. Just a quick announcement, Below the Surface listeners can learn more about Eclypsium by visiting Eclypsium.com/go. You can find on that site the ultimate guide to supply chain security. Also 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. Of course, if you’re interested in seeing our product in action, you can do that and more at Eclypsium.com/go.

Paul Asadoorian (01:50.717): Alrighty, I am excited for this episode. We got three succinct topics. I like it, although we’ll probably branch off into other things as we sometimes do. You’ll get me started talking about my new Tesla. I know that happens. We go off on tangents.

Brian Richardson (02:16.594): Really? That happens?

Paul Asadoorian (02:20.555): Brian, well I want to start with Brian. Obviously we already mentioned that you transitioned from Intel to Eclypsium, but tell us about how that came to be and what you do here at Eclypsium for our audience.

Brian Richardson (02:29.33): Yeah, so when we last spoke, I was doing firmware evangelism at Intel. I think at the time I was still the TianoCore community manager. And for a while I was also doing some promotion of Chipsec, which is actually where I ran into the people that are now my corporate overlords. I mean, very, very competent managers at Eclypsium. And I’ve kind of took the journey from firmware developer to sales engineer to firmware evangelist over the path of my career. And I, like many people, graduated from Intel back in the summer of 2025. And fortunately Eclypsium for me is literally like right up the road. And it’s kind of a weird skill set mashup of like all the stuff you do with firmware. And for a while I was doing security marketing at Intel. So this is kind of like a weird intersection of all the things and it takes me back in time.

Brian Richardson (02:57.364): You know, do the shimmering effect in post, Paul. I don’t think you can do that as part of the live, but when I was a baby AMI developer, I started out at AMI, Prestolite Intersetup. And actually, if you look me up on YouTube, I have a talk on Y2K. So that gives you kind of a time when I was in the, yeah. So I, yeah, I shaved.

Paul Asadoorian (03:47.551): Now you have to explain for our younger audience that was born after the year 2000 what Y2K was.

Brian Richardson (03:56.123): I actually had to do that. So I’ve actually given a Nerd Night talk twice now on the history of Y2K, why it relates to the BIOS, how it dates back to the reverse engineering of the original PC BIOS. And if that wasn’t haunting enough, we could probably throw the link in the show notes, I don’t know. I censored most of the bad words out of it except for the four-letter word BIOS, which comes up quite a lot in that program. But back when I was a baby as of 1999, while we’re all trying to fix this Y2K nonsense, one of the functions I had at AMI when I was a BIOS developer is also release coordinator. So that means like when we at AMI would develop a BIOS package for a customer, we would typically do like periodic releases. And so we’d put everything in source control and then package it up.

Brian Richardson (04:23.252): Back in the day, this was like, we would send you a link to a zip file or like an FTP or something archaic. Like it wasn’t quite gopher, but it was somewhere in that sort of like, if we did that today, you know, that kind of level of file security, we might end up in court. But back then FTP with a password was the gold standard. And I started noticing that the releases weren’t matching. We had a pretty decent release process where we would build locally and then we would check everything in and then check it back out and do bit compares. Now this is before UEFI. This is back when BIOS was 16-bit nonsense and we were doing stuff like just blindly yeeting to the MBR on the hard drive. And the hard drive made the spin emotion.

Paul Asadoorian (05:25.173): I feel like you’re gonna talk about how you noticed a Tencent accounting error. That’s what it feels like, right?

Brian Richardson (05:33.127): It’s pretty close to that. I noticed that the files didn’t compare. This isn’t quite like Superman III level accounting, but another dated reference. Anyway, basically I’m like, hey, these files don’t match up. And I was talking to one of the QA engineers, he’s like, I’m seeing the same thing. And so this is when we started noticing that we were finding a virus, as they say, in the wild. In other words, we had picked up a virus before any of the EDR scanners of the day had found it.

Brian Richardson (06:02.548): So we started noticing a pattern across this that it had a header and the header always said CIH and had a version number and that was popping up in the free space of an executable. So we’re a Windows DOS house. 1999, so this is like spring of 1999. The reason we were early on the case is because one of our engineers from Taiwan who was now like a vice president at a software company, he shall remain nameless—it wasn’t his fault really, but like he had brought his laptop from Taiwan and at some point he had gotten it on his laptop and brought it into the company firewall. Back when you could get viruses by like actually sitting next to the notebook and putting it on your physical network, not just like, “I got owned through a webpage.”

Brian Richardson (06:31.252): And we noticed that it had this header and consistent versioning and it’s hiding in essentially what is white space in Windows PE executables. So things in like Windows executable files are usually page aligned so that you can say, like the first kilobyte of this is always gonna be some amount of information with variable length, and then the next K is gonna be something else. There’s enough space in there to put a small payload. And people still try to pull this nonsense on executables on Windows all the time. And we noticed that a consistent header, a consistent version number…

Paul Asadoorian (07:20.659): And this was in your BIOS update from AMI.

Brian Richardson (07:23.572): Well, this wasn’t in the BIOS update. This was in the files we were giving people to build the BIOS. So it was attaching itself to executables. And so we started, this payload is attached to executables. We don’t know what it is. All we know is that in a couple of occasions, it actually did try to wipe the master boot record on our drives, which is essentially before you had GPT style partitioning. If somebody wanted to, the typical virus payload of the 80s and 90s was that they would try to overwrite the boot drive, either with a vector that sent it to an alternate location, like we’re gonna hook the boot vector before you actually load the OS, get something in ahead of it, or we’re gonna end up maybe just wiping out the first four kilobytes of your drive, which effectively kills your hard drive. You’re not able to boot. So we noticed that was occasionally triggering and trying to infect some of our systems.

Brian Richardson (07:53.128): So we ended up reporting this to one of the many antivirus vendors of the day. And what we didn’t realize was that once we got more information about it, this actually had a BIOS payload. And it’s very rare for that to have happened back at the time. So the way this worked is Intel had a, so back in the day when Pentium was the main processor and Pentium was not the discount brand for Intel, so way before Core, this thing called Pentium MMX, which was like the gaming processor of the day. And it was trying to, on this very specific model of Pentium MMX board, overwrite the first four kilobytes of the BIOS, what we call a boot block, which would have…

Paul Asadoorian (09:01.321): Yep. So it was not attacking the MBR on the drive. It was attacking the… Was it SPI Flash? It was still SPI Flash back then. No?

Brian Richardson (09:08.421): No, it wasn’t SPI Flash. This was like PLCC 32. So, or even like older, it wasn’t quite EEPROM yet. It was still FlashROM. So like you could program it the way that you program SPI today. Because what happened on old boards, and there’s a Tom’s Hardware article that’s gonna be in the show notes that kind of brings up the history of this. It had its anniversary on April 26. It happens to coincide with the Chernobyl event, but it’s not related to it. The C in CIH doesn’t stand for Chernobyl, it’s the dude’s initials in Taiwan who wrote it, which is its own wacky story.

Paul Asadoorian (09:40.935): Right. And someone named it the Chernobyl, someone from what McAfee or one of those early companies, right? Yeah.

Brian Richardson (09:45.349): Somebody, yeah, somebody, I think it was maybe Dr. Dobb’s or somebody like named it Chernobyl because they noticed the date and they thought the C was Chernobyl. And then later on, it’s like, well, no, this dude’s English name initials were C-I-H and it was a Taiwanese student who wrote it as an example because he had noticed that antivirus didn’t look below the surface, name of the podcast. And so everyone’s like trying to figure out why is it targeting this particular set of motherboards?

Brian Richardson (10:12.39): So back in the day, if you wanted to protect the BIOS, there was a physical jumper. Like you had to go inside the case and pop the jumper out. And that would unlock the first kilobyte or so of the flash chip. And that’s where…

Paul Asadoorian (10:24.011): I think Chromebooks today use a similar method. Yeah. It’s a hardware thing. Yeah.

Brian Richardson (10:27.188): Chromebooks have a similar mechanism for overriding the boot process. If you want to do custom payloads, basically. It’s a similar process. So this is like a, so this is a staging problem. If you’re starting to do more flash updates, because we’re leading up to Y2K and people are doing BIOS updates to fix Y2K problems, then you ended up with this problem of, you have to like physically intervene with the system. You got to take the lid off, move the jumper or do the thing.

Paul Asadoorian (10:56.427): To do your traditional BIOS update where you booted on a floppy, but even some systems you had to move a jumper or jumper pins to. Yeah, okay.

Brian Richardson (10:56.679): Exactly. Yeah. So, when Intel came up with a new chip design, they would end up making what they call a reference board. So they would just say, hey, this is the 430TX chipset, the Pentium MMX processor. We’re going to give any of our customers a fully designed motherboard as a starting point. So this is your chili recipe and you get to figure out how much spice you want to put in it, but here’s the base level of what we think of, like they validated memory, devices. There was like a test BIOS that came with it.

Brian Richardson (11:32.148): So they had this whole thing wrapped up. And what a lot of the Taiwanese ODMs did is they just Xeroxed this thing and took the entire design as is, made a couple of small changes just like branding strings and whatever. So this is what like white boxing is the term for it. Like you wouldn’t necessarily know where your motherboard came from, but it was super compatible with everything. So Intel said, hey, we think this is gonna be a problem [having to move a physical jumper]. So in the reference design, just as an example, you all can change it if you want, we’re gonna move this jumper to a GPIO, a software controlled GPIO so that you can trigger this on or off in your BIOS update utility.

Brian Richardson (12:01.681): And everybody just copied that too. So that meant if you knew where the bit was, even if you weren’t the BIOS update, you could flip it. So high probability that a 430TX motherboard—and the virus actually checked for this, “If it’s this PCI device and vendor ID, I’m gonna go play with these bits.”

Paul Asadoorian (12:07.081): Yep. Everyone’s like, that’s great. Our users don’t have to move a jumper anymore. Beautiful. Ship it. You could flip it.

Brian Richardson (12:28.179): Most of us actually weren’t using 430TX motherboards on our development systems, so it didn’t affect any of us in development. So not upgrading immediately, I guess, you know, a value-oriented company, you know, not immediately jumping on the bandwagon saved us, question mark. I did accidentally release it to a customer and I had to go apologize to them, but you know, we didn’t know any better at the time. But this is an interesting thing because if you look at like the Tom’s Hardware article, they’re like, yeah, this couldn’t happen on BIOS today. And Chase and I were discussing it. We’re like, no, that’s not really how that works. This is why we have a business.

Paul Asadoorian (12:56.779): They did say that and we were talking about that. Let’s address that. But the first thing it reminded me of before we even got to that statement in the article, which we wholeheartedly disagree with with much evidence, is when you were talking about the jumper and then the GPIO setting, it reminded me of manufacturing mode. It’s like a very similar problem where you’ve got to give the OEMs full access to customize the platform, and then they’re supposed to lock it down to prevent others from tampering with the platform, it sounds like even the early days that similar situation was happening.

Brian Richardson (13:42.42): Yeah, it’s the difficult problem. Being at AMI when we were developing bias reference kits for customers, it’s the same thing. You can’t fully lock down your example system because then no one can debug and develop on it. So you’ve got to like leave a couple of doors open for CPU debugging, SPI debugging, serial port access for remote, whatever the thing is on your platform, and then leave enough breadcrumbs to lock that down.

Brian Richardson (14:10.567): You know, you’ll still run into like, so if you do any system inventories, like you open up Windows system information, if you ever see something where there’s a string and it says “to be filled in by OEM,” that means that somebody didn’t read the “how to lock this platform down.” They didn’t like do all the steps of like, let me turn this from a reference design to my own design. So they put no spice in the chili, basically. They left it at factory defaults. And that’s still a huge problem, which is why like things like Chipsec or Eclypsium or other methods where we’re like, hey, check to make sure that you have turned on the security bits, that you’ve turned on boot block protection. Intel will call it Boot Guard, AMD’s got an equivalent, Qualcomm’s got an equivalent. On your cell phone, it’s secure boot. Like these little lockdowns of did you protect your memory, did you protect your flash part, is the flash descriptor writable? It shouldn’t be. These are all checks that people still have to do.

Paul Asadoorian (15:01.619): Right. Now, but I just want to point out, I want to point out to people that locking your SPI descriptor, I’ve covered it in articles now that I wrote when I joined the company three, four years ago. There’s a lot to unpack there. Like it’s not just the, you protected your SPI flash where your UEFI BIOS is stored. No, there’s a whole bunch of things to, yeah, there’s multiple configurations that each have their own different ways to protect that, but also some of them chain together and it gets very confusing. And obviously when it’s that confusing, OEMs can make mistakes. They can not properly lock it down, which leads to like, yes, this could happen today, 100%. I mean, I think we’ve done it. I mean, we still do it today in test systems.

Brian Richardson (15:44.655): Yeah, we found a system less than a year ago that, and the OEM was asking us to test this, that we were like, hey, you actually didn’t fully lock down your flash descriptor. And you protected the BIOS image, but the payload on systems now is more than just BIOS. Like in that same flash part, you have things like AMD PSP code or Intel Manageability Engine (CSME) code that are sharing space there or option ROMs for secondary devices that are not covered by the main BIOS. So you can still, like you can do all this stuff to protect the main UEFI BIOS image and still miss a trick and have somebody else be able to edit that and put extra entries into the flash part or like keep you from running your Intel ME code which will essentially break your system. So this is still an issue.

Paul Asadoorian (16:41.003): Yeah, people have tried to do that safely. People were really paranoid about, you know, we used to work for Intel, right? So you know the community reaction to the Management Engine which got renamed to CSME.

Brian Richardson (16:55.796): Yeah, it’s Converged Security and Management Engine, I think.

Paul Asadoorian (17:02.571): But people found ways to basically disable that. I talked about it the article that I wrote four years ago. I think that you had to do that through hardware, I want to say. That’s the other way. I mean, OK, so we’ve talked about software. Yeah, software-wise, through the operating system, you can potentially write to the SPI Flash. The other way is to put a clip on it or some other mechanism right but a clip on it and then write it and don’t do that on your systems unless you know what you’re doing because you can easily break your system.

Brian Richardson (17:36.018): Yeah, 100%. So the short version of that is this is still an issue and it’s something that you need to be diligent as a manufacturer to make sure you’re locking down. But then even like over updates, could be version one could get it right and then you could do an update and somebody could make a mistake and version two would be wrong. So it’s like it’s a constant monitoring thing. It’s not a fixed point in time, which I think people think of firmware as kind of a fixed point in time problem.

Brian Richardson (18:09.18): Like, yeah, we got it right at shipping and then this isn’t malleable, but like the average enterprise laptop’s gonna live in service probably three, maybe four years, maybe now five since DDR5 is, you know, you’re making four installments on your online payment.

Paul Asadoorian (18:30.475): If you can afford DDR5 RAM.

Brian Richardson (18:33.992): Yeah, but yeah, so you’re probably gonna have your units stay in service longer because of the market forces. So servers could be seven to 10 years, client device could be three to five, industrial could be seven to 10. So you’re gonna take dozens of firmware updates over that time if you’ve got a vendor who’s staying on top of things. And not checking in between those, you could accidentally expose yourself to one of these issues. It’s not malice necessarily, it’s just things happen. You just need to stay on top of it.

Paul Asadoorian (18:58.623): Yes. There’s certainly an operational risk. There is certainly a security risk. We’ve seen several different strains of malware try to attack, use UEFI to attack the system, to get in before the operating system. I think now the trend that hybrid Petya largely set was boot kits, and that’s living inside where your bootloaders live, in the ESP partition on Windows systems, right? And living in that partition. But still it is a huge threat landscape today. I mean we can go all the way back to 1999 and talk about the threat that then would destroy your system. Now, of course, we have threat actors that have more sophistication that aren’t just looking to destroy your system. My concern is what if an attacker were to go, hey, I just want to destroy a bunch of systems—not Petya, right?—but if I’m gonna do it from the UEFI level… To me that is, I don’t wanna give anyone ideas, but to me that’s really frightening because we talked about it many moons ago on the show, right? But the recovery from that is potentially extremely difficult, if not impossible in some circumstances, to physical hardware.

Brian Richardson (20:44.894): Yeah. And that was the thing with the original CIH and a lot of the issues now is that CIH didn’t try to introduce any kind of malicious code. It just bricked and it was purely a demonstration, purely a show off of “I think there’s a gap in this market. The only way I can show it is to nuke it.” And you’re nuking this area, the boot block is the first bit of instructions. And in a normal BIOS, the first, depending on the era, the first 4 to 64K contains enough code to recover, which is why the boot block is usually not malleable after it ships. So that’s why like the Boot Guard and those kinds of things are not protecting the entire part necessarily, they’re protecting like a key area. So this was bad enough to where you couldn’t recover this unless you physically had like a clip. You know, either the thing was socketed or you had a giant PLCC32 clip to chonk onto your motherboard. And most people turns out did not have that thing.

Brian Richardson (21:14.042): Now what the concern is, if you’re what we call a high value target, you’re a bank, you’re a government agency, you’re an insurance company, there’s enough incentive to say, I’m going to develop a specialized payload. So much like CIH was targeting 430TX or even a later version of it, like CIH versioned his headers. CIH had better software control than some software I was developing at the time and I was kind of mad about it. version one, two actually specifically had targeting in the payload to look for Chinese actors. It was looking for a Chinese, like a mainland Chinese version of the code. And the whole East Coast, West Coast thing that China and Taiwan have are a topic for a completely different podcast. But you can see where that and the good old Israeli associated firmware for certain countries, spinny bits that made the uranium better (Stuxnet), was very machine targeted. So people can say, I’m going to make a machine targeted payload that goes after a particular model of system, a particular model of system with these other properties, depending on your target, is worth enough of somebody’s time to pick that system apart and make it specialize for a particular version model vendor that targets an industry. And that’s where the real risk come from.

Paul Asadoorian (22:32.541): It’s interesting too. We talk about how malware can be somewhat sophisticated, even going back to CIH, right? Making decisions based on geolocation. When we talk about ransomware, ransomware doesn’t necessarily want to destroy the system. They want to preserve it in order to extort and get the ransom. However, just like any other software, it can have bugs. And if this is persisting in these lower layers, as we just talked about how dangerous it is if someone were to wipe your SPI flash or mess with it so your system’s not bootable, if they get that wrong, it ends up just being, basically wipe-ware malware. And I have an example of this. I did some forensics for a friend of mine. And I pulled the ESP partition, and that’s the partition in Windows that basically holds all your boot loaders. So the problem that my friend described to me was like, I’m booting my system and it’s telling me it can’t, basically it can’t find the bootloader. And I’m like, well, let me tell you how the boot process works on PCs today. And he was like, wow, that was a lot of information. Like send me the drive.

Paul Asadoorian (23:29.311): When I looked at the ESP partition, I could see that the files were encrypted in a certain way. And a quick search in AI was like, it’s this ransomware group. And I’m like, I know what happened, at least I think. The ransomware group had a little bug in their code that it encrypted the ESP partition as part of the ransomware. But what happens is when your system boots, when your BIOS goes to go, okay, I gotta go find the bootloader now, BIOS/UEFI goes, I can’t find the bootloader, and I just stop, and you don’t see the ransomware message. So I’m like, they messed up, basically. Yeah, just crazy.

Chase Snyder (24:22.562): I don’t know if I’ve ever heard the phrase “chonk onto your motherboard” before on the pod. So that’s good. We’re hitting all kinds of firsts.

Brian Richardson (24:29.396): It’s the worst crane game ever. Cause you’re just like, kinda this little clippy thing, and you’re hoping you’re getting like lined up just right on the SPI part or that the part’s readable. There’s this whole sidebar of like, if they do a pull-up resistor or not determines if you can clip it with the power on or off. Like there’s this whole thing, which is why we don’t normally get frustrated and de-solder the part.

Chase Snyder (24:55.198): Dude, we got to make this actual crane game and have it at the booth. We got to make the game. We’re in the age of because you can just vibe code a game and put it on Steam in like three hours. I saw one that was a data center wiring simulator and it was like, this is you’re being instrumented by the algorithm right now. They built the video game to train you to be a data center tech.

Brian Richardson (25:21.896): They PowerWash Simulator to data center? Wow. It is a beautiful day in the data center and you are a horrible goose. Yeah, so now I’m imagining just like the claw chooses who stays and who goes and you have to like get it just right to read the data. And so you could actually do like a live read. Like if you could get the Dediprog to read it, you get a prize.

Chase Snyder (25:43.758): We’re doing this. We’re doing it. We’re gonna get an old timey claw machine. We’re gonna put the like giant motherboard on.

Brian Richardson (25:49.778): We should call Kenny. Paul, I think Kenny wants in on this one. I’m just gonna call it right now.

Paul Asadoorian (25:51.849): Yeah, yeah. I did want to, Chase, I wanted to get your take on the Firestarter malware because you and I both have researched this a lot. Not this particular malware, but campaigns, threat actors, and malware specifically targeting Cisco ASA and FTD devices. We’ve even somewhat using Graynoise’s data, right, predicted that things were going to happen and then they happened. And I’ve been kind of doubling down on my research here at Eclypsium going, we should pay attention to this because in my research, it’s like the number one most deployed platform by revenue, by number of installs for firewalls and VPNs. And so all of this leads up to, by the way, there’s this whole new strain of malware that’s attacking these platforms. So I wanted to get your take on it too.

Chase Snyder (26:50.338): Yeah, sure. I don’t know. We talk all the time about how the network devices and security appliances are becoming kind of the battlefront for cyber attacks. Like they’re being targeted increasingly by both more advanced APT type attack groups and just like ransomware gangs and less sophisticated groups. And it’s because they don’t have, it’s like when your security box, you know, ASA, that’s Adaptive Security Appliance. FTD is Firepower Threat Defense. You would think that these would have the security internals that would befit their name, but they just don’t. They’re opaque to defenders and people who buy them and deploy them think that when they buy a security appliance from a major name like Cisco, like the household name of technology, that the box itself would be secure. And it just isn’t.

Chase Snyder (28:21.675): It seems like it’s taking a really long time for the mindset to shift and start thinking of those devices as devices that you have to secure unto themselves. Like you ask people how they have secured their stuff and they said, “We’ve got the firewalls in place.” Like, what are you doing to secure your firewalls? “What do you mean? I don’t secure the firewall. The firewall secures me.”

Paul Asadoorian (28:21.675): It’s a firewall. And you’re like, well, what do you do secure your Windows systems? Well, we put all this EDR and stuff on it. And like, what do you do to secure your Linux servers? And like, oh, we do a lot of monitoring and we keep them patched. Well, on your edge security devices, what are you doing? Because it’s just a Linux box, except you can’t really manage the Linux box because the vendors don’t want you to, except when, as we’ve said before, a threat actor has an exploit for it. Now they’re managing your Linux box for you, essentially.

Chase Snyder (28:53.282): Yeah. It’s like a framing that we’ve used in the past that just sticks with me a lot is like for you to gain root access to your firewall or your VPN appliance, or your routers and switches and stuff, you would probably have to jailbreak it or something.

Paul Asadoorian (29:13.843): Right, but with ASA and FTD, you can get into the underlying Linux. They provide you a facility for that. However, big caveat, this is not a Linux that you manage. And so if it has an outdated library, if it runs Python 3.9, like the one I was just looking at today, like you can’t just go upgrade that. I mean, maybe you could. It’s Linux. Like if you want to delete your bootloader, Linux is like fine. Right. If you’re on Windows and you want to delete Edge, it’s like, can’t help you with that, right? So there’s differences here. But you will more than likely break something or even not be able to manipulate software packages on these Linux systems because they’re finely tuned for what’s running on the firewall or VPN appliance.

Chase Snyder (29:42.803): Yeah, at least you can look at it because some of them you get no visibility. It’s like a whole thing that you can’t put an EDR agent on a firewall. And there’s this—ever watch New Girl, the show? I’m dating myself a little bit, maybe. But there’s a scene where they figure out one of the roommates has not washed his towel in like maybe ever. They’re like, dude, what are you doing? Why do you you’re not washing your towel? And he’s like, “I don’t clean the towel, the towel cleans me.” It’s like, “I don’t secure the firewall, the firewall secures me.”

Paul Asadoorian (30:36.907): I like that analogy a lot, actually.

Brian Richardson (30:38.48): Yeah, and keep in mind you’re saying “I’m dating myself” to a guy who just told you he did a Y2K talk. So let’s get the range in here. My doctor has asked me if Cologuard is right for me. So like that’s where we are demographically.

Chase Snyder (30:54.434): We’ve got the range. We got range.

Paul Asadoorian (31:25.995): So just really quickly, listen to this part first, then go read more about Firestarter and you’ll have a much better time. Arcane Door is the campaign that I believe started as far back as 2023. And that is just the name of the campaign. It’s also referred to as MITREC0046 to make things extra confusing. It is not an actor, is just the moniker for the campaign, which largely is a campaign targeting Cisco and other edge devices. The threat actors that I found are UAT 4356 or Storm-1849, depending on who gave it the name.

Paul Asadoorian (31:55.339): Now the malware: Line Dancer in-memory shellcode loader. Line Runner is a persistent HTTP Lua implant on ASA devices. Ray Initiator is a multi-stage boot kit that delivers another payload called Line Viper. Line Viper is user-mode shellcode loader and post-exploitation implant. Firestarter is a Linux backdoor that hooks the “Lina” process for long-term persistence.

Paul Asadoorian (31:55.339): Now, the next logical question that everyone asks is, what is Lina? And if you’re not familiar with the Cisco ASA/FTD platform, you may not know. Lina essentially is the software that runs on Linux that provides the user with the firewall VPN technology. So they’re using the standard Linux stack as the platform, developing additional software that provides you with the firewalling, the VPN, like your traditional IPsec VPN, and the web VPN. So when we say that an attacker has hooked that process, this is the MO of these groups. This is the holy grail of firewall and VPN hacking. Because if I can hook or get inside the process that’s doing that VPNing functionality, the attacker can do things like: hey, every time someone authenticates to the web VPN, write their credentials in clear text to this file, and then shoot that file back over the C2 that I have on it. Essentially that same kind of TTP persists through multiple similar campaigns against other network vendors with other groups. UNC3886 is notorious for doing that kind of stuff as well, which I think has dotted lines to this malware. So we’ve seen this evolution of all this malware from almost three years, evolution of malware that’s essentially, to me it almost looks like they’re perfecting their craft to implant these firewalls.

Brian Richardson (35:21.234): Yeah. And it’s different technologies too, like Cisco is not consistent across those lines. So you have different ways of managing and different amounts of visibility into the products, which is a challenge for us trying to keep on top of it, and a challenge for the customers that are managing it. Because there’s some inconsistencies in between them, but you’re talking about this Lina process. If that’s common to a lot of the devices, then once you figure out how to hook that, that’s why you see this happening across vendors as well as across product lines within a vendor. You know, because it’s a supply chain thing. A lot of people relying on the same libraries components under the hood pieces. Because these things are really just Linux with a lot of SFP ports sitting on them.

Chase Snyder (36:04.088): A thing that we hear from customers all the time is that they already have whatever the management tool is from a particular vendor, their Cisco shop. They have the Cisco management product, whatever that happens to be called.

Paul Asadoorian (36:18.091): Which, by the way Chase, I just want point out that you buy all of these Firewall VPN appliances and then you’re like, I have to manage them. So you have to buy another appliance that is basically just Linux with some custom software running on it to manage all of it. FMC, Firepower Management Console.

Chase Snyder (36:46.03): Yeah, 100%. And so it’s like the amount of effort, cause almost no company will have only one vendor. Arguably you shouldn’t because you should have a sort of supply chain mitigations in place by having different vendors fulfilling the same sort of basic requirements. But then if you have different types of network devices or the same types of network devices from different vendors, and then you’ve got to have the different management appliance and console. And then you got to have the person or people who knows how to use that different management appliance or console. It gets muddy real quick. And when an organization has several of those different things and they’re trying to keep their stuff up to date to N-1 or whatever firmware across multiple products from multiple vendors through different management planes, they just can’t keep up. Then that’s how you end up with super out of date firewall managers and your firewall getting pwned.

Paul Asadoorian (38:02.699): There’s also the, I think that you could easily have, let’s say you have 200,000 employees. Any one of these platforms that’s providing VPN access especially is providing access for a user base of a hundred thousand or more people. Just think about that for a moment. Like, oh, I have to bring down access for a hundred thousand people or even better, I’m frustrated with vendor XYZ for any number of reasons—security, I’m told, is one of the reasons today that CISOs are making these decisions—and I want to move to a different platform. Oh, let’s just migrate 200,000 users to a new platform, because that’s not hard, is it? Of course it is. And that’s how they get stuck. Enterprises are stuck on these platforms.

Brian Richardson (38:59.977): Yeah. Geographic region support is one of them, right? You end up with like a solution, either through like vendor support or sanctions or politics or whatever. Like your Asia customers can run one firewall, but your US customers can’t. And so you’ve got different versions of agents places or you’re in the middle of a rollout. And if you’re still doing that phased approach, cause I’ve been in companies where we’ve migrated the firewall and it’s been months of that transition. And at that point like you’re probably not maintaining the system you’re transitioning from so you still have a gap even when you’re moving from that vendor to have something that’ll persist after you put up the new guard but the thing already got in before you switched out the firewall.

Paul Asadoorian (39:52.555): The other interesting thing about Firestarter is in order to get rid of the persistence, you have to physically power it off.

Brian Richardson (40:03.925): Ooh, oh no, no. IT people love going into server farms and playing with racks. That’s great.

Paul Asadoorian (40:11.115): Not only that, you have to power it off long enough so that all the data leaks out on the floor or whatever analogy you want to use, but essentially the malware lives in areas that would persist through soft reboots and those areas aren’t cleaned out or removed unless there’s a full power off.

Brian Richardson (40:20.437): Drain those caps. Yeah.

Paul Asadoorian (40:39.947): Cisco comes right out and says in their advisory you have to power it off. So even if you’ve patched it, even if you’ve tried to clean it, like rebooting it or patching it doesn’t remove the infection. So like applying a firmware update doesn’t remove the malware. The authors thought of that and it persists. But also it could write into areas that are persisting beyond powering off, powering it back on as well. So you have to do some forensics on these systems.

Brian Richardson (41:13.097): Yeah. And sometimes when you power off a firewall, a lot of these things are running some kind of virtual machine management or like F5, I think they call it, TMM. Essentially they’re using virtual machine management or other types of containerization that when they reboot something, what they’re really doing is like flipping the off switch on something virtual. And so there may be certain management layers where you have to hit it with the hard reset hand. Which just means if you’ve ever gone to a data center, that’s an hour of your life just getting in and out the door, getting past the gates. And then you’ve got to go in all the racks and get carted in. Those places have better security than some military bases have.

Paul Asadoorian (41:57.395): And then hoping when you power it back on that it comes back on and comes back on in the same state from when you powered it off. And those of us that have worked in IT for a long time know that’s not always the case.

Brian Richardson (42:08.661): It doesn’t know what happened. And that’s minutes per box. Like this is not like flipping on your laptop. Like these are essentially servers with a lot of network cards attached to them. So you bring a sandwich, you’re gonna be there for a while. But don’t eat the sandwich in front of the rack.

Paul Asadoorian (42:33.119): Did you want to touch on the Graynoise report, Chase, too? I thought that was super interesting. Basically, Graynoise is pointing out that we can notice scans for certain targets, and then a certain number of days after the increase in that scanning, that target, we learn of a new vulnerability, a new zero-day exploit, and new malware that is infecting it.

Chase Snyder (43:31.564): Yeah, they’ve been really effective at predicting these things over the past year or so. So shout out to Graynoise. And that sort of general lane of information, like the Verizon Data Breach Investigation Report had a solid chunk of network device facing vulnerability exploit incidents that they had as part of the data. And the median time to exploit a vulnerability across those was zero days. So a lot of the time these things are getting exploited before they’re disclosed. We find out about them because they get exploited and then they get disclosed. But it kind of shifts the whole timeline of how you need to be thinking about protecting yourself against exploitation in those network edge devices because vulnerability management and threat detection tools, anything that relies on an existing CVE or anything like that, it’s not going to find it for a while.

Chase Snyder (44:29.356): And even then, to the point of how long it takes or how hard it is to address these things, I think the median time for an organization to patch one of those vulnerabilities was like 30 days. And so there’s just a lot of operational friction and rolling out any sort of a fix to this enterprise network infrastructure layer versus the time that it takes to exploit those things just keeps getting faster. I think, yeah, there’s a whole paradigm shift coming in how folks secure their network edge because the current trend is things are getting exploited way faster. The exploits are becoming more commodified. It’s becoming easier and easier for less sophisticated groups to target your whole network infrastructure. And it’s happening super fast. I think the pain and the sort of operational downtime and financial costs that end up hitting these companies is gonna cause some of them to totally radically overhaul how they’re trying to secure these things.

Chase Snyder (46:01.003): One more data point that I just can’t stop myself from quoting at every opportunity is, it’s not just nation states. For certain vendors of on-premises VPNs, there was this insurance company called App-based Cyber Insurance that said that certain vendors were associated with a 6.8x higher likelihood of being targeted with a successful ransomware attack. So having that VPN, you think it’s like a security product, right? The VPN, it’s not really a security product. People treat it that way.

Paul Asadoorian (46:29.363): Right. It’s like I parked my car in the garage so my insurance would be cheaper, right?

Chase Snyder (46:33.152): Yeah, yeah, it’s like you’re six times more likely to be robbed if you put it in the garage. That’s a great analogy.

Paul Asadoorian (46:43.847): It’s so nuts. Also my other concern is, well, we’ve established that threat actors know about the vulnerabilities and exploits before we do. My other concern, and I don’t think it gets talked about enough, is what if the InfoStealer—it’s all the rage today, right? Threat actors are just going after data, wherever, however they can get data through supply chain attacks. I’m like, hey, I got an account. Someone’s just telling me like, they’re just going to log into your Salesforce. They’re going to push the export button and they’re going to dump everything. And then this is so common and they’re stealing so much data. Shout outs to Tammy at Flair. She was just telling me about this. There’s so much data that there’s a site called Leak Bizarre and their service, their niche is to go through the info stealer logs or data dumps and pull out what’s interesting because attackers are getting hundreds of gigabytes, terabytes worth of data. And it’s a lot of work to analyze that and figure out what you got, right? We saw it with the MOVEit breach that had a long tail as they were sifting through all of the data. And my concern is that in some of these dumps and leaks is information about vulnerabilities. I mean, we had that concern with F5, right, when they disclosed that their network was breached.

Brian Richardson (48:52.558): Yeah, it was one of the reasons why they did a massive key rotation. Like one of the big things in that update was not just, we patched a ton of vulnerabilities, which they probably were already in the pipeline for, it may have accelerated the release. If you read the change log on those releases post-disclosure, they’re long. They fixed a lot of stuff. It was very comprehensive, but the biggest thing was like, we’re gonna rotate some keys. And that was like trying to prevent them from like being able to take advantage of build infrastructure, for instance, hoping that they didn’t have the new keys because they hopefully had locked them out by the time they did that regeneration.

Paul Asadoorian (49:14.667): Sure. Which is why we put so much effort into, I mean, not to plug our product, right? But this is why we are entrenched in this topic. One reason is we’re trying to help people defend their network edge devices, right? So that’s important. Mythos was interesting. We talked about it a lot. Everyone’s talking about Mythos. But the latest thing, Brian, I think you put it is: The White House doesn’t want Anthropic to broaden its access, but Anthropic is doing that anyway.

Brian Richardson (49:47.508): Yeah! Yeah, so Mythos, if you want background on it, there’s probably 4,000 podcasts that have already covered it, but source level tool for trying to find exploits. And Mythos is not a general release. It is most likely a derivative of one of the existing Claude models, but it probably has different guardrails and different prompting techniques to look for things that maybe the standard model doesn’t because Anthropic does a very good job of guard railing. And we spend a lot of time trying to massage that for our purposes. “We’re the good guys, trust us.”

Brian Richardson (50:45.545): But so Anthropic, it could be the fact that some of the current government agencies were not first on Anthropic’s list for giving them the Mythos model, but they want to be able to expand it out. So the administration, they’re having these conversations around it. And this is a Wall Street Journal article. So they really want to, they want to up the number of customers that have access to this. And they went to some big people like CrowdStrike and Intel with the initial model, so they could use it internally on their source code and look for things. And this is where everybody was kind of freaking out about Mythos and thinking like, this is gonna kill every security company out there. And it probably really won’t because again, you need source level access to work on this.

Brian Richardson (51:41.501): The government’s concern, according to the article, is that if Anthropic spreads its resources too wide supporting Mythos or even other new products, it reduces the number of engineers that can respond to the government’s needs for Anthropic models. Because as we’ve heard in the news recently, several government agencies heavily rely on Anthropic for models they use for a variety of purposes—and the discussions about what purposes those should be, it’s a topic for a different podcast. So this is of interest and it’s hard to say if it’s motivated by the concern over, “We weren’t first on your list, what gives?” And more of the, “You’re someone we rely on, so let’s make sure that…” Yeah. Yeah, yeah. Sorry about that. There was a glitch in the Matrix. I was talking about Anthropic in the government. I should have turned on my VPN first.

Paul Asadoorian (52:23.532): Brian froze.

Chase Snyder (52:26.1): He was in the middle of making such a good point. Yeah, that systems level thinking.

Paul Asadoorian (52:31.298): He’s back. Good. Glitch in the matrix here.

Brian Richardson (52:39.861): But I’m just going to assume that disconnection is completely unrelated to the topic—

Paul Asadoorian (52:43.498): He’s frozen again.

Brian Richardson (52:47.679): Am I still getting…yeeted?

Paul Asadoorian (52:53.475): I did read something where NSA was still, despite it being kind of poo-pooed by the government, that NSA was still using Anthropic’s models. And I mean, let’s be frank, Anthropic has the best models for a lot of tasks.

Chase Snyder (53:11.682): I mean, there was the big drama in the news, Anthropic getting designated as a supply chain risk, first ever American company to get that designation. But I think that the level of integration that they already had into government systems, it’s much like when a massive vulnerability is discovered inside of some network appliance and CISA issues a binding operational directive that’s like, hey, you guys have to rip this out of all your systems or patch it or whatever. They give them a certain amount of time and it may or may not be possible. My sense is that Anthropic was so involved and being so heavily used and was so integral to certain operations that were happening that even though that designation happened, they couldn’t get pulled out in the middle of the action. I don’t really have any evidence about that other than reading publicly available internet stuff and reading between the lines of it. But I think they’re still using it and that it is foundational enough to certain systems and operations that it would be hard to pull Anthropic models out of some government action that’s happening right now.

Paul Asadoorian (54:45.227): Brian’s back.

Brian Richardson (54:45.885): Yeah, I’m back. Now, turns out you talk about AI and used in the government enough and somehow your Wi-Fi goes down at the same time and I’m just going to call it a coincidence.

Chase Snyder (54:55.15): Spooky action at a distance.

Brian Richardson (54:58.397): Yay. This is probably in a normal podcast, the part where the sponsor segment would come up and they try to sell you a VPN, but we’re not that podcast.

Chase Snyder (54:59.736): Don’t talk about goblins.

Paul Asadoorian (55:08.235): We’re not. We’re not. Yeah. Well, I thought it was a great discussion. I thought we covered some great topics. I wanted to thank everyone for listening and watching this edition of Below the Surface. We’ll see you next time.

]]>Pull the Plug: FIRESTARTER Survives Patches, Reboots, and Your Incident Response Planhttps://eclypsium.com/blog/firestarter-cisco-firewall-backdoor-survives-patches/

Thu, 07 May 2026 13:00:00 +0000https://eclypsium.com/?p=16366A Linux backdoor hooks the firewall data plane (LINA) on Cisco ASA and Firepower devices, persists through firmware updates, and only a full power cycle gets rid of it. The Patch Is Not the Fix You patched your Cisco ASA. You rebooted it. Your vulnerability scanner shows green. You closed the ticket. However, the backdoor […]

The post Pull the Plug: FIRESTARTER Survives Patches, Reboots, and Your Incident Response Plan appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>A Linux backdoor hooks the firewall data plane (LINA) on Cisco ASA and Firepower devices, persists through firmware updates, and only a full power cycle gets rid of it.

The Patch Is Not the Fix

You patched your Cisco ASA. You rebooted it. Your vulnerability scanner shows green. You closed the ticket. However, the backdoor is still there!

That is the actual operational reality CISA and the United Kingdom’s National Cyber Security Centre (NCSC) put on paper in Malware Analysis Report AR26-113A, published April 23, 2026. The malware is called FIRESTARTER. It is a Linux ELF that runs on Cisco Firepower and Secure Firewall devices, hooks the LINA process, and re-installs itself after every termination signal it receives.

A Quick Note on LINA

LINA is the core data plane process on Cisco firewalls. It handles the actual firewall functionality, including stateful inspection, ACLs, NAT, routing, and VPN termination (including WebVPN). The binary sits at /asa/bin/lina on the device and runs as a userland process on top of Linux.

On Cisco ASA devices, LINA is the whole show. The OS underneath exists to keep LINA running. There is no other inspection engine in the data path. On Cisco FTD (Firepower Threat Defense) devices, the architecture is split into two parts. LINA still does the firewall and VPN work, exactly like on ASA. Snort runs alongside it to handle deep packet inspection, IPS, and application identification. The two processes communicate internally, and traffic flows through both. FIRESTARTER does not care which platform you run. It hooks LINA, and LINA exists on both.

That is why hooking LINA matters. Hook the process that parses WebVPN requests, and you get a covert trigger that arrives as ordinary VPN traffic without requiring a new listener/port.

FIRESTARTER survives reboots, firmware updates, and patches, including those that closed the original CVEs used to install it. The only way to remove it is to physically unplug the device from every power source for at least 1 minute. Redundant power supplies count. Soft reboots do not. If you do not pull the cord, the backdoor stays.

This is the part of the network that almost everyone treats as out of scope for endpoint security tooling. There is no EDR agent on your firewall. There is no XDR telemetry. The device sits at your perimeter, and you trust it. That trust is exactly what threat actors are counting on.

The Campaign: ArcaneDoor, UAT-4356, and the September 2025 Compromise

FIRESTARTER did not appear in isolation. It is the persistence mechanism for an ongoing intrusion campaign that Cisco Talos tracks as UAT-4356, the same actor cluster behind ArcaneDoor. The original initial access was through two Cisco ASA vulnerabilities patched in September 2025:


CVE	Type	CWE
CVE-2025-20333	Missing Authorization in Cisco ASA WebVPN	CWE-862
CVE-2025-20362	Classic Buffer Overflow in Cisco ASA	CWE-120

CISA published Emergency Directive 25-03 on September 25, 2025, ordering Federal Civilian Executive Branch (FCEB) agencies to identify and remediate compromised Cisco devices. During that response, CISA found a real, in-the-wild FIRESTARTER infection on a Cisco Firepower device running ASA software inside a federal agency.

Note:

Many of the names we have given threat actors, campaigns, and malware targeting Cisco ASA/FTD can be confusing. Below is a brief outline:

ArcaneDoor: The campaign name ( MITRE C0046), not a threat actor or malware reference
UAT-4356 / STORM-1849: the actual threat actor labels
LINE DANCER: in-memory shellcode loader for ad-hoc command execution (2024)
LINE RUNNER: persistent HTTP/Lua implant on ASA (2024)
RayInitiator: multi-stage bootkit that delivers LINE VIPER (2025)
LINE VIPER: user-mode shellcode loader, post-exploitation implant (2025)
FIRESTARTER: ELF backdoor that hooks LINA for long-term persistence (2025, public 2026)

The actor first deployed an implant called LINE VIPER for post-exploitation, used valid VPN credentials from former employee accounts to bypass authentication policies, then installed FIRESTARTER for long-term persistence.

CISA’s report explicitly notes that the actor used FIRESTARTER to redeploy LINE VIPER in March 2026, well after patches were applied. They never had to re-exploit anything as the persistence mechanism did its job.

What FIRESTARTER Actually Does

The malware sample CISA analyzed was named lina_cs. When lina_cs runs, it copies its own contents from /usr/bin/lina_cs into memory and registers a signal handler, allowing the malware to take action in response to signals (e.g., when the system or user tells the process to restart). It also triggers on runlevel 6, which is the system reboot runlevel on Linux. Which means every time the device shuts down or reboots, FIRESTARTER’s persistence routine fires.

When a termination signal is received or the device reboots, FIRESTARTER reverses the cleanup. It re-creates /opt/cisco/platform/logs/var/log/ if missing, opens /opt/cisco/platform/logs/var/log/svc_samcore.log, and writes a copy of itself to that file. That directory is reboot-persistent. Then it re-stages CSP_MOUNT_LIST, appending shell commands that move the binary back to /usr/bin/lina_cs, set permissions, and execute it in the background:

The sequence is straightforward. The device reboots; the boot-time mount script executes the appended commands; FIRESTARTER moves itself out of the log directory back into /usr/bin/; and runs again. Patch the device, update the firmware, reboot, and the boot-time configuration script does the actor’s work for them.

FIRESTARTER works by quietly editing the LINA process in memory. It finds a specific spot inside one of LINA’s loaded libraries and slips in a small piece of code that acts as a trapdoor. Nothing changes on disk, and LINA keeps running normally.

The trapdoor only opens when a very specific WebVPN request comes in, one carrying two secret values that act like a key and a victim ID. If both match, FIRESTARTER drops the next stage of malware straight into LINA’s memory and runs it. That is how the actors redeploy LINE VIPER on a compromised box without having to re-exploit the original Cisco vulnerabilities. It is also worth noting that this whole technique looks a lot like what the RayInitiator bootkit did on Cisco ASA.

Why Reboots and Patches Do Not Help

Most security teams have a deeply ingrained mental model: patch the CVE, reboot the box, the threat is gone. That model is wrong here for two reasons:

The persistence file is in a reboot-persistent location: CSP_MOUNT_LIST is a configuration file that the device executes during boot. Modifying it means the malware gets re-run on every boot, no matter how many times you patch. The firmware update does not touch the config partition (where this file lives).
Soft reboots do not clear running memory the way you think they do: Cisco’s security advisory on this campaign is explicit: a soft reboot does not remove the malware. The injected shellcode and in-memory hooks can survive across reboots on these devices. Only a hard power cycle, with all power sources disconnected for at least one minute, fully clears the state.

If your firewall has redundant power supplies, both must be removed. Otherwise, the device never actually loses power.

Detecting FIRESTARTER

CISA’s Supplemental Direction for ED 25-03 lays out a specific hunt sequence. Whether you are an FCEB agency or not, the procedure is worth running on any internet-facing ASA or FTD device. CISA also published two YARA rules in AR26-113A. They are also packaged by ThreatHunter.ai into a clean detection bundle. The rules are short, direct, and effective when run against either a core dump or a disk image.

Both rules are designed to work against memory captures. Run them against your core dumps and disk images obtained through Cisco TAC. CISA explicitly recommends getting the disk image through TAC rather than open-source acquisition methods because the actor employs anti-forensic techniques.

If you are hunting beyond YARA, these are the artifacts to look for:


Artifact	Purpose
`/usr/bin/lina_cs`	Active FIRESTARTER binary (filename can vary)
`/opt/cisco/platform/logs/var/log/svc_samcore.log`	Reboot-persistent staging copy of the binary
`/opt/cisco/config/platform/rmdb/CSP_MOUNT_LIST`	Boot-time mount script with appended persistence commands
`/opt/cisco/config/platform/rmdb/CSP_MOUNT_LIST.tmp`	Temporary file used during persistence write
Modified XML handler in LINA memory	Hook target for the WebVPN trigger
Shellcode block before end of `libstdc++.so` text segment	Active shellcode injection

Recommendations

For network defenders, here is the concrete action list:

Inventory every Cisco ASA, Firepower, and Secure Firewall device on your perimeter. Use the device’s first-deployment date and patch history to identify boxes that were online and unpatched between September 25, 2025, and the date you applied the fix.
Treat any device that was exposed to the internet and unpatched during that window as suspect. Patches addressed the CVEs. They do not remove FIRESTARTER. The persistence is post-patch.
Run the CISA hunt sequence before you reboot, patch, or reconfigure anything. Capture show checkheaps and show tech-support detail. Generate a core dump and save it off the device.
Run the CISA YARA rules against the core dump. Both CISA_261290_01 and CISA_261290_02. If either triggers, treat the device as compromised.
If compromise is confirmed, do not reboot. A soft reboot does not remove FIRESTARTER. Coordinate with CISA (or NCSC for U.K. organizations) before taking the device offline.
When directed to remove the malware, perform a hard power cycle. Unplug every power source while the device is still running. Leave it disconnected for at least one minute. Reconnect and let it boot. Both redundant power supplies must be unplugged.
Audit VPN sessions for use of accounts belonging to former employees. The threat actor used valid credentials from inactive accounts to bypass VPN authentication policies. “Disabled” does not mean “removed” in this case.
Rotate every credential, certificate, and private key stored on a confirmed-compromised device. LINE VIPER, the post-exploitation implant, exposes all configuration elements, including admin credentials, certificates, and private keys.
Implement TACACS+ over TLS 1.3 for device administration. Not specific to FIRESTARTER, but the recommendation is in CISA’s mitigations because device-admin traffic is a frequent target for credential interception during these campaigns.

The Bigger Picture

This is what supply chain compromise looks like at the network edge. The actor did not exploit anything novel after September 2025. They did not need new CVEs. They needed a place to hide and found one in the boot-time configuration script of a network appliance that no security team has ever instrumented, because there is no agent running on it.

The Eclypsium platform monitors firmware integrity, boot configuration, and persistent storage on network devices specifically because this category of threat exists. FIRESTARTER is the campaign that is making headlines this month. It will not be the last. The next one will look different and live somewhere else on the same device, and you will need the same kind of visibility to find it.

To learn more about how Eclypsium can help with network device security at the component level, read our white paper: Eradicate Hidden Risks in Network Edge Devices.

References

Frequently Asked Questions

What is FIRESTARTER, in one sentence?+

A backdoor on Cisco ASA, Firepower, and FTD firewalls that lets the attacker keep coming back, even after you patch the box.

I applied the September 2025 patches. Am I safe?+

The patches close the door the attacker came in through. They do not remove the attacker if the attacker was already inside. If your firewall was internet-exposed and unpatched between late September 2025 and the day you applied the fix, you should assume the box could have been compromised and run the CISA hunt steps.

How do I know if I am infected?+

You will not see it in your SIEM. FIRESTARTER does not generate logs. The reliable way to find it is to capture a core dump and run the CISA YARA rules against it. That is it. Reboot logs, syslog, NetFlow, none of that helps you here.

Why does rebooting make it worse?+

A soft reboot is the trigger. The malware listens for the shutdown signal and uses it to re-stage itself on disk before the box goes down. Every clean reboot re-arms the persistence. The only thing that breaks the cycle is removing power entirely.

What counts as a “hard power cycle”?+

Pull every power cable. If the device has two power supplies, both come out. Leave it that way for at least a full minute. Then plug it back in. If one cord stays in, the device never actually loses power, and the malware never actually goes away.

Can my endpoint security tools catch this?+

No. There is no EDR on a Cisco firewall. There is no agent. That is exactly why this category of attack is so attractive to the actor in the first place. The firewall is a trusted black box on your perimeter, and most organizations have zero visibility into what is running inside it.

Is this only a problem for US federal agencies?+

No. CISA found it on a federal box, which is how we got the public report, but the same vulnerabilities and the same backdoor work on any internet-facing Cisco ASA or Firepower device. The UK NCSC put their name on the joint advisory for a reason.

Can I just replace the firewall?+

You can, and in some cases that is the cleanest answer, especially if you cannot get downtime to do a proper hard power cycle and core dump. Just do not stand up the replacement with the same configuration, the same VPN credentials, and the same admin certificates. The attacker has all of those.

Who is behind this?+

Cisco Talos tracks the actor as UAT-4356. Microsoft tracks them as STORM-1849. The campaign is called ArcaneDoor. It is widely assessed to be a state-aligned cyberespionage operation. They have been hitting network edge devices for over two years.

Should I take my firewall off the internet?+

If the WebVPN interface does not need to be reachable from the public internet, take it off the public internet. Most of the recent Cisco edge device compromises have come in through WebVPN. If you are not using it, do not expose it.

]]>Zero Trust Target Level Compliance Device Pillar Challenges: Do The Hard Parts Nowhttps://eclypsium.com/blog/dod-zero-trust-target-level-compliance-device-pillar/

Tue, 05 May 2026 13:00:00 +0000https://eclypsium.com/?p=16322The Department of War’s Zero Trust Target Level deadline may be September 30, 2027, but for agencies responsible for device security, the practical deadline comes much sooner. That is because some of the hardest Zero Trust controls sit inside the Device pillar, and many of those activities are scheduled early enough that they need to […]

The post Zero Trust Target Level Compliance Device Pillar Challenges: Do The Hard Parts Now appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>The Department of War’s Zero Trust Target Level deadline may be September 30, 2027, but for agencies responsible for device security, the practical deadline comes much sooner.

That is because some of the hardest Zero Trust controls sit inside the Device pillar, and many of those activities are scheduled early enough that they need to be operational, integrated, and producing evidence in 2026. Waiting until the final year to address device trust creates avoidable risk: procurement delays, integration gaps, incomplete baselines, missing telemetry, and limited time to demonstrate measurable progress.

For Zero Trust leaders, the implication is clear. Device trust cannot be treated as a late-stage compliance exercise. It is one of the early dependencies that determines whether the rest of the architecture can make reliable access, authorization, monitoring, and response decisions.

Read the Eclypsium Supplement Guide: How Eclypsium Covers 31 Of The Most Challenging DoW Target Level Zero Trust Activities

The FY2027 Deadline Can Create a False Sense of Runway

DoW Components are expected to reach Target Level Zero Trust by the end of FY2027. On paper, that may sound like there is still time. In practice, the Device pillar has a different clock.

The DoW Zero Trust Capability Execution Roadmap lays out a multi-year implementation timeline, and the Device pillar is effectively front-loaded. Multiple Target Level device activities are expected to be implemented and matured across FY2024 through FY2026. That makes 2026 the critical year to operationalize device controls, close visibility gaps, and begin producing measurable evidence of progress.

This matters because device trust is not something that can be switched on at the end of a program. Agencies need time to:

Discover and classify devices across heterogeneous environments;
Identify gaps in existing device health tooling. Existing tools often don’t reach the depth required by the Target Level mandates;
Establish known-good hardware and firmware baselines;
Integrate posture signals into enforcement workflows;
Tune policies for mission impact;
Validate reporting and evidence collection; and
Mature operations around continuous compliance.

The 2027 mandates are already in place. But while a policy can be signed today, a trustworthy device program takes time to build. We can’t wait until the deadline to begin.

The Hardest Device Controls Are Not Paperwork Exercises

Some Zero Trust activities can begin with policy updates, process definitions, or configuration changes in mature enterprise platforms. Device-pillar activities are different. Many of them require agencies to know whether each device is actually trustworthy, not merely whether it is enrolled in a management tool or has an endpoint agent installed.

That distinction becomes important in activities such as:

Device Health Tool Gap Analysis;
NPE/PKI, Device under Management;
Implement C2C/Compliance Based Network Authorization;
Implement Application Control and File Integrity Monitoring tools;
Integrate NextGen AV tools with C2C;
Deny Device by Default Policy;
Managed and Limited BYOD and IoT Support;
Implement Asset, Vulnerability and Patch Management tools;
Implement UEDM or equivalent tools;
Enterprise Device Management;
Implement EDR tools and integrate with C2C; and
Implement XDR tools and integrate with C2C.

These activities are difficult because they move beyond visibility into enforcement. They ask agencies to make decisions based on device condition: whether a device should be allowed onto the network, whether it should receive a certificate, whether it should access an application, whether it should be quarantined, and whether its posture should influence incident response or risk scoring.

Some of these activities have useful analogies in other fields. Comply to Connect (C2C) has precedent in the context of Criminal Justice Information Systems (CJIS) requirements. Law enforcement agencies throughout the U.S. must validate the integrity of firmware in any computer that accesses CJIS systems. But assuring that squad cars don’t connect to CJIS data if they aren’t compliant is a nontrivial problem. Multiply it across all the other types of devices and restricted data sources and you begin to see the scope of the challenge this pillar poses.

Those decisions require reliable signals. If the device telemetry is incomplete, the enforcement logic will be incomplete too.

Why Device Trust Is a Zero Trust Dependency Chain

The Device pillar should not be viewed as a checklist of unrelated controls, but as a chain of dependencies. First, agencies need to know what devices exist. Then they need to know whether those devices are under management. Next, they need to understand each device’s health, configuration, firmware integrity, vulnerability exposure, and patch posture. Only then can they make risk-based access decisions and continuously enforce policy.

A simplified progression looks like this:

1. Know the device.

Build accurate device inventory, identify unmanaged or unknown assets, and understand where existing health tools lack visibility.

2. Trust the device. Verify device integrity, establish known-good baselines, monitor for drift, and understand vulnerabilities or insecure configurations below the operating system.

3. Enforce based on device trust. Feed device posture into C2C, NAC, ZTNA, UEM, IdP, PAM, and other access-control workflows so authorization decisions reflect actual risk.

4. Operationalize the evidence. Export device-trust context into SIEM, XDR, SOAR, ITSM, vulnerability management, and compliance reporting workflows so security teams can act on the data and demonstrate progress.

This sequence is why the schedule matters. If agencies are still working through basic device visibility in late FY2027, they will not have enough time to mature the downstream enforcement, analytics, and automation activities that depend on that visibility.

The Hidden Challenge Is Below the Operating System

Most agencies already have some combination of endpoint protection, EDR, vulnerability scanning, configuration management, mobile device management, and asset inventory. Those tools are necessary, but they do not always answer the deeper device-trust questions that Zero Trust depends on.

A device may appear compliant at the operating-system layer while still carrying risk in firmware, hardware components, BMCs, boot processes, security processors, network interfaces, or other layers below the OS. These layers can affect whether the device is truly in a known-good state, whether it has drifted from baseline, whether it contains vulnerable firmware, and whether it should be trusted for sensitive workflows.

That is the below-the-OS gap.

Traditional tools often focus on what the operating system can see. Zero Trust device decisions increasingly require evidence about the device itself: firmware and component inventory, hardware roots of trust, known-good integrity verification, vulnerability and patch posture, and drift detection.

This is where device trust becomes more than endpoint management. Agencies need authoritative signals that can support access decisions, compliance reporting, threat detection, and remediation across the full device stack.

Why 2026 Is the Window to Act

The Device pillar’s front-loaded schedule means 2026 is not a planning year. It is an execution year.

Agencies that act now can use 2026 to establish baselines, integrate telemetry, refine policies, and build evidence before the FY2027 deadline. Agencies that wait risk discovering too late that their existing endpoint and management tools do not provide the depth of device trust required for Target Level outcomes.

The practical work should start with five priorities.

1. Identify device-health visibility gaps. Start by comparing current tooling against the Device pillar activities. Determine which assets, firmware layers, unmanaged devices, network devices, servers, BYOD, IoT, or NPEs are not adequately covered.

2. Establish known-good device baselines. Do not wait until enforcement is required to define what “trusted” means. Establish baseline expectations for hardware, firmware, configurations, vulnerabilities, and patch posture.

3. Extend vulnerability and patch management below the OS. Firmware vulnerabilities and insecure configurations can create risk that traditional scanners miss. Target Level progress requires a more complete view of device exposure.

4. Integrate device-trust signals into enforcement workflows. Device telemetry becomes more valuable when it informs C2C, NAC, ZTNA, UEM, IdP, PAM, EDR, XDR, SIEM, SOAR, and ITSM workflows. The goal is not another dashboard. The goal is better authorization, detection, prioritization, and response.

5. Produce evidence continuously. Target Level readiness is not just a matter of implementation. Agencies need measurable evidence that controls are operating, telemetry is current, baselines are enforced, and exceptions are understood.

How Eclypsium Helps

Eclypsium helps agencies accelerate progress toward DoW Zero Trust Target Level activities by providing authoritative device-trust signals that traditional OS-level tools often miss.

These signals include firmware and component inventory, integrity verification against known-good baselines, vulnerability and patch posture, and drift detection. They can be managed directly within the Eclypsium platform or integrated into C2C, NAC, ZTNA, UEM, SIEM, XDR, SOAR, ITSM, and other enterprise workflows.

That support is especially relevant to the Device pillar, where agencies must move from basic endpoint visibility to continuous device compliance and authorization. It also supports related outcomes in User, Application and Workload, Automation and Orchestration, and Visibility and Analytics, where device posture can enrich access decisions, vulnerability workflows, incident response, threat intelligence, and compliance evidence.

The point is not that any single platform “solves” Zero Trust. The point is that Zero Trust decisions are only as trustworthy as the signals behind them. For the Device pillar, those signals need to include the layers of the device that traditional endpoint tools may not see.

The Device Pillar Is A Prerequisite For Achieving The Others (So You Should Do It First)

The end of FY2027 remains the formal Target Level deadline. But for the Device pillar, agencies should plan as though the decisive work happens in 2026.

That is when device inventories need to become authoritative. That is when known-good baselines need to be established. That is when firmware and component risk needs to become visible. That is when device posture needs to begin flowing into access, monitoring, and response workflows. And that is when agencies need to start producing the evidence that shows real Target Level progress. In our eyes, the hardest Device controls are front-loaded, so the time to act is now.

To learn more about how Eclypsium covers 31 of the most challenging DoW Target Level Zero Trust activities, download the Eclypsium Supplement Guide.

Frequently Asked Questions

What is DoD Zero Trust Target Level compliance?+

DoD Zero Trust Target Level compliance refers to the Department’s expected implementation of a defined set of Zero Trust capabilities and activities by the end of FY2027. For the Device Pillar, Target Level compliance is not just a policy exercise. Agencies need to know what devices exist, understand whether those devices are trustworthy, and use device posture to support access decisions, monitoring, response, and compliance evidence. Eclypsium’s Zero Trust Supplement Guide explains how device-trust signals can help agencies prepare for Target Level outcomes.

Why is the Device Pillar important for Zero Trust compliance?+

The Device Pillar is important because user identity alone is not enough to make trustworthy access decisions. Agencies also need to know whether the device requesting access is known, managed, healthy, patched, and operating in a known-good state. This is why Zero Trust must extend beyond users and applications to the hardware, firmware, operating systems, and components that make up the device itself. Eclypsium’s guidance on applying DoD Zero Trust overlays to devices explains how device and component verification support Zero Trust outcomes.

Why should agencies focus on Device Pillar compliance in 2026 instead of waiting until FY2027?+

Although the formal Target Level deadline is the end of FY2027, many Device Pillar activities need to be operational, integrated, and producing evidence earlier. Device trust takes time to build because agencies must discover assets, close visibility gaps, establish baselines, integrate posture signals, tune policies, and validate reporting. Waiting until 2027 can leave too little time to mature enforcement and evidence workflows. Agencies can use 2026 to identify device-health gaps, strengthen baselines, and connect device-trust evidence to compliance and enforcement systems.

What makes Device Pillar activities harder than traditional compliance controls?+

Many Device Pillar activities require agencies to prove whether devices are actually trustworthy, not just whether they are enrolled in a management tool or protected by an endpoint agent. The hard activities include device health gap analysis, compliance-based network authorization, application control, file integrity monitoring, deny-by-default policy, managed BYOD and IoT support, asset and vulnerability management, EDR integration, and XDR integration. These activities depend on trustworthy device telemetry, operational workflows, and evidence that can be used across compliance, security, and access-control systems.

What does below-the-OS device trust mean?+

Below-the-OS device trust refers to security evidence from layers that traditional endpoint tools may not fully inspect, such as firmware, hardware components, boot processes, BMCs, security processors, and network interfaces. A device can appear compliant at the operating-system layer while still carrying risk in firmware or hardware. Target Level readiness increasingly requires visibility into these deeper layers so agencies can verify known-good state, detect drift, and understand firmware or component vulnerabilities. Learn more about Eclypsium’s approach to firmware security.

Why are traditional endpoint tools not enough for Device Pillar Target Level outcomes?+

Traditional endpoint protection, EDR, vulnerability scanners, configuration management, MDM, and asset inventory tools are necessary, but they may not provide complete evidence about firmware integrity, hardware components, insecure firmware configurations, or below-the-OS vulnerabilities. Device Pillar compliance depends on reliable device-trust signals that can support access decisions, compliance reporting, threat detection, and remediation across the full device stack. Eclypsium’s Zero Trust for physical devices and supply chains solution brief explains why device authentication must include hardware, firmware, and component validation.

What evidence do agencies need for Device Pillar compliance?+

Agencies need evidence that device controls are implemented and operating continuously. Useful evidence includes accurate device inventory, managed and unmanaged asset coverage, device health gaps, known-good hardware and firmware baselines, vulnerability and patch posture, firmware or component drift, compliance exceptions, enforcement decisions, and telemetry flowing into systems such as C2C, NAC, ZTNA, UEM, SIEM, XDR, SOAR, ITSM, and compliance reporting workflows. Eclypsium’s platform coverage and capabilities page outlines the types of device, firmware, component, vulnerability, and integrity evidence the platform can provide.

How does device posture support Comply to Connect, NAC, and ZTNA?+

Device posture gives enforcement systems a stronger basis for deciding whether a device should connect to a network, receive a certificate, access an application, or be quarantined. Instead of relying only on user identity or network location, agencies can use device condition as part of the authorization decision. Integrating device-trust signals into C2C, NAC, ZTNA, UEM, identity, PAM, SIEM, XDR, SOAR, ITSM, and vulnerability management workflows helps access decisions reflect actual device risk. The Eclypsium platform helps deliver device-trust telemetry into these operational systems.

What are the first steps agencies should take for Device Pillar readiness?+

Agencies should start by identifying device-health visibility gaps, establishing known-good device baselines, extending vulnerability and patch management below the operating system, integrating device-trust signals into enforcement workflows, and producing evidence continuously. These priorities help agencies move from basic endpoint visibility toward continuous device compliance, authorization, and reporting. Eclypsium’s approach to Secure Device Lifecycle Management supports device discovery, acceptance testing, production monitoring, vulnerability management, integrity monitoring, remediation, and compliance across the device lifecycle.

How does Eclypsium help with DoD Zero Trust Device Pillar compliance?+

Eclypsium helps agencies generate authoritative device-trust signals that traditional OS-level tools may miss. These include firmware and component inventory, integrity verification against known-good baselines, vulnerability and patch posture, and drift detection. Those signals can be managed in the Eclypsium platform or integrated into workflows such as C2C, NAC, ZTNA, UEM, SIEM, XDR, SOAR, ITSM, vulnerability management, and compliance reporting. Eclypsium’s Government Solutions page explains how the platform supports Device Zero Trust, firmware integrity, network device hardening, compliance, and cyber supply chain risk management for public-sector environments.

]]>Reverse Engineering & Hardware Hackinghttps://eclypsium.com/events/reverse-engineering-hardware-hacking/

Thu, 30 Apr 2026 21:43:25 +0000https://eclypsium.com/?p=16316The post Reverse Engineering & Hardware Hacking appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>The post Reverse Engineering & Hardware Hacking appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>CISA’s Advisory On Botnets: Why Banning SOHO Routers Won’t Fix Critical Infrastructure Cyber Riskhttps://eclypsium.com/blog/cisa-cybsersecurity-advisory-router-botnets-fcc-router-ban/

Tue, 28 Apr 2026 13:00:00 +0000https://eclypsium.com/?p=16307CISA recently released a new cybersecurity advisory focused on defending against botnets built from compromised consumer and small-office/home-office (SOHO) routers. The advisory highlights how threat actors are actively exploiting vulnerable, internet-exposed devices to build large-scale proxy networks. The timing of CISA’s advisory is notable. It arrives shortly after the FCC’s controversial move to restrict the […]

The post CISA’s Advisory On Botnets: Why Banning SOHO Routers Won’t Fix Critical Infrastructure Cyber Risk appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.

]]>CISA recently released a new cybersecurity advisory focused on defending against botnets built from compromised consumer and small-office/home-office (SOHO) routers. The advisory highlights how threat actors are actively exploiting vulnerable, internet-exposed devices to build large-scale proxy networks.

The timing of CISA’s advisory is notable. It arrives shortly after the FCC’s controversial move to restrict the import and sale of certain foreign-made consumer routers. Taken together, the message is clear: the SOHO router supply chain is being framed as a meaningful source of cyber risk to U.S. critical infrastructure.

There’s truth in that. But it’s also only part of the picture.

If the goal is to reduce cyber risk to critical infrastructure, focusing primarily on consumer routers risks missing where the most impactful leverage actually lies. It is in defending the enterprise edge of critical infrastructure companies.

Why SOHO Router Botnets Matter

SOHO routers have become a convenient resource for nation-state threat actors, including China-nexus groups such as Volt Typhoon, Flax Typhoon (Raptor Train), Salt Typhoon and others.

CISAs diagram of a basic covert network

The model is straightforward:

Exploit unpatched or poorly secured routers
Maintain persistence on those devices
Use them as distributed proxy infrastructure

This gives attackers several advantages:

Anonymity: Traffic appears to originate from residential IP space
Resilience: Takedown is difficult due to scale and geographic distribution
Plausible deniability: Attribution becomes significantly more complex

These botnets are not a target in themselves, but a staging ground. From there, attackers launch campaigns against higher-value environments including telecommunications providers, energy systems, and other elements of critical infrastructure.

Mitigating this class of threat is absolutely worthwhile. Restricting high-risk devices from entering the market may reduce future exposure at the margins. But it doesn’t address the full problem.

What the CISA Advisory Actually Recommends

Beyond highlighting the threat, the advisory also provides concrete guidance for organizations to defend against this activity. The recommendations include:

Mapping and understanding network edge devices, with a clear inventory of what assets exist and what should be connecting to them
Establishing baselines for normal network behavior, particularly around VPNs and remote access services
Identifying anomalous connections, including traffic originating from consumer broadband ranges
Leveraging dynamic threat intelligence feeds to identify known malicious infrastructure
Implementing multifactor authentication for remote access

None of this guidance is controversial. In fact, it reflects well-established security best practices.

And that’s the point.

These are not new controls introduced in response to SOHO router botnets. They are foundational measures that organizations responsible for critical infrastructure should already have in place.

The Real Implication of the Guidance

Taken at face value, the advisory is framed around external risk driven by botnets built from compromised consumer devices. But the defensive measures it emphasizes are almost entirely focused on internal visibility and control.

Knowing what devices exist at the network edge
Understanding what “normal” looks like
Detecting deviations from that baseline
Securing access pathways like VPNs

This is not about stopping botnets from being created. Organizations don’t control that. Protecting the organization comes down to the condition and integrity of the systems inside the network.

If enterprise edge devices are properly secured, patched, monitored, and validated, then it matters far less whether an attacker is routing traffic through a compromised home router or any other proxy infrastructure. You can worry a lot less about getting targeted by botnets if they’ve got nowhere to actually break in or pivot inside your own network.

Where Organizations Actually Have Leverage

There’s a tendency to focus on upstream threats. But most organizations can’t effectively act on information about where attacks originate, what infrastructure adversaries are using, or how they build scale.

For defenders, the highest leverage is almost always downstream. Organizations cannot realistically prevent botnets from being created. They cannot control the global population of vulnerable consumer devices.

What they can control is their own environment:

Whether their network infrastructure is running vulnerable or end-of-life firmware
Whether their devices are authentic and free from supply chain tampering
Whether access paths are hardened with strong authentication
Whether abnormal activity is detectable and acted upon quickly

That’s where the outcome of an attack is decided.

The Limits of a Consumer Router Ban

Banning or restricting certain SOHO routers may help, but it’s an incomplete solution for several reasons.

First, the existing installed base of vulnerable devices doesn’t disappear. Millions of routers already deployed across homes and small businesses will remain exposed for years.

Second, attackers are adaptable. If one class of device becomes harder to exploit, they will shift to others. The Mirai botnet was recently discovered targeting DVR devices. The same potential lies within countless consumer and enterprise IOT devices, edge appliances, or any system with weak security controls and internet exposure.

Third, enforcement is inherently uneven. Grey markets, resale channels, and secondary distribution paths make it difficult to fully control what devices are actually in use.

In other words, a router ban can reduce some risk at the edges. It does not fundamentally change the attacker playbook.

The Bigger Risk Is Already Inside Critical Infrastructure Networks

If we step back and look at where these campaigns are ultimately headed, a more uncomfortable reality emerges.

Critical infrastructure organizations and federal agencies already operate large amounts of vulnerable network technology inside their own environments.

This includes:

Firewalls with known, actively exploited vulnerabilities
VPN appliances exposed to the internet
Routers and switches running outdated or end-of-life firmware
Network management interfaces accessible from untrusted networks

CISA has issued multiple executive directives, advisories and binding operational directives over the past year calling for the remediation or removal of exactly these types of systems.

The pattern is consistent: attackers don’t just rely on external infrastructure like SOHO botnets. They actively target weaknesses within enterprise networks themselves.

In many cases, these systems are:

Directly exposed to the internet
Highly privileged within the network
Difficult to patch or replace quickly

From a risk perspective, that combination is far more consequential than a compromised consumer router acting as a proxy.

Supply Chain Risk Doesn’t Stop at Consumer Devices

The focus on foreign-made SOHO routers also highlights a broader concern about supply chain risk. The concern is valid, but the current supply chain is so complex and international that achieving a U.S. only supply chain for technology products will take years or decades. That isn’t a solution for immediate risk. And again, the risk being addressed in the router ban is not confined, or even primarily relevant to consumer hardware.

Enterprise and mission-critical systems face significant supply chain challenges of their own, including the persistent issue of counterfeit components.

A 2019 report from the Defense Systems Information Analysis Center estimated that approximately 15% of spare and replacement parts for U.S. Department of Defense equipment are counterfeit.

Counterfeiting affects a wide range of technologies:

Network switches
Graphics and compute hardware
Embedded systems used in defense and infrastructure

The risks associated with counterfeit or unauthorized components go beyond reliability:

Modified or malicious firmware
Hidden backdoors
Inconsistent or unpatchable software states

Unlike a vulnerable consumer router on the edge of the internet, these components are often deployed directly within sensitive environments. That makes their potential impact significantly greater.

The Real Gap is Lack of Device Integrity Visibility

Across both consumer and enterprise contexts, one theme keeps emerging: organizations often lack visibility into the actual state of the devices they depend on.

Security decisions are frequently based on assumptions:

That hardware is genuine, and has been provided in a secure state by the vendor
That firmware is up to date and hasn’t been tampered with
That configurations match expected baselines

Those assumptions are not always verified before deploying the hardware.

This creates a gap between what organizations believe about their infrastructure and what is actually true. That gap is where supply chain risk lives.

The Need For Continuous Device Integrity Validation

If the objective is to meaningfully reduce cyber risk to critical infrastructure, the focus needs to shift from restricting specific device categories to verifying the integrity of all devices in use.

That means treating device trust as something that must be continuously reëstablished, not assumed.

A more effective model includes integrity checks and security validation across the entire device lifecycle:

Before deployment:

Validate hardware authenticity
Verify firmware integrity against known-good baselines
Confirm supply chain provenance

During operation:

Continuously monitor for firmware drift or unauthorized changes
Detect configuration anomalies
Identify unexpected behavior at the device level

Throughout the lifecycle:

Ensure patch integrity, not just patch presence
Track end-of-life status and enforce replacement policies
Revalidate devices after maintenance or component changes

This approach directly addresses the root issue: whether the devices inside critical infrastructure can be trusted.

Policy vs. Practice

Efforts like the FCC router ban are not without merit. They signal recognition that supply chain risk is real and that hardware can be an attack vector. But policy interventions alone cannot solve a problem that is fundamentally technical and operational.

Attackers are not limited to one class of device, one vendor, or one supply chain path. They exploit whatever is available, wherever verification is weakest.

If defensive strategies focus too narrowly on restricting inputs by controlling what can be bought or imported, they risk overlooking the much larger challenge of securing what is already deployed.

Where the Real Leverage Lies

SOHO router botnets are a real threat, and mitigating them is worthwhile. However they are a means to an end.

The actual targets remain critical infrastructure networks, where vulnerable, unverified, and sometimes counterfeit systems already operate with high levels of access and trust.

If we want to reduce risk in a meaningful way, the focus needs to move closer to those environments. Not just controlling what enters the supply chain, but continuously validating what is already inside the organization’s walls.

Security isn’t determined by where a device was manufactured. Routers made in America will still have vulnerabilities, and will still reach end-of-support with units in the wild operating outdated firmware. It’s more effective to focus on whether you can trust what your devices are doing right now.

The Full Network Edge Risk Landscape

The landscape of risk at the network’s edge reaches far beyond SOHO router botnets. Our recent webcast untangles the growing risk facing enterprises from their own firewalls, VPNs, routers, and switches, with professional analysis of the F5 source code leak, recent Cisco Firepower exploitation, and more. View our webcast: Edge Of Catastrophe: How Network Device Attacks Became The Biggest Cyber Battleground.

FAQ: CISA Botnet Advisory and FCC Router Ban

What problem is CISA’s botnet advisory trying to address?+

CISA’s advisory focuses on the growing use of compromised consumer and SOHO (small-office/home-office) routers to build large-scale botnets. These botnets act as proxy networks that attackers use to obscure their origin and launch attacks against higher-value targets such as critical infrastructure systems.

Why are SOHO router botnets useful to attackers?+

Attackers exploit unpatched or poorly secured routers to create distributed infrastructure that provides anonymity (traffic appears residential), resilience (hard to take down at scale), and plausible deniability (difficult attribution). These botnets are not the end goal—they are staging platforms for attacks on enterprise and critical infrastructure networks.

Will banning certain consumer routers reduce cyber risk to critical infrastructure?+

Only marginally. A router ban may reduce some future exposure, but it does not address the large existing base of vulnerable devices already deployed, attackers’ ability to pivot to other device types (such as IoT or DVRs), or inconsistent enforcement across global supply chains. It does not fundamentally change attacker behavior or risk outcomes.

What defenses does CISA actually recommend for organizations?+

CISA emphasizes foundational security practices at the enterprise edge, including maintaining an accurate inventory of network edge devices, establishing baselines for normal network behavior, detecting anomalous connections (such as traffic from residential IP ranges), using threat intelligence to identify malicious infrastructure, and enforcing multifactor authentication for remote access. These measures focus on internal visibility and control rather than stopping botnets themselves.

Where should organizations focus to meaningfully reduce network edge cyber risk?+

Organizations should focus on securing and validating their own infrastructure. This includes patching and monitoring enterprise edge devices like VPNs and firewalls, verifying hardware authenticity and firmware integrity, detecting abnormal device behavior and configuration drift, and continuously validating device trust throughout its lifecycle. Risk is driven more by weaknesses inside the network than by the external botnets used to reach it.

]]>