Risky Business - Risky Business #838 -- GitHub investigates possible breach

Episode Date: May 20, 2026

On this week’s show Patrick Gray, Adam Boileau and James Wilson discuss the week’s cybersecurity news. They cover: GitHub announced a possible breach CISA leaks important creds, keys in public repo Awful vulnerability in Bitlocker renders it useless without a PIN So. Many. Patches. Polish Government urges officials to ditch Signal for mSzyfr Much, much more This week’s show is brought to you by Thinkst Canary. Thinkst’s founder, Haroon Meer, is this week’s sponsor guest. He joined James Wilson to talk about how doing “the basics” in security isn’t trivially easy. This episode is also available on YouTube. Show notes GitHub on X: "We are investigating unauthorized access to GitHub’s internal repositories. While we currently have no evidence of impact to customer information stored outside of GitHub’s internal repositories (such as our customers’ enterprises, organizations, and repositories), we are closely" / X CISA Admin Leaked AWS GovCloud Keys on Github – Krebs on Security Experts Confirm the Fast16 Malware Was Sabotaging Nuclear Weapons Tests, Likely in Iran Iran hackers: Hackers have breached tank readers at gas stations; officials suspect Iran is responsible | CNN Politics War and Data Centers Are Driving Up the Cost of Fiber-Optic Cable Microsoft on pace to break annual vulnerability record as AI-driven patch wave takes hold | The Record from Recorded Future News NCSC’s Ollie Whitehouse on surviving the "bugpocalypse" - Risky Business Media Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmark | Microsoft Security Blog Project Glasswing: what Mythos showed us Linus Torvalds says AI-powered bug hunters have made Linux security mailing list ‘almost entirely unmanageable’ First public macOS kernel memory corruption exploit on Apple M5 OpenAI launches Daybreak to combat cyber threats | Cybersecurity Dive Zero-day exploit completely defeats default Windows 11 BitLocker protections - Ars Technica GitHub - Wack0/bitlocker-attacks: A list of public attacks on BitLocker · GitHub Catalin Cimpanu: "The Polish government has advi…" - Mastodon CISA orders all federal agencies to patch exploited bug in Cisco SD-WAN systems by Sunday | The Record from Recorded Future News CVE-2026-20182: Critical authentication bypass in Cisco Catalyst SD-WAN Controller (FIXED) Huawei zero-day attack behind last year’s crash of Luxembourg's entire telecoms network | The Record from Recorded Future News Patch bypass allows hackers to exploit prior flaw in SonicWall SSL-VPN | Cybersecurity Dive Microsoft disrupts Fox Tempest malware-signing-as-a-service platform tied to ransomware gangs | The Record from Recorded Future News Streamer Realtime Deepfakes Himself into Mr. Beast, Says He Loves 'Touching Little Boys'

Hi everyone and welcome to risky business. My name's Patrick Bray. We've got a great show for you this week. James Wilson and Adam Bwalo will be along momentarily to talk through the week's security news. And then we'll be hearing from this week's sponsor. And in this week's sponsor interview, James Wilson, chat with Harun Mir about how going back to basics with security controls is probably going to be, you know, the best path forward when it comes to dealing with sort of AI-enabled threats. Funny, actually, in an interview I did with Adam Point and CEO of Knock Knock, another basic control.

He came up with this great line, which is people look outside, they see it's raining and they talk about getting their AI-controlled laser beams to shoot down the raindrops when probably you're just better off with an umbrella. So that one is coming up with Harun Mia from Thinks to Canary a little bit later on. But first up, we're going to get into this week's security news. And we're going to start this week's news with an hour-old. GitHub social media post, which is best described, I think, as ominous, James. Yes, that this does not bode well.

So about an hour ago, GitHub posted that they are investigating unauthorized access to their internal repose, but they'll let us know if there's been any impact, and we have seen nothing further yet. So, yes, this will be a good one to keep an eye on. Yes. I just wonder, like, if there's no impact, why are you tweeting about it? it, I don't know. This doesn't feel good. But of course, like this is a breaking item now, so we don't really have much to add there. But we've got another GitHub-related story. Again, we're going to start with you on this one, James. But apparently, it looks like some sort of contractor who was working for Sissar was running a repo on GitHub that was just chock full of secrets. And like Brian Krebs has this story. And this story, I mean, Adam, you described this as being better than having an RSS reader. Because Brian, actually texted me a link to this story as soon as he published.

He's like, hey, check this one out. Because, yeah, it's a doozy. A contractor apparently was taking all of these like Sissar, like AWS secrets and stuff and stuffing them into a repo that was what, public, James? Yeah, so there's all these, there's a lot of companies out there that basically monitor GitHub repos to look for things like this, right? They see a new repo created if it's public. They look at their secrets.

And in this case, it was a company called Git Guardian, and they spotted this repo pop up that was, you know, I mean, innocuously named Sissor. private. And when they took a lock in look inside of it, it's got credentials, files including cloud keys, tokens, plain text passwords, logs and a whole lot of sensitive stuff. Now, the point here is this is not about, oh, whoops, the repo should have been private. You never, ever, ever store things like this in a GitHub repo, right? This is the stuff that goes in your password manager and your secrets vault. Repo's just the wrong place. And I mean, you say it best, right, Pat, the Siss's century of humiliation continues,

but I don't think anyone could have had this on their bingo card in terms of just the sheer severity of the dysfunction here. Yeah, I mean, my favorite titbit from this is that one of the exposed files was titled Important AWS tokens and included the administrative credentials to three Amazon AWSgov cloud servers. And those tokens kept working 48 hours after this repo was taken down. Well, this is the other thing, right? Git Guardian were trying to contact Sisser and let them know about this

and they didn't get a response until Brian Krebs got involved. You know, this guy went to Brian Krebs, and Brian's like asking Sisser, and then, yeah, they pulled like a website where the credentials were used, but the AWS credit. Anyway, it was an absolute bun fight. I wonder, though, given it looks like this was the act of a contractor and not some sort of sanctioned approach that, you know,

Sisser says it's the way they should store their credentials, open in an open repo. What could you do to prevent someone from doing something this nuts? Oh, well, the answer is simple. GitHub will stop you from doing this. And there's actually evidence in the logs here that shows that this contractor went out of their way to turn those safeguards off

just so that they could actually commit these credentials into GitHub. No, no, no. I understand that this guy has done the bad thing, but what I'm asking is what could Sisa have done to stop one of its contractors from doing this? And I'm sort of drawing a blank. Yeah, I guess it does depend on the ownership of the repo where it was located. Is it part of an organization that Sissor could have had policies on?

Ideally, in an organization, you have your GitHub organization. That's where you set your top-down policies that would have prevented things like that. Don't check in secrets, credentials for being turned off. But in this case, I mean, this is just the problem of, I guess, repo sprawl combined with credential sprawl, which is anyone can create GitHub repo, anyone can put anything in there. And if they're doing it in their own private repo, then they can turn off the safe go. So this comes down to like a managing your contractor sort of scenario of surely they know that this is just not what you do with credentials. But nevertheless.

But evidently, James, they do not. And I mean, Adam, you see where I'm coming from with this, right? Which is you can't stop someone from just like taking credits they have access to and going, you know, I could put these in a text file on my desktop or I could just throw them into one of my GitHub repos so I can access them that way. Like you can't really do much to stop that. Ultimately, this is a thing you can't solve with a technical control. This is a human problem where you've hired someone through this work, contract through this work,

and they have decided of their own volition to just use GitHub. I think the suggestion seems to me they were synchronizing, like content from their work machine to perhaps a home machine or something. So it was like shadow IT sort of thing going on here. But ultimately, like this is a human problem, not a technical one. And I don't know what technical controls you could, put in place, given that this is being done, presumably outside of anything, so-so-managed, outside of anything where they have even visibility,

because it's all HTTP on the wire. So, like, short of, I don't know, having what your DLP look for files called, like important Amazon creds.com, and saying like that sounds like a bad thing. But, yeah, this is a human problem, not really a technical one. Yeah, I mean, you can't trufflehog, you know, how are you going to trufflehog a repo that isn't in your control, right? So I just sort of think, you know. Well, it was public in this case, so Trufflehog away.

Sure, but then you're just throwing trufflehog at all repos, and then it's an attribution problem. And like, I don't know. So as much as this is like, yeah, we get to laugh at Ciccer. I kind of like mostly what I feel for Cicester at this moment talking about this story is sympathy. And, you know, feeling sympathetic for Cicester is a bit of a theme this year. Let's move on, though, and talk about the latest research into the Fast 16 malware. This is the malware that turned up.

recently when some researches at Sentinel 1 actually dug it up, it was Jags and Vickley Camluck, I think, who found this and apparently there was like a link to some of the leaked shadow broker stuff because Fast 16 had been mentioned it and whatever and that was a breadcrumb that led to the discovery of this malware and this malware, I mean the guts of it is like a kernel driver that messes with scientific simulation software

and we didn't really know in the first round of report what that meddling was supposed to do. And now Symantex come out and said, yeah, this is designed to interfere with simulations, simulated nuclear detonations, basically, which makes 100% sense and is also extremely badass, James. Yeah, like, it is wild to see the level of, I guess, evidence that they've been able to find here

around exactly when this triggered and what it, what it sought to modify. You know, there's a Sentinel 1 report basically linked it to two potential applications and those had a history of being used in nuclear and other CAD things and all. So it was a bit weak, but then this research really goes into the in-depth of actually the exact type of calculation that was being adjusted here is specifically related to supercritical nuclear reactions, which is, you know, the point in time when a nuclear reaction becomes self-sustaining.

And they were also able to identify that, The actual intention here was that it makes the tests seem less effective than they actually were. And so you could imagine it gets a researcher in a mode of, well, this is not working, keep working on it and keep trying to refine the methodologies. But just, wow, for something so old to be doing such just incredible work, it's fascinating. But to your point about the breadcrumb, the really sort of thing that I find fascinating is it was shadow brokers that had an opaque reference to Fast 16 and it was just that the tooling set off.

If you see this, nothing to see here, move along, but no one knew what it was. Then there's a dormant virus total sample that sat there for two years before Jags and Co picked it up and realized that was Fast 16. So it's like, we lucked into discovering this. What else is out there? Yeah, we sure did. And look, you know, to make it clear, I mean, this thing is like 20 years old, right?

And if they're doing this 20 years old, 20 years ago, It makes you wonder what they're up to now is one thing that I really wonder about. I also think it's quite funny that Iran consistently denies that its nuclear program is anything other than peaceful, right? And yet, for some reason, presumably the NSA and their colleagues or their counterparts in Israel, spending a lot of time developing software to subvert, developing malware to subvert software that models nuclear explosions. Gee, I wonder why they're spending all of that time to do that when Iran does not have. have a nuclear program. Adam, I imagine you've been really enjoying all of the coverage on this as well. Yeah, I mean, seeing like another artifact of Five Eyes tooling from the Stuxnet era.

And this is, you know, like in some cases kind of predate some components of Stuxnet. The timeline is really interesting there. It's just amazing what they were doing back then and how sophisticated both the thinking about like how to do it, some of the bits of specific tradecraft. And then, yeah, yeah, like the action on object. of this, like actually modifying, you know, simulation of nuclear weapons, you know, kind of implosion testing or whatever it was, like, just wild. One of the things I really liked about the story was in Jags's write-up, he talks about, like, early on in this research, the thing that got him thinking was there's a bunch of examples of malware that came out of the Five Eyes that used lure virtual

machines to kind of deliver their runtime behavior. So, like, you have basic as little malware as you need to get code running and to propagate and then all the logic you can do in a higher level language. And the use of lure in that context is pretty unusual. And they found these samples by pivoting on the like bytecode headers of lure, you know, bits of lure code to be executed by a VM. And that's just a really, that's just smart thinking. Like Jags is clearly a smart guy to start with. But like that's just a really cool insight. And going hunting that on virus total and then it leading to this and leading to, you know, this story being uncovered. Like, it's just a wild ride.

And then, of course, you know, we had seen some talk about Fast 16. And then no one really knew what it did until, you know, semantics started digging in, a bit of AI to help with understanding it. Like seeing all those bits of the puzzle come back together and it rewriting our history of like what Stuxnet meant, what how advanced Stuxnet was, what they were doing back then. Now we've got this whole other piece. And as you say, like, that was 20 years ago. what like witchcraft are they up to over at Fort Meade these days like now I want to know that too so

well we always want to know right and I mean it's kind of sad because the stuff we get to hear about is like fake ransomware attacks against Venezuelan state oil companies and it's like yeah okay not exactly imaginative are you um you know it's not like this stuff which is which is very very cool I'm sure there's stuff this cool out there but you know it's just a shame that we tend to hear about it 20 years later so maybe when we've you know kicking around eating apple sauce couple of teeth left in our head, Adam. We got to find out, you know? Now, meanwhile, you know, it's not only the United States and its allies that can do this

sort of very sophisticated cyber war. The Iranians can do it as well as per this story in CNN. James, walk us through it. My goodness, they really have leveled up what they're doing, Pat. They have gone after automatic gas tank readers at gas stations in the US with default passwords that had been left on the internet to just maybe make it look like you've got a little bit less gas intake. I believe, in fact, it wasn't even default passwords. It was no passwords. No password is default password. Yeah.

Null as a default. Yeah, I guess. I guess you could make that argument. But I mean, this is pathetic, isn't it? I mean, I'm embarrassed for the Iranians that, you know, what are you going to do? Like, and there's this stretch in here. Where is it? I posted this into Slack with you guys earlier. Yeah, so you can mess with like gas tank level readings, right? So the cyber intrusions are not known to have caused any physical damage or harm, but the breaches have raised safety concerns because gaining access to an ATG could, in theory, allow a hacker to make a gas leak go undetected, according to private experts and US officials. That's a stretch. I'm sure you would agree, Mr. Adam Boyle. Yeah, I mean, the juxtaposition of this and FAST 16 is just, it's so

disrespectful to Iran. Um, and hacking technique. Yeah, like that's just, it's a real stretch. And trying to make these things, like I think was a CNN have the like exclusive headlines scoop with this. So they're trying to make it as jazzed up as possible. And yeah, that's just a real stretch. Yeah. Now look, we're going to move on to a piece here. There it is not strictly cyber, but all three of us agree that it's really interesting. So I guess, you know, cyber people are going to be interested in this. And 4.4 media has a good write up on it. And that is, uh, fiber optic cable is like the prices of skyrocketing because there's essentially a shortage. And this is happening for two reasons.

First of all, the buildout of AI data center infrastructure in the United States is just, you know, the demand is just insane. Absolutely insane for fiber optics. And I think with certain buildouts, there are like local content requirements for fiber as well. You know, building American and all of that sort of thing. So like, you know, you have to get your fibers from Corning or whatever. And the other thing driving up the prices globally is the war in Ukraine where both the Russian and Ukrainian side are just using so much fiber that yeah the price has got to the point where the Ukrainians are starting to use Starlink dishes on certain one-way drones because it's cheaper than using

the fiber. I mean, this is a great write-up, Adam. I mean, it's just like what, you know, as you would like to say, you know, this is the cyberpunk dystopian future right here, right? Yeah, I mean, some of the pictures of like Ukrainian wheat fields kind of. covered in glistening glass fiber because of all of the drones flying back and forward. Like it really just is this topic, future stuff.

But it kind of makes sense that it would have an impact. I mean, you can't put 50 kilometers of fiber on every drone you're sending one way and not have it have some kind of impact on the market. And, you know, we've seen some numbers where like the prices have gone up like two, three, four, five fold over the, you know, over the course of that conflict. We're also seeing fiber drones being used, you know, by Iran and that kind of fight. on as well. So it's definitely, you know, the state of electronic warfare against radio control drones as such that using fiber is a great alternative to dealing with more sophisticated,

you know, kind of EW adversaries. So, you know, it kind of makes sense that the cost will go up. But yeah, it's, it's just like the fact that it got to the point where a Starlink terminal is worth thrown away instead of a bucket of fiber. Like, that's pretty crazy stuff. Yeah. And then some of the defense mechanisms against this, like we saw a 4-4 has a a little video of a Ukrainian defensive technique, which is like a fence made of spinning razor wire. And so then when the fiber drapes over it, it gets tangled up and cut. Yeah, so it's like a single strand, just to describe it to people, it's a single strand of razor wire that rotates. So the idea is, you know, as a drone flies overhead, you know,

it just gets severed. I mean, it's completely sound, the logic in this. You just think, what a great low-tech solution to this. I wonder how well it'll work. Yeah, but it's exactly the sort of thing we've come to expect from Ukraine, like super pragmatic real world solutions to very real problems. And there's going to be like when someone writes the book about all the things we've learned about modern warfare from this conflict, this is the sort of thing that's going to be in it because there's just so much interesting insight in there. Yeah, and I will say too, it really does look like at the moment Ukraine has the initiative

in the war. They were, you know, hitting Moscow the other day with drones. Like it looks like, you know, Russia's air defences have been attracted to the point where that's possible. Yeah, it's a very interesting time in that conflict now. I mean, it's been over four years and Ukraine has just not given up. Ukraine has fought very hard and innovative and, you know, things are turning around at the moment. Whether that is lasting, it's difficult to know, but we obviously wish them all the best in their struggle. Now, moving on to back to some more bread and butter cyber and we've got a whole bunch of stories here talking about the you know what

what has been termed the volumpocholips or the bugpocalypse you know the first one we got here is from Alexander martin over the record which notes that Microsoft is on pace to break its annual vulnerability record they've just dropped a patch Tuesday with 130 patches in it so no surprises there I've had conversations with people in Microsoft and look I think it's worth noting that they're going through what everyone's going through when it comes to AI which is the volume of AI which is the volume of generated code within Microsoft at the moment is insane. Trying to do manual review on all of that. Just forget it.

The number of bugs they're finding also insane. You know, trying to also figure out how to deal with everybody wanting to run agents on Windows. That's another insane problem. So they're all very busy. They've also come up with a multi-model agentic security system for bug hunting, which is very interesting because it supports what we've been saying and what people we've been speaking to have been saying,

which is James, that the model is not necessarily the important bit when it comes to bug hunting, the more critical part is actually having a good harness. And that's been Microsoft's approach here. And indeed, we've got other coverage from Cloudflare, where it turns out that's been their approach as well. The funniest part, though, I guess, is that Microsoft has actually named its harness M-Dash,

which is the best diss against LLMs, which just love inserting M-Dashes into any cost. they generate, but James walk us through Microsoft's thinking here. It does really seem like they're onto a similar train of thought as Nils Provost outlined in his interview with you recently. Yeah, 100%. It's directly ties back to that in two ways. One, they talk about different models are better at different tasks. And so they're very diligent about giving model specific tasks and also quite narrow tasks as well, right? I think there was not in the Microsoft one, in the cloud for their one they particularly called out that if you just use a typical coding agent

even with the best model out there you're just not going to get the results because coding is a much different approach to security research so that was the first thing that was interesting the second is yeah as you said the harness is what matters and in particular it matters because a model really wants to get to done and this this is again what i learned from talking to niels model is is trained to finish to complete, to give you the answer. And so what the harness adds is things like finite state machines where it essentially governs the model and says, you can't just go straight to done, we're going to go through an audit phase, we're going to go through a hypothesis phase, we're going to go through a testing phase, we're going to go through a proving phase.

And when you can add that structure in those finite states in, it's almost like you've caged the model more restrictively, which causes it to strive for a different kind of level of what done means, which I think is yielding the difference in terms of the actual quality of the output here that Microsoft and Cloudflare have spoken to. Yeah, and it's not just, you know, it's not just Microsoft and Cloudflare. We've had some comments, some grumpy comments from Linus Torvalds.

Fancy that. He seems a bit shirty, how unlike him, but he is complaining that the Linux security mailing list is almost entirely unmanageable, because there's all these duplicate AI bugs and it's all just, you know, crap. Very Torvalzi. linising there basically. But look, dude makes a good point. I think one of the interesting things

is though, is one of the things he's complaining about is duplicate entries, right? Which has led some people to say, again, something that we've said on this show previously when it comes to like, well, you know, are these models going to be useful to the intelligence community? And they're not largely because these bugs that the models find, anyone can find them, right? So they essentially become public at the point that that new model is released. But what do you make of the impact here, Adam, on like, open source projects? Because I imagine it's going to be, in some ways, it's going to be harder for open source projects to try to get a grip on the bug deluge than it is for, you know, profitable companies

that are going to be able to spin up resources and assign resources to dealing with this. Yeah, I mean, it's hard for everybody to deal with the volume of output. And I think the challenge for open source people is they have the added complexity of the social dynamics of open source communities. Like at Microsoft, you know, if they produce hundreds and hundreds of bugs and they have to distribute those to hundreds of teams, there's like a real cost involved with that. And everyone understands that if they produce bad reports, it's going to have downstream financial impacts in other units. And there's like there's some centralized control there that can direct the discovery process to be more selective or to produce better quality input or whatever. In the open source world, that all comes down to historically just kind of social dynamic. and people acting in the interest of the community

and that's quite a hard thing to manage to start with and especially when those communities are rewarded through kind of kudos and, you know, kind of recognition. So it's a different, like it's not just a financial metric, I guess. And so open source communities have problems already with that. And then AI just kind of like the economics of that are a bit weird for them. So I think, you know, they've got some very real challenges. and, you know, the Linux kernel, I guess,

is a bit more controlled than the average open source environment because Linus, you know, is, you know, his grumpy self. So, yeah, it's going to be interesting to see how that unfurls, you know, and I'm thinking, I was just going to mentally comparing it to say, like how the Kerle project is dealing with, you know, Badger being very, also quite opinionated about how and where AI is useful for them and similarly with Firefox and Mozilla and Firefox. So, yeah, we're going to see different responses from different open source communities.

Well, actually, this was a very important. evident in the copy fail bug. I caught up with the folks from theory that were behind that bug this week, and they called this exact problem out, right? When they're disclosing a bug to Microsoft and Google, they knew how to do that safely. And in this case, as you'll hear in the episode that I'll drop in this week, they did actually disclose it to the Linux security in the kernel mailing list and there was patches, but they, by their own admission, dropped the ball because they didn't understand the social dynamic of then who's contacting the distros, who's managing that process, all of which has a very well-managed process in a corporate company.

So that was a big part of the reason why that was such a quite a clunky, shall we say, disclosure of that bug. We dropped a patch into the mainline tracker. We're done. We're done. Everything's fine. Now, look, speaking of other bugs, we've got an interesting mythos one here. Apparently, some researchers in conjunction with mythos managed to find a memory corruption exploit

targeting macOS on Apple M5. And the reason that's interesting is because that means they bypassed Apple's memory integrity enforcement. Now look, I would be more impressed by this if people I know in X-Derve hadn't kind of intimated to me that memory integrity enforcement like wasn't perhaps as good as Apple thought it was. You know, it's the sort of thing where you ask, oh man, is this thing causing you trouble? And they would just sort of smirk a little bit. So I don't think, you know, it's taken an advanced frontier model to figure this out. But I guess, James, you know, you being an ex-Apler who understands the guts of these operating systems,

I'm guessing you would have found this more interesting than most. Yeah, I'm so keen to read the write-up from these guys once they can actually publish it, because all they've done at the moment is just said, ha, we got past this on an M5 Mac, but we're not going to tell you how we did it until it's patched, which, you know, again, see earlier comments about disclosure. that sounds a good way to do things. There is, you know, my intrigue is also piqued by the fact that this, whatever they've found is constrained to, first of all, the M5 chip and only on Macs.

Now, is that hardware difference that makes this more exploitable on some platforms, or is it the, you know, more closed nature of iOS that means maybe the bug is there, but they haven't been able to find it. So, look, there's just, there's going to be lots of really interesting details. I hope this comes out soon. Oh, couldn't afford Corellium, I think is what that is. But anyway. Moving on.

Well, actually not quite moving on. This is still very much in the same topic. Last thing on the same topic is OpenAI has now launched its daybreak initiative to, quote, combat cyber threats according to Page Gross at Cybersecurity dive. I find that framing really funny, which is like you've got a model that can crap out O'Day, and that is combating cyber threats. I don't really see it that that's how you combat cyber threats. But James, you actually looked at what day.

break is and the best you can tell it's a web form at the moment. Yeah, yeah, like, gosh, it's another poor example of open AI being like, look at us, we do this too. We really do. We're also scary. We're also just as scary as mythos. We're just as dangerous. We're so dangerous. You have to fill out this form if you want to use us. But this, look, it's really hard to work out what this is. The best I can tell is it's their 5.5 model, maybe with some guard rails removed, but they don't give you access to the model, it seems. You sign up and they, you sign up and they, do a security vulnerability analysis for you as a service. So suffice to say, Pat, I don't get it. I mean, look, maybe that's a good way to do it, right? You can just give your software. Why would

you need to have access to the model if you're just going to send you a bunch of one-shot prompts saying, find bug in this? You know what I mean? Like, they can do that for you. Like, unless you're giving it to some sort of real expert, like, unless you're giving it to Niels Provost who's plugging it into a harness and like, you know, actually doing some active research on it, why not? I don't know. this could work. Could work, but again, if that's what they're doing, they could have made more noise and been more explicit about it because then we would be really actually excited about that being a service. But I'm really just trying to read the tea leaves here on what little data they've given us beyond fill out this form, please. Now, we're going to get Adam to talk about this

one and hope that his head doesn't explode as he's describing this bug in Bitlocker, which I've got to be honest, I had to read this a few times to be like, wait, what, really? So it turns out like during a default installation of Bitlocker on a standard like Coop laptop, getting around that is comically easy. I could not believe this. But Adam, you walk us through it, please. So in many corporate environments, like the way that they deploy Windows Bitlocker crypto is TPM back.

So the key material lives in the TPM chip on your machine. And at boot time, the TPM checks to see whether the machine meets some kind of like trustness, you know, hasn't been tampered with, you know, isn't booting off a weird device, etc, etc. And if it passes those tests, then it just kind of pulls the key material out of itself and passes that on the windows to decrypt the drive. Now, this is a thing that most corporates prefer because the other option, which is adding some kind of pin or extra like credential step pre-boot, just has a whole bunch of support overheads. Now, there's been a lot of bypasses in TPM, pure TPM backed BitLogger over the years because once the machine has booted,

there is a bunch of attack service to try and get that key material out. So, for example, we've seen some research that just pulls it straight off the bus, like off the physical wires, but on the motherboard between the TBM chip and the rest of the computer, use that steel key material and off you go. This particular researcher who seems to have real beef with Microsoft. It's like an anonymous researcher that honestly sounds like he's having, I'm assuming he, is having a really rough lifetime. Like, it does not seem to be in a good place mentally.

Anyway, he has... There's the real sandbox escaper vibes with this particular person. And the knowledge of Windows seems crazy. It's like, did you... Like, either you are just a screw-loose person who just immediately understands everything Windows or you worked there or something, and it's like the whole thing is weird.

Yeah, I mean, they seem pretty unhinged, but on the other hand, are absolutely delivering the goods with the bugs. So what they've got is basically a trick where you can boot a Windows machine into recovery mode with an extra like USB storage device plugged in. And on that USB storage device, you have a like,

NTFS has an option for like doing transactional file system as support for transactional file system kind of bits where there is a file system kind of like can replay changes that were previously written that didn't complete such that, you know, it's more, it handles like power loss and other bads. better. So you put a transaction log on this USB storage device that can then replay changes back onto the main, well, onto other drives in the system, which in the context of a Windows recovery boot is the RAMDisc that contains the Windows recovery image. So then they can override

config files and basically make that RAMDisc spawn a command prompt pre-Orth. So at that point, the machine boots up. It's in a trusted state. The TPM has released the key materials. The Windows Recovery RAMDisc is running. But instead of running the like, Windows hello, login process or whatever else, it just drops you into a command shell, and at that point you can extract key material, edit the disk, do whatever you like. So the net result is physical access to a TPM back bit locker machine gives you full control of device, which is kind of one of the things that you're relying on Windows BitLocker to prevent. Of course, the security community is like, well, this is kind of like what you should

be using pin-based bit locker for to prevent this kind of thing because there's been other attacks. And indeed, after this particular one came out, somebody else published another technique that could have, does a similar kind of trick, manipulating Windows recovery images. But the reality is the support overheads of pin-based bit locker are just so high. That this is how everybody does it. And this is how everyone does it. And the protections you are getting from your bit locker probably don't match your expectations because of this kind of weird weakness. And it's just, ultimately, there is so much attack service pre-boot in Windows, like pre-full system

startup that kind of can break that trust chaining from the TPM through the BitLocker into trusted kernel is running and machines in a hardened state. So it's not great. And I imagine plenty of people need to kind of rethink about what this means for their, you know, the amount of trust they can put in their BitLockered systems. I think also we have to remember why it is that all. organizations apply Bitlocker to laptops in particular. And it's because of compliance regimes where previously, if a staff member went out for a few

beers after work, had a few too many and then left a laptop in the back of a taxi, that was going to be recorded as a data bridge. So this is why BitLocker is everywhere. Is it a compliance thing? It's a way to stop data breaches that aren't really data breaches. It's just like stuff left in the back of taxi. right? So I think for most organizations, not much changes here, but for organizations that are really concerned about BitLocker being a functioning control, they're going to have to deal with this,

but my guess is if you were thinking that BitLocker was a functioning control in the first place, you were probably one of the few organizations that was using pin control. So, like, I look at the way that this works, and I think, oh my God, like, that shouldn't be the case. Like, it shouldn't be possible to do it. this. But at the same time, I think we've got to keep a lid on, you know, we've got to control ourselves and we're talking about the impact of this, I think, in the real world, right? Because, yeah, I think it's actually quite limited. Look, let's move on to this next story now. And Catalan got this one based on a series of press releases from the Polish government. We wrote about this in, well,

he wrote about this in the Risky Bulletin newsletter. So go to Risky Bulletin. you're not, is and subscribe to that one, if you're not already. The Polish government is advising officials to replace signal with its national messaging app,

which is called M-Cyfer, but it's like M-S-Z-Y-F-R, which reminds me of the immortal onion headline from many, many years ago, which is Clinton to deploy vowels to Bosnia. But yes, it's pronounced M-Cyfer. And I think this is really interesting. So our colleague, Tom Uren,

know he's working on this one for his seriously risky business newsletter, which will go out tomorrow. Because you kind of worry, I worry. I understand why people are moving away from signal, because it's being fished by the Russians, right? At the moment, it's causing a lot of problems, because they're doing this, like, linking fishing where you wind up, they wind up tricking people into like QR code authorizing an attacker's computer to be linked with their signal account so they can spy on their communications. That's bad. That's a really bad thing, especially when you consider that signal is like the default de facto method through which politicians communicate. And not just within a country, but globally as well. It is the communications infrastructure of

the world's leaders. So now we're seeing possibly some sort of balkanization here towards homegrown stuff. I don't know, man. I don't know if that makes me feel good. But James walk us through M-Cyfer here, I believe you know a little bit about what they've thrown together. Yeah, it's basically a fork of the Matrix open source protocol, which is a signal-like thing. But I think the thing when I looked at this was you've got to realize that yes, signal has its problems with being fished and whatever else. And you and I've talked about how sometimes it's between their use of mobile phone numbers for some identifiers and other handles or other things. It's a bit of a complicated landscape. I never know who I'm talking to anymore since they introduced this, like,

like, oh, you're a signal connection with someone called D. Yeah. Okay. Who's that? I got no way to tell, right? It is, it is, and you've got disappearing messages, so you try to open up the conversation. There's no history there. So it's like, I think they've actually made it quite confusing to use in its default

configuration and quite easy to fish in its default configuration. And I think as much as they can put out statements saying, well, this is the way it's got to be. And, you know, we've put a lot of thought into this and education is key. The fact is when your most important users are getting owned by Russian intelligence servers and other users like me, and I would not call myself like the most technical person in the world, but I host a cybersecurity podcast for God's sakes, and I have done for 20 years. And if I'm finding it difficult to use, then I guarantee you a lot of your other users are finding it difficult to use.

And here we are with the Polish government launching their own forks of Matrix, which are not going to have the same QA as my online signal, which really, worries me. It worries me. I worry this is like crime phones, but for the world's leadership. Adam, what do you think here? Yeah, I mean, splintering it up. And one of the great things about signal is it's had so many eyes over it, right? Because it's so important, because it's, you know, used in all sorts of relatively high trust situations. And in the moment anyone tries to make it do something else. I'm reminded of the like weird TM signal fork that got, you know, messages leaked out of it because it kind of changed the trust model and bad co-quality and so on and so on.

Like, anytime you move off mainline signal, you're into kind of into the, you know, dangerous bits of weeds. And Matrix, at least, by virtue of being open sourced and used in other places, you know, it's going to be better than something completely homegrown. But, yeah, like... But that's the protocol. That's not the app, right? And the problems with Signal, again, they're not in the protocol. They're in the app.

You know, they're in all of the weird little features and do-hickies that, you know, that gets stuck on top of the protocol. You know, I don't know. I mean, look, if people wanted to fork signal, they call. as well, right? But we've seen, yeah, we saw, as you said, with that, that signal fork in the, well, it was an Israeli company that did it and then sold it to the current government there to do, that was crazy. But yeah, I just don't know. I just, I don't know. I find this, this is a worrying sign, actually. Yeah, I mean, I think you're right that signal, one of its advantages was that it was relatively simple and signal purpose, single purpose. And as they've added

more and more stuff to it over the years, then we start to get, you know, things get a bit more complicated, the ux gets a little bit more difficult to explain. Old phone, who dis? Yeah. Exactly right. And identity is a hard problem. I mean, I'll give them that. Like, this is a difficult thing to solve.

But yeah, I'm not convinced that forking a, I mean, fork in matrix and letting people use it is the solution either. So, yeah, I don't know. Signal foundation. I think it's on them to kind of come up with some things to smooth out some of these rough edges. Yeah, I mean, maybe a version. I mean, look, the whole point is you can't trust phone.

numbers as an identifier and what signal did was it applied PKI on top of that and that was good. That was the right balance I think between being, you know, and then you have a pin so people can't sim swap and then reset the account. And I think, you know, that was a really good sort of status quo that combined the sort of availability of phone numbers with the PKI on top of that is an extra layer of sort of identity identification. Now it's just got a bit, it's just got a bit silly. And then the linking, I've never liked linking it as well. And you know, I don't know if it's an electron app anymore, but that was the thing that kept me away from it for a long time,

and now I just find the whole idea. Weird, I think also there are better ways if you wanna use Signal. I think using iPhone mirroring, if you're a MacOS user, that's gonna be a better way to bring Signal to the desktop, but instead of, you know, QR code based linking with like weird electron-like frameworks.

Anyway, it's just disappointing that they've, I think they've made it more, too complicated for its own good. Anyway, moving on and, oh God, there's these bugs, in like a Cisco SD-WAN product. There was a round of these bugs earlier this year that were being exploited in the wild.

And now there's been a second round of very similar bugs, I believe also being exploited in the wild that CISRA is telling everyone to patch. Rapid 7, I think, found this second set of bugs, but it looks like it is also in the wild. But just, you know, absolute clown show at Cisco. And also, Adam, there's, apparently, according to some original reporting out of the record

by Alexander Martin, there's some sort of Odean Huawei gear like Dos Ode that was apparently responsible for bringing down Luxembourg's entire telecommunications network last year. And then on top of that, we may as well combine these all into one is there is a patch bypass for a flaw in Sonic Wall's SSL VPNs. So like you add this up and it's just like, I mean in our run sheet they're the tabs of fail between Cisco, Huawei and Sonic Wall. depressing reading, what's your take? Yeah, there are some fun bucks here, actually. The SDWAN,

let's go SDWAN one. There's like us UDP protocol we used to coordinating between the components of the SDWAN solution, and you can orth and kind of say that you're one particular type of device, and they didn't really think through the orth flow for that type of device, and you end up in an authenticated state without having to have a valid, like, certificate or anything else. And then from there, you can call a function that lets you add a SSAH private key to the controller. So then you can just like SSH and reconfigure it then. And like, what were you thinking, Cisco? So this one, it was just like good bug.

And I enjoyed that one very much. I mean, it's probably some product they acquired through some acquisition of years ago. You know, like that's always how this, a lot of this stuff happens with us. 2017 acquisition of Heptela. I looked this up because I've worked at Cisco in the days when Cisco was good. And I'm like, I bet this is an acquisition. And you always is. Always is.

There were days when Cisco was good. Yeah, that 1999, 2000, 2001. Those were good days. Once upon a time, yeah. That time was a long, long time ago. The Huawei bugs in Luxembourg, now this is interesting. So there was an outage of the Luxembourg Post, which also operates mobile and landline networks in Luxembourg.

And what they seem to be saying is that a whole bunch of their core Huawei router gear crashed and went into a reboot loop. And this bug appears to, been triggered by like packet forwarding from the user plane. So this is not people connecting to the Huawei devices management interface and then causing to go into some DOS thing. It's them forwarding bad packets across them, their interfaces, and that resulting in a reboot loop. That should not happen. Which clearly should not happen. Like that's not the sort of thing we want. Like just just getting a bad packet to transit a bit of Huawei gear crashing it. Like that's,

I mean, that's, that's, that's cool. I mean, we've seen bugs like that in the past and I feel really good. Like we back in the insomnia, old old, and sometimes we had a like single packet EDP Y Shark bug and you could, it was a beautiful, wonderful thing. Yeah, this is like, this is ping of death, but for Huawei, I mean, you got to love it. Yes, yeah, but like in the user plane, mind me, you don't have to ping the Huawei, you just ping across it. Anyway, this was like, what, 10 months ago or something, and we still see no details.

Huawei doesn't want to talk about it. No one else seems to know anything about it. So it's just an interesting bug and like I am talking to you across a network that almost certainly is Huawei in the middle. And I would like to know about this magic. It's because Kiwi's a slow learner, but anyway. Well, well, yeah. It's embarrassing for everybody concerned. Anyway, I just thought that was really interesting. And if you have Huawei in your network, then maybe time to go hit your Huawei account manager up and apply some pressure.

The third one you mentioned, the Sonic Wall. It's being written up as a patch bypass, and it's kind of not really a patch bypass. It's that when Sonic Wall patch this particular bug in their older model of their devices, it wasn't enough to apply the patch. You had to also then make a bunch of configuration changes, and no one did. And so everyone who was running version 6 of the Sonic Wall things, who just applied the patch and didn't read the rest of the patch notes is now getting owned. And fortunately for Sonic Wall, in that time period,

that particular model of their software has reached the end of life, and now they don't have to care about it. So they nailed that particular thing. They managed to thread the needle there. Unfortunately, a whole bunch of people getting a lot of owned, but if you run Sonic Walls on the Edge of Network, you're probably used to that. Now, we're on to the home stretch here at a bit of good news before we go. John Greig reports at the record,

and we had this one in the risky bulletin as well, that Microsoft disrupted a malware signing as a service platform, are tied to ransomware gangs. the service was called Fox Tempest I found this interesting because really they were doing like simple administrative crime as a service right when they were basically spinning up

what fraudulent companies obtaining valid signing certificates and then you could submit your malware samples to them and whatever I mean this is just like you know they're simplifying administration this is a productivity enhancer for the malware scene I mean this is you know I hate to admire

a malicious business but this is fulfilling a market need what did you think James. Yeah, exactly right. It was also interesting just the scale that this is operating, because when I was looking through it, I had that same sort of reaction of, oh, yeah, I could see how this would be useful, but really how many people really need this? How often do they use it? Turns out a lot and at scale. So yeah, they were creating hundreds of seemingly valid as your tenants with made-up businesses, etc., so that they could create these short-lived signing certificates that would make their malware seem legit. But it was all crafted around this as a service concept where you'd

have your malware parked on their service ready to go and then you'd sort of go and log in and say, quick, I need a signed version right now, please. It'd go find, you know, the right tenant to give you that and create the cert. But, you know, this must have been incurring a cost of tens of thousands, maybe hundreds of thousands of dollars in terms of Azure and all the rest. But then in this article, it says Microsoft went to the length of tracing the cryptocurrency payments that had been made to Fox Tempest and it was ordering in the millions of dollars that ransomware affiliates had been funneling into this company to do their jobs. So yeah, like you said, admin as a service, helping folks out and quite profitable at the same time. Well, it's B2B SaaS for cybercriminals and I just

find it really funny because it is the type of drudge work that nobody wants to do. So it's actually a really good SaaS play. Adam, you ought to add something there. Yeah, the thing I thought was really interesting about this is that they are using the Microsoft service called artifact signing where they will sign this code for you and I was a bit confused because like normally code signing involves code sign certificates and blah blah blah blah but this is a Microsoft service where they sign your binaries for you as a service and this is kind of part of as you or you I think you can run it standalone as well but the interesting thing is it's it's kind of pivoted what you

meant by code signing from this code has been you know like Verersons given a company certificate and Davis a 10 tested to it themselves and like this kind of idea of a long-lived trust signature thing to very, very short timeframes, but it's being tied by Microsoft to an Azure identity. So it's kind of changing code signings meaning from company authentication to Microsoft identity authentication. Now, we would look at a code signing certain normally go, well, you know, Veracine says that this company is fine, so therefore the binary is probably fine. Now we're saying, you know, Microsoft has just said this particular account is in good standing in Assyra and has paid their bill.

The meaning of that is kind of the same, but also like the, there's a, the way you think about code signing, I guess, is a little bit different. And yeah, I just thought it was an interesting kind of change for how I thought about it as a result of this like very rapid, like now it's just about identity and tying it together at a point in time and that's all. In a way, that's good. Like, that's kind of what it always was. Well, I was just thinking as you were talking, like next week, sponsor interviewers

with the airlock guys. and it's a funny one because they're talking about a couple of things like how DigiSert got owned with a malicious.scripts. And then someone was able to sign like malicious files or obtain hardware certificates for like Yuba keys that were signing certificates. One of them was for like 10 cent by actually completing orders that they paid for and whatever and going through that process. But the funny thing and the reason Airlock were talking about it is like shortly after this happened, Microsoft Defender started flagging DigiSirt's route. certificate as malware and removing it from people's machines I think it hit like 4% or something of defender users and like thankfully it didn't affect airlock customers because and not because they're geniuses it's because they cash certs right so by the time it was like they Microsoft

detected it quickly and sorted out but you know just the whole thing the whole story like the CIA getting owned malware being signed Microsoft's you know like they haven't admitted that that was what they were trying to deal with was like revoking some certs and accidentally nuking the trust cert. But like the point is that whole system is kind of broken, right? So if we're moving to something a little bit fancier la what you described, I mean probably some people who are smarter than us have put some thought into that and it's going to be a step forward.

But that is it. Oh, no, that is not it for this week's news because we do have one more thing I wanted to add. There's a story here in 404 media and we'll just add it as a reading list item because we are out of time. There is, it just talks about more of this software that does real-time deepfakes. This one's targeted at streamers. We spoke last week about some Chinese software more suited for criminals who are trying to do fraud stuff with the real-time re-skinneding of people, real-time deepfakes. The point of including this this week is this stuff is popping up now.

And very soon it is going to be absolutely everywhere and available to absolutely everyone you need to adjust your understanding of risk accordingly. And BAC procedures and things like that because it ain't too long before you're going to get face-timed by someone who looks exactly like your boss. and sounds exactly like your boss, who is not, in fact, your boss. But we are going to wrap it up there. Guys, great discussion, as always this week. James Wilson, Adam Bwalo. Thanks so much for joining me. No worries, Pat.

Thank you very much. Yeah, thanks, Pat. I'll see you next week. That was Adam Bolo and James Wilson there with a look at the week's security news. Big thanks to them for that. It is time for this week's sponsor interview now. And, you know, as regular listeners would know, I've been a bit under the weather lately. So James Wilson actually stepped up to do this week's sponsor interview with Mr. Harun Mia, the founder of Thinks Canary.

Now, Thinks for those who don't know, it makes Canaries, hardware canaries that you can plug in at various points in your network. And you can, you know, you can set them up to look like anything you want, like a SAP system, file share, you know, network device, whatever. The idea being if someone is on your network and they're starting to see something that looks like an interesting target, they're going to start interacting with it and you get an alert. They also do a lot with Canary tokens and whatnot. And, you know, this stuff has been around a while now. It is, I think you could probably lump it in with one of these sort of, it's a, it's not a control, it's a detection, but it is one of the simpler ones, right? And we're hearing a lot of talk lately now that we're entering the sort of AI attacker age

about how the simple things are really going to be what's most valuable to our defenses in the future. It's a sentiment I happen to agree with. So here is Harun Mir, reflecting on that about whether or not the simple things are what's best. The back to basics thing is an interesting take. A little while back I gave, I think it has a talk at Black Hat, where I said one of the problems with back to basics is that it's almost overdetermined.

Like post a breach, people say, well, they should have covered these basics, but there's 50 bajillion basics. And so it becomes a catch-all that makes sense in hindsight, but which of those basics should the CISO have focused on? And so a company gets popped because of password reuse and you go like, oh, they should have had those basics. Or they get popped because of like flat architecture and you go, oh, why didn't they do the basics? And so it's a little bit unfair that way. But what's interesting, and obviously I'm a vendor and you take it with a pinch of But we shaped Canary very specifically, like against other deception players, almost one of our defining

characteristics has been for crazy ease of deployment. And the main reason we did it, like there's lots of features that we'd like to build, like we'd like the end product, but we think they're too implementation heavy. And we think for deception, that's not good enough. because like our product belief is that deception should install easily and get out of the way. And our pitch for that is if companies have to focus on deception and build like fancy deception stories and deep integrations, then that's time they should be spending on solidifying their base and fixing their problems. So we believe Canary's work best if they're,

The implementation cost is so low that you literally deploy it in an afternoon and forget about it. And so we're looking for that really low cost. And then what we spend time on trying to get right is those sweet spots where you get an asymmetric payoff. Like the implementation is really cheap, but the payoff is really high. So I think the key takeaway from what you just said is, as people go back and revisit that long list of stuff they could have would have should have. done. Canary is actually pretty low on that list and should be like the next thing to pop out because it's fast, it's broad spectrum and you just get it done fast, right? I think you end up mentioning there the perfect takeaway for me from Muthos model volumpocalypse is like probably one of the

most enduring security quotes that I don't think gets enough airtime was Brian Snow way back had this great quote that said, your networks only survive due to like the sufferance of your opponents. Like, like, the only reason you're not popped is because opponents haven't popped you yet. Like, it's not what your team are doing. And, and Brad were saying during the week or during the previous podcast, we've gone through a few iterations of, is this a world changer? And, like, like, to put a thing on it, like, when, When patch diffing became a thing, like, everyone was like, oh my God. Like, we're going to reverse patches.

We're going to have end days. We can't patch so fast. We're dead. When Metasploit came out, it was like, oh, my God, like, everyone's going to have access to shells and good shell code. And all of them were game changes. Like they did accelerate timelines. But more than anything, what every one of those did was chip away. at this thought that said

our network's untouchable. Like all of them said, you're touchable now. Yeah, yeah. You better do something about it. Like, like, you're going to get, you're already naked, like the tides going out.

So the famous quote is like, when the tide goes out, you see who wasn't wearing their swimming trunks. And all of these are basically like, yep, the tide's moving out. You'd better, you'd better put on some shorts. There was a point in time, when a canary was super useful because you would know when someone was rifling through your stuff.

And that was back in the days when dwell time was long. And if you got that heads up, you could probably evict them. You could minimize your damage. But man, what we're seeing emerge now is just this indiscriminate. As soon as you've got access, smash and grab, do the damage and go. I mean, tell me why a canary is still useful in this day and age when, frankly, by the time the canary pops off, we're all gone anyway. It's you. Yeah. So I think as those attacks become a thing, like, again, if I talk about original sin stuff, one of the problems we always have is when a new attack pops up, it doesn't mean the old attacks stop and stop being useful. So we've got to worry about these new speed of

wire attacks. And look, some people, like Dave I tell has been even pre-LMs making this claim and insisting nowadays the attacks are going to happen so fast, detection doesn't matter because we're going to be out of there before anything really trips a wire. And I think that's true, but I think you've still got state agencies taking their time and rifling through stuff and finding things, and you still want to detect that stuff.

So if I understand what you're saying now, I think it's a good point, right? I think what you're saying is, it's almost like this is a cumulative game, right? the surface area and the defenses are cumulative. And you don't just stop doing one thing because the speed's increasing. Because if you do, well, maybe they'll turn around and say, actually, that smash and grab was not what we want to do. That was means to an end. And if you've all given up on Canaries, awesome days, we would just take our sweet time now. And I think that happens

pretty consistently. There's a defocus on this and that becomes the path of least resistance again and attacks. And I don't think those attacks have gone away. Like I, like I, don't think people are massively retiring their teams of attackers because people are still going to be doing the troll through networks. I think we can see signs like with the recent published Mexico or Mexican government attacks, you've seen signs of people abdicating to agents so that agents can move really quickly. And I think those are going to happen. And again, I'd argue, even in those cases, like the thing that we largely got lucky with Canaries was attack on a like objectives of the attacker are still such high quality signal that says you can absolutely

react to this thing. So when someone's done this stuff, you can now say, very few things give you the certainty to say, yep, kill that IP, yep, absolutely kill this, drop this whole segment because this attack is so clearly bad. And the different intent you're talking about there is like there's probably a very different response to, hey, the canary that's pretending to be our SAP instance is just gone versus, you know, hey, that, that, you know, AWS credential that we left lying around, right? Because it's just, if I'm understanding, right, those are fundamentally two different mindsets of an attacker. If it's the thing that looks like the SAP instance that they're going after, then you've probably got someone that's very interested in your data. If it's the AWS

credentials, you know, could be totally different motivation, right? Exactly right. And so, Like a long time ago, Ryan from Slack said any sufficiently advanced attacker is indistinguishable from your lead developer. I think it's vice versa. Yeah. Exactly. It's going to be impossible to tell. And interestingly, for agents internally, I think there's a whole new problem that's going to come up where, like it's a whole separate thread that we can go down that says with agents, And we've started to see it with open claw.

We had these problems with over-provisioning users with credentials. And we largely, despite what people with scars would tell you, we've largely gotten away with over-provisioning users because Sally from accounting didn't know what to do with domain admin, even though she had it. Plus, there's a couple of other checks and balances that make sure that Sally's not going to go and wreck the domain. So what's interesting is lots of sallies and bobs were running around with more credits than they needed,

but actually they didn't know what to do with it. Their agents will. And so we're going to bump into this next level of the problem where their agents go, well, I've got the credentials and I've got PowerShell and now I can go do stuff. And I think we're still going to figure out what happens there. But to close that off, I think, yeah, because. Because Canaries so accurately are able to say, this is badness, you're able to do stuff at reaction speed that doesn't easily happen with other stuff.

Yeah, there's no second guessing, right? It's like, step one, detect, step two, close it out, as you said, right? There's no like, hmm, I wonder what they could be doing. What does that log message mean? This is abnormal activity, yeah. Exactly right. In fact, again, in our product, and this was a product decision. early on. Lots of the people who evaluated deception stuff wanted deep forensic traces,

like post a canary getting hit. Until today, we don't do that. Like, we literally make our pitch on actually, if I told you this IP did this thing, like in our case, it's enough. Yeah, it's, it's, this guy did something really bad, go do something to it. And we've gotten better around it, like, better info for security teams, but for the most part, we think it's efficient because that's what we're going for. This is really high-quality signal. This is badness. Go do something. Well, it's a slippery slope that you're avoiding as well, right?

Those product requests mount up. Harun, listen, it has been so great to chat with you. Thank you for putting up with my cranky challenges, and I appreciate the answers. You know, it's going to make me really rethink the way I've been viewing this problem and what we need to do. But man, like I said, great to meet you. Thanks for dropping by. It's been super fun. Nice to meet you.

That was Harun Mia from Thinks to Canary there. Big thanks to him for that. And you can find them at canary. Dot Tools. And that is it for this week's show. I do hope you enjoyed it. I'll be back soon with more security news and analysis. But until then, I've been Patrick Gray.

Thanks for listening.