PODCASTS

BTS #76 - Binwalk, Brickstorm, AI Model Madness

Paul Asadoorian is joined by Chase Snyder and Vlad Babkin for episode 76 of Below the Surface, recorded June 11, 2026. The conversation starts with the security implications of highly restricted AI models, then moves quickly into a deeper question: what happens when AI accelerates vulnerability discovery faster than organizations can safely patch?

The episode connects several threads that are usually discussed separately: model guardrails, firmware research tools, Secure Boot trust chains, DBX updates, opaque network appliances, and malware targeting edge devices. Across the discussion, the hosts return to a practical theme: finding vulnerabilities is only one part of the problem. Applying fixes across real systems, with real dependencies and real operational risk, is much harder.

That tension shows up in almost every story. AI may help researchers identify flaws more quickly, but defenders still need accurate asset data, trustworthy firmware visibility, vendor cooperation, and a safe way to update systems that cannot afford to break.

Key Topics Covered

  • AI guardrails and cybersecurity research: Paul, Chase, and Vlad discuss Anthropic’s Fable Five/Mythos model and the backlash around restrictive cybersecurity guardrails. The concern is not only inconvenience, but whether defensive researchers are being blocked while capable adversaries may still find ways to use the same technology.
  • The “too dangerous to release” pattern: The hosts compare AI release messaging to a familiar cycle: models are described as exceptionally risky, then released with restrictions, creating both hype and frustration. Chase frames this through the lens of security research that is already public but still gets restricted by model policy.
  • AI vulnerability discovery versus patch deployment: The episode’s central tension is that AI can help find vulnerabilities, but does not remove the operational risk of applying patches. Paul argues that vulnerability research and patch creation can happen outside production, while patch deployment happens inside production systems where failure has consequences.
  • Operational risk in firmware updates: The discussion turns to firmware updates and why scaling them is difficult. Vlad emphasizes that firmware update workflows can fail in many ways, especially when systems have unique hardware, drivers, boot configurations, or research-specific setups.
  • Binwalk and vulnerable research tooling: Paul highlights a Binwalk path traversal vulnerability affecting firmware extraction workflows. The larger lesson is that security researchers depend on tools, and those tools can become part of the attack surface when analyzing untrusted firmware images.
  • FWUpd, Secure Boot, and key management anxiety: The hosts discuss FWUpd behavior around Secure Boot databases and why modifying trust stores can make defenders uneasy. The concern is not simply whether the tool is good, but whether enterprise-scale updates can account for custom keys, unusual configurations, and systems that may fail to boot.
  • The complexity of Secure Boot and DBX: Paul explains why Secure Boot is more nuanced than being simply “on” or “off.” DBX entries, signed bootloaders, revoked hashes, certificate replacement, and vendor-specific implementations all complicate detection and remediation.
  • Shim, signed bootloaders, and inherited trust: The group discusses vulnerable Microsoft-signed UEFI shim bootloaders and the problem of old or forked bootloaders remaining trusted. The episode connects this to prior Secure Boot research, including Eclypsium’s work on shim vulnerabilities.
  • Why transparency matters for signed UEFI software: Paul argues that Microsoft should provide an attestation-style API showing what software has been signed by key certificates. Without a public inventory, researchers must discover vulnerable signed binaries by chance, as with signed UEFI shells and related Secure Boot bypass issues.
  • Network appliance opacity and supply chain risk: Chase and Vlad draw an analogy between AI restrictions and the lack of visibility inside network devices. If vendors do not expose what is inside the appliance, defenders cannot easily know whether vulnerable open source components, forked code, or outdated firmware are present.
  • Vulnerability data is still too imprecise: Paul expands the discussion to vendor advisories, CPE data, configuration-dependent exposure, and the difficulty of knowing whether a product is actually vulnerable. The Arista example shows how version alone may not be enough when exploitability depends on enabled features and specific configuration.
  • AI may favor attackers more than defenders: Vlad argues that AI is accelerating the discovery side of the equation faster than the remediation side. The result is a growing asymmetry: attackers can reproduce or weaponize findings, while defenders still face slow patch cycles, incomplete data, and operational constraints.
  • BRICKSTORM and edge-device persistence: Paul closes with BRICKSTORM activity targeting storage and firewall appliances, including Linux and FreeBSD variants. The episode connects this to the broader trend of adversaries using network edge devices as footholds into enterprise environments.
  • The end of trusting SSL VPN appliances: Vlad argues that organizations should stop treating edge devices as inherently trustworthy, especially when they authenticate users against Active Directory. The group discusses alternatives such as WireGuard, OpenVPN, IPsec, mesh networking, and the operational burden of moving large fleets away from legacy SSL VPN infrastructure.

Timestamps

00:00 – Intro and episode setup
00:28 – Welcome to episode 76 with Paul Asadoorian, Chase Snyder, and Vlad Babkin
00:48 – Eclypsium resources and show opening
01:36 – Anthropic Fable Five/Mythos, AI guardrails, and cybersecurity restrictions
03:16 – Tool restriction, defensive research, and who gets to decide permitted use
05:19 – Enterprise data retention concerns and model downgrades for cybersecurity topics
08:51 – Project Glass Wing, AI vulnerability discovery, and rising disclosure volume
10:53 – Operational risk: why finding vulnerabilities is easier than safely patching them
13:19 – Using LLMs to assess Linux update risk on individual systems
16:32 – Binwalk path traversal and the risk of vulnerable security research tools
20:05 – FWUpd, Secure Boot updates, and DB/DBX handling
22:13 – Risks around Secure Boot keys, custom configurations, and update failures
25:55 – Why Secure Boot detections are difficult to build correctly
29:07 – Microsoft-signed UEFI shim bootloader vulnerabilities
31:14 – Open source dependencies hidden inside network appliances
33:39 – Proposal for a Microsoft attestation API for signed UEFI software
35:32 – Signed UEFI shells, Framework devices, and Secure Boot bypass concerns
39:40 – DBX revocation lists and why many systems remain outdated
41:15 – Why DBX updates do not always happen reliably through Windows Update
44:28 – Vulnerability data, CPE limitations, and configuration-dependent exposure
45:40 – Arista KEV example and why version-based vulnerability management falls short
47:43 – AI acceleration and the defender’s remediation problem
49:10 – AI-found vulnerabilities versus AI-generated patches
52:00 – BRICKSTORM malware targeting storage appliances and firewalls
54:57 – Network edge devices as footholds into Active Directory environments
56:09 – Mesh networking, VPN architecture, and why SSL VPN needs to fade out
59:12 – Cyber insurance pressure around risky on-prem VPN infrastructure
01:00:08 – Closing thoughts

Core References

Transcript

Paul Asadoorian (00:48.207) Just a quick announcement. Of course, below the surface, listeners can learn more about Eclypsium by visiting eclypsium.com forward slash go. There you’ll 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 DigitalOcean. If you’re interested in seeing our product in action, you can sign up for a demo. All that at eclypsium.com forward slash go. We got some fun stuff to talk about this week, as always. why don’t we why don’t we start with we could old-fashioned AI? It’s old-fashioned AI now, because AI is everywhere. Every podcast is talking about AI. So we should start by talking about Claude Fable 5. Anthropic’s most powerful public model with the most guardrails I’ve ever observed on a model. So much so I refuse to use it.

Chase Snyder (01:36.036) Let’s go.

Chase Snyder (01:44.358) Dude, have you guys read the three body problem?

Paul Asadoorian (01:48.289) Yeah, why does that sound so familiar?

Chase Snyder (01:48.87) I don’t.

Vlad Babkin (01:49.44) I have I have seen the idea. I didn’t read it in depth.

Paul Asadoorian (01:52.417) Yeah.

Chase Snyder (01:53.51) I don’t want to do any spoilers, but there’s a situation there where essentially it’s gonna be a spoiler, Three Body spoilers, sorry, but people are referring to the the fable guardrails as the sofon lock, which is basically a thing where aliens sabotage scientific progress so that humans can can never develop effective tools and weapons to be a be a real competitor. And that, yeah, I don’t know, there’s so much, there’s so much like sociological commentary going on with Mythos and with Fable. But someone pointed out to me recently, I thought it was so funny that the sort of release, the like messaging model for every AI product release has been back to like GPT 2 in 2019, has been This is so dangerous, we don’t even think we should release it to the public. And then it gets all this like hyperventilating hype about it. And then they d release it. And it’s like, yes, this does in fact affect my job. But it’s not like But you know, at some point one of them is gonna be actually genuinely dangerous, or maybe we’re in the singularity already, and and I just can’t see the see the dark forest for the trees. But the

Paul Asadoorian (03:16.887) Yeah, I’m just I’m not a huge fan of the tool can be used for evil. Therefore we should restrict access to the tool. Cause oftentimes there’s other tools or other methods to achieve the same result. So what are you what are you really preventing by restricting or banning tools?

Vlad Babkin (03:37.58) You yeah, like e I don’t want to say anything, but if you look at history of OpenAI, there was a guy who pretty much pioneered the this is too dangerous to be released. And at some point that guy moved from OpenAI to Anthropic. And guess what? Anthropic now has the same new policy. It’s too dangerous to be released. At the same time we have OpenAI who pretty much gives much easier access to their frontier models for cybersecurity. And like

Paul Asadoorian (04:17.421) Yeah, that was the same. I’ve I’ve heard so many negative things about it. I haven’t even tested it. I’m still on Opus four eight. Also the fact that your output tokens are two X what Opus four point eight puts out kind of put me off to it as well.

Chase Snyder (04:34.886) The two yeah. The two dangerous to release.

Chase Snyder (04:49.756) Well, it also has even if you have an enterprise account with them, they still retain the data. So any sort of like don’t you know, there there’s no with previous models, if you have an enterprise account, you know, you have your contract with them and it’s like we don’t use your data for training, we don’t retain your prompts that you type into it. and that is changed for for Fable. I’ll say that I did try it.

Vlad Babkin (05:12.941) Mm.

Chase Snyder (05:19.342) I used it to create a visualization of a particular attack chain that was public on a blog post. It was something we’ve talked about on this podcast before, I think. It was a whole thing. so it’s like no secret information, but it was a cybersecurity topic. And cybersecurity is one of the sort of no-go topics. and it downgraded me to downgraded me to four eight while I was doing it just because it was a cybersecurity topic. I was like, there’s nothing in here that’s not already just on the internet, it’s in the corpus.

Vlad Babkin (05:36.666) Mm-hmm. It’s the biggest one.

Chase Snyder (05:46.524) There’s no no research question. I wasn’t like figure out how to do anything with this. I was just like visualize this. Here’s an attack chain described in text, make it in pictures, and it downgraded me. So it seems like it’s really a hair trigger, hair trigger for the cybersecurity topic to downgrade you on the model, which I don’t, you know, hope it’s four-a’s fine. I’ll use half the tokens, it does a fine job. But the the amount of like backlash that they’re getting for it,

Paul Asadoorian (05:58.251) And it was like, Yeah, I can’t do that. Yeah.

Chase Snyder (06:15.928) on Twitter really is is enormous.

Paul Asadoorian (06:17.121) Yeah. So ironically, I prompted Claude using s I like Sonnet four six for general research. ’cause it uses a lot less tokens, and doesn’t cost as much. So when I did that, that’s how I generated some of the show notes. I need to make like a skill or like artifact, whatever they call it for that. I gotta I gotta do that.

Chase Snyder (06:40.53) Mm-hmm.

Paul Asadoorian (06:42.599) but these notes say an immunologist reported the word cancer as being flagged as a biosecurity risk. Like just to go show you how l off the rails, the guardrails are, in Fable Five.

Vlad Babkin (06:54.669) It’s just like what are we doing? Like sure, I understand there they’re concerned with the risk. Like there is no question about that one. But What do we wanna ban all of the research, including defensive one? I understand that it’s incredibly hard to write a classifier for this. Sure. But like at this point it’s not even usable for defensive purposes. And like how how how are you planning for enterprises to defend against this stuff? At the same time, we we have in the news, it’s not like I’m main inventing this making this up, some random guys when Mythos just released actually broke access for it and and had it, even though Anthropic never approved them.

Paul Asadoorian (07:19.701) Yeah, it exactly. It

Vlad Babkin (07:35.456) So there is a non zero chance that a government level threat actor right now is using Mythos because he is like somehow sneaked into one of the approved organizations to maybe stage their attacks. Like we don’t know. And the point is Anthropic like they cannot really view like review every single prompt every single user makes. So like the chance that some threat actor is already using Mythos for evil, while you cannot even use it to defend yourself is not zero. And like who who are Anthropic to actually decide what is permitted use? Like there is a lot of stuff which is like fringe use cases, like vulnerability research. Who can tell us if this is a good thing to use it for vulnerability research or a bad thing? It’s like both things happen. And like when this the cyber verification program I was thinking that okay they’re doing a reasonable route. But with the route they took with Mythos and just blocking access to everybody Yeah, that’s not going how it should. Like they’re gonna lose a following or maybe whenever a competitor comes up with a this level of model, like let’s say OpenAI, and just release it to the public more freely, they will just lose a lot of their following immediately.

Chase Snyder (08:51.43) Here’s another perspective I’ve been sort of noodling on from this too. Is that so when they first announced Mythos, Anthropic also announced Project Glass Wing, which was a project where 40 companies got early access to Mythos to use it for cybersecurity research on their products to find vulnerabilities that they could then patch. And a bunch of companies, notably Mozilla, said that they found 270 or something vulnerabilities in Firefox. That they patched. meanwhile, Microsoft using their own AI vulnerability, you know, discovery. Yeah, they have their own thing. And they said, we’re on our we’re on track to break our record for patches issued on patch Tuesday because of AI vulnerability discovery. And so they’re rolling out patches more and more. Meanwhile, so more and more vulnerabilities are getting disclosed and patched by the vendor, but the pace at which

Paul Asadoorian (09:29.043) they called it something. Yeah.

Chase Snyder (09:51.004) Companies that use products are able to roll out those patches is slowing way down. In the in the Verizon data breach investigation report that came out a week or two ago. So the most recent one, it they indicated that among the breaches they look at, which is like 20,000 plus breaches, the organizations that were affected had gotten way slower at rolling out patches for even known exploited vulnerabilities. So it’s like the median time to patch went up from 30 something days to 40 something days. And the number of patches that ever ever get patched, the number of vulnerabilities, known exploited vulnerabilities that ever get patched, the percentage of them went down significantly. And so it’s like, okay, the number of vulnerabilities being disclosed is going up, the number getting patched or the percentage of them getting patched is going down. It’s also getting slower. So this is actually like creating new attack surface at a pretty alarming rate. directly attributable to these AI vulnerability discovery tools.

Paul Asadoorian (10:53.047) Think this is directly correl, I’m glad you brought this up, directly correlated to operational risk versus non-operational risk. Because searching for vulnerabilities, finding vulnerabilities, even developing a patch for vulnerabilities carries with it zero operational risk. You can do that outside of any operational thing, and it can just be independent research. You can throw all the money and models at it that you want, you can let it churn, it can make mistakes, it can create false positives, and you’re gonna sort that all out until you create the patch. Now it it’s still like pretty much zero operational risk to develop a patch and distribute a patch. The operational risk comes down when you have to apply that patch. That carries with it a ton of operational risk that you can’t AI yourself out of.

Vlad Babkin (11:43.415) Mm.

Paul Asadoorian (11:50.315) I mean, I hope we get better technology to help us with this problem, but you can’t really AI yourself out of it because at some point you have to apply that patch, cross your fingers and hope for the best. Because every patch that’s released, there is always a person who is going to apply that patch first and recognize whether that’s gonna go well for them or not.

Vlad Babkin (12:13.345) Yep. And like moreover, once the vulnerability gets discovered by Mythos and like okay, let’s say patches come out, like okay, Firefox is full open source. Any attacker worth the assault, like let’s say I would be a government level threat actor. What I would be doing is literally cloning a Firefox version daily, diffing, and then passing it through a simpler model. Right? And like I would be finding all of the same vulnerabilities Mythos found, but just at a fraction of the cost. And like now you are not patching, you cannot even like scan your own products for this. But others suddenly have like some kind of level of access to this stuff. And like setting up this pipeline is not trivial. Like sure you can do this, but like will a like medium sized company do this? No. Because that’s cost resources. You need people who are proficient with this level of stuff. And like only a handful of companies even have those. out of like regular ones, not cybersecurity focused. And yeah, this this situation is not very fun to be in.

Paul Asadoorian (13:19.191) Yeah. And I think I think AI has so I’ve used certain models to help me determine if I’m applying updates to my Linux system, if it’s gonna go well or not. And I probably need to turn this into an an app that collects information about your hardware and software, right? And this is as simple in Linux as running the INC command, right? I N XI INKSY is a great utility. I’ve used it in my cheat sheets that I’ve published on Eclypsium’s website. I think there’s a GitHub repo where I have a script that’ll run it for you on my personal GitHub. and basically it collects all the information about your system. So your hardware, what graphics card you have, what CPU that you have, what drivers, what kernel, what Linux distro, what version of everything it’s at. And you give that to an LLM and you go, like in the case of Manjaro. Here’s the stable update forum post where they’ve released a new version of Manjaro. And in that post, they have details like stuff you got to do before the update, stuff you got to do after the update. And then there’s a bunch of posts from users who have applied the update and are describing their experiences with it. And so you can’t be the first one to apply an update because you need this data, right? You need people to actually test it. Then tell the LM go to that post, collect all that data, cross-reference it with what’s on my system. Should I apply this update? And if I do, what do I have to do before? And what do I have to do after to make sure I’m mitigating my operational risk? Now that works pretty well if a couple of things are true. One, it’s one system for one user, right? Works great. also, you need other people to apply the patches or fixes and report on the outcomes of it.

Paul Asadoorian (15:18.475) Right. And once you have that data, LMs are great at helping you. I mean, I’ve had LMs tell me do not go to that kernel version because you have this graphics card in that configuration and there is a bug that hasn’t been fixed and that’ll be in the next kernel version. So you should wait. And and that’s normally what I would do research manually. Now an LM is gr I think is great at doing that for me and in in helping me mitigate that operational risk. If you could Yeah, this is a great company idea. If you could operationalize that and scale that with an LLM, that would be a great thing. I’m sure the companies that are doing patch management are already looking at that. I’m sure Vlad’s gears are churning on how we can integrate that into our own product, right? They can help you apply firmware updates. and I I think that’s a that’s a great approach. But again, I’ve only tested it on like the an individual basis. I’m curious to see if if

Vlad Babkin (16:07.487) Mm.

Paul Asadoorian (16:17.324) We could get that to scale.

Vlad Babkin (16:19.713) Yeah, and like scaling some s like this is incredibly hard. Like so many things can go wrong with like updates of firmware, like it’s not even a joke.

Paul Asadoorian (16:23.106) Mm-hmm.

Paul Asadoorian (16:28.075) Right. Even just firmware, yeah.

Paul Asadoorian (16:32.801) That’s my idea for the day. And speaking of firmware, Binwalk has a path traversal vulnerability. I’m always keen to point out when the tools that we use as security researchers have vulnerabilities. Cause I’m super conscious, like I don’t want to get owned. And especially with like clawed code running even in a VM, I’m telling Claude Code to go get tools. Right. Going it, telling it, go put on this GitHub. I I installed this tool to go use this tool. And so we still rely heavily on tools, especially w you know, Flad, you know, when you’re looking at reverse engineering firmware, you need a set of tools to do that, to do the extraction, to do

Vlad Babkin (17:18.221) Yeah you cannot you cannot you cannot do everything from scratch every single time.

Paul Asadoorian (17:22.765) Correct. and binwalk is what has been one of the most popular tools over the years to unpack firmware, right? It’s probably its its best use case. and this vulnerability arises from Windows CE firmware binaries are when they are extracting those, there is a condition where it allows for a directory traversal. So if you I guess if you packed up a Windows C E firmware, you could put artifacts in there that would traverse the file system and lead to remote code execution on the analyst system. Which is pretty wild. The full write up I’ll put in in the show notes. but that’s that’s a neat find. I’m wondering if they used AI to find the vulnerability. I don’t think they said in the article. I did read the article. What led me to this target? this does have a C V E twenty twenty six seven one seven nine.

Paul Asadoorian (18:27.915) I wonder if this is the this is the Python version of binwalk, not the Rust version. Not that not that Rust necessarily prevents path traversal. Isn’t Rust more about memory safety, Vlad?

Vlad Babkin (18:44.023) So Rust is about memory safety. I don’t think Rust prevents any high level wounds. Like for example, like you i if i if you put a skill injection in there, Rust is not gonna help you with anything because like it’s not it’s not focused on this. Don’t don’t expect like a magical tool to solve all of your security problems with just a flick of your fingers. It doesn’t work that way.

Paul Asadoorian (19:12.579) Yeah, and he’s got he’s got proof of concept.

Vlad Babkin (19:12.693) Like securities that you acquire this way, you lose this way as well.

Paul Asadoorian (19:17.793) And they’ve published a a full proof concept for this vulnerability as well. It’s on there, it’s in GitHub. All available. So make sure you update your bin walk.

Vlad Babkin (19:31.181) Yeah. Or don’t. It’s very fun. You know you never Yeah, you never know w what you can catch this way. You know, it’s like training your computer’s immune system. Install a small virus for it to be like more resistant to big one.

Paul Asadoorian (19:36.823) Fun just to see what happens.

Paul Asadoorian (19:54.557) an update on w did you guys want to s d ha have a preference what we talk about next? Sorry, I’m just kinda going in order.

Vlad Babkin (20:05.197) So I would I would I would say this interesting one is the f firmware updater thingy. fwupd.

Paul Asadoorian (20:05.534) some people I say FW up D. Some people say FWAP D, which I I kinda like. I think I th I think it’s kinda neat to like actually pronounce the the acronym.

Chase Snyder (20:18.522) What this?

Vlad Babkin (20:20.301) fwapd.

Chase Snyder (20:25.906) I’m just gonna skip the W be I’m gonna F you up, D.

Paul Asadoorian (20:29.025) That’s right, right? What up D. so this is interesting. There’s a a situation that a arises and I I couldn’t really fully unpack what they’re doing because I couldn’t get past the fact that your DBX is signed by your key exchange key and FW up D in some cases of secure boot to preserve the boot integrity.

Vlad Babkin (20:30.589) Ha ha

Paul Asadoorian (20:58.721) will update your DB with appropriate records so that your system still boots. and I was trying to unpack exactly what FWFD was doing and how they were signing it. But apparently I think what’s happening is they have multiple capsule updates, like new and old capsule updates that contain the correct signed DB and they’re kind of flip-flopping between them. Because you would it would have to be signed by your your key exchange key, unless you’re doing a mock or machine owner key kind of thing on a Linux system, on Windows systems, right? They it all has to be signed. Like you that’s the whole point of secure boot. You can’t just allow anyone to go add entries into your DB, because then they could attackers could just boot you know use any software they wanted. so it has to be protected by the root of trust. so it’s following the root of trust, but in certain times. case is especially secure boot, F W up D is modifying the the D B, which kinda weirds me out a little bit, but as long as it’s preserving the root of trust, I think it’s okay.

Paul Asadoorian (22:12.515) I don’t if you looked into this one, Vlad.

Vlad Babkin (22:13.133) In this case yeah, in this case like honestly, like all of these updates sound like a very, very risky thing to me. Like Yeah. Like one thing is like if there is some way okay, you have one certificate, let’s say the second one, and now you have two of them. If it would be this simple, maybe yes, and it is actually safe and I wouldn’t have like angry butterflies in my stomach when I would be using the update tool, right?

Paul Asadoorian (22:21.931) Okay, so I’m not the only one. I when I read I thought the same thing, Vlad. Yeah.

Vlad Babkin (22:41.631) But if what they’re doing is actually removing the old certificate as well, now we have a surprise. And like second issue is like systems which are set up to use their own signing signing keys. Like Which can get very very iffy, especially if fwupd is does not have access to the key. Right? It can mess the system up really really badly, especially if it just removes your own key. Suddenly the system will stop booting.

Paul Asadoorian (23:04.227) Mm-hmm.

Paul Asadoorian (23:12.929) Yeah, I get super weirded out when we talk about updating your keys or key stores in secure boot. That ’cause the like you’re saying, Vlad, that could it could lead to a system not booting pretty quickly if you start messing with that stuff.

Vlad Babkin (23:13.428) And like

Vlad Babkin (23:30.507) Yep. Yep. And also another another question in my brain, what about people who want to get rid of Microsoft certificate and wanna completely manage their own key? What what would they do if this thing actually messes their setup? It can be a nasty surprise. Like I can I can imagine like

Paul Asadoorian (23:41.667) Mm.

Paul Asadoorian (23:47.639) Yeah, hopefully there’s logic in there to only use the the public do this with the public certificates, if you will, not your own. Yeah.

Vlad Babkin (23:53.972) Hopefully. Hopefully because like if they messed it up, then th there will be a pretty nasty surprise with this. Like I would be very, very careful about this thing. Like I don’t even know like you i if you should deploy something like this at at at enterprise scale so easily. Like maybe if your enterprise actually has like a thousand copies of the same laptop and you can actually test it on one, maybe then you can use it. But companies like

Paul Asadoorian (24:01.869) Yeah.

Vlad Babkin (24:22.529) Like for example, Eclypsium doing cybersecurity research. Well, researchers have weird setups on their laptops by design. Even if they have the same laptop, all of them, each one will have some kind of special setup for their specific function. And like maybe it is web research, in which case you don’t really need a lot of like secure boot stuff. But what if you are a researcher who does low level stuff? Well then you might have to use outdated drivers and you might have to use like

Paul Asadoorian (24:39.041) Mm-hmm.

Vlad Babkin (24:52.407) some like weird things that you are now analyzing needs some kind of weird compatibility mode in the CPU for you to run it locally. And now surprises start. So like it’s very, very questionable thing.

Paul Asadoorian (25:09.911) Yeah, I’m sure ma maybe we’re missing something here too. I’m sure Richard Hughes, who’s been a guest on the show before, could explain exactly what what he’s done. It’s time to bring Richard back, get an update on the project. ’cause Rich he’s a sharp dude and he he knows all this stuff inside it out and backwards, so

Vlad Babkin (25:18.431) Yeah. Yeah.

Vlad Babkin (25:26.033) Mm-hmm. Yep, yep. Like he fwupd has been a good tool. So I’m not saying that they did anything wrong. I’m just pointing out everything that can go wrong. Like it’s it’s not it’s not that any of this is wrongly implemented in the tool. I have not checked the update. Just to be clear. But like yeah. There is a lot of like weird questions to this that can and probably should be asked.

Paul Asadoorian (25:36.491) Yes.

Chase Snyder (25:44.764) Real.

Paul Asadoorian (25:55.755) I what and it’s one of the things with Secure Boot that has plagued us over over time is the the complexity of it all. Right? Maintaining a root of trust in the context of secure boot, traditionally it can be very difficult in certain circumstances, right? And it gets more complex over time. The more certificates expire and you need to issue new certificates, the more D B and D BX entries have to be issued.

Chase Snyder (25:55.9) This is a really good

Paul Asadoorian (26:25.377) entries are you know, multiple hashes are replaced with certificates inside of the DB and the DBX to conserve size. and so the building detections on that is hard because you want to say, well, if hashes go missing from the DBX, that could be suspicious. Except that’s normal behavior. If you’re adding a certificate into the DBX that has signed a whole bunch of software, you don’t need those hashes anymore. so there’s a lot of nuances with Secure Boot that operationally make it somewhat risky, which is why I think you’d find a lot of organizations have systems in a a not great secure boot state. Like on or off is a state, but even on doesn’t necessarily mean that secure boot is doing everything it can to protect your system.

Vlad Babkin (27:17.591) Yep.

Vlad Babkin (27:25.591) Yep, and we have seen devices shipping in like manufacturer mode in Secure Boot, which is like Secureboot is technically enabled, but also it’s useless. Right? I have seen one device like myself, one of my laptops had that. And like it was a finding by our product, by the way. So like we actually did did some I believe it’s called Dog Food. So like yeah, like we actually ran it on on like personal machines as well. And like sometimes you find really tasty stuff.

Paul Asadoorian (27:25.591) Mm.

Paul Asadoorian (27:46.327) Yeah, I did the same. When I joined, I ran it on one of my servers and manufacturing mode was enabled. Yeah. It’s interesting.

Vlad Babkin (27:54.712) Yep. And this this this was flagged only thanks to like me actually using Eclypsium. Like sh shameless shill, but like

Paul Asadoorian (27:59.659) Yeah. I don’t think you find that much anymore though. The yeah, the manufacturing mode thing I think has largely been aged out. I don’t think we see it as much as we used to.

Vlad Babkin (28:10.209) Yeah. Yeah it’s like thankfully it is. Like it’s it’s good good thing. Like you don’t want that thing. I mean maybe you do but if you’re evil.

Paul Asadoorian (28:12.919) Which is good. Yeah.

Paul Asadoorian (28:23.446) Right.

Vlad Babkin (28:26.573) So but the e she Yeah, and we we they interrupted you.

Paul Asadoorian (28:26.881) Sorry, Chase, were you gonna say something earlier?

Chase Snyder (28:30.046) nothing of note, just that this is a good episode for us to refer back to the canonical XKCD comic where all of I modern computer infrastructure is relying on one tiny little open source project being thanklessly maintained by some guy in Nebraska. Numerous numerous such cases in today’s show Docket Alone of some some little project that is just like

Paul Asadoorian (28:46.146) Yeah.

Vlad Babkin (28:47.285) Yeah, yeah, yeah, yeah, yeah.

Chase Snyder (28:55.932) critical path for so much of software and and engineers and developers and security researchers that’s just like, by the way, this is just like one person’s brainchild that they continue to maintain. You’re welcome.

Paul Asadoorian (29:07.991) Well, I mean, one could say it’s a a similar case, Chase, to what you’re talking about in US CERT’s vulnerability note six one six two five seven. Microsoft signed UEFI Shim bootloader is vulnerable to secure boot bypass. So Shim is the piece of software that gets signed by the Microsoft certificate that allows Linux operating systems to do secure boot. So rather than Microsoft signing every different version of mostly Grub or system D bootloaders that all the hundreds of Linux distributions are using, they’re like, we’ll just sign Shim, and then Shim will take care of you know, validating the rest of the chain. and that, well, it’s not great. No no one in the Linux community was happy about this, I don’t think. it’s not great.

Vlad Babkin (30:03.937) Mm.

Paul Asadoorian (30:05.971) And so what happened was multiple bootloaders, shim loaders, had vulnerabilities, got signed or vulnerabilities were discovered, and a bunch of vendors had forked different versions of Shim, gotten them signed, and never fixed the vulnerabilities. I believe is the the chain that happened. there was a great quote in here. One of our coworkers, Thas pointed it out. and I’m gonna I’m gonna have to find it. so over time, multiple security vulnerabilities were identified and corrected in the upstream Shim project. However, a number of vendors had previously forked or customized older versions of Shim for their own products and boot environments. In many cases, these vendor-specific bootloaders were not updated after vulnerabilities in the upstream pub project became publicly known. As a result, vulnerable bootloaders remained signed and trusted by Secure Boot because they had not been revoked through the Microsoft signed DBX revocation list. And there you have it.

Chase Snyder (31:14.834) Dude. We talk about yeah. We talk about the yeah, I mean software supply chain security heavily rotates on talking about open source components. and we’ve talked about one there’s a particular network device vendor that we did some analysis on and found that over the last six years or so it went from having no open source dependencies built into it to like over a hundred.

Vlad Babkin (31:18.125) That’s fun.

Chase Snyder (31:45.026) And it’s like with all of the NPM and Python, you know, marketplace supply chain attacks, it’s like that stuff could be in your network boxes. We talk about like the non-transparency of Mythos, right? Where it’s like they don’t want you to there’s certain things that they won’t let you do. And there’s an analogy there to be made, I feel, for the way that network device vendors don’t let you see inside the inside the guts of the box. And so you would have no way of knowing.

Vlad Babkin (32:13.271) Yep. Mm-hmm.

Chase Snyder (32:13.852) There’s a vulnerable open source component that they forked and never updated, or just even if they’re up to date, you know, there’s constant vulnerability supply chain attacks in those things. And so when it’s like hidden hidden away inside of these devices that you’re are obscured from you by the vendor, that there’s forcing you to trust. It’s

Vlad Babkin (32:35.405) Yup. Yep. Like modern mod modern network devices supply chain and like their obscurity and like we am not gonna let you see the shell because it’s gonna harm device stability is nonsense. Like

Chase Snyder (32:48.474) Yeah, because it they’re like, because it’s too risky, which is the exact same message like we can’t release this, we can’t let you do this, it’s too risky. and

Vlad Babkin (32:56.107) Yeah, risky for whom? For them about you finding out how bad their products are? Maybe. But like the point is, like if your product is owned every single week and you don’t solve visibility problem, what are you doing as a cybersecurity vendor? And by the way, what are you doing buying from such a vendor? Like come on, they have a weekly vulnerability more or less.

Chase Snyder (33:00.807) Mm-hmm.

Vlad Babkin (33:19.497) And like there’s very few vendors like this. No not not calling any names out, but like questions gotta be asked for this to actually improve. And the improvement would be let’s give at least ability into products to whomever asking for them.

Paul Asadoorian (33:39.147) I think Microsoft should publish an attestation API based on just the Microsoft UEFI CA twenty eleven cert. That’s the one that signs third party bootloaders. Well, it used to, right? They kind of they kinda t you know, shifted around in the the newer certs, but take the old cert as an example, you know, that certificate was used to sign

Paul Asadoorian (35:12.747) An unknown amount of unknown software. Like there’s no list of everything Microsoft signed with that certificate. And so, like, props to ESET for actually finding this software, determining that it’s vulnerable, and and reporting on it. What I would like to see is Microsoft publishing attestation API that’s like, hey, here’s all the software that we signed with this certificate. Now we’ll get dicey if it’s commercial software. But I also want a URL where I can go download that software, right? It should publish the hashes for it. It should publish a link to download it. Then as researchers, we would know that any piece of software that we can pull from the attestation API has to be free of vulnerabilities or it needs to be revoked. So it would kind of like be almost if I mean they could have a bug bounty program for it too. Like, how awesome would that be? Because this software has to be has to maintain the integrity of the root of trust. And right now that’s shrouded in secrecy, which as we all know is not the right way to implement security. It should be o it should be open and it should be open for public scrutiny, much like cryptographic algorithms. No

Vlad Babkin (35:12.747) Yeah, it’s security through obscurity as Security through obscurity never worked. Never ever worked. Like everybody who tried to make security through obscurity eventually failed somewhere. And like that’s a universal rule more or less. Like you d you don’t get

Paul Asadoorian (35:22.071) Mm-hmm.

Paul Asadoorian (35:32.013) Could because more than once in history we’ve found UEFI shells. Mickey and myself have found a couple in history. The most recent one was the framework disclosure, which is on our blog. who framework has has fixed everything. but there were signed UEFI shells that contained functionality to bypass secure boot via the memory mapping. and I’m confident there’s more.

Vlad Babkin (35:56.407) Mm.

Paul Asadoorian (35:59.629) We just don’t know all the UEFI shells that exist that have been signed to work with secure boot. If we had an API and we could go query that, then we could we could scrutinize that software for configuration and for vulnerabilities. But we can’t. We just gotta we gotta get lucky. We gotta find it on a system and go, that’s a UEFI shell I haven’t seen before. What happens if I see if it’s signed by secure boot and if it has there’s like two different ways

Vlad Babkin (36:13.837) Yep.

Paul Asadoorian (36:26.416) capabilities in a UEFI shell that if it’s in there you can use those as an attacker to bypass secure boot.

Vlad Babkin (36:33.153) Yep. And like This is a whole show and like some software like has to be like maybe not open source but at the real least public. And sa sadly we don’t we don’t have this. Like and I don’t mean a specific vendor. We don’t have this as an industry. Which is much more sad thing to say. Like we we just don’t. That’s it. So there is nothing we can do about it.

Paul Asadoorian (37:05.302) Yeah. It’s i except, you know, it’s kind of like finding a needle in a stack of needles, right? We don’t even in this case, we don’t even know where the stack of needles is. I we don’t know this. How do you know the software exists if if it’s not published anywhere? You get it as part of some operating system or IoT device or whatever, right? But if I don’t have that device or that system, I I can’t analyze that software. I can’t acquire every

Vlad Babkin (37:16.011) Yeah, we don’t we don’t even know what the needle is.

Vlad Babkin (37:30.327) Yep.

Paul Asadoorian (37:32.855) device on the planet and go look at its bootloader and see if it boot process and see if it has a UEFI shell.

Vlad Babkin (37:37.613) Yep. Yep. And like the stupid part is and the stu stupid part is somebody who has this device and like put their effort in, they have this software.

Chase Snyder (37:39.858) We’re gonna try. We’re trying.

Paul Asadoorian (37:41.699) We could try.

Vlad Babkin (37:51.412) And like this is a much more scary thing. Because now attackers have a asymmetric advantage. You cannot easily copy this capability.

Vlad Babkin (38:04.587) Like you can try to purchase this.

Paul Asadoorian (38:05.025) Yeah. When they when they get on a system, it it’s a potential attack path once an attacker lands on the system that defenders are a huge disadvantage about knowing if that is even an attack path or not.

Vlad Babkin (38:17.749) Yeah, like you just don’t know and you cannot know with like how we architect modern systems.

Paul Asadoorian (38:23.937) Right. Unless you give us the the binary. Then we can tell you. Or we can tell you how to find it in the binary. Actually, I think my framework post shows you how to find it in the binary. At least gives you some hints on that. I don’t think I released all my tooling. I did write some Python scripts, I think, to analyze it. But you could very easily, especially with an LLM today, take public sources, take some UEFI shell like I I think that’s pretty much what I did, right? Just to have some kind of test system to analyze the shells.

Vlad Babkin (38:34.975) I mean it it it it it helps.

Vlad Babkin (38:50.445) Mm.

Paul Asadoorian (38:52.988) to see what was inside of them.

Vlad Babkin (38:56.331) Yeah. There is stuff you can do, but you don’t want this to be doom to be done manually. Like if if you are an enterprise or even if you’re a customer, you don’t really wanna dig into every single device you own. Like you want some automation around this. Like like i i i i i i i yeah, even even if as a as a private customer, like you might have more than one l computer. Like I have like three of them.

Paul Asadoorian (39:11.937) Right. And rever start reverse engineering every single UEFI shell in your your two hundred thousand workstation fleet. Yeah.

Paul Asadoorian (39:25.793) Right.

Vlad Babkin (39:26.379) Right. Now what? Do I analyze every single UFI binary I have in them? And then what do I do? Do I go for network devices firmware as well? How am I sure that my analysis is actually good? Like I I really want just a list of software, realistically. But I’m not getting

Paul Asadoorian (39:40.983) Yep. Now Microsoft will will be adding the affected bootloaders to the Microsoft official DBX revocation list as part of coordinated disclosure. And they do list the hashes of all of the bootloaders that are there.

Vlad Babkin (39:58.37) Yeah, but now this means that you need to have updated DBX.

Paul Asadoorian (40:02.315) Right. We’re back to that.

Vlad Babkin (40:03.947) Which quite a lot of people do not surprise.

Paul Asadoorian (40:07.309) Correct. I think it’s w it’s historically one of the biggest findings in our product, right? Is outdated D BX. It’s very common.

Vlad Babkin (40:17.783) Then yep, it’s very common and very popular.

Chase Snyder (40:20.412) What’s the answer? How should people deal with that? Like, what do you do if why why aren’t they doing it? Is it just not seen as a big enough risk and that’s gonna change over time? Or is it some sort of operational friction or just not enough bandwidth, too many priorities?

Vlad Babkin (40:30.517) That’s that’s one that’s that’s

Vlad Babkin (40:35.841) That’s that’s one part of it. Like it’s an operational risk. If you update your DBX and suddenly your your software stops booting, well you just locked yourself into a corner. Congratulations. But like at the same time it’s not just that. It’s also like operationally hard. Like if you have one device you can find everything you need to update D BX from it. Okay, sure. Now do this for a fleet of devices, especially if every single device is different. And then also do this on a fleet of devices which each has its own settings. Now that gets even more fun and just like brings repeat.

Paul Asadoorian (41:15.969) Yeah, and so this confirms my suspicion. My question was, and I think I knew the answer, does the UEFI DBX always get updated, even we’ll just talk about Windows eleven systems, via Windows update? And the answer is no, it does not always get updated reliably on Windows eleven. And I forget all the details as to why, but it doesn’t. That was my impression. So Chase, y answer your question is i it requires some like manual intervention from IT and IT security teams to push out a D BX update, which, as we described, is a very can be a very risky or dangerous process. it it because it has to be the that update has to be have a check built in. And F W upd actually built this in for Linux systems.

Vlad Babkin (42:00.408) Risky.

Paul Asadoorian (42:13.719) Take the the hash or signing process for your current bootloader and make sure it’s not in the DBX update you’re about to apply. Because if it is, then your system’s not gonna boot if secure boot’s enabled. And so the right update process is to check that that chain.

Vlad Babkin (42:29.151) Up like Yeah, and the the right update process is also to check if you are currently using anything in Z DBX, which is also like very system OS dependent. Like even if you wanted to check all of that, you would be really hard pressed to do something like this. And it’s not because like IT uncooperative and just I don’t know, scarity cats or something. It’s just really hard problem. It’s not like even if even if I would be solving this like as a like to be honest, solving such an update is a

Paul Asadoorian (42:42.019) Mm.

Vlad Babkin (43:02.421) product of its own. Right? Like we we we like in Eclypsium we have this for certain devices, but not for all of them because like again it’s really hard to maintain something like this. So like

Paul Asadoorian (43:10.691) Mm-hmm.

Vlad Babkin (43:20.459) Without help from vendors, we are basically doomed.

Paul Asadoorian (43:20.902)

Chase Snyder (43:24.018) So you’re saying nobody’s gonna vibe code a solution to this problem overnight with Fable Five?

Vlad Babkin (43:28.193) Very unlikely. Like it’s it’s it’s not even a moat, like it’s an actual heart problem. Like you have to have so much data collected for this and analyzed and properly categorized that like even an attempt to wipe code this and use AI will heavily rely on you getting all of this data. And vendors don’t easily make it available. Thank you guys for locking all of the firmware updates behind a contract. Like at the very least give us updates to analyze and lock it in the software.

Paul Asadoorian (43:29.451) Very unlikely.

Paul Asadoorian (43:47.939) Right. Right.

Paul Asadoorian (43:56.855) Yeah, it’s hard to know even what’s in an update. You’re right. It’s hard to know what’s even in an update.

Vlad Babkin (43:56.876) Because like this this is doing community a disservice.

Vlad Babkin (44:02.369) Yeah, and like then then some vendors do a another disservice to the whole community. Let’s encrypt our updates. It’s gonna make them so much more secure if nobody can look into them.

Vlad Babkin (44:16.235) I cannot even I don’t know. Somebody should should should create a evil lender voice for this when like they they don’t intend to be evil but actually are.

Paul Asadoorian (44:28.572) Don’t get me started on vul don’t get me started on vulnerability data. You both know how I feel about that recently. And what a hot mess that is.

Vlad Babkin (44:28.705) Because like

Vlad Babkin (44:35.361) Yes, we do.

Vlad Babkin (44:39.659) It’s just a hot mass.

Paul Asadoorian (44:42.375) But it’s it’s even you know, we’re talking about a very hard problem to know how to safely apply a DBX update. It’s one thing. But if we back up, it’s difficult to determine what when a vulnerability arises, what products and versions are affected by that vulnerability. That’s a super that’s also a super hard problem. That’s usually shrouded in mystery.

Vlad Babkin (44:47.149) Yeah.

Vlad Babkin (45:08.79) Yep.

Paul Asadoorian (45:11.489) Behind a vendor advisory, right? Or they try and put it in the CPE data. We had that conversation earlier, Vlad, right? not all vendors are filling out the CPE data. We we struggle with the CPE format. so like how do we do patch and vulnerability management if we don’t have a good basis for the fundamental data that we’re applying and then relying on version falls down, right?

Vlad Babkin (45:19.383) Mm-hmm.

Vlad Babkin (45:35.735) Yelp.

Paul Asadoorian (45:40.417) I go back to my recent Arista example, which by the way, was added to the SISA KEV this week. And that was one where, yes, certain versions of Arista products are vulnerable. And this isn’t Arista’s fault, by the way. I’m not picking on Arista in any way, but ’cause this is a situation that arises and is more of a a problem we haven’t solved with the right data and processes. Both in in in Vendorland they make it really hard and as an enterprise defender it’s super hard. So Arista issues that vulnerability, the vendor advisory and they go, This is exploited in the wild. These versions are vulnerable, but it’s only vulnerable if you’ve got this component enabled and it’s configured this way. And by the way, if it’s configured in this different way, it’s not vulnerable. And by the way, it’s not just for like one component, it’s for a bunch of encapsulating protocol support. on that on that device. So the if you look at the Arista advisory, there is like tons and tons of configuration examples. So you have to do really hard work to figure out if that device is actually vulnerable to know that you have that in your environment. Yeah, I may have Arista EOS in my environment, but is it the right version? Does it have those things enabled? Are they configured insecurely or are they configured securely? Like that’s an investigation. That has to happen. And by the way, now on top of it all, threat actors are actively exploiting this vulnerability. So your requirement to know if you have it in your environment and it’s vulnerable, we just shined a big spotlight on that. It’s like you need to know this if you’ve got to risk the products. So maintaining an accurate asset database and all that stuff is important, but relying just on version isn’t enough. We need deeper intelligence into

Vlad Babkin (46:37.175) Mm.

Paul Asadoorian (47:05.079) especially our hardware virtual appliances in order to determine not even if they’re compromised, that’s a different thing, just to determine if there if there’s a vulnerability that we need to address in them.

Vlad Babkin (47:43.608) Mm-hmm. Uh-huh. And it gets more and more fun with every single step. Right? So like the industry is just going nuts with like AI detected stuff, and not only that. So AI is not like AI is just accelerating everything by a lot. And like it’s not always a good thing. Like attackers have a much easier time with all of this and defenders.

Paul Asadoorian (47:50.519) Mm-hmm.

Paul Asadoorian (48:11.019) Yeah, agree. I you I think what we’re saying is AI is helping attackers more than it’s helping defenders, potentially.

Vlad Babkin (48:18.285) Yup. Yeeyup. Not potentially actually.

Paul Asadoorian (48:20.515) ‘Cause we were talking about it last night too, like the SOC using AI to find events. That’s great. It’s a great use case for that. But where it falls down is how do we fix the things? Like the SOC is looking for security events, not and maybe vulnerabilities, but where the rubber meets the road to mitigate that vulnerability, you’ve got to find it and fix it. And I don’t see the AI technologies helping us get better. at fixing it and good lord, if someone is out there and in has this technology or has done it, like I want to talk to you ’cause I think that’s awesome. Cause I’ve struggled in my career myself and guiding people on how to apply patches. It’s hard. If there’s vent like technology out there that is helping us, that’s using AI, I thought I wanna know.

Vlad Babkin (49:00.417) Yeah. I have I

Vlad Babkin (49:10.027) I will actually s d at this. A number is on social media. Didn’t have a chance to check it. But some guy actually took a look at published Mythos related vulnerabilities and their how do you put it? And like their patched vulnerabilities. Found vulnerabilities was at Five one hundred so like it’s one thousand five hundred and ninety six. Guess how many of them were actually patched with Mythos?

Paul Asadoorian (49:49.709) Patch by Mythos.

Vlad Babkin (49:51.937) Yeah, patched by the eyes that found them.

Paul Asadoorian (49:56.301) Like maybe half.

Vlad Babkin (49:59.074) No, ninety seven.

Paul Asadoorian (50:01.399) Wow.

Vlad Babkin (50:02.925) So like AI has a whole problem with patching things and it’s not easily fixable.

Paul Asadoorian (50:11.593) interesting. So you’re saying even though AI can find vulnerabilities, it’s still struggling coming up with a valid patch for that vulnerability. Cause that’s that’s the harder part, right? It’s almost easier to find a vulnerability than it’s to patch it. Yeah. And patch it in all the places too.

Vlad Babkin (50:20.001) Yep, yup, yup, and and that’s a much harder part. And and like defenders Yeah and defenders face a massive problem with this like as a defender you have to pretty much patch everything and like if you are a defender who has a product well now you are in a tough spot. Because now you have a lot of people finding rules with the eye and you somehow have to punch them all. So like it becomes like it’s a cat a mouse game come and mouse game, but in this case cat wins. Right? Like cat cat is already like has a claw next to the mouse’s neck. Because like with the amount of vulnerabilities that are found and are publicly known to be found and thus reproducible with even simpler Eyes by like high level threat actors. It’s becoming more and more risky waters for defenders. You have like every single software company now has to have a airtight SDLC. There is no more we don’t care about security because our product is not gonna be used in such a way. Like z this era is over. Like it’s just done. There is there’s no continuation for it. Like every single company needs to have like cybersecurity program, the fact. Like ev ev even if it is a water company. Like like you know, the famous joke like how water bottle producing company pivoted into AI and it was public news. Well, it’s no more no no longer a joke. Every single company now is a cybersecurity company.

Paul Asadoorian (52:00.461) I had one more story transitioning into targeting edge devices with Brickstorm. Brickstorm’s malware if we can start an ASA and or F T D devices. but you know it’s it’s a a Golang based malware and so threat actors can have some flexibility as to which platforms they can deploy the malware to, which is actually a good design choice by threat actors, I hate to say.

Vlad Babkin (52:00.94) Because like

Paul Asadoorian (52:28.995) But they found this recently Volexity published a post and they were found threat actors deploying this to an Egnyte Storage Sync appliance and they had a dwell time of at least 18 months before detection. So I don’t know how much that speaks to the stealthiness of Brickstorm or the lack of detection capabilities in the companies they compromised or combination of both. but Brickstorm is still alive and well and increasing in the breadth and scope of devices that they’re compromising. there was also a free BSD variant of Brickstorm that was found on a pfSense firewall, which was interesting as well. So it’s not just Linux, now it runs on BSD. it’s really kind of becoming the the right once run anywhere of malware.

Vlad Babkin (53:19.695) no.

Chase Snyder (53:27.92) Yeah that that pretty much covers the gamut of underlying network devices, right? Linux and FreeBSD are like the two.

Paul Asadoorian (53:33.453) Yeah.

Paul Asadoorian (53:36.161) Mm-hmm.

Vlad Babkin (53:36.161) Yeah, this is the this this the two big boys. Let’s put it this way. Maybe you can find something else if you pray really, really hard and struggle a lot. But like it’s just bad.

Chase Snyder (53:39.185) Yeah.

Paul Asadoorian (53:52.535) Yeah, it’s pretty pretty pretty amazing to s to see Brickstorm being used in this way. And of course, you know, they they pivoted into the Microsoft environment from it. used things like Python reverse shells, intended as a fallback should Brickstorm be removed. So this is a fairly complex and advanced campaign. verdant bamboo is the

Paul Asadoorian (54:57.247) I don’t if that’s the name of the campaign. on Verdant Bamboo, also tracked as Warp Panda or UNC5221. So that’s the threat actor group. they’re calling Verdant Bamboo, but I recognize it as UNC5221, Chinese threat actor. that their TTPs in this campaign are pretty similar from the ones I’ve observed. the more heavily use network edge appliances as the initial foothold. to then pivot into Microsoft Active Directory and deeper into the organization.

Vlad Babkin (54:57.247) Actually I cannot stress this enough. Don’t trust your edge device. Like the era of like edge device being your firewall and it being reliable is more or less gone. You don’t trust it with access to your Windows network. Like that bad that idea to give it any kind of like active directory credentials. Like this error is just over. Done. There is no more to to to to be to be expected from it. Right?

Vlad Babkin (55:01.869) Mm.

Paul Asadoorian (55:21.676) Yeah.

Paul Asadoorian (55:26.241) Yeah, you’re right. If if your users are authenticating to an edge device using Active Directory credentials, that is going to be a huge target for attackers. I don’t care who the vendor is, I don’t care what kind of device it is, if it’s on the internet, because it has to be, right? So users can be anywhere on the internet and they’re authenticating to it, especially with Active Directory, that’s a target for attackers because that’s a huge foothold, amazing foothold for a threat actor.

Vlad Babkin (55:26.613) And like this is a this is a very big message.

Vlad Babkin (55:54.52) Yep. And like how amazing? Yes. Like there is just no other comment to be made. It’s yes. It’s amazingness of yes.

Paul Asadoorian (56:09.387) What we need is the the the tail scale style. I don’t know what we there’s names for that. S D WAN comes up in that conversation. But there’s mesh networking, yeah. And it it’s newer, it’s I it’s not new new, but it’s newer technology, but it’s more like a a tail scale, right? where i it happens in reverse, right? You don’t have to expose anything to the public internet.

Chase Snyder (56:19.834) Mesh mesh mesh would be

Paul Asadoorian (56:38.273) that authentication is done in a different way so that not everything has to be exposed to the internet. Like I don’t have to expose any ports for tail scale as an example.

Vlad Babkin (56:43.821) So

Vlad Babkin (56:47.927) Let’s let’s let’s let it put it this way. If you don’t have to expose any ports, somebody still has to. So now you’re relying on some public cloud which which like if exploited it exploits every tail scale customer. So like it’s not it’s not better. You can expose one VPN port. Nothing else must be exposed, and that VPN port must not be SSL VPN. Like that that that that VPN port po that

Paul Asadoorian (56:53.975) Someone has to. You’re right. Yep.

Paul Asadoorian (56:59.5) Mm-hmm.

Paul Asadoorian (57:11.115) Yeah, SSL VPN needs to die. I said that when it first came out and it still lived on, and now people are finally killing it.

Vlad Babkin (57:19.159) Yeah, like the the real point of this is that like SSL VPN has to die and your exposed VPN needs to be either OpenVPN or WireGuard, or maybe if you if you float that way IPsec. Like some well known protocol. Yes there is a chance that will get broken as well, that happened. But the number of exploits in something like I key like IT V two implementation or open VPN or WireGuard is much lower.

Paul Asadoorian (57:33.825) Yep. Yep.

Vlad Babkin (57:48.833) historically than what we observed with SSL VPNs. And like this will probably be the safest deployment you can have.

Paul Asadoorian (57:50.017) Yeah. They they still hap they still happen, but yeah. Agreed.

Vlad Babkin (57:57.774) Yeah, like it will be even safer than tail scale.

Vlad Babkin (58:03.341) So because you don’t rely on magic anymore.

Paul Asadoorian (58:03.757) Cool.

Paul Asadoorian (58:08.675) It’s a different kind of magic. We need different magic.

Vlad Babkin (58:10.902) Yeah.

Paul Asadoorian (58:14.541) ‘Cause the the the magic of your network edge appliances with S L V P N’s, everyone knows those magic tricks now.

Vlad Babkin (58:21.783) Yep. It’s

Paul Asadoorian (58:23.073) In in fact, I want to say some network edge vendors have deprecated SSL VPNs in the client and on the server. They’re moving away from it. I saw that in one vendor particular. I don’t I don’t know I don’t remember which one, so I don’t want to call them on the show. But in my research, I did I did s observe a vendor when I was looking at their versions and capabilities, the the feature of SSL VPN is being phased out.

Vlad Babkin (58:34.732) Wow.

Vlad Babkin (58:38.997) I wonder what happened.

Chase Snyder (58:52.122) I mean they should.

Paul Asadoorian (58:52.417) Which is good. But it also means you need to go update your appliances and not just your appliances, but you need to update every VPN client that a user has. So if you’ve got two hundred thousand users with a VPN client, get ready to push out a software update to all two hundred thousand users.

Vlad Babkin (59:06.667) Yup, and like this you’ll have to install it because otherwise hello there.

Paul Asadoorian (59:11.851) Mm-hmm.

Chase Snyder (59:12.466) Yeah. What was it? Last year we talked about, not last year, even just a couple episodes, we talked about the cyber insurance companies that were like calling out. It’s like, hey, if you have certain on premise VPNs, on premises VPNs, around that is like six Xing your likelihood of getting ransomware based on their insurance claims. And in their website, they had this was at bay cyber insurance company. I love to quote their reports.

Vlad Babkin (59:40.439) Mm-hmm.

Chase Snyder (59:41.072) And on their website, they were basically like, if you have these characteristics, if you have this stuff in your environment, we have they have a s a service essentially that’s like, we’ll help you migrate off of this to make you insurable. Cause if you have this stuff on in your system, we cannot insure you, but we can help you get off off of it.

Paul Asadoorian (59:57.697) Isn’t it? Yeah. That that’s one of the most telling data points, Chase, certainly. So

Chase Snyder (01:00:02.532) Yeah, the cyber insurance ’cause there’s money on the line, man. They got Yeah.

Vlad Babkin (01:00:02.635) Yep. This this is this is the the big

Paul Asadoorian (01:00:08.299) And there’s solutions out there to help you. I mean, you know, I’m gonna plug other vendors, but there’s solutions to this problem. but again, ripping and replacing this infrastructure in your your network, especially in larger networks, is not is not easy and I get that, but it’s coming. It’s coming. Gotta do it. Awesome. Well, Chase and Vlad, thank you very much for appearing on this edition of Below the Surface. That’ll conclude the show for today. Thank you everyone for listening and watching.

Vlad Babkin (01:00:23.138) That’s not

Vlad Babkin (01:00:27.852) It is.

Paul Asadoorian (01:00:37.293) We’ll see you next time.

Vlad Babkin (01:00:38.635) And thanks for hosting us, Paul.

Chase Snyder (01:00:40.796) Yeah. This is always the greatest. Thanks, guys.

Paul Asadoorian (01:00:40.877) Anytime.

Back to all Podcasts