PODCASTS

BTS #83 - AI's Impact on Cybersecurity

Below the Surface episode 83 brings host Paul Asadoorian together with Vlad Babkin for a wide-ranging discussion about AI-assisted vulnerability discovery, the shrinking patch-to-exploit window, and why network edge appliances remain such difficult systems to defend. The episode was recorded on October 2, 2026.

The conversation begins with AI’s accelerating role in both vulnerability research and exploit development. Paul and Vlad argue that AI is not simply making attackers faster; it is also helping skilled researchers and adversaries reason through complex exploit paths, patch diffs, compiler protections, and chained weaknesses that previously required much more manual work.

From there, the episode turns toward infrastructure: VPNs, firewalls, management appliances, BMCs, firmware, embedded Linux, and the limited visibility defenders often have into the systems that sit at the edge of the enterprise. The recurring point is practical: hardening matters, but so does evidence. If defenders cannot inspect, verify, monitor, and collect forensic artifacts from the devices they depend on, they are left trusting systems that attackers increasingly treat as high-value footholds.

Key Topics Covered

  • AI and the shrinking exploit window: Paul opens with the idea that AI is helping compress the time between patch release, exploit analysis, and active campaigns. The hosts connect this to rising vulnerability volume and the growing challenge of defending perimeter appliances before proof-of-concept or weaponized exploits appear.
  • AI-assisted vulnerability discovery: Vlad argues that AI makes it easier to analyze large codebases, identify base vulnerabilities, and reason through chains that would take humans much longer to inspect manually. The issue is not only faster exploit writing; it is faster discovery.
  • Exploit development as expert acceleration: Paul distinguishes between AI helping a novice and AI helping someone who already understands exploitation. For experienced researchers, AI can quickly map compiler flags, ASLR, PIE, SELinux, ROP requirements, and other constraints that shape a working exploit path.
  • Network appliances are not always hardened systems: The hosts discuss Citrix NetScaler and F5 BIG-IP examples as evidence that many security appliances still lack the full hardening defenders might expect. The larger point is that products marketed as hardened devices may still have incomplete memory-safety and OS-level protections. See Eclypsium’s work on F5 BIG-IP vulnerability detection. Eclypsium
  • Why firmware access matters: Vlad returns to a familiar theme: defenders need access to firmware, shells, and device internals in order to verify integrity and investigate compromise. Closed appliances may slow defenders more than attackers.
  • Hardening and monitoring have to work together: Paul argues that vendors should enable stronger Linux and BSD protections by default, including memory-safety-related compiler flags and OS hardening features. But he also emphasizes that prevention is not enough; teams still need behavioral monitoring, anomaly detection, and compromise detection.
  • The limits of eBPF on appliances: Paul asks whether eBPF could give defenders better telemetry from Linux-based network devices. Vlad’s answer is cautious: eBPF may help, but if attackers gain root or kernel-level control, they may be able to disable or evade it. Telemetry without forensic access still leaves gaps.
  • Why network devices are hard to investigate: The hosts compare laptops and servers, where teams can collect disk images and perform forensic analysis, with network appliances, where storage may be inaccessible, encrypted, undocumented, or locked behind vendor controls. Eclypsium notes that these devices often cannot run standard endpoint agents and require different visibility models. Eclypsium
  • Anomaly detection on relatively static systems: Paul points out that edge appliances often change less frequently than general-purpose Linux servers. That stability can help defenders detect unexpected file, process, configuration, or integrity changes—especially when version updates and support activity are treated as observable events.
  • NVIDIA’s AI agent sandboxing approach: The episode examines NVIDIA’s Open Agent Safety Platform, including OpenShell, Sentry, and BlueField-4 DPUs. Paul sees value in hardware-backed sandboxing and quarantine for agents, while Vlad warns that sandboxes should be treated as escape rooms unless backed by hard controls.
  • AI safety programs and defender access: Vlad criticizes AI vendors for talking about advanced cyber capabilities while limiting access to the models and programs that could help independent researchers and security companies find flaws. Paul discusses his own experience with OpenAI’s Daybreak validation process.
  • Management appliances as high-value targets: Paul discusses Bishop Fox’s Check Point management platform research and connects it to broader attacks against management systems such as Cisco Firewall Management Center and Fortinet FortiManager. These platforms often hold credentials, configurations, VPN details, routes, and other sensitive control-plane information.
  • VPN appliances and exposed services: The hosts separate accidental exposure of management interfaces from the unavoidable exposure of VPN services. VPNs often need public listeners, making bugs in those services especially dangerous. Vlad argues for simpler, better-understood components such as OpenVPN or WireGuard rather than custom appliance stacks.
  • Linux privilege escalation and appliance risk: Paul notes the continued stream of Linux local privilege escalation vulnerabilities, including Dirty COW, Dirty Pipe, Dirty Frag, Copy Fail, Docker-related issues, and Spectre variants. For Linux-based appliances, these bugs can matter because many services run with too much privilege or expose broad post-exploitation paths.
  • File notification side-channel research: The episode closes with a novel class of research involving file notification systems across Linux, Android, Windows, and macOS. Paul frames it as an early-warning research area: not necessarily a stop-everything emergency, but the kind of side channel that may later become one step in a larger attack chain.

Timestamps

00:00 – Audio setup and pre-show microphone troubleshooting
02:09 – Episode preview: AI, exploit speed, NVIDIA agent safety, Check Point, and file notifications
02:37 – Welcome to Below the Surface episode 83
02:51 – Eclypsium listener resources and AI infrastructure context
04:10 – AI, vulnerability volume, and rising advisory counts
05:08 – Why AI changes large-codebase vulnerability analysis
06:06 – Google’s reported growth in vulnerability disclosure and exploited flaws
08:35 – Vlad on AI increasing both speed and sophistication
09:27 – AI as an accelerator for experienced exploit developers
11:37 – Faster base vulnerability discovery and pressure on source-code analysis tools
12:05 – F5, NetScaler, compiler protections, and incomplete appliance hardening
14:05 – AI and web application exploit development
15:15 – Guardrails, open models, and the practical reality of AI-assisted exploitation
16:36 – Hardening network edge appliances with Linux and BSD security features
18:33 – Vlad on closed platforms, firmware access, and defender visibility
19:52 – Whether eBPF can improve appliance telemetry
20:37 – Vlad’s critique: eBPF is useful, but not enough
22:09 – Cat-and-mouse monitoring, /tmp abuse, and attacker adaptation
23:24 – Why forensic access is harder on network appliances than endpoints
24:54 – Anomaly detection and why appliance operating systems can be easier to baseline
27:43 – NetScaler attacks, malware reporting, and attacker adaptation after public IOCs
28:51 – NVIDIA Open Agent Safety Platform, OpenShell, Sentry, and BlueField-4 DPUs
29:56 – Sandboxing AI agents and the risk of sandbox escape
31:51 – Daybreak, cybersecurity model access, and validation barriers
33:03 – Vlad’s critique of restricted access to advanced cyber-capable AI systems
35:11 – Bishop Fox research on Check Point management software
35:26 – Management platforms, Cisco FMC, FortiManager, and appliance control planes
37:51 – Why configurations, credentials, VPN data, and routing details make managers attractive targets
39:01 – Vlad on distrust of closed appliances and lack of defender control
40:03 – VPN appliances, exposed services, SSL VPN, IPsec, and RCE risk
42:15 – Using known-good VPN components and reducing exposed attack surface
43:37 – Internet-exposed BMCs and the danger of root-running services
44:39 – Linux local privilege escalation trends and visibility after compromise
47:11 – Open source, Linux vulnerabilities, and why visibility helps defenders patch
47:59 – File notification side-channel research across major operating systems
51:00 – Vlad on legitimate and unexpected uses of file notifications
52:20 – Closing thoughts

Core Eclypsium References

Companies, Products & Platforms Mentioned

  • NVIDIA Open Agent Safety Platform
  • OpenShell
  • Sentry
  • NVIDIA BlueField-4 DPUs
  • Hugging Face
  • OpenAI Daybreak
  • Anthropic Glasswing
  • Mythos
  • Claude
  • Google / Mandiant
  • Check Point management platform
  • Bishop Fox
  • Cisco Firewall Management Center
  • Fortinet FortiManager
  • Citrix NetScaler
  • F5 BIG-IP
  • Fortinet VPN appliances
  • Cisco IOS XE
  • OpenVPN
  • WireGuard
  • Linux, BSD, Android, Windows, and macOS

Concepts & Technical References

  • File notification side channels
  • Patch-to-exploit window
  • AI-assisted vulnerability discovery
  • AI-assisted exploit development
  • Public exploit code
  • Remote code execution
  • Local privilege escalation
  • Management plane exposure
  • Network edge appliances
  • VPN termination
  • BMC exposure
  • Firmware integrity
  • Device shell access
  • eBPF telemetry
  • Forensic imaging
  • Anomaly detection
  • Indicators of compromise
  • Tactics, techniques, and procedures
  • ASLR
  • PIE
  • SELinux
  • ROP gadgets
  • Stack canaries
  • No-execute stack protections
  • Dirty COW
  • Dirty Pipe
  • Dirty Frag
  • Copy Fail
  • Spectre v2

Transcript

Paul Asadoorian (02:09.444): This week: AI shrinks the patch-to-exploit window. NVIDIA wants to put AI agents in a box. Can AI help researchers find the next remote code execution? Check Point management has a one-port problem. Your file notifications are telling on you. Stay tuned — Below the Surface, coming up next.

Paul Asadoorian (02:37.894): Welcome to Below the Surface. It’s episode number eighty-three, being recorded on October second, twenty twenty-six. I’m Paul Asadoorian, joined by Mr. Vlad Babkin. Vlad, welcome.

Vlad Babkin (02:48.833): Welcome and hello!

Paul Asadoorian (02:51.194): Good to have you here, Vlad. Just a quick announcement before we get started. Below the Surface listeners can learn more about Eclypsium and how we help organizations assure and secure the infrastructure their operations depend on by visiting eclypsium.com/go. There you’ll find our guide to AI data center security, our white paper on eradicating hidden threats in network edge devices, and a case study showing how a major cloud provider used Eclypsium to protect its infrastructure hardware during a merger and IT consolidation.

You can also request a demo to see how Eclypsium verifies device integrity, hardens against risk, and detects active exploits across enterprise infrastructure — from the AI data center to the network edge to user endpoints. Find it all at eclypsium.com/go.

Speaking of AI infrastructure and AI models, I think our top two stories this week are centered around AI, which has become a fundamental part of many of our workflows. Regardless of your role, I think you’re using AI in some capacity, and certainly people are using it to find vulnerabilities in things.

As we’ve established here on the show, this has been a growing trend, and I think the numbers support it across the board. Wherever you look today, we just have more vulnerabilities, more patches, just more of it, because AI is enabling us to find these vulnerabilities. If we look at the AI Infra Trust Pulse, we can show that even though we’ve added more vendors and slid the time frames around, if you just look at the past three reports, the number of advisories and CVEs is growing exponentially. I think our coworker Eric told me that over a thousand Linux kernel CVEs were published just yesterday.

And I think we can attribute all of this to AI models. Is there really any other explanation for it?

Vlad Babkin (05:08.179): Nope. It’s literally just AI models, and a lot more people hunting for vulnerabilities using AI. Imagine that you have a project with 150,000 lines of code. Let’s say something closer to child-toy size. Well, it’s not quite child-toy size, but it doesn’t compare with major projects with millions of lines of code. Even analyzing that manually…

Paul Asadoorian (05:34.896): I think I looked this up before: how many lines of code are in the Linux kernel? I think it’s tens of millions, the last I looked.

Vlad Babkin (05:42.454): Yeah, it’s an insane amount of lines, and I guarantee you no human is going to be able to review that many. It’s just too much. AI lets us go through all of them at no cost. “Hey, Claude, look for vulnerabilities in this code. I want to fix them,” and Claude just goes. It might find them literally by the hundred.

Paul Asadoorian (06:06.255): Yeah. And it’s no secret that LLMs have capabilities we didn’t have before in the tools that look at our source code. Our tools before really didn’t have that intelligence, that ability to learn from previous examples, apply that to a code base, and recognize and correlate multiple patterns together. As many of us know who listen to how AI models work, one of the things they’re really good at is finding vulnerabilities in source code. Google says vulnerability disclosure doubled in twenty twenty-six, reaching ten thousand seven hundred and forty in August, while exploited vulnerabilities have already surpassed the total from twenty twenty-five.

It also says in this article that a larger concern is AI helping attackers analyze patches and public exploit code, turning newly disclosed flaws into working attacks within days, especially against perimeter appliances and exposed enterprise services. We can back that trend up. Every one of those that comes out, I read and attempt to get our teams to build the detections necessary, especially for these perimeter appliances, as they call them.

I was talking with someone else about this, the CTO of ThreatLocker actually, and I’m curious to get your take on this, Vlad: with threat actors enabled with AI, I don’t see the attacks necessarily getting more sophisticated. However, I see AI enabling them to move more quickly, and with better accuracy and efficiency. I think that’s what Google’s report is preying on, right? Patch comes out, public exploit code is out right away, and campaigns are already beginning — if they hadn’t discovered it as a zero-day.

So, question to you, Vlad: do you see speed and efficiency over sophistication when attackers use AI?

Vlad Babkin (08:35.853): Yep, so it’s not even speed and efficiency over sophistication, it’s both. AI can find and chain stuff that would take humans months to properly chain. Imagine that you find a missing boundary check five levels deep in a kernel driver. When are you going to build the exploit for it? Probably not very fast by hand, right? It will take you a while to analyze the full code. AI does this immediately.

It just instantly finds the full path. So the task for the human is then pretty much just to hunt down all of these things and chain them together. That’s the human part, and potentially also the AI-assisted part: “Hey, look, I found these five separate issues which I can use to build something.” Great.

Paul Asadoorian (09:27.718): Especially if you already know how to build an exploit. There are classes of people who can construct exploits, from super ninjas on down — high, medium, low, that kind of thing. But if you fall somewhere on that scale where you know how to build an exploit reliably, using AI as an assistant is going to shorten your time. That’s very different from “I’ve never built an exploit and have to use AI to do it,” where I think there’s a lot of mixed success. But if you know how to build an exploit, AI is going to tell you very quickly, with a two-second query: what compiler flags exist in this binary that might prevent my exploit from running? What protections on the system might be running? Like we talked about PIE, the compiler flag which, if ASLR is enabled, allows the binary to run in that randomized memory space.

So AI is able to map all that out and then tell you what you’re going to have to build. I’m going to have to build a ROP gadget. I’m going to have to find some other way because SELinux is enabled on this box. So you know that, and you’ll have to find a way around it as well. It can help you figure out what that path is going to be, and you can guide it with your expertise in developing an exploit based on that path. You’re not hitting those dead ends or doing all that research, which can take more time. AI is giving you the landscape and telling you, “Look, this is probably your path,” and then you can use AI to help construct an exploit along that path. Even better if you’ve got examples of exploits that already exist, and for a number of these network edge appliances, there are example exploits out there.

That makes your job that much easier. If you have a body of work that already exists, that is great context for AI. So it’s no wonder these exploits are being created so quickly.

Vlad Babkin (11:37.666): Yep. And it’s not even just exploits being created so quickly. How do I best put it? The time is shortening by a lot, not just because it’s easier to build exploits, but also because it’s easier to find the base vulnerabilities. In the past — basically what I heard a person say is that a lot of vendors selling source code analysis tools are in a very bad spot.

Paul Asadoorian (12:05.647): Yeah, I agree. That is not an industry you want to be in or investing in. Not that I’m giving investment advice, but that is a hundred percent being impacted by AI today. I also think, and Vlad, you can speak to this as well, that when we analyze the exploits and payloads being constructed and used on network edge appliances, it’s very much like writing an exploit or malware twenty-plus years ago. The protections just don’t exist. What I observed in both the Citrix NetScaler and F5 BIG-IP cases is that there were some protections: the binary had some compiler flags that implemented some of the memory safety tricks in the compiler, and the systems themselves had some level of protection, but not all of the protections were in play. You might have no stack execution but not have the canary enabled. You might have ASLR, but the binary wasn’t compiled with PIE, so it’s not going to work.

If you read the watchTowr Labs write-ups — I think they wrote up both, how to construct the exploit for F5 and NetScaler — they were very well done. The higher-level takeaway, because obviously those blog posts are very technical (if you don’t have a computer science or exploit-writing background, you’re going to do some research before you read them), is that these systems are not hardened devices. Even though they’re marketed as hardened devices, they’re not fully hardened.

Vlad Babkin (14:05.003): They aren’t. They actually aren’t.

And this is a case not just for binaries. It’s also a massive case for web app exploits. Plain web app exploits are much easier to build now. How do I put this best? It’s a field where you don’t even have to worry anymore about building them. Claude can analyze vulnerabilities and spit out a full report for you, and after that, if you’re an experienced guy with exploits, it will take you a few days to read through it and have your mind blown, because there are so, so many exploits.

Paul Asadoorian (14:54.309): Right. Your audio’s kind of crackling. I don’t know what’s going on with your audio, Vlad. It’s crackling and skipping. It could be the network.

Vlad Babkin (14:59.853): It’s probably the network. I don’t know. Is it better?

Paul Asadoorian (15:09.339): Hopefully it corrects itself. I’m waiting for it to correct. Yeah, it did. Okay. Sorry. Continue.

Vlad Babkin (15:15.969): Yeah, it’s just the network. Anyway, the fun part is that you don’t have to think about some of the simpler stuff anymore. The grueling part of exploit writing was always, “Hey, the vendor decided to escape this one character,” which makes the whole process painful. Now you’re hunting for an escape for this one character and having to be creative about it, and that’s not work that is usually interesting for the hunter. AI just does it instantly.

And if you think AI is infallible and has full guardrails, you’re wrong again. Guardrails for AI are not perfect, even for closed projects like Claude and OpenAI, let alone anything open source. And if you think open source is bad and should be banned because of this, that’s also a stupid position, because now you’re pretty much locked to two vendors who decide who gets it and who doesn’t. If they decide you don’t, well, good luck. Anybody can walk in the front door and you have no tools to defend yourself with.

Believe it or not, Chinese companies are probably doing a lot more for safety than the so-called companies with high morals. I’m not calling out specific names, because there is more than one and more than two. I’m not just talking about those two companies everybody talks about.

Paul Asadoorian (16:36.645): Yeah, I think the call to action, and it’s well within reach, is for companies that make these network edge appliances to harden their devices. Most of them have Linux or BSD underneath the covers, which is highly customizable and has the capabilities — excuse the pun if you’re a Linux nerd — and features inside the system to be able to harden it. The examples I mentioned are all of the memory safety and application safety things you can do on Linux: ASLR, SELinux, everything you can do with compiler flags. Those should be table stakes today, because of the point we made at the top of the show: it’s way easier to find vulnerabilities and create exploits today with AI assistance. Your devices therefore have to be more hardened than they were before, to raise that bar and make it more difficult to get a working exploit on that system.

Are you going to make it impossible? No. That’s why we also monitor these systems for behavior, for changes, for anomalies, for indicators of compromise. You have to do that too. You can’t just harden and you can’t just hunt; you have to do both. And you also have to patch them to the latest version. I will say, and I think you’ve experienced this too, that later versions of a lot of the operating systems and code for these network appliances do get better. I have seen improvements from vendors where the latest version has better protections. Fortinet, as an example, enabled a much safer encryption, or hashing algorithm I should say, for passwords. So the later the version you’re on, the more features I believe you’re going to have to harden and protect your devices.

Vlad Babkin (18:33.399): Yes, but also no. The problem with these devices is that they are closed. The only way to fix this is for network vendors to finally understand that closing their platform is not doing anybody any good. Attackers will crack your encryption, especially with AI. It’s not a question of if or how clever you are, it’s a question of when, and when they do, your customers are the ones getting… you know what they’re getting. I don’t want to use swear words on stream, but outside of that, this is the only way. You have to give defenders access to firmware and to the device shell. Some vendors already do this, and kudos to those vendors. For example, Cisco IOS XE gives you a Bash shell on the device. So, hey, you get to hunt for exploits if something happens. You get to scan the devices in depth. You get to check their integrity in depth. But many other vendors don’t, and that’s a mistake. I’m pointing this out in every single BTS episode, and this one is no exception.

Paul Asadoorian (19:52.614): How do you feel about enabling eBPF on Linux-based devices so that the customer or a vendor could collect some telemetry, perhaps a way to implement your own modules in there? I understand the vendors are gun-shy with this particular thing because it’s running inside the kernel, but to have that visibility inside these devices, where there is a feature in Linux that allows us to collect that telemetry… I can’t see a way to convince vendors to do this, because it could impact performance and stability of the system. But what are your thoughts on that, Vlad?

Vlad Babkin (20:37.355): Not enough. My thought is: not enough.

Paul Asadoorian (20:42.565): Really? eBPF? Because you create visibility. Great telemetry, no?

Vlad Babkin (20:47.743): It just isn’t. I don’t know how great it is, but it just isn’t all that good. Explanation: when attackers attack, they get root privileges on the device. They get to do whatever the hell they want, because that is how these devices operate. There is nothing you can do about this. Get on with your life. You cannot, when the attackers get root privileges. If you only get eBPF, attackers get to disable your eBPF, because they have higher…

Paul Asadoorian (21:26.415): Yeah, they can mask. Once the attacker’s in the kernel, it’s kind of game over, right?

Vlad Babkin (21:32.206): And once they get code execution, if your eBPF misses even one spot where an attacker can get in without your eBPF noticing, GG. You are never going to see the attacker again. And eBPF does not allow you to collect a forensic artifact. It will make the game much more difficult for attackers, I’ll concede that point, but it becomes a cat-and-mouse game. What does your eBPF actually monitor? And eventually you’ll have to install a BPF program that monitors every single file operation, which will produce a lot of noise and a lot of load on the device. And it’s not even safe by itself.

Paul Asadoorian (22:09.423): No, it’s true. If you start limiting the scope of what you’re monitoring because you don’t want to impact the performance or stability of the device, which I get — some of these devices are huge routers routing traffic for large portions of the internet, as an example, and you don’t want to impact the performance and stability of that device — once you start limiting the scope of your visibility due to those concerns, that gives attackers other places to hide.

One of the techniques we’ve observed being used a lot in the past few years especially is attackers loving to write stuff to /tmp. Why is that? Everyone who knows Unix and Linux knows it’s the one world-readable and world-writable directory that exists on all systems with the same name and same permissions, so it’s a safe place for attackers to go. They know they can drop stuff there because /tmp is always world-writable. As soon as we start monitoring that, they’re just going to change their tactics. They’ll be like, “Well, where else can I write that’s not being monitored? How else can I hide from the monitoring that’s going to happen in /tmp?” So it’s a cat-and-mouse game. It’s always been a cat-and-mouse game.

Vlad Babkin (23:24.405): And that’s going to happen very quickly. And if you don’t give your cat enough privileges, the mouse is going to win every single game. Imagine, okay, traditional machines: let’s say your computer got exploited. Let’s say your initial tooling, like your EDR tool, just failed to see the mouse. Let’s presume that. Not a very hard assumption. Agree? Agree. Now you can get forensic images. You can shut down the laptop, take out the drive, and pull an image of the drive. You have full documentation for what’s supposed to be there — well, as full as you can get with things like Windows. But you get to do a lot of forensic work, and even, if you want, some dynamic forensics. With network devices, the only route is pretty much to disassemble the device and hope that the drive is not encrypted, which in many cases is not true.

It just isn’t… It’s not true.

Vlad Babkin (24:39.925): Now what? You don’t get forensic images in many cases, because vendors are just stingy with you. They don’t give you access, they don’t give you anything. So even if you manage to catch a mouse, good luck actually pulling out the details about the mouse.

Paul Asadoorian (24:54.937): Yeah, my concern is that once the TTPs and IOCs, if you will, are published and public, most attackers are going to pivot their techniques to get around that. Which is why one of the initiatives on everyone’s mind is how we do anomaly detection, so we’re looking for less specific things that happened and more generic behaviors that happen.

One thing that works to our advantage on these devices, and I was talking to one of our coworkers about this, is that the underlying operating system, usually Linux, sometimes BSD, is not something that is actively managed and maintained by the user or the admins. The admins are using a router, a VPN, a firewall, or a switch at a higher level to configure the functionality. It might run Linux underneath, but that’s not something you typically interact with. I get it: you open a support case, you do some troubleshooting, they might have you go in there and collect evidence and maybe make changes. And certainly when you apply version updates and patches, that could change it.

But for the most part, those two use cases aside, the artifacts on a Linux system that represents an appliance don’t change that much. Compare that to a Linux server. Linux server administrators are configuring services, provisioning users, customizing the system. They’re making changes, and it’s much harder to hunt there because more changes are expected on those systems. On network appliances, a lot less change is expected. I think as an industry we can do better with anomaly detection on these devices. I also think enterprise teams doing incident response and threat hunting can do a much better job, because there’s just stuff that shouldn’t change or be modified in the normal course of an edge appliance’s life. Again, updates and support cases aside.

But an update is an observable event. So if you’re looking for anomalies one day, and then the next day you’re looking for anomalies and you notice that one thing that changed was the version, now you know there are some expected changes.

Paul Asadoorian (27:43.323): So I think there’s a lot we can do better across the board, as an industry and a community, to not make it so easy for threat actors to target the network edge and be successful there. Like Vlad said, we’ll come back to this every week, because every week there are new vulnerabilities, new exploits, new payloads, new campaigns, and threat actor groups targeting these every single week.

To read more about the NetScaler attacks — I should have put the story in here — we are analyzing that. Google’s Threat Intelligence Group, or Mandiant, published an article that detailed and named the malware. I forget what they called it, but they named the malware, the techniques, and the behaviors in a post. Now, like I said before, I fully expect the threat actors to read that same report and go, “Well, our payloads and malware are burned. Now we’ve got to do something different, because that’s what people are going to be looking for.”

Vlad Babkin (28:48.0): Immediately. Not a big surprise.

Paul Asadoorian (28:51.136): An interesting announcement from NVIDIA this week: they announced their open agent safety platform. They say it combines the open-source OpenShell runtime with a hardware enforcement layer called Sentry on BlueField-4 DPUs. The system is designed to sandbox agents, enforce policies, log decisions, and quarantine agents that try to take actions outside of their approved boundaries.

This to me sounds reasonable. No? I’m also trying to be somewhat critical, as part of our jobs, of new defensive technologies, especially ones centered around AI, which is highly ubiquitous and very dynamic, especially when we talk about agents. But this is not a bad strategy, no? I don’t know how much you read into the story, Vlad.

Vlad Babkin (29:56.234): It isn’t. In all honesty, it just isn’t. We need to put AI in a box. The only problem with sandboxing AI is that a sandbox is like an escape room for AI. It will make things somewhat harder, but I’m going to defer to the Hugging Face incident instead.

Paul Asadoorian (30:16.741): Well, that was a very weak sandbox. I will give NVIDIA some credit for doing this more at the hardware layer and providing the ability to quarantine agents. On the Hugging Face incident, from what I read, the sandbox was not very good. It wasn’t that hard for an AI to break out of it, because it really wasn’t much of a sandbox.

Vlad Babkin (30:41.751): I can’t disagree with you. If I’m completely honest, I cannot disagree with you in good conscience. NVIDIA is probably doing a lot better than that sandbox. Something else AI vendors don’t do enough is focus on hard controls.

We are all talking about AI safety, how dangerous AI is, how the AI apocalypse is upon us. Guys, it’s been upon us since 2020. It’s 2026. Where is the apocalypse?

At some point the marketing just stops working, and your marketing is making defenders’ lives harder. “Hey, we’re building yet another sandbox.” Guys, what you should focus on is getting defenders the tools. A lot of defender companies don’t get access to Mythos, don’t get access to whatever OpenAI calls their programs. I currently don’t even know all of the names. It’s Daybreak now, and we’re living with something else.

Paul Asadoorian (31:51.302): Yeah, OpenAI is Daybreak. They have Daybreak Red and Daybreak Blue, which is interesting. If you apply as an individual and purchase a Pro plan, you can get Daybreak, but you don’t get an actual model. They tell you to use GPT-[model name unclear] or one of the other models, and it’s just approved to do more cybersecurity work than if you’re not validated. I actually just went through the validation process, which was a huge pain in the butt, by the way. Dude, I had to buy a new YubiKey. I needed a YubiKey 5 hardware token associated with my OpenAI account before they would unlock Daybreak for me, which is nuts. I had to buy something. A physical thing.

Vlad Babkin (32:31.029): And it’s not even that. If it would at least give you Daybreak Red for pentesters, I’d get this. Right now, so-called companies worried about safety give customers who are just big names access to red-teamer tools, but actual red teamers don’t get anything.

Paul Asadoorian (32:44.901): Which it didn’t. It gave me Blue. It didn’t give me Red, it gave me Blue.

Vlad Babkin (33:03.775): As long as this continues, I’m going to start calling these companies out. It’s time to put some pressure on, maybe make an open letter to AI companies, because at this point it’s getting ridiculous.

Paul Asadoorian (33:17.317): I think if you have an enterprise account, you can apply for some of these models. But again, the AI companies are trying to gate this technology, and I get both sides, but no.

Vlad Babkin (33:23.573): Paul, you just cannot. Even if you are an enterprise, applying for access to these programs is not a thing you can do. You cannot apply for Glasswing. Good luck. You aren’t applying for that. That’s Anthropic.

Paul Asadoorian (33:44.389): Glasswing’s OpenAI’s… Mythos is the model, and the project is called Glasswing. It is Anthropic. Yeah, yeah, I gotcha.

Vlad Babkin (33:52.118): You can apply to CVP, which is another thing, but CVP does not give you the latest models. No? Then what are we talking about? At this point it’s just infuriating to hear, “We have increasing cyber capabilities.” Congratulations, you have them.

Paul Asadoorian (34:04.08): Same thing with OpenAI. I didn’t actually get the models. They told me to use the existing ones and they’d be unblocked.

Vlad Babkin (34:20.437): If you’re not giving them to people, shut the fuck up.

Paul Asadoorian (34:25.125): It’s the people whose job it is to find bugs, outside of the major companies making the software and hardware we’re trying to help people secure. The cybersecurity researchers working for cybersecurity companies don’t have access to the same models to find bugs, even though there’s a pretty large collection today of highly skilled people, many of whom have spent their careers finding bugs and vulnerabilities and often don’t have access to the more advanced models. So how’s that helping? It’s not really helping anyone. I agree with you.

Vlad Babkin (35:00.365): It’s not helping anyone.

Paul Asadoorian (35:11.779): Yep. Did you read Bishop Fox’s article on the Check Point management software?

Vlad Babkin (35:24.001): Nope. Believe it or not, nope. I just didn’t have enough time.

Paul Asadoorian (35:26.417): It’s interesting, and it’s a theme from the most recent AI Infra Trust analysis in September: there were many management platforms that contained not just vulnerabilities, but threat-actor-developed exploits and pretty massive campaigns. Cisco’s Firewall Management Center (FMC) was associated with a pretty major campaign from threat actors. I’ve also seen threat actors historically target Fortinet’s firewall management platform, FortiManager. And recently, Check Point’s management platform. Bishop Fox wrote a great article about CVE-2026-93616, a flaw in that management platform.

I think this is yet another network edge appliance that you have to manage. If you’ve got hundreds or thousands of devices from any one manufacturer — if I recall, at least back in the day, this is how it worked. I worked for a university twenty-plus years ago with a pretty large network, and we would enter into a contract with a major network systems provider. Let’s just say it was Cisco at the time, which is not uncommon for large enterprises and universities. You say, “We’re going to buy thousands of Cisco devices, and we’re going to need a way to manage them,” and there’s a line item in most of those contracts. Maybe it’s steeply discounted, maybe it’s free, whatever it is, you get the management software to manage those devices, because how else do you manage thousands of firewalls? All these vendors provide yet another appliance, usually one that can be installed on a physical appliance from the vendor or in a virtual machine, and that’s what you use to manage all of these systems.

Paul Asadoorian (37:51.96): Attackers are obviously going to go after this, because guess what? All your configurations, as one example, will live in your management software. And as we all know, the configuration for your network appliances, routers, and switches contains sensitive information. It contains credentials. It contains where your credential manager might live, like TACACS+. It contains your route tables, all your tunnels, your VPN information, all that stuff.

In fact, that’s exactly what the threat actors did in the campaign against Cisco’s FMC. They had custom scripts harvesting credentials from FMC. So this is another part of your attack surface that you have to apply great scrutiny to. I don’t know if you’ve looked at some of these platforms before. They typically run on similar, Linux-based appliance images. Have you ever looked at any of these, Vlad?

Vlad Babkin (39:01.549): More or less. How do you put this? I’ll just put it plainly: I stopped trusting appliances all that much a long time ago.

I just do not believe, in my right mind, that buying an appliance is safe. None of them are open. None of them provide the visibility you need as a defender. If they claim to be a VPN appliance… you cannot control it. At this point, installing OpenVPN manually on a Linux box is going to be safer for you. That’s it. Similar for everything else.

Paul Asadoorian (40:03.323): It’s interesting, though. Let’s pivot to VPN appliances for a moment, which I think are an even more difficult attack surface, because typically there’s some type of service exposed to the internet. In a more traditional VPN appliance model, you need to terminate connections, whether it’s SSL VPN, which is largely being phased out, or other IPsec-based VPNs. You still need a public endpoint. You still need a service listening on a port to terminate those connections, and it has to be exposed to the entire internet. So the successful attacks I’ve seen against VPN appliances involve a buffer overflow against that service that gains an attacker code execution. That’s not “I accidentally, or on purpose, exposed the management interface of my firewall or VPN appliance to the internet.” It’s “I have to expose this service to the internet,” making it much harder to defend.

On the management plane side, you can and should restrict traffic, much like with BMCs, because it doesn’t need that internet exposure. But VPN appliances do. And some of the latest campaigns achieve code execution in the VPN software and then live off the land from there. One classic example that cropped up this week or last week was on Fortinet. I think this was an older CVE, perhaps, but an RCE on the VPN service. Since Node.js is installed on these appliances, they’re just spawning node as a child process of the exploited service. We see this with the web services exposed on these appliances as well, maybe more for the management interface, but similar-style attacks. So this can get tricky when you have to expose it to the internet.

Vlad Babkin (42:15.532): Yup, it gets very, very tricky. I agree with you on this one. But still, that’s not a response. Come on. You don’t even have to terminate it differently, that’s my main point.

Paul Asadoorian (42:28.537): It’s a solvable problem. We’ve talked before about how you can terminate it differently. We’ve talked about the architecture. Cloudflare, ThreatLocker, and others have solutions.

Vlad Babkin (42:43.362): What you have to do is… how do I put this best? Instead of trying to terminate it with your own custom TLS thing, you just run OpenVPN, or WireGuard. Use known-good solutions that the community actually maintains for you, and don’t expose anything else. As soon as you expose something other than the VPN port to the public, you are going to get attacked. It’s the doom of VPN appliances.

This applies literally to everything. If your appliance exposes some communication port and the service is running as root on the appliance — on all of them — okay, it’s an internal network. It’s not different. A lot of people just expose them to the internet. For Lord’s sake, there are at least 30 to 40 thousand confirmed exposed BMCs online.

And that’s potentially underestimated, because it’s very hard to scan every port. We probably have a lot more.

Paul Asadoorian (43:37.189): Yeah.

Vlad Babkin (43:48.972): Don’t make your web services run as root.

Paul Asadoorian (43:49.106): It’s true. It’s one of those things I’ve talked about on podcasts since the dawn of time: exposing stuff to the internet is dangerous, yet people still do it. BMCs are a great example of that.

Vlad Babkin (44:00.163): Yep. Again, whatever appliance we’re talking about, it shares the same question. Anything that’s hardware: if it doesn’t give you visibility into itself, if it doesn’t run with least privilege, which most of them don’t, it’s just not safe. You shouldn’t use them. Building a solution on your own is going to be cheaper for you long term. And AI is just accelerating the process of their death.

Paul Asadoorian (44:39.953): Well, speaking of least privilege, we’re also seeing a proliferation of Linux local privilege escalation vulnerabilities and exploits. Now that I say that out loud, I’d almost like to do a study that charts them. We’ve seen a huge uptick. That’s just a gut feeling that I have, but I think again AI is assisting folks in analyzing the Linux kernel source code, and a lot of what’s being uncovered are flaws in the Linux kernel and Linux systems that allow crossing the boundary from regular user to root privileges. There’s so much attack surface to defend that these bugs are coming out all the time. There was a new one I covered the other day on my Security Weekly podcast. There was another new one, actually two of them: one was a Spectre v2 variant and one was some other primitive in the Linux kernel that allowed for privilege escalation. I’m now seeing new ones come out almost every week, or at least once a month. We had Dirty COW, Dirty Frag, Dirty Pipe, Copy Fail, all those vulnerabilities; there are several classes of very similar vulnerabilities that were disclosed. There was also one in Docker disclosed recently. There are just so many ways that I think it’s super difficult to preserve the boundary between normal user and root user on Linux systems today.

I don’t have the answer to that. I think we’re going to continue to see a proliferation of these vulnerabilities. One, you still keep up with patches. Two, you try to keep attackers out, but that’s a losing game. You’re not going to keep attackers out a hundred percent of the time. So the third thing you have is that visibility point we keep coming back to: how do I monitor and detect anomalies fast enough to respond before they cause damage?

That’s the name of the game.

Vlad Babkin (47:11.436): The name of the game is opening your technology up. The only reason we are seeing all of these Linux privilege escalations, and not just attackers using them, is that Linux is open source. That’s the answer. Linux is open, so defenders see all of these vulnerabilities and get to patch them, instead of some attacker using them for years until anybody knows. And for anybody who thinks differently: we are providing evidence for you. If you don’t accept the evidence, I don’t have a reason to actually buy anything from you.

Paul Asadoorian (47:59.855): Right. And it’s interesting, too. The last attack is a side-channel leakage in the file notification system. This affects Linux, Android, Windows, and macOS, which is interesting. I don’t think this is earth-shattering, stop-everything-and-go-apply-a-patch. But I do think it’s a very novel attack. What it’s preying upon is that as files change in an operating system, there is, in various operating systems, some notification service that something’s changed. It’s how, if you’ve got a file manager window open on really any of these operating systems and you go to the command line or another file manager window and drag and drop and change files, it updates in the other window. Behind the scenes there’s a notification service and things are listening.

What this particular attack does, and there’s a link in the show notes, is construct attacks that could perhaps figure out keystroke timing, or perhaps let a non-privileged user know which files are changing and which directories are changing. It’s kind of interesting. They say they’re not aware of exploitation in the wild. But there’s a paper you can read, being presented at a conference in November, and they did publish the paper and a lot of the details about it. So again, not earth-shattering, but a very interesting class of attacks.

Historically, what I see is really cool research that uncovers this type of flaw, and you think, “That’s not that big of a deal.” But maybe it’s used in some type of attack path or series of attacks. It gives attackers information they need to carry out other attacks, and it evolves. Or someone develops a new technique and goes, “We can use this to sniff keystrokes and do it better.” They did kind of theorize about that in the paper: you get a notification of a key press, you could figure out how the person types, apply an algorithm, and work out which key is actually being pressed. I still think that’s in development, but it could evolve over time. So to me this is an early warning, and I hope the operating systems become a little more resilient to this style of attack before it evolves. You have time, so we should do it now.

Paul Asadoorian (50:55.281): I don’t know if you saw this one, Vlad. It’s a very interesting attack.

Vlad Babkin (51:00.694): Not yet, but it sounds incredibly interesting. File notification attacks are absolutely insane.

Vlad Babkin (51:15.17): To be honest, I did use file notifications for really cool stuff. I can’t even describe it, potentially. What you can use it for legitimately is absolutely mind-boggling. When I was playing CTFs and we were playing attack-defense, we often needed to very quickly dump flags somewhere and upload them immediately. There is not enough time to debug a proper network service and proper network communications. You just want to dump them to a file and have something else figure it out. How does that something else find out about a file? File notifications. We just find out which files got created or edited, and dump all of the data from them. So somebody abusing this is amazing. I honestly didn’t expect it to have any kind of leaks at all. As a guy with a lot of experience in the field, if it’s unexpected to me, you should probably read it.

Paul Asadoorian (52:20.239): Yeah, and that link will be in the show notes. That’s awesome. We covered a lot of ground, a lot of good stuff. Vlad, thank you very much for appearing on Below the Surface this week. Thanks, everyone, for listening and watching. We’ll see you next time.

Vlad Babkin (52:35.938): Yeah. Thank you for listening to all of my mad rants this whole time.

Paul Asadoorian (52:40.433): We love your rants, Vlad. It’s awesome. Thanks, everyone.

Back to all Podcasts