Risky Business - Risky Business #839 -- TeamPCP stole GitHub's internal repos

Episode Date: May 27, 2026

On this week’s show Patrick Gray, Adam Boileau and James Wilson discuss the week’s cybersecurity news. They cover: TeamPCP breached GitHub’s internal repos. Now what? Some absolute plonker glued Coruna to a hijacked npm package CISA is worried about about open source and wants third party submissions for KEV AI infrastructure is “systemically” insecure Much, much more This week’s episode is sponsored by allowlisting vendor Airlock Digital. Airlock’s founders David Cottingham and Daniel Schell join Patrick Gray to talk about Microsoft briefly flagging DigitCert’s root certificate as malware. Fun! This episode is also available on YouTube Show notes GitHub confirms being hacked by TeamPCP, says customer data unaffected | therecord.media Grafana Labs links GitHub environment breach to TanStack npm supply chain attack | Cybersecurity Dive Coruna Respawned: Compromised art-template npm Package Leads... | Socket CISA chief frets about open-source vulnerabilities, delayed security improvements | cyberscoop.com Anthropic: Mythos finds more than 10,000 software flaws in first month | cyberscoop.com Pardon MIE? | ironPeak Blog CISA asks cybersecurity community to alert it to vulnerability exploitation | Cybersecurity Dive Lawmakers Demand Answers as CISA Tries to Contain Data Leak | krebsonsecurity.com Google publishes exploit code threatening millions of Chromium users | arstechnica.com Millions of AI agents imperiled by critical vulnerability in open source package | arstechnica.com Discord migrates all users to end-to-end encryption by default | The Record Texas AG sues Meta over claims that WhatsApp doesn't provide end-to-end encryption | arstechnica.com Alleged Kimwolf Botmaster ‘Dort’ Arrested, Charged in U.S. and Canada | krebsonsecurity.com Iran-linked hackers target key US, allied sectors with sophisticated spear-phishing messages | Cybersecurity Dive FBI warns about fast-growing phishing kit targeting Microsoft 365 users | cyberscoop.com Analyzing the rise in device code phishing attacks in 2026 | Push Security Trump Mobile confirms it exposed customers’ personal data, including phone numbers and home addresses | TechCrunch Security Kash Patel’s clothing brand website shut down after reports it was hacked | TechCrunch Security Tulsi Gabbard resigns as US director of national intelligence | Social Signals When Certificate Trust Fails: The DigiCert Code-Signing Incident and Microsoft Defender False Positive |

Hey everyone and welcome to risky business. My name's Patrick Gray. We'll be getting into the news in just a moment with Adam Boiloh and James Wilson and then we'll be hearing from this week's sponsor, Aeroch Digital. Daniel Shell, the CTO of Aerlock 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 with some, uh, with some, uh, 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 were 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 listened 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 of you. 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? Well, I think we should care because on two different threads.

First of all, your package ecosystems, they get a bad wrappers 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. They own the failure end-to-end. I mean, that's amazing, right? It is brilliant vertical integration of the failure stack, if nothing else. The other thing that's interesting here is, you know, GitHub says, oh, you know, 3,800 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 3,800 repos, hacks for, who knows how long. Well, my favourite thing in all of this is the Corpospeak, new levels of Corpospeak being unlocked by GitHub spokespeople

because they were asked whether or not it was true that Team PCPs claim that 3,800 repos had been compromised, and the spokesperson said that number was directionally consistent with what they had figured out, which is just like, man, we're getting new words and phrases banned from risky business here. 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 the fact that they got done over by a compromised VS code extension is somewhat embarrassing. 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 org? 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 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 got to trust them. And they've got to 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 going to get this one right because TeamPCP aren't going to cut them any slack. No, but I mean, you also wonder like, okay, say you don't trust GitHub. Then what? Right. Like, I don't know. Yeah, you go to GitLab, which has had a, yeah, they've had a flawless, rock solid relationship. Floorless security record.

I think you've ever gone wrong with GitLab. No, I mean, this is the problem. Like we've, 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, right? We didn't plan it like that. And I don't know. I guess we're going to find out how bad a choice there was.

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 way. of 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 involved the TANSTAC compromise and Mini Shia Lood 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 asked 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 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 think about all of this? Yeah, 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, you know, they referenced here that, you know, there was a number of GitHub workflows.

They rotated a bunch of credentials. They missed one credential. But, you know, it begs the question of, like, 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 TAN stack when it should have been pinned to the version. Like I just, 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 address this.

Yeah, I mean, it's just, it's wild times, right? And I mean, that's been the thing about the 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. 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? Well, you know, it's funny, because... 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 Kempano.

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 three... driving marketplace for compromised credentials. 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 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? Yeah, I mean, I guess we always want to see like that one planet melting, everything ruining, you know, beautiful, well thought through

hack of our, you know, that the 90s hackers and us all want. But yeah, that's maybe that's just not the world that we have anymore and maybe there is something else to do with this stuff. And, you know, it reminded me of the like conversation we had last week about the US versus Iran with the beautifully, exquisitely crafted Fast 16 and Stuxnet versus Iran just, you know, hack and water supply treatments in small town USA. In the end, the impact matters. And all of their like cunning hacking you do there. Ultimately, there's only of interest to nerds like us. And, you know, maybe Team PCP needs to do something useful with all this access or whatever happens to be. And that's the real, that's the winner on the day, not all of the stupid hack and 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. Yeah. Now, look, staying with supply chain stuff and someone did something really weird, where they compromised an MPM 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 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, that's your vibe on this too, right? Yeah, grandma's crypto wallets in serious trouble from this campaign. But that's what I mean. It's like someone's 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. 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. And, you know, especially if you're going to take the time to curate that relationship with the previous owner of the package and convincing that you're going to take good care of it, great. So many things you can do. Then why? Why, Karuna? I mean, yeah, this was your reaction as well, Adam, right? Which is, but why?

Yeah, but why? And, like, part of me is, like, it's just, like, hot riding, 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 the car analogy is, but like, you know, kind of hoting up your ancient old, you know, dung 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 R 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 someone's just... Put a Ferrari engine in a car. you and I excel. I'll help you. As the car guy on the podcast, I'll help you. 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? Yeah, yeah, to what end? And look, staying with open source, right? We've got some comments from the acting chief of Sisser here

who is fretting, the headline says. Acting director Nick Anderson's comments, camers, blah blah blah, blah. He is fretting, cyberscuit 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 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 bug reports. And it's good because, you know, they've actually got people 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 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 govies actually flagging this as an issue. Was that your vibe there too, Adam? Yeah, yeah. I mean, obviously these are real issues and everybody is having to deal with the shake-up of the security industry and the way we find and report bugs.

And, yeah, open-source people by virtue of their community routes aren't necessarily well-equipped. And yet, it's an important issue. and the, you know, the alternatives to open source software, you know, Microsoft's and Oracle and, you know, big, you know, vertically integrated software companies, you know, 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, you know, 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 know, you called out the important point, which is, but so what are we going to do about that? we don't really know. Well, this was James note on this, right? Which is like, Cicester is calling for modifications to the way they deal with it. And he's like,

what modification? Tell us, 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, I do agree with your take there, Pat, that, you know, good that they're calling this out, good that senior govies are doing this and kind of nice that senior govies are doing it and referencing an skccd 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 dot challenge there is yes but then they're also not investing as much in cissor and other things so how do we change that investment on was a question that left me with. 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 2,800 of them or something as critical.

You know, like 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. Yeah, good to see numbers. I think the numbers were larger than I thought they were. would be, you know, because we're still, without the, you know, this being in the hands of the public, there's, it's still a bit of a latent concern of how much was this just marketing hype, you know, was it really that dangerous? But these numbers do a pretty good job of saying,

hey, yeah, it's real, it's finding things. But, you know, this sort of conversation you and I are having around this, Pat, is that, you know, yes, it can find bugs, but also, gosh, the models are still really good at creating their own bugs. And so, yeah, yeah, there's bugs on both size of the equation with moral use. That's the thing. And I think, look, I really think one of the most insightful things said about this was the gruck on this show a few weeks ago when talking about those

Mozilla bugs, 270 bugs found bi Anthropic and he's like, well, that's not going to meaningfully improve things because infinity minus 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 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 Codex because Anthropic has done its quarterly lobotomy of Claude. Yeah, it's fired. Claude, you're fired. I'm done with it this week. It's just not working at the moment. So we're back on Codex. But like 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 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? Yeah, it will keep us in comedy stories for a long time.

I think the thing I get, the vibe I get is that, like 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, you know, 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 the, 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. Well, that's the main thing. Self-interest. Yeah. 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'd think, oh, my God, that's incredible. And I spoke about this last week where I said, well, I knew people in X-Dev 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 a bit disappointing, James. Yeah, I mean, I remember saying that last week that I was so excited to see this research be released once the, you know, the patches were out. And of course, the patch came out, and before the researchers could even publish their work, someone reverse engineer the patch and found there was like a one-line assembly change.

And like the actual bug, it just makes you go seriously, that's all. Like I, to bypass memory integrity enforcement, I was thinking back to the deep dive around Corona again, right, the pack bypass where it was a confused 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. I think this was actually my biggest disappointment of the week, and the bar is actually pretty high for that this week.

Yeah, and you sort of get the feeling if that bugs in there, there's probably like, you know. 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. 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 sock, sees some CVEE 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 in the wild who have no way to report that. it's a really good idea but I think all of us have agreed that the you just wouldn't want to be

the person triaging this Adam this is not this is not a fun day being responsible for that the product of that web form yeah yeah exactly I mean the uh the sissa kev 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, you know, here's thousands of bugs in your environment. How do you prioritize? I mean, Kev gave you a nice clear metric. And it was quite aligned with kind of Siss's mandate of like secure USGov things, doing things that matter for, you know, the US itself. And the kind of, the more you broaden that, the sort of the less, in a way that the, some of the value was that

that quite tight focus early on. And I do worry that, you know, we're going to see it flooded and become less useful. And obviously NIST's experience of triaging the overall CVE database has turned into, you know, kind of a mess. And for a lot of people, CSEA KV has kind of taken over CVE. If you're a, if you're a bank, the things that you care about are going to me what's on the KV list, not what's on the overall NIST CVE list. But that's an argument for expanding it in my mind, man.

Like that's, you know. Which is. I agree. 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. 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 can 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.

Yes, in very sure. 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, you know, 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. Yeah. Yeah. Someone's open claw is going to be working overtime on that in block.

So I'm doing first stage triage. What else are we got here? We've got Krebs on security as reported. A few other outlets reported on this as well. That's a couple of senators are now making noise about this, this Cicelyke 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 in saying, hey, you know, isn't this security stuff your job?

Like what the? Which is great. It was nice to see both you guys actually quoted by Brian Krebs in this article based on comments you made in last week's show. What else we got? 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 hayer 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 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. 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 you go. So it's like long-running things that can survive across a browser tab being closed. And that's kind of the guts of the proof of concept that was. or the person who originally reported the bug that dropped some videos on social media before they realized 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 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 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, you know, 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 a long-running JavaScript in the context of someone's browser session within all of the constraints that already exist, same origin policy, cause, you know, 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 it has been particularly, you know, that useful. Yeah. James, do you think they'd need to drop everything and fix this? Because from what Adam said, it doesn't really feel like it. This would not jump to the top of 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 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. 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 and, and whatever. But there's a lot of infrastructure being built. You know, there's this 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'd 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. where this is a systemic problem. And I think that's an interesting framing, and I think it's good that someone's taken a look at this.

And then we've got this report about a little Python back-end web framework called Starlet, 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 to make it go away faster, 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? 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 stylet, for example, this is a component that is used in many different other components, or it's this classic case of it, does one bit of underline. functionality, in particular, you know, handling high volumes of requests, then things like Fast API, 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 a style of bug, that there's just really simple and, you know, alarmingly dumb bugs in that. there. Like this was just a, you know, if you could change the, uh, 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 allow me here. Because if you, if I then look at the, uh, 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 is, 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 than 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. 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 where, that's why MCP has had that big moment? 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 what MCP does. That's valuable. And so I actually don'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 an larger 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 Oath implementation, yet another restful endpoint. That's where we went wrong in my view. Yeah, well, you know, this will accelerate

its demise as everyone's MCP server gets owned. So, you know, happy days. Some news here at a Discord. They are introducing end-to-end encryption for all of their calls and chats and whatever. It's actually looks like a pretty 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. Yeah, very baseless. 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.

baseless. Actually, I don't think I can add any more than the excellent line that Dan Gooden finishes 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. Yeah. And I mean, this is kind of where you landed at him, because, you know, it's your position here that, well, yeah, I mean, 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? Yeah, exactly right. And there are mechanisms in WhatsApp and so on for like reporting abuse to matter. And because of E2E, the way that works is that on the client where you are reporting abuse, you say flag messages abusive,

and then that gets submitted along with whatever other context to some API meta for them to triage and handle. So there's mechanisms for them. to circumvent the circumvent, and I'm putting, you know, scare quotes here, the E2E 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, you know, we trust the Signal Foundation to not do that to signal. Do we trust Mehta to do that? Kind of, yeah, like they're probably not going to, like it's going to, people are going to notice, maybe.

But ultimately, you just got to 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've got to trust somebody. Ah, now, 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 bad time. If you go back and read Brian's original reporting that docks 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 an email account that contained his actual full legal name, which is just very funny. But this is the thing with Opsack, right? Like all it takes is a mistake like that 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 are 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 Cybersecurity Dive. It looks like they are just doing some spearfishing

across aerospace defense and telecommunications industries. they've got some new remote access trojans. I mean, nothing too surprising here, James. Not really. Almost the surprise here is how much it's kind of hyped that 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 fishing. So, no, I didn't take a lot away from this other than, yep, okay, they might have got a little bit better, but yeah, certainly not FAST X-16 better. Yeah, no, definitely not. And the FBI, meanwhile, has put out a warning about a fish kit called Cali365. And this is actually interesting because this fish kit, one of the things it does is it does the OWath device code fishing. My question this morning, before we got recording, was to you, James, which is why are they doing the device code fishing instead of a standard Oath consent fishing attempt?

And it's because these device code grants tend to last longer, which I thought was, 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 pass keys, 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 heated. Adam, what was your takeaway here? We've certainly seen device code fishing before, and much like Active Man in the Middle, you know, two-factor-orth bypass fishing with a proxy in the way,

the thing that really makes it matter is the availability of tooling. Like, because when attackers can grab something off the shelf that implements this and is all polished and is kept up to date with, you know, all the nuances of, you know, what Asia does or what Google does, you know, like 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 fishing of two-factor was a thing. like we had tooling for that back on the end so 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 lulled people into a false sense of security because the main flow through the orth mechanism works and works well But there are these few little side things, you know, consent fishing, device code fishing, device linking a signal, like those edge cases around the good off is of course where the attackers go. And, you know, if there's tooling for it, then they're going to get hit with it. Yeah, and I've linked through to like push security and, you know, hopelessly conflicted. I'm an advisor, et cetera.

But tooling like that, which works as a browser extension, which can actually get in there and see these sorts of things and block them, is going to be this control that might. makes the most sense here. I've linked through to their write-up too, which is from last month about these sorts of fishing campaigns. Now, we're going to round out this week's news items with like 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, James. Of all the stories, I thought I might want to really pull the thread on, I was surprised at this

one was it, but it just every 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 the essentially the order numbers were sequential and anyone logged in could, 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 detail. 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 found it. 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. 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. 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 Cash 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, look, what even do you say here? But what a world? Exactly. Yeah, exactly. I think there was like, it was like click fix pretending to be cloud there on the front of his website or something like that. So yeah, I mean, pretty standard kind of stuff. And loll. 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 at work on this? Like, is that how that works? 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, dumps some click fix in his stack and, uh, and off your guy. I believe he doesn't have any direct relationship with it anymore. Presumably there's some kind of property rules still somehow left in the US government. But just what, what a dumb. world we live in. And finally, Tulsi Gabbard has resigned as the US 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 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. 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 time off. But James, Adam, great to chat to you both, and we'll talk to you again soon.

Yeah, thanks, Pat. Yeah, what a week. That was Adam Bwalo 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 to 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. 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 Uber key 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 Roots certificate on Windows as malware and removing it. It looked like that was a ring deployment though,

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 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 a twisted tale enjoy To give the background, I guess what happened is, you know, DigiSert themselves had a security incident, you know, running the screen saver on customer reps, I guess, through web chat.

We're convinced them to ring these screensaver certs. 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. It's saying that in customer pause, you 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 complete. orders that had finished their verification of, you know, these are for EVs, so very strong verification of your ID and all this sort of stuff, and then get their sort of like, I get things they're called like IV numbers, the initialization vector numbers, and from the portal

for these certs. And what you do of these, you know, we have to do this ourselves as a vendor with EVs 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, you know, sets up the key where your certificate. through the software. Right, so these attackers were actually generating new certs using like near completed customer orders kind of thing? Yeah, well, 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 traditionally of code signing you have like the private key, the customer generates that, the provider never has it. And in this case, Digiert 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, you know, vendors that they managed to compromise,

that they got these activation codes for, and then, you know, they can start signing code as those vendors. And your EV-Serts again, like, just have higher level of trust. It used to be, like, with Microsoft SmartScreen, or just go right, pass it was EV signed. I think Microsoft changed that like a year or two ago, which is like good in this case. But still in general, for lots of different like the security side of things, you're generally an identity, like an EV cert is, 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. Well, I mean, there's an argument about whether or not, you know, 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, they don't so much. extend the validation. I mean, it looks like in this case, like, you know, you've guys have 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 sets, blockchain Canada and, you know, Blue Edge National Reprogram.

graphics. I mean, whatever that is. Beijing 263 Enterprise Correspondents, Darfur 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. And what was interesting about that, so I guess what we did, like, you know, looking at all this and then, you know, 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 dug through

virus total and found, like, my question was, is like, were these actually activated, how people actually used the sign code with these certificates? And turned out they had, you know, at the time we found sort of 39 samples on virus total about that. And the 10th cent 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 10cent one was, you know, called, interestingly enough was called like MSTC.EG, which is like the terminal services client on Windows, like when they saw the file, and it had sort of node 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. Which was probably the guy who wrote the malware, like, accidentally getting it flagged by his own machine or something, or testing. Yeah, maybe. Yeah. 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. like they use their best cert in the best way. 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 wow yeah sure so on May the 3rd

I guess, you know, around the world, I think as they said at the end of the day, 4% of Windows Defender customers were getting sort of detections and I guess, you know, a Trojan quarantined. Now, the detection for the name of that Trojan detection is called like Sir Digient, which to me sort of like is like Digi Cert certificate related detection. But, you know, I'm confident that, you know, well, not confident, but, you know, my real feeling here is that someone at Microsoft saw this thing, went okay we're all like put these um thumbprints on a block list but instead they've accidentally

them block they've actually blocked listed the root certificates for digi cert so the digisert assured ID CA and the trusted root G4 CA um were just removed from the certificate store on these machines um yes spaghettios um and that then you 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 probably about security warnings. 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 site. 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? 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 so hard to tell after the fact So this was like ring deployments and they caught it at like ring number whatever Yeah pretty quick and you know there's a post-instinct report put out where there's like you know yeah that was a mistake we're going to put more validation in the future but no actual like what happened hey could have been worse could have been a kernel panic right so um 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 for digi cert 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 Digi cert executing in that environment. You got real lucky though because even for customers that did experience this sort of

you know Microsoft enforced certificate revocation you actually cash. You actually cash certificates and that meant that you were able to ride through this without any drama. Yeah that's right. I guess you're in the design of our product for performance reasons. We do cache like a

case of successful executions the past on file 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 support tickets logged worldwide about this. I think apart from like monetary 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, you know, files will be blocked. So, you know, by chance of engineering, very good on our end. If we had this sort of situation occur, otherwise, I think there'd be very, very, you'd be very easily able to sort of put in trust mechanisms in place to get out of trouble quickly with the solution but you know trusting those signers again and stuff like that manually like overriding um i mean once you've got that you know once you got something like airlock in place right you can't there's a there's a bunch of different ways you could you could yeah yeah you could do it like file based you know hash based if you really needed to a directory based less

good you know or as you say just like add those certificates yeah or certificate thumbprints or of Of course, you can also just restore those certificates if you could work it out quick enough to the enterprise. So, I mean, the question is, what have we learned? What do we learn here, Daniel? Well, I think the biggest surprise or learning is, to me overall, is that the fact that DigiCert could be vulnerable to saying like this, like, you know, they are such an important part of the internet self-trust. Yeah, but CIs suck. We know this.

They operate on razor-thin, razor-thin, paper-thin margins. I try to have, like, better expectations of the biggest ones. Yeah, 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? 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 without, you know, the traditional private key being private thing. You have, this is saying like only affects EV certs, not like a traditional signing situation. So that's sort of interesting to me. Now look, also joining us, waiting in the wings is Airlock CEO David Cottingham, who wants to pop in, boo, to give us a product update because you've actually got some new stuff.

You've got some new stuff in the product. Tell us what it is. You're doing more stuff with file-based analysis, file-based intelligence. What is it? Yeah, so we've got a. 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 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, you're 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, it's about all the other behaviors that it's doing, and drawing groupings in that way, it's been, provide some really rich and interesting data for our customers that are trying to figure out what files to trust. 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 would call them. Pulls out the premium trash. Yes, exactly, right? That's it.

The bin chicken, an Australian icon. I love it. All right, well, that sounds fantastic. When's V-7 coming? Early June for this one. Early June. Awesome. Okay, and everyone can get their own little Australian bin chicken

to go through and dive through the trash that is their enterprise collection of binaries and DLs 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.

Thanks, Patrick. Thanks, Patrick. That was Dave Cottingham and Daniel Schell there from Aerlock Digital. Big thanks to them for that. And yeah, doubling down on 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 Aarlock 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. back soon with more security news and analysis, but until then, I've been Patrick Gray. Thanks for next.