Topics:
The so-called vulnapocalypse has largely focused on the volume of CVEs landing in the laps of cybersecurity and network management teams. Frontier AI models are uncovering vulnerabilities by the hundreds, or even thousands, on a regular cadence and that’s putting pressure on teams to rethink patching and how they prioritize which systems are remediated.
In this episode of the Nexus Podcast, Joe Slowik, Director of Threat Research and Cyber Engineering at Dataminr, shared another thought, however. In a recent report published by Dataminr called "Examining the Vulnapocalypse and Defensive Responses" Slowik warns that the overwhelming volume of CVEs may be an unnecessary distraction.
“It is undeniable that the number of issued CVEs over the last five years has exploded. There are more in 2026, and we've already surpassed 2025 and that will only increase between now and the end of the year. That is a statement of fact: There are more CVEs,” Slowik said. “However, If you start digging into CVEs. that are actually being exploited then the proportion of items that are critical hasn't changed. It's been sitting at around 20% to 30% for that same five-year period.”
Slowik adds that trying to keep pace with volume is a losing proposition. Already in 2026, Microsoft has had numerous record Patch Tuesday CVE counts, and the same goes for other vendors participating in the frontier model programs focused on vulnerability discovery.
“Looking at the volume of CVEs as being a concerning item kind of doesn't tell the whole story and maybe doesn't tell us the right story that we should be looking at,” Slowik said. “So we really need to rethink what it is that we are looking for. What's the metric that's going to drive decisions? And how do we make better decisions when it comes to vulnerability management, patch management, and similar?”
Slowik also advises organizations to adopt a mindset that not only assumes breach, but one that also assumes exploitation.
“We need to assume that it is well within the possibility that it can be and maybe already has been exploited,” Slowik said, adding that asset visibility and compensating controls such as segmentation will play a huge role in guarding not only critical infrastructure devices, but also initial entry points at the edge.
“Presuming initial access has taken place and, depending on the adversary and what they're trying to achieve, an exploit alone may be sufficient in and of itself,” Slowik said. “Which gets us into defenders and the need to start planning for greater operational resiliency and redundancy.”
Slowik also covers why we haven’t seen a massive influx of OT vulnerabilities from the frontier models, and some insights from a threat-intelligence perspective on the refrigeration attacks in Europe. For security leaders in those sectors, the sins of technical debt may be coming due soon.
“This is where the ‘just-patch’ item goes out the window for things like maintenance windows, long uptimes, long install times,” Slowik said.
“Looking at the refrigeration incidents that have been taking place over the last six weeks or so. Yes, some really curious, really sad sort of vulnerabilities and defaults being abused. But if you also look at a lot of these organizations, and we're talking about in some cases, a butcher shop, an independent grocery store, or similar. organization. They don't have the budget to rip and replace their refrigeration system," Slowik added. "They need that to last 15-20 years given their operating margins. So what do we do then?
"When it comes to the cyber-physical element, I think [it’s about] going back to the same sense of building resilience and building a sense of understanding engineering and physical safeguards that can step in for when worst case scenarios begin to manifest.”
Mimoso 0:14
All right, welcome back to the Nexus podcast, and welcome back to security researcher Joe Slowik from Dataminr. Joe is back to discuss the impending Voam apocalypse and what you as security leaders and practitioners should be doing about it. Joe wrote an excellent article for his company and uh on the subject and brought some important context and realities to the discussion. So I am going to invite you to check that out. The link is here in the show notes. And uh as usual, before we say hi to Joe, uh don't forget to subscribe to the podcast. We are very easy to find. Uh, we're on every feed Spotify, Amazon, Apple, you name it, and you'll have access to all 142 episodes, I think. So find us out there and subscribe. So with that, let's get started. Hey Joe, it's good to see you. How are you?
Slowik 1:07
Doing very well. Doing very well. Thanks for asking.
Mimoso 1:10
Yeah, of course. So thanks again for coming on. Um, you know, I I I start some of these uh discussions with people I don't know very well about their career path, but I know we know each other a little bit. I don't think I've ever asked you about how you landed in cybersecurity.
Slowik 1:26
So it's kind of a funny story. Um I my academic background was actually philosophy, and uh I tried playing that out towards the only path that makes remote sense there and going the academic route, and that didn't work out for me. I kind of quit on that endeavor. Worked for a few years in an industrial supply company in suburban Chicago as a result. Kind of taught myself computer doing that to automate away parts of my job. Yeah, and then got bored and joined the Navy, and the Navy looked at my background and said, Hey, we're gonna send you here to do these things. And that was really my introduction to at least one perspective on cybersecurity, and that was almost 20 years ago now, and it's been an interesting ride since then.
Mimoso 2:19
Yeah, I I love asking that question because no one has that direct path to cybersecurity. Nobody's got that cybersecurity degree, nobody went from you know, uh direct, especially OT cybersecurity. That's just not a thing. Everybody's got like this zigzag and eventually landed in the net.
Slowik 2:37
Yep. Yeah, so I mean it's always fun. I mean, certainly things are changing uh over the last five, maybe even ten years or whatever, and that there's a bit more of a direct path than maybe there used to be. But yeah, generally speaking, you talk to folks who have been in here for a while and it's like, oh yeah, I was doing something completely different. I just kind of wound up here.
Mimoso 2:55
Yeah. All right, so let's get into the discussion. You wrote uh a report a few weeks ago now uh called Examining the Volume Apocalypse and Defensive Responses. Um obviously this is coming on after months of acceleration because of the frontier models and a lot of headline-grabbing stats about just the acceleration in CVE disclosures. And I I found it interesting that the report kind of argued that that volume is is a distraction a little bit. And I'm wondering if you can take me kind of inside that that part of what you wrote and that and that theme.
Slowik 3:34
Sure. So if you look, it is undeniable that the number of issued CVEs over the last five years has exploded. Um, there are more in 2026, and we still have a couple, well, not a couple months, but a few weeks to go here. Uh it was a couple months at the time that that report came out. Um, and we've already surpassed, well surpassed 2025, and that will only get that difference will only increase between now and the end of the year. Um, so that is a statement of fact. There are more CVEs. However, if you start digging into CVEs by severity, the ones that really matter, but especially if you start digging into CVEs that are actually being exploited, that the proportion of items that are critical hasn't changed. It's been sitting at around 20 to 20 to 30 percent for that same five-year period. And then if you look at things that get added to known exploited vulnerability lists, whether the SISA one, which is good but has some limitations because it's really meant for government primarily. So it's helpful to look at some industry ones like Volnček maintains a known exploited vulnerability list as well that is a little bit more uh wide in scope. I don't think you guys do, but maybe Clarity will someday. But anyway, um, you know, actually track what vulnerabilities are being used in the wild. That number has largely remained about the same as a proportion of all vulnerabilities and hasn't seen that huge increase that we've witnessed just in the total number. So looking at volume of CVEs as being a concerning item kind of doesn't tell the whole story, and maybe doesn't tell us the right story that we should be looking at. And so that's what I really wanted to dig into and hopefully inform some folks in getting into data miner information, but really pulling a lot of publicly accessible things from Kev lists, NVD, and similar. So anyone can replicate this analysis and say, like, oh, Joe's full of something. Right. Um, if you want. But the numbers in this case are are pretty clear uh that volume has gone up, but criticality or the number of items that really matter hasn't. But that doesn't mean the Vumpocalypse doesn't matter. Uh go ahead.
Mimoso 5:57
Right. I mean, excuse me, for probably two decades now, we've all we've been counting CVEs, and it never seems to lead security teams down the right path. I mean, is that a fair statement from your perspective?
Slowik 6:11
It's a fair statement. It's a distraction. And if we're focusing from a security from a volume management perspective on trying to keep pace with volume, the losing proposition is just not going to happen. It couldn't happen five years ago. It certainly isn't going to happen today. So we really need to rethink what is it that we are looking for? What's the metric that's going to drive decisions and how do we make better decisions when it comes to vulnerability management, patch management, and similar, whether we're OT, IT, IOT, some other flavor of tea that hasn't been invented yet, that uh just saying, well, just patch isn't gonna cut it anymore.
Mimoso 6:53
Right.
Slowik 6:54
If it ever did.
Mimoso 6:56
So there's lots of interesting data in the in the report, but uh one that is is going to stand out for a lot of people is the the shrinking time between disclosure and um when it becomes a Kev. Um I think it's from 150 days to under 30 days. Is there really an acceleration there in exploitation, or is that something, is that the effect of the the frontier models also in in concert kind of developing proof-of-concept exploits?
Slowik 7:29
So I don't think we have enough data to really make a definitive call on that just yet. I mean, certainly the frontier models and just large language models in general have really facilitated vulnerability identification, and I'm sure it has really assisted with proof-of-concept development, provided you're using an LLM that'll let you do so, because some of them get pretty cranky when you ask to do certain things these days. Um, but whether it's you know the the AI app at aspect of things that's pushing things forward, or just general adversaries recognizing that, hey, this works and it works very effectively. So we're just going to you, you know, we've been doing fuzzing for decades. Um Python makes life easy for coming up with a POC and similar, that you know, certainly the AI helps, but it's not necessary to, or maybe might not be a complete explainer for all that we are seeing in this regard. But you are right in that the time for Kev Edition has collapsed. And even that average number of a little under 30 days, I think, for 2026 so far obscures that for a non-trovia there it that average number is affected by some items having addition times in the hundreds of days, while there are many that have kev edition times of zero or even negative uh numbers, they get backdated. That's the real crisis of the Voln Apocalypse, is how this velocity has increased substantially from time of discovery to time of exploit, or not even having the benefit of an issued patch or CVE when something is already under active exploitation, which is again why the well, just patch that solves the problem. Like, no, there's not even a patch, it's already being exploited. We need to figure out a different way of addressing the problem set um because it's far different than what we've historically come to think of the vulnerability management uh use case.
Mimoso 9:35
So where should defenders be putting their emphasis of just patch? I mean, it's just the volume alone. There's no way to test and regression test patches and and properly deploy them the way we used to. Um how should defenders be prioritizing this volume?
Slowik 9:54
Yeah. Uh, I mean, I you know, patching is still an important part of a security program. So I hope no one is listening to Joe and it's like, oh, Joe Slowic said don't patch or don't worry about patching. Absolutely not. That's ridiculous because there is still quite a long tail of adversaries using N plus one day uh vulnerabilities and similar for operations and taking advantage of the fact that organizations aren't applying patches in a timely fashion. But we've seen entities from your big scary advanced persistent threat state-sponsored adversaries onto various e-crime uh groups that have proven to be quite effective at identifying and then weaponizing actual zero days. Um, you know, it's always interesting, like, oh, this is being exploited as a zero day. It's like, no, there's a patch already. That's not accurate. But here we're talking about things that have not been disclosed or maybe have been disclosed privately, which lead to very interesting discussions as far as was the research you know independently mirrored by the adversaries, or did something leak? Separate issue. Um, but in if we're seeing this increase in zero day or day of release exploitation, patching's not going to solve your problem. Instead, what defenders need to start thinking about is adopting a mindset. We've had this phrase of assume breach for ages now. I think I did some looking around on that, and it first time I could find mention of that phrase and something that it could be linked to was a Microsoft blog post from the early 2010s, I believe. Um it's been you know over 10 years that we've been tossing that phrase around. Well, we might need to modify that a bit or add to that, assume exploitation, that anything that I have that a threat actor can touch, we need to assume that it is well within the possibility that it can be and maybe already has been exploited. So, what do I do about that? Well, I need to figure out compensating controls and the visibility necessary so that if and when, whether it's a VPN concentrator, a uh mobile device management server, or some some other application, anything that can be touched, if that gets popped for some reason, how would I know? How can I identify the adversary breaking out of that initial access point in order to do whatever it is they're aiming to do within my network? That certainly puts us in a less than desirable position in that we are already proof, you know, presuming initial access has taken place. And depending on the adversary and what they're trying to achieve, that exploit alone, if they're just trying to wipe systems or uh cause an outage, may be sufficient on an in and of itself, and which gets us into defenders then need to start planning for greater operational resiliency and redundancy. But either way, figuring out what is possible to identify these items short of having a suricata signature or a similar that's going to flag the exploit payload over the wire, which it's probably gonna be encrypted anyway, so good luck.
Mimoso 13:02
Right.
Slowik 13:02
Um what does that look like? And so you know certain buzzword bingo items that have been tossed around and made fun of, zero trust network architecture. Yeah, that's been abused pretty badly over the years, but there's something to be said for it in that we are probably need to fundamentally rethink what we think about in terms of trusted assets within our environment, pull on that thread a little bit so that we are not implicitly trusting as many things as maybe we um are currently and probably shouldn't be because they could be subverted without our knowledge by an adversary. So if we start reducing those trust relationships or questioning them more effectively, what does that look like in terms of a visibility perspective? Thinking about things like east-west monitoring as opposed to just ingress and egress uh monitoring for network traffic. Uh thinking about things like enhanced host of visibility, not just on end-user workstations, but can I see or can I even identify if a new user is added to a network appliance? Do I have that monitoring and visibility in place? A lot of organizations don't. And so pretty simple post-exploit activities that should stand out just don't get uh even seen because it's taking place on device types for which we don't have EDR or similar.
Mimoso 14:26
You mentioned the VPN concentrators a minute ago, and I remember probably about a year, maybe 18 months ago, there was a lot of activity around edge devices and a lot of advisories, you know, that these devices were a concern. Um any insight as to whether that may have gotten better or worse since then? And you know, why is that such a natural kind of place to target if I'm an attacker?
Slowik 14:51
Yeah, I mean it's about the same as far as I can tell, or maybe even a bit worse. Although I think we're now very well aware of that weakness that people are at least paying attention more than they were, say, in 2021, 2020 time frame, where that really started to take off as an initial access mechanism when people went remote because of COVID and similar. Seems like that was a decade ago, right? But now it's just four or five years ago now. Anyway, um, it's still an issue, and it's an issue because we're talking about, you know, whether it's a VPN concentrator, application delivery controller, firewall or similar that's going to sit at the network edge and by nature be accessible. Having said that, just because something's accessible doesn't mean that it should be accessible in every way. It could be accessible. Thinking about things like external facing management interfaces, for example, are a big no-no for these devices. That's facilitated a lot of badness. So there are secure architectural decisions in terms of what am I actually exposing here and how do I limit that visibility. That can go a long way to reducing that attack surface. But otherwise, adversaries know that for modern organizations to operate, these things need to be up online, and I need to be able to touch it. And not only that, but when it comes to patching it, generally need to restart it uh or something after applying it, which means there's a potential downtime issue, right? Rather, an uptime issue that, okay, if I want to make sure that my custom configuration or for whatever device survives a reboot uh and similar, I'm gonna have to do some testing and probably then apply this after hours or uh similar, which means work needs to be done and delays get introduced into that patch and maintenance cycle, which adversaries are happy to take advantage of.
Mimoso 16:37
I want to go back to the kind of the shift you mentioned from assume breach to assume exploitation. I think it makes a lot of sense for a security practitioner, but if how do I take that to my CEO or to the board and say, you know, we're probably owned in some respect. I mean, any insight there as far as you know, whether how that how that message is coming across? Um, you know, are people hesitant to kind of bring it up the ladder, so to speak?
Slowik 17:05
I think so because it is almost an acknowledgement of failure to a degree that it's like, yeah, you know, we're probably already compromised. Like, well, that's not what I pay you for. Why the hell are we already compromised then? Um, but there needs to be a degree of awareness and almost humility around these these sorts of discussions where it's it's not because it's anyone's fault uh in some of these instances, short of we're running networked applications in 2026 on code bases that have, you know, that probably are old enough to vote at this point or similar. So how do we then operate securely in an environment where we are at somewhat of a disadvantage relative to adversaries and leverage other advantages we may have relative to those adversaries to build to achieve security, but also to build in resilience and similar into these environments. And that requires going to decision makers and people who control the purse strings and such with advice that it's not just about buying a blinky box or you know installing the next greatest, you know, XDR, NDR, EDR, whatever, but rethinking how we're doing business to a certain extent, which is painful and expensive, but also increasingly necessary. Thinking about do we have a sit a secure and sustainable architecture for how our network is even set up? How is it that end users are interacting with this environment? What do we allow? What should we not allow? And how do we manage these things so that we can find that sweet spot between running a very secure network while also running a network that allows the business to do its job and fulfill its mission? Because the two often are in conflict with one another to some degree, that greater degree of convenience often play against greater degrees of security and vice versa. So it's really about making hard decisions. And the painful bit is there is no easy panacea that you know, invest in this one thing or do this one trick or AI versus AI, and we'll win this. Like, no, that's not gonna cut it. It's a much longer, more expensive slog, unfortunately. But if we don't realize that, we're just setting ourselves up for continuous and long-term failure as well. Because this isn't going to get any better.
Mimoso 19:26
Yeah. I and and there's so many exposures, there's third parties, there's you know, just lousy passwords. I mean, look at the refrigeration hacks. I mean, this all could be just because of a default password that wasn't changed. We just don't know yet. But yeah. The basics really count.
Slowik 19:44
Yes, they do. Um, yeah, and that's the thing. Uh it's almost a hackney statement or whatever of like do the basics, do the fundamentals, eat your security vegetables, however you want to phrase it, that it still matters. And the way that I like to explain this, and I'm kind of working on some write-ups on the side or whatever, maybe it'll come out in the next couple of weeks or so, that we need to have a sense that security isn't just about preventing things, it's also about managing when bad things happen to an extent. Part of that is sort of preparing the ground, preparing the landscape around us so that we're shaping it in such a fashion that, yeah, the adversary is going to get in or try to get in. How do we disadvantage them to the greatest degree possible so that we can see them and evict them uh effectively from that environment? So assume breach, assume exploit, but when it happens, which it's going to happen, that we're able to prevent domain takeover, we're able to prevent ransomware deployment, we're able to prevent OT network access, let alone OT uh impact delivery and similar, that we can set up boundaries and guardrails within the environment to mitigate against worst-case scenarios and increase response and recovery time frames.
Mimoso 21:01
Yeah, I have a feeling a lot of people are going to start talking about the kill chain very soon again, kind of resurrecting those discussions and where they can inject themselves with a control to kind of you know blunt the effect of these intrusions.
Slowik 21:14
Yes. I mean, uh, you know, to make a Bruce Lee reference, because why not? Um be like water. Uh shape yourself to the adversary, can you know, contort yourself to their movements and take advantage when they slip up or when they make a mistake and then fight back.
Mimoso 21:28
Yeah. Um, I especially with regard to OT, I think a lot of technical debt payments are are going to be coming due soon. Don't you think that a lot of that is going to be exposed in the very near future, especially in the context of the frontier models kind of uncovering vulnerabilities, et cetera.
Slowik 21:48
Yes. And this is where, again, the just patch item goes out the window for reasons that your listeners probably don't need me to reiterate things like maintenance windows, long up times, long. Stall times or whatever and similar. Looking about the refrigeration incidents that have been taking place over the last six weeks or so. Yes, some really curious, really sad sort of vulnerabilities and defaults being abused. But if you also look at a lot of these organizations, we're talking about, in some cases, uh a butcher shop, an independent grocery store, or similar organization, they don't have the budget to rip and replace their refrigeration system. They need that the last 15, 20 years, um, given their operating margins. So what do we do then? When it comes to the cyber physical element, the OT, however you want to phrase it, I think going back to the same uh sense of building resilience and building a sense of understanding engineering and physical safeguards that can step in for when worst-case scenarios begin to manifest. So thinking about refrigeration control systems, having things like physical alarms and similar, like we have in other fields and that do exist in certain refrigeration environments. It appears that it was an operator responding to an alarm or at least visually monitoring the system that led to the identification of the French blood products uh agency uh for their contractor being hit as part of what appears to be part of the same wave. If we want to translate this to the electric sector, it's kind of hard to hack a fuse. So thinking about things along those lines or to compromise a valve and similar, what are the things that we can rely on that we know an adversary can't touch, can't circumvent? And how do we start building up? You know, certainly we don't want a fuse to blow or blowout valve to rub or uh disc to rupture and similar, because that's a bad day on its own. But it's better than the you know, getting even further beyond that where you have equipment destroyed or an explosion or similar. So, okay, we're leveraging these unhackable defenses to avoid worst-case scenarios. How do we walk that back a little bit further, even so that we're preventing even getting to a point where we need a fuse to step in in order to prevent an overcurrent situation or similar? And you know, this sort of consequence-driven uh analysis, so CIE and similar sorts of items, um, become effective frameworks from the cyber physical perspective to start thinking about how do we build these systems in a way that allows them to be redundant, resilient, and to be able to take a punch from an adversary while still being able to deliver that critical function of clean water, reliable power, and similar to end users.
Mimoso 24:39
Just to bring the OT discussion back in the context of the Vuln Apocalypse, what we haven't really seen a huge influx of Volns in that respect. Is that a function of either the Rockwells and the Schneiders and the Siemens either not being part of programs like Glasswing or just relatively newly joined to those programs? Or is it something else?
Slowik 25:04
I think there's a few things going on. And I think what you just identified that for initial efforts like Glasswing, and I forget the ChatGPT OpenAI name off the top of my head right now, but this the program they're running as well. Uh originally, and I blogged about this too a couple months ago, they were OT agnostic. Just that what even is that? Doesn't even exist. You know, why you know where's Siemens, where's Schneider Electric, where's GE in these discussions? They just weren't there at the at the beginning from the frontier model research perspective, which has probably limited certain things, and we've seen other things like open source libraries, poor, poor curl, um just getting hit repeatedly, uh, and then enterprise IT software being mostly in the crosshairs. What worries me is that, okay, so that's what's we're what we're seeing publicly from the researchers, from the big AI labs and similar. But if we think back to a couple of years ago when uh Ink Controller, Pipe Dream, whatever you want to call it, was disclosed, that had what, four or five vulnerabilities that were baked into it that were not public, that were only identified when that code was discovered under somewhat mysterious circumstances. Um, okay, so we know that adversary entities are doing vulnerability research and identification privately, and certainly not telling the vendors about this. What worries me is how much of that same vulnerability discovery is going on with on-site, on-prem models, the open weight models and similar that are turbocharging research and identifying things in critical infrastructure systems that aren't being disclosed to vendors, then we're not going to hear about it until we see an attack or we, you know, the capability actually gets deployed. So I think there's a real visibility issue when it comes to these items that you know, these are often not harder, but certainly for acquiring firmware software in certain instances, like you have to buy crap off of eBay and then extract firmware to research it and similar when code bases are proprietary and similar. So there's a barrier to entry for a lot of other researchers, and then we have them not being part of some of these uh initiatives to begin with. But for motivated state-backed, state-sponsored entities, this is well within their wheelhouse. Thinking about long-running campaigns like a Vol Typhoon. If I know most of the attention on something like a Volt Typhoon has been, oh, of living off the land techno uh techniques and behaviors. If you think that Vol Typhoon is not sitting on some storehouse of OT-specific capabilities to be used at a time when they want it to, I think might need to reassess that position. Right. The same for other sort of threat actors out there that are poking in this space. So just because we haven't seen a deluge of OT-related vulnerabilities, people are almost certainly poking at them. And I bet what we don't see is awfully it it will be quite concerning.
Mimoso 28:04
Yeah. So in that context, uh just going back to assuming exploitation, how different is that within an OT environment where safety is so critical or uptime and availability are obviously driving strategies always.
Slowik 28:21
Yeah. And you know, it again comes back to doing the basics, making sure you have properly segmented and isolated networks, not air gapped, but segmented so that you don't have any any relationships between any two nodes and similar, that you're doing things sane in terms of remote access connectivity or introducing uh software or code into these environments, and they're not coming from untrusted repositories and similar where possible. Um building for and designing around resilience, recovery, and sustainability instead of just pushing what is immediately applicable and useful. Buying into a mindset that I think we're going to have to make a shift to in this industry that, or in various industries, that we're no longer in a world where if you're putting together a plant, setting up a power new power plant, wastewater treatment facility or similar, it's like, oh yeah, this is going to be solid for the next 20, 30 years. Like, no, that's no longer tenable. And having a mindset of more rapid, agile um maintenance cycles and similar to keep pace with not just vulnerability items and patching, but also for doing things like managing networks and being able to shift them, uh, their posture in response to events, things like software-defined networks and similar technologies that have been exciting and have existed for years, but their adoption has been maybe less than it should be to enable a more dynamic OT operating environment.
Mimoso 29:53
All right, before I let you go, I definitely wanted to, I know we've touched on it a couple of times with the refrigeration hacks. I just wanted from your uh threat intel experience, um, you know, what are your takeaways from these attacks? Why don't we know more about how they got in, attribution, et cetera? I know the French cert this week um attributed to the the R RGC. Um just from your threat intel background, what do you what are your takeaways from the these attacks?
Slowik 30:25
Yes, so I will say that the French reporting from the C4, um, so DGSE ANSSI, uh I'm at a loss for the other acronyms right now, but basically they're CISA on steroids. Yeah, um there is from my own perspective and technical analysis no reason to doubt their analysis uh at this point. So especially given if anyone's looked at the PDF accompanying the uh disclosures, they went into pretty good detail, not just into what was responsible, but who, in a sense of here's a photograph of the person in charge of this unit and such. So they're pretty confident. I'm pretty confident that we can say that they they can be confident. Um that's all I'll say on that for now. But in thinking about, well, why was this hard? Why did this not happen initially? Well, because think about how this intrusion played out. You had directly internet accessible systems at organizations with, because we're talking in many cases end-of-life, unpatched, vulnerable devices here that were interacted with. How much logging do you think was taking place as far as what was accessing those systems and who was doing what to them? I'm guessing little, if any, in the vast majority of cases, which meant from an investigative standpoint, there was almost nothing to work from except maybe backbone net flow data and similar to try to identify who was talking to what in given time windows, um, that there just wasn't much to go on. And if you look at the attack itself, you know, between the research that you know Team 82 published back in August, I believe, uh, that may have been leveraged uh by an adversary in order to facilitate some of these items, you know, Dan Foss, they pushed a patch and uh the researchers worked with the vendor to make sure that disclosure was responsible, but that can't force an organization to apply the patch, even if it is done in the best way possible. Um but the overall technical sophistication, if you want to even call it that in this case, is exceptionally low. So even looking at how this attack played out, you had relatively easy access to devices, and all the attackers did was reassign set points to the maximum allowable value for at least the Dan Foss devices, 50 degrees Celsius. Um, and that's it, and just script that. And that, especially if you're using Claude or Chat GPT or whatever to help you out, doesn't take much in order to write that and then use it. So anyone could have potentially done this. I shouldn't say anyone, anyone, but lots of people, it falls within the capabilities of lots of adversaries. So I know there were Z Pentest and no name, uh I forget the numbers, 05716 or whatever they are, claiming they did it. Their track records are so poor in terms of actually doing anything other than DDoS that I when they rushed to make that claim a day or two after the events took place, immediately discounted them as just being bluster. Yeah, so not the easiest thing of things to investigate given lack of evidence. Lots of different entities that could have done this. Um, and were uh and then thinking about what sort of entities would have access to the information necessary to really run this down, really only talking about a few commercial organizations and governments that can poke into and uh you know subpoena or get access to certain types of data sources to allow them to not just say start seeing what happened, but start running that trace back to where it originated from.
Mimoso 33:57
Right.
Slowik 33:58
Which gets me back to I would trust the French on this one.
Mimoso 34:02
I mean, we're so reactive in security. I hope that something positive comes out of this in terms of kind of locking stuff down from away from these default passwords and you know, the technical debt, everything we've talked about in this in this discussion this last 35 minutes. It's just yeah, it's all sitting right there.
Slowik 34:19
Well, and it's also a very sad sort of situation because again, we're talking about your supermarket here, not a power plant or anything like what you know, the IT at your local Kroger or Carafor if you're in Europe or you know, whatever, it's run on the back end. A lot of the building control systems are also contracted out, not necessarily all to the same entity and similar. And it's kind of a wake-up call and thinking about like, whoa, the attack surface actually extends to this as well. How are we gonna fix that? Uh, because I did a look yesterday morning, actually, there's still several hundred end-of-life Danfoss devices of the kind that we're interacted with in this campaign that are up on the internet. Now, granted, at this point, half those are probably honey pots at now, but there's still several hundred, though, that are legitimate systems uh that this same attack can be replayed against uh even several weeks later. And some of those organizations probably have no awareness that they're even at risk, unfortunately.
Mimoso 35:20
Yeah, I mean it's it's not your IT guy usually. It's some integrator or somebody on the outside that's that's running this stuff for you. And I I they may not even be aware that there's a Dan Foss controller in in their environment. So that's what they're dealing with. All right, Joe. Let's leave it there. Um, thank you so much again for coming on the podcast. Uh people really enjoy our conversation, so I'm glad we did this one.
Slowik 35:44
Yeah, thanks for having me, Michael. Always a pleasure.
Mimoso 35:47
All right, take care. Bye.
Michael Mimoso is Director of Influencer Marketing at Claroty and Editorial Director of Nexus.
