B (3:01)

Why is the server side written in some ancient grandpa language like Java instead of modern hip JavaScript and why don't the same developers work on it? And why don't we tightly couple the client side to the server side so they can work more closely together? And that's kind of the React client side framework started to expand into the server side. And now we've kind of got to the point where many modern JavaScript applications have a JavaScript front end and a JavaScript backend. And the rise of Node JS and a bunch of other JavaScript server side frameworks made that a pretty popular path. And so now we have this thing where a thing was traditionally felt like it was. Client side is actually now kind of both client and server. And of course there's a communications mechanism between these components and that's where this particular bug came along. So it's a like deserialization flaw in I guess it's kind of like JSON encoding on the wire inside HTTP, obviously used between the client and server. And the bug is quite clever. It leverages sort of the asynchronous execution properties of modern JavaScript environments to lead to kind of code injection. So you can craft a JavaScript object which refers to the future execution of another JavaScript object, and then you can basically provide code and have it run by the server as it is in the process sort of resolving these dependencies. And it's pretty cool bug, I gotta say. And CVSS 10 and in the implementation used by the React server components unauthed, which that's a good time bug.

A (4:41)

Hell yeah, it sure is. I mean it was funny, right? Like just in researching this stuff, watching a video from a developer who was like talking about this stuff, like next JS has been all over this like React server component stuff, right? And they were giving examples and stuff and showing like really, you know, being able to do really cool stuff with this, like is it the client, is it the server? Well, it's kind of like you need to think about it differently. And as this guy's giving examples, he's like, I don't know how this part of it actually works entirely. I'll just consider it magic. But this is what you do with it, and it was really cool. You really do get the impression that this is not just some dumb change for dumb changes sake, but with anything that's new and involving passing serialized bits and pieces between client and server, you're going to expect there's going to be some attack surface there. And that's what we're seeing.

B (5:26)

Yeah, there absolutely is. And there is good reason for it. As you say, this is not just let's bolt this in because we can. There's been a lot of thought about people want experiences that feel more like mobile apps, that feel like slick applications, and delivering that requires a bunch of things that the old model of transactional HTML rendering didn't really deliver. And then we moved to single page applications, but then the back end was kind of out of step. And now things like single page applications make delivering search engine to search engine discoverable content really complicated because the search engine is not going to execute the JavaScript, so it's very bad for discoverability and it's bad for things like accessibility. So there's a bunch of reasons why they aren't ideal. And so we've moved towards a world where you can decide, do I render the content server side, Do I render it client side, Do I render it a mix of both, depending on which client I'm serving? Like if I'm delivering it over a mobile network where it's really like the end device is low power, maybe I want to do a bunch more rendering server side. And so having frameworks where you're flexible about where the code executes and where content gets generated or rendered or processed and how API calls get made and so on is attractive for a bunch of reasons. But as you say, it tends to look like magic because you've abstracted away the actual complexity of dealing with this kind of distributed application developer. And distributed programming is very, very hard. And we end up with flaws like this and this stuff. It moves so quickly. The developers move very quickly, the frameworks move very quickly. Us poor security folk are left scratching our head thinking, but we thought React was a client side technology. What's. How can it have a CVSS 10 remote code exec in it?

A (7:07)

Well, I mean, I mean here we are talking about the CVSS10 in server side JavaScript. What like it's just for us old farts, it's a bit, it's a bit weird, you know, but just.

A (7:20)

Thinking on this a little bit more, these server components, you would think, I mean, just immediately off the top of my head I'm thinking, is there any way you could just containerize this part of your web application and lock it down pretty hard to sort of protect yourself somewhat from bugs in these processes? I wouldn't have thought you would need to give these react service components absolute privileged raw access to your web servers. Right? I mean, or am I wrong there?

B (7:49)

I mean, you're not wrong, but I guess the question then becomes, does access to the underlying shell actually even matter anymore? Because as you say, everything's containerized. A lot of the stuff will run like ephemeral sort of environments where the underlying UNIX isn't important. And what is important is.

A (8:06)

I get that, but I mean, once you've containerized it, you might put some rules about what sort of access, database access to this container is anomalous and things like that. I just would have thought breaking it up a little bit and treating it as, you know, distinct thing would be perhaps a sensible thing to do. But I don't know these environments, that's why I'm asking.

B (8:25)

Yeah, I mean, I guess there was a trend for a while towards microservices where we would break up all these applications into very small components with kind of better defined contracts about how they were going to interact with databases or other resources on the network or backend systems or whatever else. And we went down that road for a while as a kind of a modern application development.

A (8:47)

I remember it got a bit out of hand.

B (8:48)

And that's it. It got out of hand, or we over containerized things, or we over componentize things, and then the amount of interaction that you would have to do with the environment to get anything done, you'd end up making 1000 HTTP requests on the back end to render one page to go out to the client. Finding a middle ground between breaking applications up into tiny components and then having to have flexibility and routing and load balancing between every one of them. Or giant monolithic apps that do everything in one process and therefore have no externally controllable security boundaries. The reality is we kind of need the middle ground and we are, you know, we slosh backward and forward between these sort of approaches to things. And you know, us security folk tend to be a bit behind the ball because the stuff sloshes very quickly and developers move very quickly and coming along and saying, hey, how about some controls here or whatever else is not. We historically have not been very good at that. And then traditionally developers just kind of did their own thing and didn't take responsibility for that security thing. In the modern world, like developers that are, you know, continuously publishing and don't really have the supervision of external security folk have to take responsibility for that stuff themselves. And we're seeing more sensible outcomes as a result. But you know, there's collateral damage along the way and a lot of people are getting a lot of shelled with this react shell thing.

A (10:10)

Yeah. So let's look at the timeline here. So I think it was like last Wednesday us time, which would have been Thursday for you and I. There was. Well, it was a patch, wasn't it, that came out and then everyone sort of scrambled to find a poc. And then what happened is the proof of concepts gradually got smaller and smaller as people whittled down and figured out this bug. And I think someone dropped a patch for some service that was like a dead giveaway that you could do it in this really simple way. And then before you know it we got like a 10 line POC and then all hell breaks loose. Right, so you've got Cloudflare basically dosing itself because it needed to fix this and made some boo boo. They had like a 25 minute outage which comes on the back of another outage they had like a week earlier. So Cloudflare has been having a pretty, pretty rough quarter, shall we say. You would think if this continues it's actually going to start causing problems for them too. And then of course we saw the usual stuff, right? Like apt crews out of China just going nuts with this thing. I mean it's a free for all right. And they're dropping web shells and every actor under the sun is doing God knows what with this. I mean I get the impression with the Chinese stuff they're just dropping web shells and figuring out what they can do with them later. Right, which is the usual approach from our friends at the Ministry of State Security and their contractors.

B (11:24)

Yeah, I mean just shell everything right now while you can and deal with the mess later, you know, because you can't stop to think when you're competing with everybody else for these shells because you know, when a bug like this drops that you don't have foreknowledge of like it really is, you know, a race to who gets to shell it first and shore up their access and hey, figure out what it is later. And I think we've seen some Graphs and data from like the gray noise people about like the scale of scanning. And it's just, yeah, man, that graph.

A (11:50)

Went to the market. That's a hell of a chart. That is a hell of a chart, that one. We've seen a couple people like Kevin Beaumont, actually, he was sort of downplaying this one, saying, you know, security. The security world is sort of panicking over this one. I wouldn't say that. I'd say that it's an interesting bug and it pops up in a lot of places. Like, his point is, oh, it only affects 2% of organizations or something, but go look at Shopify's latest thing, which is called Hydrogen, which uses Next JS REACT server components, right? So if you have developed your store using this, it affects you. So there's a lot of downstream products, you know, Cloudflare, for example, which obviously fixed it. So I think that that's where the issue is, is there's going to be a lot of downstream stuff, most of which I have a positive feeling though, Adam, because. Because it is such a recent software tool. I have a feeling that the sort of people who use this stuff are the sort of people who are going to be aware that there is a problem and they're going to upgrade it. It's not like this is like log 4j when we're talking about ancient Java stuff where the people who wrote it retired 15 years ago and nobody knows about it and there's like that huge long tail. I think this one has a pretty good chance of getting tidied up pretty quickly. What do you think of that?

B (13:01)

Yeah, I think your instinct there is, right? I mean, the JavaScript environment ecosystem moves so rapidly already that anyone who is deploying anything kind of serious out of this stuff already is used to having to roll the stuff all the time, like constantly be redeploying, constantly rebuilding. Like that's a part of their. Like the way that they approach development is that kind of constant rolling and reintegration of upstream stuff. And you know, that's a curse and a blessing, right? I mean, it's a curse in that we've seen supply chain attacks on NPM and stuff are really bad because people are used to pulling new dependencies in very quickly. But on the other hand, when it comes time to patch something like this, they are used to doing this and it's not a scary, exciting process. Like, as you say, the Java.

B (13:46)

Log 4 shell stuff, where no one knows how to even compile those apps anymore, let alone fix it and deploy it. And Blah, blah, blah. So there's a very, very long tail. So yeah, compared to a bug in like ancient PHP or ancient Java applications that are long since dead, I think this will get, you know, there are much less of a long tail. But it is interesting because, you know, as a kind of. Because this stuff is so new, there are opportunities for new and quite exciting bugs like this and that's always a good time.

A (14:15)

Funny, funny you should say, because the very next thing I was about to say is I saw some researcher of note, I can't remember who it was, but they were on Twitter and just saying, well, this is the sort of thing that's going to make people go back and look at this code, right? And you get a feeling that, I mean, this one did sort of come about like it was a pretty bad mistake that led to it, right. And you sort of think, well, if there's that bad mistake, maybe there's other stuff that's like not so obvious. So I guess we look forward to more fixes. But yeah, I mean, it looks like we're getting a happy ending here, right? Like it's not like log 4J where like everybody got. Is still getting shelled with it.

B (14:51)

Right?

A (14:52)

I mean, that said, there are, there are, there is some real damage being done out there. So. Well, you know, we. It'll be a while before we actually see a lot of the reports coming out indicating what sort of victims they were, what was taken and whatnot. But look, staying with Chinese apts, right, because there's a lot to talk about with the old Chinese apts. This week we've got some research here at a CrowdStrike looking at a. What are they called? They're calling them Warp Panda. A Chinese APT crew that's going after VMware VCenter. I mean it just. VMware just depresses me so much because it went off to Broadcom and they've done nothing to try to improve it. It's just been left to rot. And you know, the vultures working for the Chinese government are certainly having fun picking the bones of the old VMWares out there.

B (15:43)

Yeah, CrowdStrike wrote up this particular actor and some of the tooling that they're using, they use a tool called brickstorm and it's actually honestly pretty cool. I mean there's so much old VMware infrastructure and big enterprise and it's.

A (16:00)

So.

A (16:02)

Is this the one that's written in Go?

B (16:04)

Yes. Has a bunch of golang components and stuff which is very, very, very hip, very modern of Them and it does like all the sorts of things that you would expect, you know, being able to access the virtual machine. So you compromise like ESX hypervisors and drop this, you know, golang tooling on it. But one of the bits that I really appreciate about this is I've compromised some VMware in my time and one of the things you often want to be able to do is land on the ESX hypervisor a steal the file system, which is straightforward, you can take some snapshots or whatever else and exfil those. But being able to pop up inside the virtual machines and then use their connections onwards to the rest of the world is a thing that you can do it, but it's fiddly. You have to kind of rig up some PowerShell or get a shell and do it by hand. It's kind of funky, this tooling they've got. They drop a SOCKS proxy on the guest VMs and then they have some plumbing for their C2 so they can connect through their C2 network into the hypervisor and then from there pass the connection into the guest which then will proxy it onwards through the SOCKS proxy, onwards to wherever it needs to go. So if for example there's network plumbing or VPNs or application access, they can just straight up use that. And that's a super slick tool as an attacker. And we've seen these Chinese groups, for example, like steal browser tokens, like session cookies out of the browsers and then pivot through virtual desktops inside the VM infrastructure using this so that they can then piggyback on existing sessions, come from the right place in the network and not look anomalous, blend in with all the other network traffic. Like it's just, it's exactly the tooling that if you are a real serious business actor and you Want to use VMware in your day to day, this is kind of what you need. And I love that for them. Like they're good work, Chinese MSS contractors or whoever it is.

A (17:54)

Yeah, I mean I read this earlier and I was just thinking, wow, you know, go like new school meets old school, right? Like they're writing a nice clean go malware. But yeah, there are many other signs in fact that, that they're doing, doing a good job there, sorry to say. Now we've got to just quickly discuss a piece by Alexander Martin that appeared in the Record.

A (18:18)

Look, it's a good piece but I feel like he kind of buried the most interesting part of this and his conclusion perhaps should have been his introduction here, which is he's looked at the, the absolute mess of overlapping actors targeting end day vulnerabilities. Like one of the good examples he uses here is the.

A (18:37)

SharePoint stuff that happened, you know, six months ago or whatever when.

A (18:42)

It looked like there'd been some low and slow exploitation. But then when the attackers got wind that this was going to get patched, that Microsoft knew about it, well, all of a sudden a whole bunch of other threat groups in China got it and they went absolutely crazy exploiting it. Right. So he's looked at how this seems to be a bit of a pattern with Chinese crews when they might be using some sort of bug. And then well, oh, there's an announcement that a bug in XYZ is going to get patched. And then it just, you know, everyone starts going absolutely ape with it. But you know, it's right at the end where he says, he writes that China's sprawling cyber ecosystem is very busy and there are limited data points differentiate differentiating state units, contractors and cybercriminal actors. That the, that three distinct entities converged on tool shell is not unprecedented. From proxy logon to Avanti, a pattern is emerging. You know, I mean, as I say, I think it's a great piece. I just feel like that should have been the introduction if I was the editor.

B (19:38)

Yeah, yeah. It's just, it's a good kind of state of the. I was going to say state of the nation, like state of affairs of understanding how this stuff works in China and kind of what it means for defenders as well. Right. I mean being able to understand how your adversary is thinking and what they're doing and the kind of patterns that we see emerging there is interesting. Another thing I thought that he didn't mention in this, which I thought would have, would have rated a bit specifically Talking about the SharePoint bug is that when ProPublica was covering it and they mentioned that like Most of the SharePoint maintenance or development teams are also in.

A (20:10)

China and The on prem SharePoint is a Microsoft China product. It all leads back to China.

B (20:17)

Yeah, which is just also an interesting kind of nuance, especially because he brings up the kind of requirements for, for software developers and researchers in China to cooperate with their government as you do with everyone does with their host governments. You have to obey the local rules and laws and things. But yeah, it's a good write up and I think that it's definitely one for the kind of policy wonks to think about perhaps more than the infosec people because we Kind of understand what's been going on, what we've seen, but big picture, we do need to think about how it all fits together and you know, how they roll.

A (20:50)

Yeah. And I think what's interesting is over the last year or two, you know, the ISOON leaks also help with this. We've got a bit of a clearer picture of how things work in China and it is a bit nuts. I mean, it's funny because there's this current discussion happening in the USA about whether or not using contractors to go after cybercriminals or, you know, state backed adversaries is good policy. And you think, well, I mean, the Chinese are doing it and it's a mess, you know, but is that an argument to not do it or is that an argument to do it? And I just don't know if I can make up my mind on that just yet. I might need to mull it over over a few weeks off. So anyway, it's just a good piece to read in, you know, as a backdrop to that whole discussion, I've also linked through to Catalan Kimpanu's write up from July about the timeline of the tool shell stuff because he did a spectacular job where he wrote a newsletter piece which was essentially all just dot points, but man, it's a useful resource and he did a great job. Now, speaking of Catalan, he had a few weeks off and you know, we had to lower him into a vat of regenerative fluid, basically, which is what you do with cattle, and you leave him in there for a few months, he's basically regenerated and we've put him back to work. So those Risky Bulletin news podcasts are back. The, the Risky Bulletin newsletter is back as well. And in today's edition he's actually got some really cool news. I don't see anyone else covering it yet, but they probably will. But Linux is adding support for PCIe encryption and the first thing I thought was, man, how would you even key that? And then I read his piece and like that's what the support is doing. It's doing the actual keying for it. But why would you want a PCIE card to have, you know, encryption? And where should it be encrypted from? And to. Adam, help me understand here.

B (22:38)

Yeah, so the idea here is that between the CPU and PCIe connected peripheral devices and I guess GPUs are the big thing at the moment that are PCIe connected, sometimes you want to have a situation where a snooper on the bus isn't able to see the contents of the traffic between devices. And if you're cynical, you would say that. So people don't steal AI models that are executing on your hardware. The more actual reason is that, you know, we're seeing this trend towards trusted computing in the cloud where we can't do all of the AI compute on the edge of the network. So we're going to ship it up to the cloud. But we have privacy concerns. And we've seen both Apple and Google release their work on implementing, you know, kind of trusted confidential computing in the cloud, where we have VMs that we trust to execute, you know, or operate on data that the end user doesn't necessarily want to share with the hosting provider or the place where the hardware lives. And the hardware vendors, amd, intel and ARM kind of cooperated on this standard, trying to come up with a mechanism where a virtual machine that's executing some particular code can trust that it has a clear path out to probably the GPUs or other PCIe connected hardware. And the trust anchor on the platform, the TE on most platforms, or the.

B (24:00)

Kind of that particular trusted path of the hypervisor is able to assert to these virtual machines that, hey, there is a trusted path. I've done the key exchange. It's all good. You can have a private chat with the GPU and no one outside is starting to snoop. And, you know, that's a, you know, the old adage of, you know, if it's your computer, you controls what control goes onto it and goes on, on it. And by extension, if it's somebody else's computer, you can't, you know, that adage is always going to be true to some extent, but we can definitely make it more difficult for someone who can, you know, has physical access to the computer to kind of observe what's going on and abuse that. So it's interesting work. And the fact that we're seeing this, we're seeing the main vendors cooperate on this and contribute the code back to Kernel, it's also really cool, like seeing them work together. It's nice. But yeah, it's just an interesting kind of sign of the hardware times that we're trying to make it so that you can actually have some guarantees about the robustness of computers that aren't in your hand.

A (25:02)

Yeah, I mean, we've seen this before with like confidential computing and hypervisors and stuff. And I feel like the reason this is happening is, as you say, it's for GPUs, right? It's, they just want the Same sort of level of assurance. And it's probably a compliance thing where, oh, no, you can't do this in the cloud because for GDPR reasons, you can't tick this box anymore. And I figured this is probably a way to help people tick the box more than any actual security gains. That's just my feeling. But I don't know, am I too cynical?

B (25:28)

I mean, box ticking is an important part of the process. We do a lot of box. And sometimes by accident, box ticking does improve things. So. But no, the whole kind of how we build trusted confidential computing in a remote environment like that's a very hard problem and we're making steps towards it. And yeah, the cynicism is still pretty warranted, though.

A (25:49)

Yeah. Now let's put our cynicism into overdrive now and talk about Sean Planky's nomination to lead sissa. This guy, I mean, from what I've heard, competent, good pick, you know, going to be great. And it's not happening because of shipbuilding in Florida.

B (26:04)

It's us, the whole us like legislative process, regulatory process, whatever you call this, like, it's just so bonkers some days. Like the way that, you know, this kind of completely unrelated, I'm not going to call it pork, but you know what I mean, Some completely unrelated small issue like this can change the way things work. So there was a.

B (26:26)

There was a vote that covered a whole bunch of nominations to various positions in US government and he was excluded from them because of the objections of, as you say, I think, a senator or a representative from Florida over. Yeah, maybe shipbuilding. Who even knows anymore?

A (26:43)

Well, you know, Sean Planky has ties to the Coast Guard and Kristi Noem has partially cancelled a Coast Guard contract with a Florida shipbuilder. And that seems to be the reason for the roadblock from a Republican senator. And meanwhile, our good old mate Ron Wyden is also saying no to, you know, installing a competent head of SISA until a report is released on Salt Typhoon. So we've got like, I feel like it's like they're both being equally stupid, but for reasons much more aligned with their sort of party brands. You know what I mean? But either way, stupid is stupid and it's not getting done. So SIS is going to continue, I guess, to have an acting head. We did see, though, during Trump's first term, there were a lot of agencies that just had acting heads. They were never sort of Senate confirmed. And, you know, the wheels didn't fall off for the most part. I mean, at least in the first Term, but let's see what happens now.

B (27:35)

Yeah, I mean, it's just there is such an important, like, cybers is kind of relevant and kind of important and it would be nice to have strong leadership there. But hey, there are so many other things going on that, you know, as you say, we may just have an acting and survive the term, and then we'll see what the mess looks like afterwards.

A (27:54)

Well, SIS has been pretty much gutted at this point. Like, and it was funny because I held back saying that on this show when people were being a little bit hysterical about it, saying, oh, it's gutted. Like, a lot of good people are gone. It's, you know, all the people they worked with there are gone. And then you just hear it enough from enough sources where they're just like, man, they have absolutely just taken a machine gun to the place and it ain't what it used to be. So, God, what it means for the future of that agency, I don't even know. Now here's a fun one. And I do not know if this is a troll or not. If it is a troll, well done. I think it's hilarious. But there is a guy all over X complaining about Graphene OS and saying the feature where you give the cops a duress pin, they put it in and it raises the phone, it doesn't work. And he's talking about it being a failure of Graphene's platform. And then he's posting, like, documents that he's received, apparently received from the Belgian police where they're talking about having extracted data from his phone. But then you look at, like, what he's been. He's being investigated for and it's murder. You just like. And he's like, yeah, I'm a suspect in a murder. This is terrible that this, like, this feature didn't work for me. I only ever used this phone indoors and blah, blah, blah, blah. As I say, it could be a troll. If so, it's a brilliant one, but it's led to the most hilarious conversations on that platform. Just, you know, 10 out of 10 as a spectator, like, amazing.

C (29:12)

Yeah.

B (29:12)

I went and read the. There's a message thread on the, like, Graphene forums about it. And, like, it's just such comedy reading. And like, this guy, I mean, he's come back, he initially posted on the forums and made his claim. And look, it's just filled with like, you know, 20 pages of people telling me trash and doesn't know how to computer. And he must have, you know, got his friend to Set him up for him or something like that. And then he. He actually comes back and defends himself in the thread at the same time that he's also being accused of murder and basically says, this is a straight up stock graphene os. I wasn't using any third party trash. I did all the right things. I watched the cop type in the duress pin and the phone did not reboot and did not destroy the murder evidence contained therein. And then there's a few people in the thread going.

B (29:59)

So you're telling us that the evidence of the murders that you did are on the phone? And he's like, yes, yes, they are.

A (30:06)

I mean, this is why I think it's a troll. Because he's also expertly calibrated all of his posts to cause maximum distress and outrage amongst the graphene Os people who are exposing. Who are, I'm sorry, responding exactly how like a completely triggered privacy absolutist would respond, right, by saying, it's not our fault that you're dumb and, like, you know, and, oh, we can never guarantee that, you know, the human dimension and blah, blah, blah, blah, blah, but our stuff is perfect. And although we don't claim it is, and it's just. It's fun, but it does. It does. Did you read it and think maybe this guy's trolling as well? Because it feels like it. It really does.

B (30:43)

It does have an element of like, Yeah, I mean, but at the same time, sometimes. Sometimes the best trolling is not trolling. Like, it's actually.

B (30:52)

It could actually be, like, it's just believable enough, honestly. Like, I, I'm. I'm willing to give the guy the benefit of the. Now that he's just that nuts that it's not.

A (31:01)

Well, I mean, what I find. What I find interesting is the graphene people like, defending their operating system instead of just saying, I'm glad the cops unlocked your phone if you committed a murder and I hope you go to prison, you know, which would be the response from a normal human being, Adam. But, you know, sadly, it was not to be. Instead of getting outraged and triggered and, like, just going for the guy's throat. Absolutely hilarious. Now, staying with mobile security and whatnot, we've got a story here from. I think this has to be Lorenzo, right? Yeah, it is Lorenzo over at TechCrunch. He's taking a look at an Amnesty International report into Intellect, which of course is alleged to have done a bunch of, like, pretty shady stuff in the spyware field. They make the. What is it? Predator? Yeah, the Predator spyware. Which, you know, it's the sort of thing that's popping up in places that, you know, you wouldn't, you would hope it wouldn't pop up in. But apparently Amnesty got a hold of some internal training material which showed someone from Intellect being logged into a live customer environment which was, you know, actively targeting a device and collecting intelligence from it and whatnot. And they're saying, you know, this is outrageous that Amnesty is saying, you know, it's outrageous that Intellect might be able to do this and is accessing its customer sites and whatever. But you know, there's a couple of people quoted in this story who are like, look, it's, it feels like that's actually probably a demo setup with TeamViewer and not actually a customer setup because most countries that use this sort of stuff, they're probably not going to give you TeamViewer access into their super secret surveillance stuff. I mean, look, who knows, right? Who knows? I mean, Intellects, I feel like, are not a good player. Whether or not they're allowing team, you know, making their customers allow TeamViewer access here, I feel like that's sort of a peripheral issue. What did you make of this?

B (32:51)

So the underlying Amnesty piece does have a bunch more details they haven't released. They got a whole bunch of data that included a video of like Microsoft Teams meeting where someone was running through a training session for other Intellects of staff and he demoed remote access. And in that meeting recording, apparently one of the people attending says, is this a test system or is it the live thing? And the guy says, no, this is the live thing. So Hamster haven't released it yet.

A (33:19)

That's what you tell the newbies. So they go, cool. You know what I mean? When it's really, it's just, you know, there's a VMware thing in the, in the cupboard.

B (33:28)

It's absolutely. Well, we don't know. We certainly don't know. But the, yeah, Amnesty's written it up. And you know, there are some things that make it look kind of like it may actually be straight up, you know, TeamViewer into some predator control panel in Kazakhstan or whatever. And there's a bunch of customers in some of the dropdowns and stuff that they all have code names. We don't know who they are. But one of the things the Amnesty report does do is try to correlate a bunch of the data they have got from this leak with things that have been previously reported or data they previously obtained. So things like Domain names that line up that they previously seen Predator being used to deliver Predator. They've seen some of these domain names in the data they've got. So there's a number of points that spoke to the authenticity of the data to start with. But then as to whether or not you can just straight up teamviewer into, I mean the idea that a government agency would buy a surveillance system that you could just teamviewer into, I agree, does seem a little bit, you know, a little bit incredulous. Makes me feel a little bit incredulous. But on the other hand, you know, people do just YOLO this stuff and I mean the idea that you could just teamview into it, it's pretty funny. Tbh, other than the whole spyware thing being, you know, not a pleasant ecosystem to start with. But yeah, the amnesty write up is pretty good and I'm glad that they are doing the research and cooperating with other people that report on this stuff. But it's just.

B (34:57)

Honestly like the idea that they would just do that kind of rings true to me. So color me convinced.

A (35:04)

Yeah, well, I mean NSO group, you know, apparently, I mean they hosted a lot of their own ATTCK infrastructure and whatever. This seems to be this dividing line between a lot of the spyware companies where the really high end pro shops, they don't do any operations. They're like, here's a tool, you know, something goes wrong, you can call us, we can help you work through it, but we are not going anywhere near your operations. Don't want to know, you know, that's, that's fine. And that, you know, when you're dealing with a professional agency in a jurisdiction that has decent rule of law, decent court oversight, decent political oversight, that's generally how it goes. So yeah, teamviewer for the Algerians or something, I don't know, maybe that's, maybe that's just how it's going to go for the, for Kazakhstan. Maybe that's how it's going to go. You just don't know.

B (35:45)

Yeah, I mean I think that you do make, that's an important differentiation, right. There are customers for this stuff that are sufficiently sophisticated that they can deploy it and manage and operate themselves. And then there's plenty of customers that are not that sophisticated. And that's kind of the niche that Intellexo are going after here because I mean they have a bunch of kind of ancillary products for deploying Predator on devices using things like if you're in the national ISP and you've got access to the national root ca then it's got mechanisms to like man in the middle HTTP HTTPs drop the like trigger for you know installing predator in the middle of the HTTP so you can use that for like targeted infection when you are the national telco or the national kind of operator and you're in a privileged position. They've also got like mechanisms deploying it with via close access like through fake bake stations, fake base stations and like baseband bugs. I think they had a Samsung baseband bug that they were using for it. So you know they are targeting people that need to buy the whole package because they don't have that capability in house and you know I guess there is a market.

A (36:47)

Well and as I say, as I say them having teamviewer access to that is like pretty small on the list of concerns that flow from what you just said. Yes. About all that they're up to now. Let's move to what it's a tentative good news story I guess. Matt kapko over at Cyberscoop has looked at some treasury data. U.S. treasuries released some data that says that ransomware payments fell by 1/3 to 734 million last year. But apparently the number of victims is remaining the same. But like you know it's generally a positive write up saying that the numbers were down last year. I mean given we're nearly in 2026, I don't know what this tells us about trends but fingers crossed we don't have to wait a year for the next treasury data set.

B (37:29)

Yeah, I mean the graphs not honestly not super compelling when you see the, I mean ransomware has done this kind of Dr. As well. Like it was an equally large dip between 21 and 22. So like it's happened before. But yeah, I think 2025 is going to be the year where we find out whether the amount of disruptions and like the sort of generally making ransomware's life a bit tougher, whether or not that has actually made a difference. So yeah, next year's numbers or this 2025 numbers are going to be the real telling ones I think.

A (37:57)

Now another one from cyberscoop here, Derek B. Johnson has reported on a warning from NCSE which is saying something that you and I have actually been saying this year, which is that large language models are always going to be vulnerable to prompt injection in one form or another. I mean you can try to filter it, you can try to massage it, you can have other models watching them. But fundamentally when you are mixing code and data. This is an inherent problem and one that cannot be solved. It is nice to see a prestigious agency such as NCSC come out and say the same thing.

B (38:30)

Yeah. This was based on a blog post from a David See as the NCSE Technical Director for Platforms Research. And he says exactly that. Right. The very nature of an LLM is its job is here is context, predict next token. Right. There is no instructions or data. There is no concept of separation between those things. It's just give next token and anything.

A (38:52)

There is no dedicated signal path for this thing, as we would say.

B (38:57)

Exactly. And so the blog post makes the sensible, kind of like the name implies, that this is somehow like SQL Injection. It's comparable to SQL Injection where there is by design already separation between data and code. And that's just not what it is in LLMs. And I think this is important for people to read and understand. We are just letting the computer yolo the next token and then thinking about it like there was some separation between code and data and then hoping and pretending isn't an approach that's really serving us well so far. And it's just fundamental to that type of next token prediction model of computing. So, yeah, I'm glad someone else said it as well. It makes me feel good.

A (39:43)

Yeah. And not for one second are we claiming we're the first people to have that thought. But when people first started saying that, we were very, very definitely quick to agree with them. And I also want to reiterate something that I said. I think it was on last week's show, which is, whatever you think of this stuff, as a security professional, this is your job now.

B (40:02)

Get on board. Like, we're going to this party.

A (40:05)

We're going, man. There's nothing you can do. And it doesn't matter that they're mixing code and data. It doesn't matter. That's your job now. It doesn't matter that you don't like. It doesn't matter that there are inherent problems with that. It doesn't matter. This is your job now. You need to get your hands around this risk. Now this one from Ars Technica. It's a bit of fun, but I don't really think it's a particularly novel story. Dan Gooden has written about these guys like Tweedledum and Tweedledummer, two guys who have been arrested for the second time for doing cybercrime stuff to the US government, which is amazing.

A (40:40)

And in this case, apparently they were trying to use AI to cover their tracks.

A (40:46)

To me, the fun part of this Story is just how bad these guys are at doing angry cybercrime. So I'll let you explain that in a moment. But the whole angle of oh, they were trying to ask AI like how to cover their tracks and whatever. It sort of reminds me of when I think there was like a congressional testimony or a Senate hearing or something into these LLMs and one of the senators or Congress people turned up with you know, bomb making instructions or whatever that got an LLM to talk about. And then the AI company representatives were like, well here's that, that bomb recipe, you can Google it as well. Like it's right here. So I sort of feel like people asking AI how do I cover my tracks? It's just sort of like asking Google. It's not the novel part but still worth talking about just because of how brazen and dumb these guys are. Tell us about them.

B (41:28)

Yes, so these two, both 34 year old brothers from Virginia, Alexander Virginia Muneeb actor and Sahaib actor and one of them got father, they both got fired. I don't know whether that was simultaneously over the same thing. They both got fired. One of them was, had their access kind of revoked from the systems that they were looking after, the other one didn't. And so they logged in to their Ms. SQL database server that they had access to and then proceeded to delete 96 databases from that system which contained some manner of sensitive information, important stuff apparently something related to like Freedom of Information act requests or something like that. So they deleted this stuff and then went onwards to clean up the process, you know, delete the evidence by asking ChatGPT or whatever, which as you say is good comedy angle. The thing that's really weird about this though is that this is not their first time. Like the pair of them also pled guilty like in 2015 to hacking the State Department. I think they were also, you know, employed in some, you know, by some contractor or employed in some way and they had stolen a bunch of like passport and visa information. But apparently this, you know, a previous guilty conviction for deleting data from a government agency where they work was not enough to stop them getting employed at a government agency where of course they have subsequently done the same thing.

A (42:53)

I think they might have been working for a third party that was doing work for a government client. Like they weren't directly employed by the government. Which is probably just answers your question of like how did this happen. But the fact that they both have like they love to commit crimes together every time like 10 years apart, I.

B (43:06)

Mean it's nice to have family connections.

A (43:08)

Right.

B (43:08)

It's nice to do things with your siblings. That's always good. I do think, though, Dan saved the best bit for the end of the piece, which is. Wait, wait, hang on a second. They were asking for how to delete logs from Windows Server 2012. Like, what year is it? Sorry, which government agency is running Windows Server 2012? Isn't that out of support? So that's the kind of. The other good bit is that. Yeah, the lack of competence or the, you know, the sort of. The comedy of this extends to all parties involved, not just to the brothers in question.

A (43:39)

Full, full stack comedy on that one.

A (43:43)

All right, man. That's actually it for this week's news. This is our second to last show for 2025 and next year. We're actually in what's my 20th season. I think it's your like 17th or 18th next year, which is a pretty crazy milestone for this program. We've got a new host joining us as well who's going to take on some new work next year. There'll be more to hear on that when we're back. So, yeah, next week's the last show. I've got a soapbox coming out actually in a couple of days, probably tomorrow actually. You've listened to that one. It's with the Spectrops guys talking about Open Graph. Headline is Graph the Planet. It is really cool. It's a really good soapbox edition. I'd really recommend people listen to that. I mean, even you were like, wow, that was. That was good. You know, it takes a bit for you. Yeah, yeah, yeah, yeah, yeah. So I'd really recommend people have a listen to that. That's me chatting with Jared Atkinson, who is the CTO of Spectrops and, you know, Bloodhound. Yeah, it's a sponsored interview, but, you know, very interesting stuff. But yeah, we'll wrap it up there. Adam, thank you so much for joining me for that discussion. It was a lot of fun and we'll do it again next week.

B (44:43)

Yeah, it was a good time, Pat. I will see you next week.

A (44:52)

That was Adam Boileau there with a check of the week's security news. Big thanks to him for that. It is time for this, this week's sponsor review now. And this week's show is brought to you by Kroll Cyber. And Kroll is, you know, a big risk firm that does a lot in cyber security. It's got a really competent incident response shop and they acquired like an MDR provider some time ago. So they do MDR as well. And, you know, they've got a really good reputation and they work, you know, with big companies, with governments, like, with all sorts. And yeah, as I say, they definitely have a reputation for knowing what they're doing. So today we are chatting in this week's sponsor interview with Simon Onions, who is the managing director of cyber and Data resilience for Kroll in London. And really, Simon has been chatting with a lot of boards lately about cybersecurity, certainly in the wake of all of the drama that has engulfed the UK with the attacks against the retail sector and Jaguar Land Rover. And he says, you know, really, there's a bit of an opportunity at the moment to get in there and educate boards about cybersecurity, but you want to do it right, you know, you don't want them to ask a simple question and for you to be sitting there spinning your wheels and unable to answer it, because that just is embarrassing for everyone. So here's Simon Onions and I started off by asking him where boards are at, really, with their understanding of cyber issues at the moment. And here's what he had to say.

C (46:13)

It's, it's really interesting and it does change. It's not, you know, I can't make a sweeping statement that says, you know, all boards are full of, you know, 60 year old, you know, died in the wall business, people who don't understand technology. But more often than not, that, that is the case. But we're not, we're typically not dealing with a generation of digital natives here. We really understand what this is. This is witchcraft to them, right? This is a dark magic that they don't understand and they need to pay, you know, a deeply technical chief information security officer or someone a ton of money to come in and fix for them. And there's a, there's a kind of delegation of responsibility that's associated with that, or in some cases, maybe even an abdication of responsibility where they, they, you know, they're just trusting that somebody else is fixing the problem. And from a sort of business perspective and from a business governance perspective, that's just, you know, you can't do that anymore. This is an existential risk. We've seen in recent times so many, you know, damaging issues that are real, core strategic business issues. And so we can't continue in that vein anymore. We've got to bring boards on the journey at a crow. Even now, we see disconnect between the executive and the board in terms of what their level of understanding of this risk is. And we need to get better at explaining it and bridging that gap. I think that's one of the core issues that we've got because, you know, if you think about the responsibilities of the board, they're there to ask challenging questions. They're there to understand the way the business is being run. And if they don't, then we've got a big issue.

A (47:44)

I mean, it's always seemed to me like a lot of boards, board members, just, yeah, they don't think about it at all. There's just this assumption that it's being handled. And you kind of alluded to that just there. But there's this, this assumption of, like, oh, there's some nerds down in the IT department, they've got all of this under control. Right. Like, and that's. That quite often, you know, said nerds in the IT department are pointing at things and saying, you know, we've got a real problem, but that message just doesn't get through. Or it sounds like typical sort of corporate whining about being under resourced like, and not like a real problem.

C (48:15)

And I think some of that is a problem of our own making. Right. I know if you go back five years, I think a lot of cyber was technical people saying, this is a really tricky problem. Let me come and fix this for you. You don't need to worry about the detail. I got it.

A (48:27)

Yeah.

C (48:27)

And we can't, we can't do that anymore. We, we have to, we have to migrate this into something that is a proper business consideration. And to do that, we need to speak business language. We need to be talking about all the impact of, to the business in, in terms of revenue, reputation, you know, broader harm to consumers or markets or wherever, whatever else it might be in a way that the board get. Because we can't be selling this as black magic anymore. We have to be talking about this in those terms because they don't get it at the moment. There are toolkits out there to help people, you know, but if you, in a UK context here, if you talk about the National Cyber Security center here, all the CISOs will understand, all the techies and understand the analysts will get it. The board many times have never really heard of them other than seeing news articles that talk about this, this government agency that in their mind is probably rather untouchable. And that's, that's just not the case. So we need, we need to be better.

A (49:22)

Yeah, yeah. I mean, so many of my friends in security consulting have made jokes about having to do like finger puppet shows.

A (49:29)

You know, he's a little bit like that. And we're not trying to deride board members, but it is difficult to cut through, right. When they, they haven't really understood that this is a risk that is board level. But I'm guessing, you know, being someone who's based in the uk, one thing that definitely would have changed that outlook in the United Kingdom at the moment is the Land Rover incident, which is, you know, it's an incident of national significance. It's showing up in like the GDP projections, right. Because it's such a big deal. You know, has that really lit a fire under their glutes, shall we say?

C (50:02)

I, I think it inevitably has, but history, maybe not at this scale, but history is littered with victims in this sort of thing. So you see these peaks and troughs where there's a, there's huge swathes of highly reported attacks. You know, we've got Ms. Co Op, Harrods, jlr. There's, there's.

A (50:21)

But they tend to, they tend to be sort of vertical specific. Right. Like retail's under attack and everyone freaks out. Not patcher in 2017. Oh my God. Terrible day for logistics and, and you know, it is that thing where it seems to be a vertical specific thing. I think what's different though, about the Land Rover thing is the, the economic impact.

C (50:38)

Right, but that's where we're going now, right? Yeah, you've got really high profile manufacturing or, or whatever. Right. I mean, I don't want to get into a victim shaming thing here because, you know, we can opine about whether or not they should, they should have done more before the event. I don't think any of us really know yet. So it could be anyone, I think is the thing here. Right. And now we're starting to see really high profile brands get hit with, with huge economic impacts up and down their supply chain. And they, you know, there are moves in regulated environments to look at addressing some of that through third party risk management, which is really difficult through, you know, better information sharing, which we've been talking about for over a decade, you know, and all these different things that people are pushing. The really interesting thing in the UK is if you look at the critical national infrastructure and if you look at the cybersecurity resilience bill that's going through Parliament now, JLR would not be caught by that, that they're not critical national infrastructure. Not dean be anyway. But if you look at the economic impact of an attack there and you can extrapolate that out over, you know, pick a large manufacturer, you know, they're not going to be captured by this. So the incentives have got to change. I think, you know, we can't be relying on somebody in the boardroom looking at that and go, well, you know, thank goodness that wasn't us. I think it's happening quite a lot at the moment, but with these peaks and troughs in mind and in six months time it's to put up again, to put a British phrase on it, right? That's going to be chip paper. That's, you know, these things are quickly forgotten because there are, you know, things are just too fast paced. So we've got to be better at making the lessons that we learn out of these big high profile incidents actually bring about fundamental change in the way that businesses are being run and the way that they're looking at cybersecurity. Because the risk management programs in a lot of places basis just don't work either, right? I mean, the ideologies, the motivations, the tactics, all these things change like a daily, hourly, whatever basis, right? I mean, these things shift all the time. You're absolutely right. It's the retail sector at the moment that seems to be bearing the brunt of it. But that could shift. That could be finance, that could be pharma, that could be anything.

A (52:41)

And then, so I mean, I guess, I guess what you're saying is what you're seeing now is like a pulse of interest from boards rather than like a permanent, you know, sea change or watershed moment, right?

C (52:51)

I mean, that's my concern. Absolutely.

A (52:54)

So let me ask you this, right? So say you're a ciso, say you're a security person. You know these, you got a bunch of old and crusty board members, right? You got to go fill them in, get them on your side. You're talking about people who, you know, dictate their emails to their secretaries and you know, only use an iPad. What is it that you can actually, you know, how do you do that? How do you talk to these executives and sort of bring them onto your side and get them sort of with a security program, what it should look like.

C (53:25)

It's a really good question and I think the most foundational one is explain this to me in a way that I can understand, right? Why are we spending this much money on cyber? Why are you telling me it's not enough? What are we not doing? It's foundational questions like that. I mean, one of the most kind of beautiful things in this is that that lack of Knowledge is actually a real power. If you exercise it in the right way and ask what might seem like dumb questions, they're not. They're actually really insightful. Because if you, as a CISO or as a technical leader, can't explain something to someone in terms they understand, you probably don't understand it well enough yourself. So it drives a level of rigor into that process. So, you know, what are we doing well? What are we not doing well? What are the risks associated with that? Because, again, I think we find ourselves baked into an environment where people look at this as an inherently technical risk, which would you. It is, but it has big business impact. So when we're testing this stuff, right? I mean, when you're sitting down doing your tabletop exercises or your pen tests or whatever else, are you taking the results of those and extrapolating that out so you can look at what a capital impact on the business is? Right. JLR is a really good example of that. Have they. A key question I would have were I a board member is, you know, have we looked at what the business viability looks like if our core operations are shut down for a month, two months, months, three months?

A (54:42)

I gotta tell you, one of my. One of my smarter CISO buddies who works in healthcare. Yeah. Was very smart during COVID because they did have to close various bits of their business. Very big business had to close various bits of it due to certain things happening in the pandemic. I won't give away too many details because that'll give away who it was. But what that meant is, all of a sudden, he could quantify what outages and downtime actually cost the company.

C (55:11)

Exactly.

A (55:12)

Because of the experience during the pandemic. So he used that to justify a bunch of really cool programs and initiatives which were essentially around ransomware control. And I think, you know, knowing a bit about what he's done there, I think they're actually in really good shape now. And it was because he could go to the board. He could go to the CEO and go to the board and say, look, you know, this is what it would cost us if we had a ransomware incident. And we know this because of xyz. And so I think. I think you're right, like, you know, being able to answer that question of, like, why. Why are we spending all of this money? Like, if you can't jump in immediately, like, instead of sort of scoffing and being unprepared, you know, jumping in with an answer, there is probably a good idea.

C (55:50)

It's so Important because what we should be doing, I mean, risk management in cyber is typically what, you know, what controls do we have in place to mitigate this threat? What it should be is what controls do we have in place to mitigate this threat. And if those controls fail, where's the impact on the business? Because that's what the board care about. How much money am I going to lose if this thing manifests? How likely is it to manifest? And that's where it gets really tricky because the likelihood changes. I mean, banks are a good example where a lot of these risks are managed, like quarterly risk and audit committees. The risk in quarter one is going to be completely different potentially to the risk in quarter two. And many of, not all of them. And it sounds like, you know, a few people that have done this reasonably well, not many of them have got mechanisms in place to set tripwires and to set mechanisms in, to detect when that threat changes to an unacceptable level and what that means to the business. So, you know, we know that there is an increased loss of losing X million if this threat manifests or X billion if this, if this threat manifests. And therefore we need to act now. We can't wait for the next risk and audit committee to approve a spend cycle that's out of budget and, you know, these other things. So we've got to be much, much more adaptive and dynamic with the way that we deal with this and people are getting on board with that now. I mean, cyber risk quantification has been a thing for, for a long time and a lot of people, including myself up until recently, were fairly skeptical about whether you could ever actually do that. I think now we're moving to a place where we can. And I think some sectors are better than others. I mean, finance have been forced to do this through various regulatory models for a long time. You know, do I have enough money to ride through a crisis? Because we've been through enough of them in the past. But those lessons haven't rippled out into other sectors and I think now they're starting to happen. And I think things like jlr, big, very high profile attacks are helping to focus the mind.

A (57:33)

All right, Simon Onions, thank you so much for joining us for that, for that conversation. Good ranting there, actually. Good ranting about where boards and executives need to be thinking. A pleasure to chat to you.

C (57:45)

Yeah, thanks very much. Really enjoyed it.

A (57:47)

That was Simon o' Nions there from Krol Cyber. Big thanks to him for that. And that is actually it for this week's show. I do hope you enjoyed it. I'll be back tomorrow with a soapbox edition of the show and then again next week for the last episode of risky business for 2025. But until then, I've been Patrick Gray. Thanks for listening.