Loading summary
Transcript122 lines
- [00:00]
A
Foreign.
- [00:06]
B
And welcome to Risky Business. My name's Patrick Gray. We'll be getting into the news in just a moment with Adam Boileau and James Wilson. And then we'll be hearing from this week's sponsor, Airlock Digital. Daniel Schell, the CTO of Airlock and Dave Cottingham, the CEO, will join me this week to have a chat about a whole bunch of stuff that went down with Digicert. They got owned and some threat actors were able to sign some malicious stuff, stuff with some certificates at Digicert. And that kind of wasn't the end of the story because when all of this was happening, Microsoft wound up accidentally nuking Digicerts where it's certificates from Windows devices, you know, single digit percentage of Windows devices. But it caused all sorts of chaos. And Daniel joins me later on to talk through all of that. And I don't know what we learned from talking about that. Like you just listen to it. I don't know what we learned, but it's fun to talk about that sort of thing. So that is this week's sponsored review. And Dave pops by too to talk a little bit about some new stuff coming in. Airlock's product that is coming up later. But first up, of course it is time for a check of the week's security news headlines with Adam and James. And we're going to start off by I guess confirming what we said at the start of last week's show, which is GitHub had just put out an ominous tweet saying they were looking into reports that they had had an incident. It turns out, yes, they did get owned. It looks like it was Team PCP who've been owning everyone's supply chains. James, I mean, what's the end result of this going to be for people like, why should we care?
- [01:43]
C
Well, I think we should care because on two different threads, first of all, your package ecosystems, they get a bad rap as being this disaster waiting to happen because there's so many different players involved, so many levels to it. But you've got to kind of zoom out on this one and say, hang on, this was a Microsoft owned company, GitHub, that was infected by a bad extension in the Microsoft curated marketplace for the code editor that Microsoft creates. It's just so end to end and yet still this degree of wreckage can happen.
- [02:13]
B
They own the failure end to end. I mean, that's amazing, right?
- [02:17]
C
It is brilliant vertical integration of the failure stack, if nothing else. The other thing that's interesting here is GitHub says, oh, you know 3800 repos, they were all only our internal thing, no customer data. But I think you're missing the point that if 3,800 internal repos are now in the hands of Team PCP, that seems to be really good at learning from their last breaches to mount their next campaign. What the heck are they going to find in there? It's like a, you know, give a man a fish eats for a day. Give a man 3800 repos hacks for who knows how long.
- [02:48]
B
Well, my favorite thing in all of this is the corpo speak. New levels of corpo speak being unlocked by GitHub spokespeople because they were asked whether or not it was true that Team PCP's claim that 3,800 repos had been compromised. And the spokesperson said it was. That number was directionally consistent with what they were they had figured out. Which is just like, man, we're getting new words and phrases banned from Risky Business here. Like, like learnings. Regular listeners would know that does not get said on this show without being challenged. Adam, what did you take away from this? I mean, I think, you know, James touched on it as well, but like, the fact that they got done over by a comparable VS code extension is somewhat embarrassing.
- [03:32]
A
Yeah, it's certainly not a great look. And I think my concerns are much like, James, what is this actually going to mean for GitHub the.
- [03:40]
D
Org?
- [03:40]
A
Because I mean, GitHub customers not directly impacted, but like the path from I've got some access to GitHub internally to I've got access to customer hosted infrastructure, customer data, you know, all of their other products that get deployed out. Like, there's just a long path from GitHub into all sorts of interesting places. And as James says, Team PCP have proved that they are capable and willing to leverage whatever they've got onwards into, into other access. And so like, it doesn't feel good. And I don't know, like, in the end, if you use GitHub in ways that everyone does, you do gotta trust them and they've gotta earn that trust and be, you know, live up to it. And man, I sure hope that they have learned how to do instant response and they're gonna get this one right, because Team PCP aren't gonna cut them any slack.
- [04:35]
B
No, but I mean, you also wonder like, okay, say you don't trust GitHub, then what? Then, right?
- [04:41]
C
Like, I don't know, you go to GitLab, which has had a. Yeah, they've
- [04:46]
B
had a Flawless, rock solid relationship, flawless security record.
- [04:48]
A
Nothing has ever gone wrong with GitLab. No, I mean this is the problem like we have GitHub has had. It's just got such a central place in modern computing and honestly I don't know that it was a, like, is that a choice we would have made in like clear headed, well planned, but we evolved into everyone putting everything on GitHub. We didn't plan it like that. And I don't know, I guess we're going to find out how bad a choice that was.
- [05:13]
B
Well, and it's all getting messy at the moment just because the amount of AI, you know, Gen AI code and everything, like, you know, we've all seen the charts, right? GitHub is like groaning under the weight of all of the, all of the commits happening at the moment. But yeah, and look, we got some more detail on the Grafana compromise which was part of this whole Team PCP thing which, you know, involved the Tanstat compromise and minishirelude and whatever. And there's just more and more details coming about how just like Team PCP was everywhere. Everyone's sort of grabbing at attribution at the moment too. I think I heard someone ask the other day, could this be Iran? And now someone's asking, could this be dprk? I don't think we really know and I don't think it really matters. I mean the fact is you've just got these people running riot through your supply chains with this sort of stuff, seemingly fairly easily and you just think, well, you know, does it, does it really matter who's doing it? I mean, probably best case is it's dprk because then they're just going to be targeting, you know, crypto. As Adam always says, it's a victimless crime. James, what do you, what do you, what do you think about all of this?
- [06:15]
C
Yeah, it's. The attribution is tough when they just seem to be stockpiling everything and not actually making that next big move that might tip their hand. But look, in terms of what Grafana put out, it's good, there's more detail, but gosh, it just leaves some questions unanswered. Like they referenced here that there was a number of GitHub workflows, they rotated a bunch of credentials, they missed one credential. But it begs the question of why did you have CI workflows that had credentials that could access all of your repos? Question one and question two. Why was that repo pulling in assumably latest version of Tanstack when it should have been pinned to the version. I think it's good they're putting more information out here like this. There's just a couple of questions that I wish they would have answered that I think would have put people in a better position of understanding how they can take more actionable steps to, to address this.
- [07:09]
B
Yeah, I mean, it's just, it's wild times, right? And I mean, that's been the thing about the team. Team PCP is just the ease with which they've been able to do all of this. And like, even though you described a few sins there, they shouldn't be terminal. I think this is the, this is the contemporary sort of threat environment in 2026. Adam, I'm sure you'd agree with this, which is, I think if there's one thing AI has taught us, is that we just have to lift our game a little bit and, you know, assume that weaknesses will just be exploited in a way that previously they wouldn't have been because we have these very thorough AI engines now that are just prepared to go out and actually do the work.
- [07:50]
A
Yeah. And it does make me wonder though, like, specifically when we're talking about like the attribution of team pcp, if all of these things get compromised everywhere and they're all up and down our supply chain, but they don't actually do anything with it, does it really matter? Like.
- [08:03]
B
Well, you know, it's funny. It's funny. Yeah. So James is like thinking about pulling together a solo podcast on this and we all had a little chat in Slack last night with Catalan Kimpano and you know, I don't think any of us really know who's behind this, but, you know, he made the point that there's such a thriving marketplace for compromised credentials that they could just be going and selling them in Telegram for all we know. Right? Like we just don't know. And that's the thing, isn't it? Because we're all old now and here we are in 2026 and the kids are doing this stuff and, you know, maybe, maybe there isn't much of a point beyond collecting credentials and selling them for 50 bucks a pop in Telegram. It'd be disappointing, but it's possible, right?
- [08:41]
A
Yeah, I guess we always want to see like that one planet melting, everything ruining, you know, beautiful, well thought through hack of that the 90s hackers in US all want, but maybe that's just not the world that we have anymore. And maybe there is something else to do with this stuff. And it reminded me of the conversation we had last week about the US vs Iran with the beautifully exquisitely crafted Fast 16 and Stuxnet vs Iran just hack and water supply treatments in small town usa. In the end, the impact matters. And all of the cunning hacking you do there ultimately is only of interest to nerds like us. And, you know, maybe team PCP needs to do something useful with all this access or whatever it happens to be. And that's the real. That's the winner on the day. Not. Not all of the stupid hacking stuff that we like to look at. So, yeah, as you said, maybe we are the old people and they are, you know, going to demonstrate the future to us.
- [09:37]
B
Yeah. Now look, staying with supply chain stuff, and someone did something really weird where they compromised an NPM package by, I think they flagged some sort of issue with it. And then they offered to the maintainer, hey, I'll take it over and I'll fix all of this stuff. Then they quickly deleted the issue and then loaded up the package to deliver malware. What was interesting, though, is that the malware they were delivering was via, like, they used the Karuna exploit kit, which is funny because it hasn't worked. It doesn't affect anything after iOS, iOS 17.3 or later, which is like 2023. I mean, I don't know who they're going to own with this, but it's going to be like somebody's grandma. James, what's. You know, that's your vibe on this too, right?
- [10:21]
C
Yeah, Grandma. Grandma's crypto wallet's in serious trouble from. From this campaign.
- [10:25]
B
But that's what I mean. It's like someone's hand me down, hand me down iPhone that's like, you know, 10 years old. It's like someone's grandma or someone's kid who's getting owned by this.
- [10:32]
C
It's not like, it's not the thing. You're keeping your large stockpile of crypto safely managed on it. Like, it doesn't stack up at all, you know, especially if you're going to take the time to curate that relationship with the previous owner of the package and convince them that you're going to take good care of it. Great. So many things you can do. Then why. Why Karuna?
- [10:53]
B
I mean, yeah, this was your reaction as well, Adam. Right. Which is.
- [10:56]
A
But why? Yeah, but why? And like, part of me is like, it's just like hot rodding, right? I mean, you've got access to this amazing exploit kit. You've owned a package via a Little bit of social engineering, like just gluing one massive, you know, high end exploit kit into this thing. You've got like, it's kind of like, you know, putting, you know, I don't know what, what the car analogy is, but like, you know, kind of hotting up your ancient old, you know, dang a car just because you can. Right? Just because it's a fun engineering project. And then when you take it down to the local meetup, everyone's going to ooh and ah and admire your handiwork, but ultimately, you know, you're not going to go drive it around or whatever. It kind of feels like that, like
- [11:34]
B
someone's just put a Ferrari engine in a Hyundai xl. I'll help you as the car guy on the podcast. I'll help you.
- [11:40]
A
Yes, that's. Yeah, exactly. I figured you would fill in the blanks there. So that's what it feels like. And in a way I kind of respect that. But on the other hand, like, but why? To do what?
- [11:51]
B
Yeah, yeah. To what end? And look, staying with open source, right? We've got some comments from the acting chief of CISA here who is fretting. The headline says acting Director Nick Anderson's comments came as blah, blah, blah. He is fretting. Cybersecurity reports that he is fretting about open source vulnerabilities and delayed security improvements. I think this is a reasonable concern to have and it is something that's popped up a couple of times in our discussions on the show and off, which is, look, there's this huge deluge of bugs coming and open source projects don't seem particularly well positioned to do much about being flooded with bug reports. Right. And I've spoken to a bunch of maintainers like a lot of them are on top of it. I spoke to Fletcher from Authentic recently. We're doing a sponsor interview. I think that one's for next week's show. And you know, he's getting hammered at the moment with, with bug reports. And it's good because, you know, they've actually got people who can, who can do it. But that's an active, very much sort of active funded open source project, whereas most of them aren't. And a lot of them are sort of complete and just have been done and developed and might fix the occasional bug. They're not, they're just not equipped to deal with an influx here. So look, you know, this Nick Anderson hasn't really suggested any fixes here, but I think it is reassuring actually to see senior guvies Actually flagging this as an issue. Was that your vibe there too, Adam?
- [13:14]
C
Yeah, yeah.
- [13:14]
A
I mean obviously these are real issues and everybody is having to deal with the shake up of the, of the security industry and the way we find and report bugs and yeah, open source people by virtue of their community roots aren't necessarily well equipped and yet it's an important issue. And the alternatives to open source software, Microsoft and Oracle and big vertically integrated software companies, they are also not necessarily super well equipped, but they are at least funded probably and have some incentive to try and deal with it. And we are all struggling in our own different ways to deal with the changing world. And yeah, open source is just so important to the Internet ecosystem and it's good that it's getting attention. But I think you called out the important point, which is. But so what are we going to do about that? And we don't really know.
- [14:00]
B
Well, this was James note on this, right, which is like SISSA is calling for modifications to the way they deal with and he's like, what modification can you tell us?
- [14:11]
C
Right, yeah, it was just one of these articles. I think I read it before a coffee this morning, which is probably a bad idea because I was cranky and it was just like every paragraph I was like, yes, but what, what give me something tangible. But I do agree with your take there, Pat, that, you know, good that they're calling this out. Good that senior guvies are doing this and kind of nice that senior guvies are doing it and referencing an XKCD comic at the same time. Like that's, that's a nice little cultural crossover of, of a reference to xkcd. So yeah, not bad. But I do like, yeah, he's, he's, I think his last statement in here is the most impactful that, you know, America has not, or the United States has not invested where it should. And you know, but then the dot dot challenge there is. Yes, but then they're also not investing as much in CISA and other things. So how do we change that investment envelop was the question it left me with.
- [15:01]
B
Well, we're going to have to, right, because we've got some follow up reporting now on Mythos. Anthropic published a report saying that Mythos has found more than 10,000 software bugs. I think they flagged something like 2800 of them or something or as critical. You know, like it's, it's real. Like these LLMs are crapping out a bunch of O day and everyone's having to deal with that it's nice to have some numbers on it, I guess.
- [15:24]
C
Yeah, good to see numbers. I think the numbers were larger than I thought they would be, you know, because we're still. Without this being in the hands of the public, it's still a bit of a latent concern of how much was this just marketing hype. Was it really that dangerous? But these numbers do a pretty good job of saying, hey, yeah, it's real, it's finding things. This sort of conversation you and I are having around this, Pat, is that, yes, it can find bugs, but also, gosh, the models are still really good at creating their own bugs. And so, yeah, there's bugs on both sides of the equation with model use.
- [16:00]
B
That's the thing. And I think. Look, I really think one of the most insightful things said about this was the grok on this show a few weeks ago when talking about those Mozilla bugs, 270 bugs found by Anthropic. And he's like, well, that's not going to meaningfully improve things because infinity -270 is still infinity. And I think that's true. We've said it for 20 years, you cannot patch yourself to secure software. Right? So that's one aspect of this. But we are just going to be drowning in bugs. I think it's the positives there are. If we keep seeing bugs being found by LLMs over and over and over again in the same code base, maybe the people who maintain that code base or that product are going to be inspired to, you know, maybe make some architectural changes, refactor some code. You know what I mean? So I'm not all doom and gloom on this, but as for these things generating bugs themselves, we had a bug recently. So James is developing a bunch of software using Claude and now Codecs because Anthropic has done its quarterly lobotomy of Claude.
- [16:55]
C
It's fired. Claude, you're fired. I'm done with it.
- [16:57]
B
This week's not working at the moment, so we're. We're back on Codex. But, like, it's. It's at this stage, it's internal apps, right, that allow us to ingest a bunch of news, sort it, triage it, reorder it, put notes on it, things like that. And as part of that, you want to be able to reorder some of the news, drag it around, drag and drop. And we had this weird bug that for me just was really like a moment of, wow, okay. This stuff is not perfect where, you know, you can add and remove news articles from A list. Right. And then you can drag them around. The bug was when you remove an item from the list, it didn't remove it properly. So when you started to drag things around, you wound up with all sorts of unpredictable effects like crashes, whatever, things just not working. And you think, okay, that's not a security bug in that instance. But that sort of thing is where security bugs come from. Right. So I just, I do just think, wouldn't it be a wild situation where you've got these LLMs generating the type of logic bugs that they're actually not very good at finding? Adam, what do you think about that idea? Because that could be just a really funny outcome here, I think. I mean, great for us because we love to talk about stuff like that because it's funny and bad and that's our bread and butter. But yeah, what's your vibe there?
- [18:11]
A
Yeah, it will keep us in comedy stories for a long time. I think the, the thing I get, the vibe I get is that the velocity of number of lines of code being written on this planet has wildly increased in the last two years and the velocity of bugs that we fix is also wildly increased. But I feel like the first number is going up a lot faster than the second number. And yes, over time the models will get better at not introducing security relevant bugs. Obviously there are still many other classes of bug logic bugs, things that aren't immediately apparent security flaws or we don't have to, that we don't understand the downstream consequences enough of as humans, let alone as AI models like those velocity numbers just still feel like we are wildly out of whack with, you know, building infrastructure, building technology that we don't yet understand the implications of and that's going to keep us in content for a long ass time.
- [19:07]
B
Well, that's the main thing.
- [19:10]
A
Self interest. Self interest, yeah.
- [19:12]
B
And I think also, like, you know, we've got a story here that sort of underscores that there is a little bit of hype involved in a lot of this stuff. Yes, it is true that LLMs can find a lot of bugs, but then you hear, oh wow, Mythos found a way to bypass Apple's memory integrity enforcement. You think, oh my God, that's incredible. And I spoke about this last week where I said, well, I knew people in XDEV who sort of would smirk a little bit when you talked about memory integrity enforcement like it wasn't that much of a problem for him. And then you actually get the details on the bug and it's, it's a bit disappointing. James?
- [19:43]
C
Yeah, I mean, I remember saying that last week that I was so excited to see this research be released once the patches were out. And then of course the patch came out and before the researchers could even publish their work, someone reverse engineered the patch and found there was like a one line assembly change. And the actual bug, it just makes you go, seriously, that's all. To bypass memory integrity enforcement. I was thinking back to the deep dive around Karuna again, the PAC bypass, where it was a confused depth. Deputy, you're using part of the software stack that is doing the enforcement against itself. I thought for sure it was going to be something in there, something had worked out, how to tag something in a certain way. No, it's a straight up integer overflow in a copy memory routine. Just like. I think this was actually my biggest disappointment of the week and the bar is actually pretty high for that this week.
- [20:39]
B
Yeah. And you sort of get the feeling if that bug's in there, there's probably like, you know.
- [20:44]
C
Yeah, there's probably a few other holes in the fence, shall we say, before you even get to being concerned about memory integrity enforcement.
- [20:53]
B
Now look, a little bit more CISA news this week. They have published a. And we've been talking about this one internally a little bit this morning. Right. Because a bit of diversity of opinion here. They have put up a web form which is going to allow people to tell them when they think a bug is being exploited, you know, in the wild. Right. So someone working in a SOC sees some CVE targeting them, they can report that to CISA and that can go on the KEV list. I actually think that's a really good idea because the US Government teams are only going to have so much visibility. Right. And I think, you know, if bank of America is being hit with some vulnerability that's not on the KEV list, that should go on the KEV list. And there's a lot of very smart people out there who are seeing public exploitation, exploitation in the wild who have no way to report that. So I think it's a really good idea. But I think all of us have agreed that you just wouldn't want to be the person triaging this. Adam, this is not a fun day. Being responsible for that. The product of that web form.
- [22:01]
A
Yeah, exactly. I mean, the CISAKEV list kind of started out as a pretty tightly focused list. Like these are bugs that are actually being used to the actual while by actual hackers and you actually have to fix. Because this overall CVE database was so overwhelming for people, right? You would get here's thousands of bugs in your environment, how do you prioritize them? And KEV gave you a nice clear metric and it was quite aligned with kind of CIS's mandate of like securing US gov things, doing things that matter for the US itself. And the more you broaden that, the sort of. The less in a way that some of the value was that quite tight focus early on and I do worry that we're going to see it flooded and become less useful. Obviously, NIST's experience of triaging the overall CVE database has turned into kind of a mess. And for a lot of people, CISA Kev has kind of taken over cve. If you're a bank, the things that you care about are going to be what's on the KEV list, not what's on the overall NIST CVU list.
- [23:03]
B
But that's an argument for expanding it in my mind, man. Like that's.
- [23:07]
A
Which is agreed.
- [23:08]
C
Right.
- [23:08]
A
I agree, like it provides useful data for those people who consume it. But my concern is what happens when the Kev list is now 20,000 items instead of, I don't know how many it is?
- [23:19]
B
Well, it's still better than a million is my view. Right. Like it is still a subset of bugs. You can't further tune it like it is. It just. It's supposed to do what it says on the tin, which is to give you a list of CVEs that are, you know, known to be exploited in the wild. I mean, I'm guessing you could do some further filtering and enrichment based on, you know, the year of the CVE and things like that. I mean, James, you had broadly the same take here, Right. Which is, you know, same as Adam, basically. Was your feelings here?
- [23:45]
C
Yes. In very short summary, the value of the KEV was. It was a short, focused list. And I do take your point, Pat, that a known vulnerability, a known exploited vulnerability list is only valuable if it's truly the actual list of things that are known to be exploited. And so open it up makes good. I think we're all landing on the same point, which is we are saying if the triage process is good, this will be a good thing. And my goodness, that is a hell of a load bearing if right now.
- [24:13]
B
Yeah, yeah. Someone's open claw is going to be working overtime on that inbox doing first stage triage. What else have we got here? We've got Krebs on security has reported, a few other outlets reported on this as well, that a couple of senators are now Making noise about this, this SISA leak where some contractor just stuffed a open repo full of secrets and like. Anyway, it's pretty funny because there's all these senators now writing, writing in, saying, hey, you know, isn't this your, isn't this security stuff your job? Like what. What the. Which is great. And it was nice to see both, both you guys actually quoted by Brian Krebs in this article based made in last week's show. What else we got? Oh, now this one we're kind of doing a bit of debunking I guess on this story. This story is seemingly popping up everywhere. It looks like Google accidentally set a private issue public in a bug tracker. The issue of course being some sort of bug in Chrome and you know, with exploit code and stuff attached to it. So of course they set this thing public. People noticed then they said it's private again. It's an old issue, 42 months old. So people are making, hey, that saying, look, they've got a bug in their bug tracker that's like years old and they haven't fixed it and whatever. And that's become the story and it's, and it's doing the rounds. But you guys have both looked at this and it's just not that big a deal. Which probably explains why Google has not patched this. Adam, let's kick it off with you. Tell us about what this bug actually is and why it might not be the end of the world.
- [25:42]
A
Yeah, so this particular flaw relates to how browsers handle. They call it the browser Fetch API. It's a mechanism for essentially using browser service workers to handle long running downloads so that you can fire up say like downloading a big video file and then have a mechanism for the browser to manage that download and then call Back to the JavaScript that initially invoked it to then say, hey, it's done and off it goes. It's like long running things that can survive across a browser tab being closed and that's, that's kind of the guts of the proof of concept that was. Or the person who originally reported the bug has dropped some videos on social media before they realised it hadn't actually been fixed. They thought that Google had publicized it because it had been fixed. They published some videos. The net result is essentially they can kind of use a browser service worker to execute code. And to my reading, most of this is kind of what I expect as functionality. Like most people may not understand exactly how the mechanisms for long running JavaScript script in browsers work. And this just looked like another way to kind of trigger kind of expected behavior inside the browser and then leverage that to run long running JavaScript that can survive the tab being closed and the whole browser being closed and reopened. And I think that's mostly an expectation flaw rather than people than a security bug. And I expect that's probably why this bug has languished in the bug tracker for so long because it's kind of not really a big deal. And we've seen the bug report was in Chromium, the open source kind of browser engine that's behind Chrome, but also Microsoft Edge and some other browsers. And the exact behavior here varies a little bit between browsers, but ultimately is just the ability to run long running JavaScript in the context of someone's browser session within all of the constraints that already exist, same origin policy, cause, credential reuse, etc. You know, within one particular scope. So I was kind of underwhelmed and that's why, you know, I don't know that the hype around that has been particularly, you know, that useful.
- [27:54]
B
Yeah. James, do you think they need to drop everything and fix this? Because from what Adam said, it doesn't really feel like it.
- [28:01]
C
This would not jump to the top of my, my bug queue. I agree with Adam. It's almost like works as intended. What's missing is just the UI layer that would alert a user to the fact that this is is going on or something else that would help them understand that there is this long running download that if they weren't expecting it, that would be a signal that hey, something odd's happening. And the real sort of deprioritization signal as well was that, I think it was the Chromium folks said, look, we've got telemetry on how often this API is used and it's about 17 times per day globally.
- [28:33]
B
Now let's have a bit of a chat about AI infrastructure. Right, so we talk a lot about these models and what they mean for vulnerability development and you know, automating attacks and whatever. But there's a lot of infrastructure being built. You know, there's, there's whole new sort of like AI stacks turning up around all of this technology. MCP is obviously a big one. And then we've got like, you know, all sorts of little frameworks and stuff that are being incorporated by agents and whatnot. And there be dragons. We've got some work here from Akamai which basically has looked at the way people are spinning up and configuring MCP and They're just like, look, everyone's making mistakes and it's got to the point, point where this is a systemic problem. And I think that's an interesting framing and I think it's, it's good that someone's taken a look at this. And then we've got this report about a little Python backend web framework called Starlet, which is really, which is really commonly used by AI agents and whatnot, has some awful bugs in it. So, James, how bad is this? Right? Like mcp, I know you're not a fan. You think it's kind of pointless. Right. So I'm guessing anything that is going to make it go away faster, you're going to, you're going to support. But, you know, is this Starlet thing a big deal as well? And like, what do you think about this idea that we're sort of building these new sort of AI stacks that are sort of fundamentally a bit broken?
- [29:57]
C
Yeah, the challenge here is it's the patterns that are emerging, not just the bugs. You know, when we talk about the. Let's start with Starlet, for example. This is a component that is used in many different other components. Right. It's this classic case of it does one bit of underlying functionality in particular, you know, handling high volumes of requests. Then things like fastapi, which is a Python sort of lightweight web server ready to go, uses that for its connection handling and AI agents. If you say to it, hey, I want to build a backend service or I want to build an MCP server, it's going to pull in something like that to build that infrastructure. And this is showing, particularly with the style of bug, that there's just really simple and, you know, alarmingly dumb bugs in there. Like this was just, you know, if you could change the, the host header by one character, you would trigger. You would basically nullify all of its authorization handling. So that's not great. That hasn't passed, like just simple security checks and maybe even code review. But again, it's the patterns that alarm me here, because if you, if I then look at the MCP research. Yes, you're right. This was Akamai saying, we're going to take 300 official MCP servers, we're going to focus on authentication, authorization tools, backend integration. See how good this is? And like, they found bugs. That's not surprising. What's surprising is they found the bugs that are the class of things that we should have not been creating for a long time now. Like, the first one was SQL Injection. Why, why is this getting into there, you know, the other one was again just it's examples of really base functionality that should be available through an API getting wrapped up in an mcp. That MCP has been probably vibe coded. It's pulling in packages with vulnerabilities, it's creating these mistakes like SQL injection. This is moving too fast and not enough checks in it. And as you said, I have strong thoughts about MCP because I think it's largely a waste of time because what you're doing is you're creating wrappers around your existing API surface. Those wrappers have got more bugs in it. If you just went and spent the time making your API Surface better to work with and more easy to adopt for both a human and an agent, then your product works out better net better overall. And I just dearly wish people would spend time in that.
- [32:17]
B
Well, I think MCP was sort of intended as a bridge between those two states. Right? Like it's like you can't, you know, a lot of APIs out there, you can't just go trivially re engineer them to make them AI friendly. You need that middle step. Do you think that's why MCP has had that big moment?
- [32:34]
C
It is, but again I come back to it went too far to try to do too much and there was a point where it should have stopped. So yes, you're right at the point in time when MCP came out, this was just when models had just gotten the capability of calling tools. And in order to call tools they needed structured data sets around what's the input schema for the tool, what should I expect for the outputs? And that's, that's what MCP does, that's valuable. And so I actually didn't have issue with the MCP protocol itself because that's how we put tools in the hands of models. And that's been the step function change in AI capability recently. The problem I have was this notion of MCP servers like creating new APIs and API surface area that then was vending this capability as servers that were being deployed either locally or increasingly in the cloud, when there was just this little point in time when I think we could have paused and said MCP is the protocol that gives a large language model these superpowers of knowing what tools to call and how to do it. But let's have the protocol then describe how to call existing API endpoints with all of the existing behaviors and authentication authorization built into that API instead of now wrapping that in yet another OAuth implementation, yet another Restful Endpoint. That's where we went wrong, in my view.
- [33:51]
B
Yeah, well, you know, this will accelerate its demise as everyone's MCP server gets owned. So, you know, happy days. Some news here. Out of Discord, they are introducing end to end encryption for all of their calls and chats and whatever. It actually looks like a pretty implement. Interesting implementation in that it's going to be like, you know, across mobile apps and, you know, someone on a PlayStation, someone on a, on a, on an Xbox, someone in a browser. Right. And it's all going to, it's all going to play nice. So this is pretty cool. We've got a link in this week's Show Notes if you want to check that one out. But in other E2E news, and this one's actually quite funny, is the attorney General in Texas is actually suing Meta over its claims that WhatsApp uses E2E because a Bloomberg article suggested that it doesn't. That's the only evidence cited in this lawsuit. This thing seems a little bit crazy, James.
- [34:51]
C
Yeah, very baseless. You know, you know, when a lawsuit's filed and of course the person being accused always comes out and says, oh, this is a baseless claim, I think this one we can categorically say, yes, this is very much baseless or virtually baseless. Actually. I think, you know, I don't think I can add any more than the excellent line that Dan Gooden finished this article with when he says, given Meta's history of privacy lapses and data grabs, there are plenty of reasons not to install WhatsApp unless new evidence comes to light. The allegations on Thursday's complaint aren't among them.
- [35:25]
B
Yeah, and I mean, this is kind of where you landed, Adam, because, you know, it's your position here that. Well, yeah, I mean, exactly, exactly that. Right. Which is you've got to trust the provider of a communications app whether they're using E2E or not. I mean, if they wanted to get to your messages, I mean, they can because they control the platform, they control the software on your endpoint, right?
- [35:45]
A
Yeah, exactly right. And there are mechanisms in WhatsApp and so on for like reporting abuse to Meta. And because of E2E, the way that works is that on the client where you are reporting abuse, you say flag message is abusive and then that gets submitted along with whatever other context to some API matter for them to triage and handle. So there's mechanisms for them to circumvent the circumvent. And I'm putting scare quotes here. The E2EE to achieve whatever things they need to do. There's no reason they can't just write software to do the same thing with all your messages if they wanted to. You have to trust them. And we trust the Signal foundation to not do that to Signal. Do we trust Meta to do that? Kind of, yeah. Like, they're probably not gonna. Like, it's gonna. People are gonna notice maybe, but ultimately you just gotta trust them. And people who think that E2E, you know, encryption generally is somehow magically going to prevent, you know, protect them from everyone and everything in every context, like, that's just not realistic. So, yeah, I think, you know, we need to understand the practical realities of these systems. And yeah, you got to trust somebody.
- [36:50]
B
Ah, now the Brian Krebs has been covering the Kim Wolf botnet. And, you know, as is the case when, you know, Brian doxes you, which he did to this guy, you know, it's just a matter of time before you hear reports of the arrest. And the apparent bot master of the Kim Wolf botnet has now been arrested in and charged in the US And Canada. So he's been arrested in Canada and. Yeah, just a, Just a bad time. If you go back and read Brian's original reporting that doxed this guy, like, one of the ways he got doxed is because he recycled a password between a account he used for crime and an account, an email account, that contained his actual full legal name, which is to. Very funny. But this is the thing with opsec, right? Like, all it takes is a mistake like that and you get. And you get done. But if you want to go check that out, we've linked through to his report in this week's show notes. And what else have we got here? Yeah, like, we were kind of talking a little bit earlier about how Iran's cybering of Western targets has been a little bit underwhelming. We've got another report on that here from Cyber Security Dive. It looks like they are. Yeah, just. Just doing some spear phishing across aerospace, defense and telecommunications industries. They've got some new remote access Trojans. I mean, nothing too surprising here, James.
- [38:07]
C
Not really. Almost the surprise here is how much it's kind of hyped that, you know, Iran's getting really good at spearfishing. They're getting really good at targeting. It's like. No, no, no. That's what you do when you're going for spear phishing. So, no, I didn't take a lot away from this other than. Yep, they. Okay, they might have got A little, a little bit better, but yeah, certainly not far. 16 better?
- [38:29]
B
Yeah, no, definitely not. And the FBI meanwhile, has put out a warning about a phish kit called Kali365. And this is actually interesting because this phish kit, one of the things it does is it does the oauth device code phishing. My question this morning before we got recording was to you, James, which is, why are they doing the device code phishing instead of a standard OAuth consent phishing attempt? And it's because these device code grants tend to last longer, which I thought was, which I thought was interesting. But I guess the main thing that people should be aware of who are listening to this is it doesn't matter if you're using passkeys, this can still get you right. And it is such a glaring hole in, you know, I guess, modern security controls. So I think it's a warning that needs to be heeded. Adam, what was your takeaway here?
- [39:24]
A
We've certainly seen device code phishing before and much like active man in the middle two factor auth bypass phishing with a proxy in the way, the thing that really makes it matter is the availability of tooling. Because when attackers can grab something off the shelf that implements this and is all polished and is kept up to date with all the nuances of what Azure does or what Google does, the various providers, like maintaining a kit like that is actually quite a lot of work back in the early days, you know, when man in the middle like proxy based phishing of two factor was a thing like we had tooling for that back at Insomnia and maintaining that was quite a lot of work. So tooling matters in, you know, even though the technique is kind of well understood, the fact that attackers have a bunch of options for doing this just makes it more likely that people are going to encounter it. And as you say, the. The fact that pass keys and things in some respects almost lull people into a false sense of security because the main flow through the auth mechanism works and works well, but there are these few little side things. Consent phishing, device code phishing, device linking a la signal, those edge cases around the good auth is of course where the attackers go and if there's tooling for it, then they're going to get hit with it.
- [40:41]
B
Yeah, and I've linked through too, like push security and hopelessly conflicted. I'm an advisor, et cetera. But tooling like that, which works, works as a browser extension which can actually get in there and see these sorts of things and block them is going to be the control that makes the most sense here. I've linked through to their write up too, which is from last month about these sorts of phishing campaigns. Now we're going to round out this week's news items with like some, some MAGA related stories. Funnily enough, Trump Mobile has confirmed it exposed customer details. The initial reporting from like TechCrunch and stuff didn't really say how this exposure happened. You actually managed to trace it to track it down this morning.
- [41:19]
C
Jeff, of all the stories I thought I might want to really pull the thread on, I was surprised that this one was it. But it just each time I keep trying to find a little bit more, something more interesting popped out. So yes, first of all, an Australian found this and we don't know who it is, it's all been anonymous. But they realized that the wonderful Trump Mobile website had a direct object reference weakness where essentially the order numbers were sequential and anyone logged in could order or perhaps even not logged in could just say I want to view this order number arbitrarily and they would get to see the order details with customer name and number, et cetera. So just your classic direct object reference bug, but kind of cool that it was an Australian IT professional or founder. They reached out to a YouTuber that they realized was in the list and that YouTuber was then the one that made a whole lot of noise because no one could get anyone to actually respond from Trump Mobile.
- [42:11]
B
Yeah. So you know, be careful when you're buying your gold spray painted Android device from Trump Mobile because you're exposing your details. Details. But look, it doesn't stop there. Cash Patel's clothing brand, Based Apparel, because the FBI director has an apparel brand called Based Apparel. It's offline at the moment because apparently it got rinsed and was hosting malware and pushing malware onto visitors, which is just what a world. It's amazing. He also has a Bourbon brand, apparently. And what I find stunning about Kash Patel is he strikes me as like one of the most divorced people I've ever seen in my life. But he's never been married and I just think we all need to take a moment and recognize that for the achievement that it is. But yes, I mean, what look, what even do you say here? But, but what a world.
- [43:00]
A
Exactly, Exactly. I think there was like, it was like click Fix pretending to be Cloudflare on the front of his website or something like that. So yeah, I mean pretty standard kind of stuff. And lol.
- [43:13]
B
Yeah, yeah, and probably just was auto hosed as well. Right? Like you would think, probably. Or someone's about to have a very bad time if they were deliberately targeting, I don't know, is he going to get FBI Cyber to work on this? Like, is that how that works?
- [43:25]
A
I mean, didn't he have his mail stolen a while ago? Like, it makes you wonder if there were like some creds or there was some kind of like team PCP style, like thread pulling that led to this. But yeah, it could absolutely just be, you know, any old random supply chain, whatever thumbs and click fix in his stack and off you go. I believe he doesn't have any direct relationship with it anymore. Presumably there's some kind of probity rules still somehow left in the US Government. But just what, what a dumb world we live in.
- [43:52]
B
And finally, Tulsi Gabbard has resigned as the U.S. director of National Intelligence. To which I'm guessing a lot of people listening to this podcast within the intelligence community in the United States would say, thank God for that. I don't know that there's much else to say there. She says it's because her husband has been diagnosed with a serious illness. That is very unfortunate. But you do also wonder if perhaps it's because of, you know, the US Government doing everything that she said the Democrats were going to do in the lead up to the last election, like, you know, military campaigns in Iran and things like that. She has been beclowned repeatedly by this administration and, you know, her position's been untenable for quite some time. But there you go. But look, we're going to wrap it up there, guys. Thank you so much for joining me to talk about this week's security news. And yeah, it's been a lot of fun. Oh, Adam, you're not here for the next couple of weeks. You're taking another couple of weeks off. Off. So next week we'll be hearing from Andy Boyd, who's going to be filling in for your slot. I think the week after that we got Chris Wade joining us and then you're back the week after. So enjoy your, enjoy your time off. But James, Adam, great to chat to you both and we'll talk to you again soon.
- [44:58]
A
Yeah, thanks, Pat.
- [44:59]
C
Yeah. What a week.
- [45:05]
B
That was. Adam Boileau and James Wilson there with a check of the week's security news. Big thanks to them for that. It is time for this week's sponsor interview now. And this week's show is brought to you by Airlock Digital, which is, you know, Regular listeners would know a company that I really, really like, they make allow listing software for Windows, Linux and Mac that is actually functional at scale. They have customers with over 200,000 endpoints using this software successfully to control executions across their entire enterprises. It's genuinely impressive stuff, stuff. So both the founders, Daniel and David, joined me for this interview where we spoke about the twisted tale of Digicert getting owned by a malicious screensaver file, a threat actor, then using portal access to obtain hardware signing certificates. So these are certificates that wind up on a Yubikey or whatever, and then using them to sign malicious artifacts and whatnot. And onwards they went from there. Where this story got funnier though, is when Microsoft, around the same time suddenly started flagging the Digicert root certificate on Windows as malware and removing it. It looked like that was a ring deployment though, because it only affected a small percentage of Windows systems. But like that's, you know, even a few percent of Windows systems worldwide is a lot of systems. So that caused some chaos and whatever. So this is really just a chat about all of that, that with Daniel Shell. And then Dave joins us a little bit later on to give us the skinny on some new stuff coming in the airlock platform. But I'll drop you in here where Daniel starts off by explaining what happened at Digicert. And as I say, it's just what, what a twisted tale. Enjoy.
- [46:48]
D
To give the background, I guess what happened is, you know, Digicert themselves had a security incident, you know, running the screensaver on customers. Customer reps, I guess through web chat were convinced them to rang these screensaver service it. And what happened then was, I guess the attackers managed to access the Digicert portal as customer reps and they were then able to sort of like view the accounts as if you were a customer, saying that in customer portals you can always go give me the customer view of what the customer would see in the portal to help them on troubleshoot issues. And what they were able to do, I guess was look at sort of completed orders that had finished their verification of, you know, these are for EV certs, so very strong verification of your ID and all this sort of stuff.
- [47:26]
A
Stuff.
- [47:27]
D
And then get their sort of like, I think they're called like IV numbers, the initialization vector numbers and from the portal for these certs and what you do with these, you know, we have to do this ourselves as a vendor with EV certs to sign our drivers and software is that when you set these things up, you need to run some special software you put in your IV number you get from the portal, and then it sets up the key with your certificate through the software.
- [47:51]
B
Right. So these attackers were actually generating new certs using like near completed customer orders kind of thing?
- [47:58]
D
Yeah, well, sort of like there were pretty much completed customer orders that hadn't been activated, where the certificates hadn't been activated yet. So it's kind of this interesting thing because, like traditionally code signing, you have like the private key, you know, the customers generates that the provider never has it. And in this case, Digicert never has the private key for hardware token either. But they do have the software in this process to seed and initiate that process onto the key. And that's all what was hijacked here. So with that case, then you get, you know, the attack ends up with all these hardware keys for all the different vendors that they managed to compromise, that they got these activation codes for. And then, you know, they start signing code as those vendors. And your EV certs again, like just have higher level of trust. It used to be like with Microsoft Smart screen, it would just go right past it was EV signed. I think Microsoft changed that like a year or two ago, which is like good in this case case, but still in general for lots of different, like the security side of things, you're generally an identity, like an EV cert should be more trusted than a normal cert because there's ID checks, business checks, and all this other verification that goes on in the application.
- [49:02]
B
Well, I mean, there's an argument about whether or not what sort of level you should put on EV certs because plenty of CAs will sell them to you without doing much of the V part. They extend the billing, they don't so much extend the validation. I mean, it looks like in this case, like, you know, you've guys written an excellent blog post on this, which I've linked through to in this week's show notes. But you look through at the actual certificates that they were able to rack off with. Probably the one that is most concerning, there would be a certificate for Tencent, which is a, you know, massive Chinese. Chinese company. But there were other ones, like, you know, Block Certs, Blockchain Canada and, you know, Blue Edge National Reprographics. I mean, whatever that is. Beijing 263 Enterprise Correspondence, Dafon Electronics Corp. But the one that really stuck out that we've all heard of is Tencent Technology. I mean, that's not good when you got attackers with signing keys for Tencent.
- [50:00]
D
No, and what was interesting about that, so I Guess what? We did like looking at all this and then Digicert did do a big write up that was sort of published to Bugzilla where they had the hashes of the compromised certificates. So we went and sort of dug through VirusTotal and found. My question was, were these actually activated? Have people actually used and signed code code with these certificates and turned out they had at the time we found 39 samples virus total. About that. And the tencent one in particular was more interesting than the others when the other ones were also like tons of detections from all the AV vendors. Standard dropper malware type detections. The tencent one was interestingly enough was called like MSTC exe, which is like the terminal services client on Windows, like when they saw the file and it had sort of no detections on that sample. Even today I think there's just one where one of the Chinese AV vendors has flagged a detection on that thumbprint,
- [50:56]
B
which is probably the guy who wrote the malware like accidentally getting flagged by his own machine or something.
- [51:03]
D
Yeah, maybe, yeah. But, but that one in particular even now, sort of like, you know, refreshing since we put the blog up, it's like still no detections. That one seems, I reckon, you know, to me it looks like they use their best IT in the best way
- [51:18]
B
now Dan, you know, it looked like, you know, none of these, none of these like bad files turned up in your customer environments. It didn't look like. I mean I imagine one of the first things you would have done is check to see if anyone was trusting these vendors, any of your customers was trusting these vendors because you allow customers to do publisher based trust. So you know, you're going to take those, you know, certificate IDs or whatever and just, you know, search through your system and make sure that that's not an issue. I can't imagine it would have been. But where this got actually like diabolical is something unrelated that happened shortly after. Like we say unrelated. But Microsoft made a pretty big Digicert related boo boo, which really could have caused problems like much more than this, than this security incident at the ca. Walk us through what Microsoft did here because like, like wow.
- [52:11]
D
Yeah, sure. So on May 3rd, I guess around the world, I think they said at the end of the day, 4% of Windows Defender customers were getting sort of detections and I guess a Trojan quarantined. Now the detection for the name of that Trojan detection is called like sir Digent, which to me so like it's like Digicert certificate Related detection. But I'm confident that, well not confident but my real feeling here is that someone at Microsoft sort of saw this thing went okay, we're going to like put, put these thumbprints on a block list but instead they've accidentally thumb block. They actually block listed the root certificates for Digicert. So The DigiCert assured IDCA and the trusted root G4CA were just removed from the certificate store on these machines. Yes, SpaghettiOs. And that then had a huge impact across the Internet for the affected people because they weren't able to browse websites that required, you know, chained up to those machines properly about security warnings.
- [53:12]
B
But I mean this is the thing because like when we were talking about this but like before we decided to like have this as our topic for the interview, I'm like, we're talking about it. You're like people couldn't browse to websites. And I'm like hang on, how did that, you know if it was about code and it's like, oh no, okay. It was their root certificate got nuked by Defender for everything. Like it was just, they disappeared. You could not change trust to them for code, for browsing, for anything, just gone. Was this for all Microsoft customers? Because you were talking about how like 4% of them had this issue through Defender. Was it a case that this was a brief in time moment mistake and Microsoft caught it before it went out to everyone or what's the go there?
- [53:49]
D
Yeah, it's that sort of like brief in time situation. I guess it's like a Defender detection. There is a chance. I'm not 100% certain it was just for like Defender APT type but the more I read into it, I don't think it is. It's sort of hard to tell after the fact.
- [54:04]
B
So this was like ring deployments and they caught it at like ring number whatever?
- [54:07]
D
Yeah, pretty quick. And you know there's a post instant report put out where there's like, you know, yeah, that was a mistake. We're gonna do more validation in the future. But no actual like what happened?
- [54:17]
B
Hey, could have been worse. Could have been a kernel panic. Right. So the funny part with that one though is you actually got kind of lucky with the way your product works. As I said earlier, people use publisher trust. Now if someone nukes the root trust cert for Digicert off all enterprise machines, right. That is going to break stuff because you know in any enterprise of scale there will be at least something signed by Digicert executing in that environment. You got real lucky though. Because even for customers that did experience this sort of of Microsoft enforced certificate revocation, you actually cache, you actually cache certificates and that meant that you were able to ride through this without any drama.
- [55:02]
D
Yeah, that's right. I guess in the design of our product for performance reasons we do cache like keep like a cache of successful executions that passed on files seen on the endpoint and your files overall don't change that much. So in this case I think it also occurred on a weekend, which is good as well. But like we didn't have any, any support tickets logged worldwide about this. I think apart from like one or two customers asking like hey, am I affected by this? Where the answer is of no. If you haven't been, you'd know about it where your files would be blocked. So by chance of engineering very good on our end if we had this sort of situation occur. Otherwise I think you'd be very easily able to sort of put in trust mechanisms in place to get out of trouble quickly with the solution by trusting those signers again and stuff like that. Manually like overriding.
- [55:50]
B
Well, I mean once you've got that, you know, once you've got something like airlock in place, right. You can, there's a, there's a bunch of different ways you could, you could do this, you could do it like file based, you know, hash based if you really needed to. Directory based, less good, you know, or as you say, just like add those certificates.
- [56:06]
D
Yeah. Certificate thumbprints. Or of course you can also just restore those certificates if you could work it out quick enough.
- [56:11]
B
Yeah.
- [56:11]
D
To the enterprise.
- [56:13]
B
So I mean the question is, what have we learned? What did we learn here, Daniel?
- [56:19]
D
Well, I think the biggest surprise or learning is to me overall is that the fact that Digicert could be vulnerable to something like this. Like they are such an important part of the Internet self trust.
- [56:30]
B
Yeah. But CAS suck. We know this. They operate on razor thin, razor thin, paper thin margins.
- [56:35]
D
I try to have better expectations of the biggest one ones. Yeah.
- [56:38]
B
But they operate on paper thin margins like as I said, extended validation never should have been trusted. I don't know man, like I am Jack's complete lack of surprise. Okay.
- [56:47]
D
For me overall, I guess I would have never thought on the attack vector of someone being able to go, I'm going to steal the activation keys to activate these EV hardware certs. And the fact that you can just with this code, paste it in and then it's activated route. You know, the traditional private key being private a thing you have. This is something that only affects EV certs, not like a traditional signing situation. So that's sort of interesting to me.
- [57:12]
B
Now look. Also joining us waiting in the wings is Airlock CEO David Cottingham, who wants to pop in.
- [57:19]
A
Boo.
- [57:20]
B
To give us a product update. Because you've actually got some new stuff. You got some new stuff in the product. Tell us what it is you're doing. More stuff with. File based analysis. File based. Intelligent sense. What is it?
- [57:33]
E
Yeah. So we've got quite a few things coming up with our V7. The first one is application context, which internally we call sort of bin Chicken or binary checker, which is you're diving through a whole ton of file data and you're trying to bring it up a level and identify what applications are in it. And it's really cool to do that heuristically because you get a whole list of what applications you have across your application enterprise based on what people are running, whether you've intended to deploy them or not. And one thing that's been really interesting doing that heuristically is seeing the links between what application groupings actually are, because you can not only see the applications, but also their related dependencies. For example, if you have Steam in there as a game launcher, you can actually group in the games that are being launched into that grouping of Steam. So it's not just about the application itself itself, it's about all the other behaviors that it's doing. And drawing groupings in that way has been provide some really rich and interesting data for our customers that are trying to figure out what files to trust.
- [58:36]
B
And I love that it's named after Bin Chicken because that may have been an idea that I cooked up with Daniel some time ago because it does go into the nasty bins, excuse me, of enterprise Storage to find things for those who are not aware. For those outside of Australia, the Bin Chicken is a majestic Australian bird. The Ibis, which spends most of its time in Sydney going through rubbish bins, or trash cans, as our American friends
- [59:02]
E
would call them, pulls out the premium trash.
- [59:04]
B
Yes, exactly right.
- [59:06]
E
That's it.
- [59:07]
B
The bin chicken. An Australian icon. I love it. All right, well, that sounds fantastic. When's V7 coming?
- [59:13]
E
Early June for this one.
- [59:15]
B
Early June.
- [59:15]
C
Awesome.
- [59:16]
B
Okay. And everyone can get their own little. Their own little Australian bin chicken to go through and dive into the trash that is their enterprise collection of binaries and DLLs and scripts and whatever, screensavers too. Guys, thank you so much for joining me for this chat. It's always great to see you. It's always great to catch up and talk about what you're up to. Really enjoyed it.
- [59:36]
C
Thanks, Patrick.
- [59:37]
D
Thanks, Patrick.
- [59:40]
B
That was Dave Cottingham and Daniel Schell there from Airlock Digital. Big thanks to them for that. And yeah, doubling down on the that question, what did we learn from all of that? I don't know what we learned, but a fun story nonetheless. Big thanks to Airlock Digital for sponsoring this week's show and for being a risky business sponsor for many, many years now. And that is it for this week's show. I do hope you enjoyed it. I'll be back soon with more security news and analysis, but until then, I've been Patrick Gray, thanks for listening.
- [60:11]
A
Sa.