Security Now 1101 transcript

Please be advised that this transcript is AI-generated and may not be word-for-word. Time codes refer to the approximate times in the ad-free version of the show.

Mikah Sargent [00:00:00]:
Hey, it's time for Security Now. Steve Gibson is here, and I'm subbing in for Leo Laporte, and we talk about, well, another record-breaking Patch Tuesday, plus Unit 42 reports on a really wild agentic attack where the agent decided to leave a lot of its evidence behind, a mass compromised hardware cryptocurrency wallet attack, and— What happens when you reverse engineer ECDSA curves, uh, by way of Claude? All of that coming up on Security Now.

TWiT.tv [00:00:39]:
Podcasts you love from people you trust.

Mikah Sargent [00:00:44]:
This is TWiT. This is Security Now, episode 1101, With Steve Gibson and me, Micah Sargent. Recorded Tuesday, the 20th of October, 2026. ECDSA's curves origins. Hello and welcome to Security Now. This voice you're hearing is not one of Leo's AI-generated voices. It is, as far as you can tell, the voice of Micah Sargent. That's me, and I'm filling in for Leo this week on Security Now.

Mikah Sargent [00:01:18]:
This is, of course, the show where world-renowned security expert, Steve T. Gibson gives us the lowdown, the uptake, and the in-between on all things security. How are you?

Steve Gibson [00:01:32]:
So this is the first of what, is 3 or 4 of these? At

Mikah Sargent [00:01:36]:
least 3, yeah.

Steve Gibson [00:01:38]:
Yeah. Well, cool. I'll

Mikah Sargent [00:01:39]:
have to check their calendar because, you know, with all the flooding that's been going on over there, they couldn't exactly—

Steve Gibson [00:01:45]:
And Leo was concerned about, like, yeah, like, I think the hotel where they had some reservations they have actually different kinds of reservations about being able to, uh, uh, have, have their stay there. Anyway, uh, this is— we, uh, uh, last week, or I guess the week before— oh no, last week was 1,100. We crossed into, uh, 1,000— episode 1,100. I've— it's bugged me that I've always been a little bit behind the big Twit podcast. I don't think there's any hope of catching up, but, uh, so— You know, because we're staying at the same distance. Yeah, you're like neck and neck.

Mikah Sargent [00:02:25]:
If there was some way, if I could figure out a way, Steve, for you, I would.

Steve Gibson [00:02:29]:
Anyway, episode 1101 today for, uh, this October 20th, um, and a bunch of interesting stuff to talk about. We've got to follow up on last week's Patch Tuesday because This one smashed. Smashed, I think, is fair. Another record which was smashed last month, uh, this one even more so. The good news is less downstream, uh, uh, consequences. Uh, last month's, uh, more than 1,000 patches resulted in a lot of breakage of things that worked before you applied the patches. And so Microsoft did a bunch of backpedaling and, and workarounds and things. And in fact, this Tuesday, uh, last Tuesday of a week ago, uh, this Wednesday's Patch Tuesday, uh, also served to finally provide some permanent fixes to the things they broke.

Steve Gibson [00:03:33]:
This one didn't break so much, but boy did it have a number. Uh, so we're going to talk about that. Um, Also, Palo Alto Networks, Unit 42. And I should say right up front, because I'll be talking about Palo Alto Networks at various points during this podcast, is a sponsor of the TWiT Network. So keep that in mind. They've got— and I love that their cybersecurity unit is Unit 42, of course.

Mikah Sargent [00:04:04]:
Oh, very clever.

Steve Gibson [00:04:05]:
the answer to everything. Uh, uh, they provide a really interesting report on an agentic attack on an unnamed enterprise. Uh, you know, their identity is just being kept on the QT for the sake of the enterprise's, uh, integrity. Uh, we learn a lot from what they share. And It moves my own needle of expectations for the future, which is what we'll get to talking about here toward the end. Uh, there was also, uh, a really interesting and actually frightening large hardware hack of physical cryptocurrency wallets, which resulted in a lot of loss of money by those who were using it. Um, we got some— we have some interesting takeaways from that also. In fact, one of them will be what to do to create your own known safe crypto hardware wallet if you want one.

Steve Gibson [00:05:14]:
Uh, I'm going to share some, uh, feedback from a listener, and then I want to talk about— and, and this feeds back into this Unit 42, uh, Palo Alto Networks attack about this— some other news that Anthropic shared with the industry last week where they were able to get an unreleased model of Claude to reverse engineer and determine the never-before-known origin of some crypto parameters which the industry standardized on without knowing where they came from, beyond knowing that the NSA gave them to us. And there was already reason to be suspicious because there's— there was another instance that we talked about on the podcast many years ago, uh, regarding a, a sort of off-the-map— why would you choose to use this random bit generator, which the NSA reportedly, reported by Reuters, paid RSA $10 million to make their default. So, okay, anyway, uh, I think a bunch of interesting stuff, but the, the, the point of that last story about this reverse engineering is, is I need to share with everybody what this Anthropic AI agentic thing did in order to solve this long-standing problem which has stumped everyone, because it suggests that we're probably in for more trouble with— when the bad guys get a hold of this kind of power than, than I've been suggesting. until now. So I think a really good, interesting podcast for everybody. Absolutely. And after we take a break, we're gonna— we have a great picture of the week. So I gave this picture, which was provided by one of our listeners, the caption, it's not only AI that takes instructions literally.

Steve Gibson [00:07:32]:
Anyway, what we're seeing on screen— thank you, Benito— Uh, uh, for those who aren't looking at the video, there was, uh, some sort of a utility box, big utility box stuck on the side of a, of a crosswalk pole. Um, and in small print in the middle, it says post no signs, which would be pretty clear. However, somebody thought, okay, uh, they printed the word no in quotes in, in very large, in 3 3 different fonts, uh, creating 4 signs and stuck them all over this thing. So in fact, they followed the rules, right? Or the, the, the command. They posted no signs.

Mikah Sargent [00:08:23]:
Oh, I love it. Post no signs. And I mean, it checks out, I gotta say.

Steve Gibson [00:08:29]:
And imagine encountering that. I think that'd just be so cool to be walking along and to see that thing and be initially puzzled. It's like, uh, what? And then go, okay.

Mikah Sargent [00:08:38]:
Then you look closer, you go, oh, clever. Very clever. Good stuff.

Steve Gibson [00:08:46]:
Okay, so as our listeners know, uh, I believe that the rate of security vulnerability discovery and patching is destined to first accelerate, uh, as we've all been witnessing, uh, but then to inevitably decelerate as that legacy of vulnerability debt is increasingly paid down. You know, even Microsoft cannot possibly be creating new vulnerabilities at the rate they're now able to find and eliminate them, thanks to their M-Dash, uh, agentic AI system, which they've been applying to great effect. Um, so without access to what's actually going on inside Microsoft, we have no way of judging, like, you know, where they are along this process, uh, when, you know, when they're gonna hit, like, that point of peak patches, um, where we will then begin to see the rate drop off. I sort of thought maybe after last month's 11— well, more than 1,000 patches, it's like, okay. And that, that was— that followed several months of, like, 400 I remember well earlier in this podcast when, you know, 25 would have been like a— like, okay, well, we got— we fixed 25 problems this month. It's like, okay, um, maybe 47 would have been a biggie. Well, okay, we've of course blown all of that away. Bleeping Computer places this October month's Microsoft update count at an astonishing 1,411 problems.

Mikah Sargent [00:10:36]:
Wow.

Steve Gibson [00:10:37]:
Now, there's a little variation. I saw 1,417 or 1,414, depending on who, you know, I mean, the problem is when there's so many, you lose count. I mean, it's like, you know, what qualifies? What does— there's a little bit of a gray area, but still, you know, way more than we had last month. And last month was a lot. So anyway, uh, before we, you know, I, I do want to say bravo to Microsoft, right? I want to go on record again with a loud praise. You know, they finally have the tools in this M-DASH to enable them to clean up their massive base of legacy code. You know, until now, they've been at the mercy of attackers like Nightmare Eclipse, who we've talked about all through the big— the early part of this year, who were individually able to invest the time and resources needed to scour Microsoft's code looking for individual exploitable vulnerabilities and then develop an exploit for them. And yeah, Microsoft would fix any problems that were discovered and shown to them, um, you know, which is what led in the old days to those 25 or, you know, or 47 patches.

Steve Gibson [00:12:02]:
But Microsoft's massively agentic M-DASH system has allowed them finally to go on the offensive, and boy have they ever. As we saw last month, with its, uh, mistakes that were also made. Fixing more than 1,000 flaws can itself introduce new bugs, but even those tend to be short-lived, right? I mean, they immediately raise alarms. People say, hey, you broke this, or you broke that, and then they work— they come up with a workaround or whatever. So, um, certainly the overall result is a significantly more secure operating system and related software, everything from Microsoft, than we've had before. Um, and if that's true, if getting rid of these vulnerabilities makes things better, then boy, did Microsoft software get a lot more secure this month. Last week, Bleeping Computer wrote the following. They said, Microsoft's October 26th Patch Tuesday security updates addressed a record-breaking 1,411 flaws, including one actively exploited and 2 publicly disclosed zero days.

Steve Gibson [00:13:24]:
Patch Tuesday addressed 70 critical vulnerabilities, 57 of which are remote code execution. 11 of the other criticals were elevation of privilege, and 2 were spoofing. So if you— if we break down the vulnerabilities by category, there were the greatest number overall, 677 were elevation of privilege vulnerabilities. And although, as we've talked about before, those don't seem as, like, horrifying as remote code execution, because who wants to have your computer executing code that some cretin, you know, managed to sneak into it? Still, elevation of privilege matters because the way Windows, uh, security hierarchy is set up, most users do not run with admin privileges. And if something happens in your computer while you're logged in because of something you do, the, the bad guys have code running with your privilege, meaning restricted, not root, not admin. So elevating that privilege to, to full access in order to do much more devastating permanent damage is crucial. 677 Problems were found and fixed just last Tuesday that allowed exactly that.

Mikah Sargent [00:14:58]:
Can you imagine the sound, the collective sound of winces that the— that I can't imagine being one of these folks seeing these and going, that's been in there for the past 15 years, and we have to hope that no one exploited it. And, uh, boy howdy, how did we miss that? And I can't imagine.

Steve Gibson [00:15:20]:
Yes, and, and, and it's funny too because from Microsoft's standpoint, while fixing 1,411 flaws, they're acknowledging 1,411 flaws on top of the more than 1,000 last week or last, last month. It's like, so, so that, that's why I want to be so clear. that it's like, go Microsoft, don't be shy. You know, just, just like we, we, you know, the, the license agreement already holds them harmless, right? It's like, well, if you don't like Windows, you can send it back. But, you know, if, you know, you're using it and taking all the risk for doing so, uh, because we just sort of tried, you know, and did as good a job as we could.

Mikah Sargent [00:16:10]:
Yeah.

Steve Gibson [00:16:11]:
It's like, so, so it's not like they're liable For any of these problems there. And the fact that they're getting it better— what, what I really love, because I have not yet seen any compelling reason to go to 11, I, I'm, I'm happily, you know, putting 10 wherever I am, I'm setting up a new machine because of the fact that such— so much of the world wants to use Windows 10, does not want to go to 11, or has older hardware that won't run 11. They're stuck at 10. But Microsoft, even though they've formally discontinued support, they keep adding a year and a year and a year to it. What I love is that 10 is being really well fixed as a consequence of all this. I mean, these are—

Mikah Sargent [00:16:55]:
That's fantastic.

Steve Gibson [00:16:57]:
And because they've moved on to 11, they're not screwing it up anymore. They're only fixing it, which— so by the time they finally stop patching, 10, and we know we have another whole year, right? They, as we were approaching this October, this month, they said the month before, uh, we've decided we're going to give you another year. Great, because, you know, we're going to see this curve of vulnerability fixings finally dropping. Maybe it'll be next month, maybe it'll be the month after, we're not sure when, but it's gonna happen where they're gonna start running out of them. Because, you know, there has to be an end. And 10 will get all of the benefit of that and none of the liability of any of Microsoft's new crap. So it's wonderful. I mean, it's just a win for Windows 10.

Steve Gibson [00:17:50]:
Anyway, as I said, 677 elevation of privilege. The second most occurring class of problems they fixed was 317 remote code execution vulnerabilities. In other words, they fixed last week 317 different ways that bad guys could run code in your computer without you wanting them to, which is like, as you said, you know, it's, it's bracing to think that there, until last Tuesday, there were 317 ways To do that. Yikes.

Mikah Sargent [00:18:30]:
Yeah.

Steve Gibson [00:18:30]:
So yeah, 254 information disclosure vulnerabilities, 73 denial of service, which mostly just now, that's what we call it when you're able to crash something because you deny everybody else its service because you crashed it. So 73 ways, you know, like to crash the DNS server or whatever. 40 security feature bypass vulnerabilities, which has always seemed sort of nebulous to me. It's like, well, okay, that's kind of like everything, right? Security feature bypass. And then 28 spoofing vulnerabilities. Anyway, Bleeping Computer said that, uh, they, they said when, when, uh, we report on Patch Tuesday security updates, we only count vulnerabilities released by Microsoft on Patch Tuesday itself. In other words, There were more. They said, therefore, today's total excludes 348 flaws fixed earlier this month, including vulnerabilities in Azure API Center, Azure App Service, Azure Event Grid, Azure SRE Agent, Mariner, Microsoft Bookings, Microsoft Dataverse, Microsoft Exchange Server, and Microsoft Partner Center.

Steve Gibson [00:19:46]:
So, and normally you, you would see things like Exchange Server fixed on Patch Tuesday. The fact that they did it sooner probably means it was really bad and they couldn't figure they could even wait until Patch Tuesday when they— on the other hand, it would have bumped the count up. And so maybe they were thinking, okay, we only— we can't do more than 1,411 all, all in one sweep. So they said, uh, Bleeping Computer said this is a record-breaking No kidding. Microsoft Patch Tuesday, as Microsoft continues to use artificial intelligence platforms to find and remediate security vulnerabilities in its products. Microsoft also said, quote, today, October 13th, 2026, Windows 11 version 24H2 Home and Pro and Windows 10 Enterprise LTSB, that's, you know, the long-term servicing branch, 2016 have reached the end of their updates. Of course, that doesn't mean they're going to stop updating them because they can't. The October 2026 monthly security update is the last update available for these editions.

Steve Gibson [00:20:52]:
However, you know, they're still updating Windows 10, so they're clearly going to give you that. You know, it's not in the normal standard Microsoft patch routine. It's in the extended services. mode, which is what they keep deciding to extend every time it gets close to ending. They add a year to it because, you know, so much of the world is still using Windows 10. Well, obviously a lot of the world is using Windows 11 version 24H2. So it's not like they're going to cut that off either, especially when they're fixing thousands of problems every month. So Bleeping Computer said earlier this month, Microsoft also said organizations running Windows 11 23H2 Enterprise Education, and IoT Enterprise editions should upgrade to newer versions as they'll no longer receive security updates after next month.

Steve Gibson [00:21:44]:
And yeah, why not have— why not update to the— unless you for some reason can't update to the latest, uh, Windows 11, uh, yeah, why wouldn't you? They said this month's Patch Tuesday fixes one actively exploited and two publicly disclosed zero-day vulnerabilities. And they noted that Microsoft classifies zero-day flaws a little differently than rest of the world. They call them, you know, we call them when they are caught being used on some software. We call that a zero-day because it's really a surprise. Microsoft classifies, they write, zero-day flaw as publicly disclosed or actively exploited. So in other words, you don't have to, you don't even have to be using it. If someone mentions it in public, it's like, oh, that's a zero-day because it surprised them. So they said the actively exploited zero-day vulnerabilities addressed during this October 26th Patch Tuesday are, and there are 3 of them.

Steve Gibson [00:22:47]:
There's a Windows shell security feature bypass vulnerability. I'm not going to go into the details. There's a .NET Framework security feature bypass vulnerability and a message pack C# denial of service vulnerability. Um, and they finished by saying, with this month's record-breaking number of vulnerabilities, Microsoft has also introduced a new method for organizations— I thought this was interesting— to prioritize security updates by grouping related flaws into what Microsoft calls risk cohorts. For the brand new idea, for the first time this month, they said this new approach groups similar vulnerabilities together to help organizations better understand which security flaws pose the greatest risk to their systems and should be prioritized for patching. So I think this is a welcome, and actually it's an understandable response. and surprisingly quick to last month's self-inflicted Windows update carnage, which, as we covered last, you know, 4 episodes ago, the week after Patch Tuesday, it seriously impacted many enterprises in many instances for many days. So, you know, this new concept of these risk cohorts is a welcome addition.

Steve Gibson [00:24:23]:
And especially when an enterprise now is, you know, facing an astonishing number of updates. 317 of the 1,411 allowed for remote code execution. So we know that the bad guys examine both the before and after patched code to locate the changes that Microsoft made as a means of attacking those who are slow to update. So reorganizing the massive patch collection, which we're now being, you know, is being dumped every month into a collection of so-called risk cohorts, will potentially at least allow concerned enterprises to verify the safety of the most, of the more serious problems first. Safety as in is it safe for us to apply these in our enterprise, um, and get those pushed out to their enterprise's workstations? Um, Bleeping Computer did, uh, break this down. They said for October 26th, Microsoft— October 2026, Microsoft published 15 risk cohorts overall, and then they listed just 5. They said including 136 vulnerabilities which affected Windows file systems, storage, and backup; 135 vulnerabilities involving Office documents and mail clients; 131 vulnerabilities affecting Windows graphics, media, and content processing; 109 vulnerabilities involving Windows core and kernel privilege boundaries; and 103 vulnerabilities infecting Windows installation, deployment, and update services. And as I think about this again, looking at these, it feels like they've divided them sort of like departmentally.

Steve Gibson [00:26:20]:
Yeah. Like, like there will be some group of people in the enterprise who would take those 136 vulnerabilities affecting Windows file system storage and backup and, and check those because that's sort of their bailiwick. You know, they're those people. Because, for example, then we have the 135 involving Office documents and mail clients. Well, that might be a different group in a large enterprise that is like in charge of, you know, the Microsoft Office stuff. So by segregating them that way, it does allow, you know, it divides this huge number of vulnerabilities into groups by, by focus group, essentially. You know, who would, who would generally handle making sure that, you know, we haven't broken something in the installation, deployment, and update services, you know, where 103 vulnerabilities were just patched? So anyway, Bleeping Computer says that Microsoft stressed that these groups do not necessarily indicate which flaws are the most dangerous, right? As the actual risk depends on whether they're being exploited in attacks, their severity, and how an organization uses the affected software. Microsoft says the new approach is still experimental and is meant to help organizations— they see, they say prioritize.

Steve Gibson [00:27:52]:
This doesn't feel like priority to me. It feels like, you know, segregate for department, you know, different departments to handle them if that's their expertise.

Mikah Sargent [00:28:04]:
Yeah. Delegated.

Steve Gibson [00:28:07]:
Right, right.

Mikah Sargent [00:28:08]:
Yeah.

Steve Gibson [00:28:08]:
So anyway, that's where Microsoft stands. Are we still accelerating? Are we going to have more next month?

Mikah Sargent [00:28:17]:
Even more?

Steve Gibson [00:28:20]:
Will November— yes, right— see an even higher count? Or was this month the month that we peaked and we will now see What will probably be— my guess is when we hit the peak, we're going to see a sharp drop-off as the pool of unpatched vulnerabilities dries up. I'm on record. We'll see if I'm right or not. So, but what's equally exciting to me is the idea that all future Microsoft software will now be able to be pre-screened by that same M-AI which is fixing the legacy code, you know, they'll be— they should be able to pre-screen anything before it's ever released. In other words, there's the real potential for Microsoft systems to be truly secure for the first time ever, and for vulnerability discovery, exploitation, and post-release patching to become an historical artifact, like where, you know, when I was a boy, you know, it's like, because there just aren't these problems anymore because AI cleans them up even before they get out the door in the first place. And wouldn't that be something? Um, for what it's worth, Microsoft is not alone. Um, an increasing number of companies, as we've noted previously, have been synchronizing their own software updates with Microsoft's Patch Tuesday. I don't know if it's like to hide behind Microsoft or what.

Steve Gibson [00:29:55]:
You know, it's like, oh, well, Adobe did this and so forth and Cisco did that. But that's been growing more and more popular. Bleeping Computer also noted that the recent updates from other enterprises who also appear to be employing AI for their own preemptive defense, yay, I mean, we need that to happen. We know that Cisco is. Last week we covered, or a week or two ago, we covered Cisco's massive patching binge, which again, props to Cisco. Thank you for fixing all this. They apparently sorted this alphabetically, Bleeping Computer did, saying other vendors who released updates or advisories in October 2026 include... We've got Adobe, uh, you know, the A-word, released security updates for numerous products including Commerce, Substance, 3D Samples, ColdFusion, Photoshop, Dimension, and Framework.

Steve Gibson [00:30:53]:
Atlassian released security updates for critical vulnerability in multiple self-hosted data center products including Confluence, Jira, and Bitbucket. Attackers soon exploited the flaw After a proof of concept was released, that was the fix for the critical vulnerability in Atlassian. Cisco released security updates for numerous products, including critical vulnerabilities in its NX-OS data center network operating system that can let attackers run arbitrary code with root privileges on Nexus switches. Citrix released security updates. I'm not going to go through them in the same level of detail. Dell was there. Docker patched a critical flaw on Docker Hub. Fortinet released security updates for numerous products.

Steve Gibson [00:31:39]:
GitLab released security updates for critical flaws in its AI gateway and CI/CD regular expression compiler. Avanti is there with updates. KiteWorks security updates for 126 vulnerabilities. There, you know, AI's on the case there. Progress Software released security updates for critical and high-security vulnerabilities. SAP released the October security updates addressing 20 security flaws. And SonicWall released security updates for a critical SMA-1000 server-side request forgery, an SSRF flaw. So anyway, we're seeing industry-wide repair of legacy code.

Steve Gibson [00:32:24]:
which, you know, it is so welcome and necessary since we already know, and I'll be sharing another example of it shortly, that the attack capabilities now being brought by AI, not tomorrow, but it's already here, are being used to increase the strength of attacks. So, go.

Mikah Sargent [00:32:48]:
Did you see that, uh, I think it was Anthropic who Just recently, and now I'm trying to find it because I'm hoping it's not something that I read that ended up not being true, but I thought I saw something about Anthropic working on a tool that was for cybersecurity where you could run its cybersecurity model against your own code in a way that— did you talk about that already? Yeah, that tested it for the model? Got it.

Steve Gibson [00:33:18]:
Yes. We, uh, we covered it last— we covered it last week.

Mikah Sargent [00:33:22]:
Understood.

Steve Gibson [00:33:22]:
Um, the, the release was that they formally agreed— they, they, they formally said they would be, they would be, uh, running open-source software projects that had opted in and that were large enough to make an impact if they had vulnerabilities at no charge. They would be— that they would be scanning and keeping an eye on any open-source projects that wanted to opt into that. So, so yeah, it's, I mean, and that's great because, you know, we know that the enterprise is able to afford AI. And this is what we just, we're seeing all these enterprises obviously spending now on, on AI vulnerability discovery. And the result is You know, much greatly increased rate of patching. So, so that side is covered. And also notice that the enterprise is the one that has their own software, their own source code. It's not open, so it isn't nearly as easy to fix it.

Steve Gibson [00:34:27]:
Not technically impossible, but still, you really need the source in order to fix the software. Enterprises are closed source, but they've also got the money. open-source projects, you know, the source is open for everyone, but they don't— they typically are underfunded or not funded. You know, it's all volunteer effort. So the idea that we're seeing them step up to the, you know, step up and recognize that AI Uh, in fact, it was the week before last week we talked about, um, them also, uh, doing a piece which noted that GLM-53 from ZAI was now just about equal to the Frontier in its ability to find problems. And being open weight, it could be obliterated And so you would remove all of its ability to say no. So, you know, so then the week after, which is last week, uh, we talked about how, how they had then— and, and Anthropic then decided, okay, because the bad guys do have access to open-weight models that are almost as good as ours, we're gonna give free access to the open-source community for big projects that matter To, you know, when they don't have the money to fund AI, you know, we do. So I think that was a really good move.

Steve Gibson [00:36:10]:
So far, despite its record-breaking 1,411 updates, the industry has not experienced what I would call an October surprise. of update consequences like we did encounter last month after the more than 1,000 updates. October's updates, as I mentioned earlier, also finally repaired a number of things that September broke. So it's been nice to see that we don't necessarily always have dire consequences following a mega patch update cycle, even though this was even more mega than the last mega one. was. I don't know how they made it differently. Maybe they tightened up their pre-release testing, having learned an expensive lesson. I mean, it was a black eye that so many enterprises were significantly impacted by installing September's updates.

Steve Gibson [00:37:14]:
And, you know, look at the pressure that enterprises were under to get them installed quickly because there were so many that that were so bad. And now everyone knows the bad guys, you know, are much better at exploiting these problems. So, you know, time really is of the essence. And in fact, the week before Microsoft released this, the September batch, they said, get ready, we're going to— we have a big September coming and a lot of these things are really bad and you can't wait to patch them. So enterprises didn't and then got hurt by not waiting. So, so far, you know, we're only a, you know, a week downstream from last Tuesday's, but we're not seeing nearly the same level of trouble. Microsoft did, however, note that some users may have trouble. This is the only one thing that I was able to find.

Steve Gibson [00:38:10]:
May have trouble turning on Smart App Control. After installing this October's patches for Windows 11's security update. Bleeping Computer covered that, writing, Smart App Control is a Windows 11 security feature that uses Microsoft's app intelligence services and code integrity features and works alongside Microsoft Defender and SmartScreen to block potentially harmful apps or binaries. You know, so So basically, it's preventing you from running something that, that you're— that could damage your— you or your, uh, system. So they— so Bleeping said, according to the company Microsoft, on affected devices running Windows 11 version 24H2 and later, the Smart App Control option is grayed out and cannot be changed, Microsoft said in an update to their— and it's the, the, the patch for Windows 11 security features, KB5127648 advisory. They said after installing this update, some devices might be unable to turn on Smart App Control in the Windows Security app if it has been turned off. On affected devices, the option to turn on Smart App Control might be grayed out. Devices where Smart App Control is already turned on are not affected and remain protected.

Steve Gibson [00:39:37]:
So big deal, you know, if that's all they broke while patching 1400 and 11 vulnerabilities.

Mikah Sargent [00:39:45]:
Yeah, exactly.

Steve Gibson [00:39:45]:
The trade-off there. Yeah, I'd call this month's Patch Tuesday a huge success. And it sounds like a trivial UI problem and really nothing to worry about. Microsoft did, however, offer a workaround. Which involves a couple registry tweaks. You need to run, you need to run regedit as an— or run a command prompt as an admin rights, and then, you know, basically set 2 keys in the registry, which essentially does the same thing that the UI would have— that the UI, you know, click the button, would have done. So It's certainly possible if you, for some reason, you have to turn that on even though you had it off before and October broke the ability to turn it on. Well, if you have to have it on, you can.

Steve Gibson [00:40:38]:
There is a workaround and obviously it'll get fixed next month. I don't think there's any great emergency, uh, to, you know, making that happen soon. Okay, next I'm going to talk about this, uh, Palo Alto Networks Sponsor of TWiT, Unit 42 investigation. But let's take a break so I can rehydrate and we'll hear from Leo.

Mikah Sargent [00:41:01]:
All right, back from the break. As I mentioned, Micah Sargent subbing in today for Leo, and it's time to go 42.

Steve Gibson [00:41:13]:
Okay, so I mentioned another example of AI-enhanced attacks. Last month, Palo Alto Networks Unit 42 published their findings from their investigation into an AI-assisted attack, and their report contains a bunch of useful takeaways which can be readily generalized. So here's what they reported, and then we'll talk about what it means. They said Unit 42 responded to an incident where a human attacker used Frontier AI to breach an enterprise network autonomously as part of a ransom attack. The agents breached the company's security layers in a methodical manner, with each agent targeting a different layer of defense to achieve their shared goal. The impact was at the scale of a coordinated effort from multiple red teams which would normally take human operators around 2 weeks. The threat actor told us in negotiations that they leveraged frontier AI models and attack-specific agentic AI frameworks. By shifting execution to an automated loop, the attacker compressed weeks of methodical intrusion tradecraft using more than 50 MITRE ATT&CK techniques into fewer than 10 hours.

Steve Gibson [00:42:43]:
After they gained initial access, the attacker used agents to map the internal architecture, raid source code repositories, and seize root credentials. The agents also triggered unauthorized continuous integration, continuous delivery, you know, CI/CD builds, and claimed master keys to the victim's cloud AI infrastructure. Oh, and get this, they said what made the attack stand out was AI-assisted operational efficiency without the need for a novel zero-day or super elite tradecraft. The attacker left all tactical execution to AI agents that monitored evaluated, acted, and replanned in real time, increasing the speed throughout the attack chain. And yeah, the attacker also directed its agents to leave behind a report on the organization's security posture, an 80-page— 8-0 page—

Mikah Sargent [00:43:56]:
Wow.

Steve Gibson [00:43:57]:
Technical audit detailing dozens of exploited findings. In other words, it, it ransacked the enterprise. It exfiltrated all of the company's crucial, critical, must-keep-it-private data, which it would then use to, to, to extort the company for a ransom. and left behind thoughtfully an 80-page audit of everything it found wrong that it used in order to perpetrate its crime.

Mikah Sargent [00:44:34]:
Well, that's nice. I mean, yeah, how kind.

Steve Gibson [00:44:39]:
Oh,

Mikah Sargent [00:44:40]:
I wonder what— like, I wonder where and what resulted in it making that choice, you know what I mean? What, what would result in, uh, a sort of vigilante—

Steve Gibson [00:44:52]:
well,

Mikah Sargent [00:44:52]:
uh, oh, you're good. We're gonna get to it.

Steve Gibson [00:44:54]:
Well, no, my guess is that, that this is what we've seen. This is the way agents work, right, is they build their own dossier of findings as they're going through. They like leave breadcrumbs behind for other agents to then read and, and, and pick up the thread or go in a different direction. Got it. So they— so this was probably being built for their own purposes as they were finding flaws and exploring avenues and pathways. And then they thought, well, what the hell? Let's format this into a formal technical audit of all the problems that we found and exploited, just sort of to give them a little, I don't know, goodbye bonus.

Mikah Sargent [00:45:44]:
It's almost from our perspective, from the human perspective, there's a little bit of a— it's kind of a brag, honestly. It's like if somebody's leaving their, their little calling card behind, my calling card is just, here's where you failed. Wow, that's funny. I mean, not funny, but funny.

Steve Gibson [00:46:06]:
So Palo Alto said the adversary ran their operation using current AI-enabled software development processes. They said we observed 3 indicators consistent with AI usage. First, large language model calls to multiple frontier AI agents in parallel. Structured markdown files— oh, here's what I was talking about— passing information between agents and sessions. So they use those, and then I would imagine they ended up digesting that into that 80-page report. And then third, custom scripts assessed with high confidence to be AI-generated due to UI elements, which— and those custom scripts were managing the dynamic operations. They said the 10-hour operational timeline included infiltration and mapping. The actor breached a publicly accessible web service.

Steve Gibson [00:47:07]:
So there was a— so that's— that was their way in, whatever this entity was, and we still don't know. They had a web service, you know, internet-facing. So infiltration and mapping. The actor breached a publicly accessible web service to tunnel into the network, deploying an automated recon agent to map internal microservices. Then secrets harvesting. Subagents combed enterprise code repositories extracting hardcoded tokens and service passwords. And okay, as I'm reading this, I'm hoping that, you know, CISOs are getting a little chill.

Mikah Sargent [00:47:55]:
Yeah, exactly.

Steve Gibson [00:47:56]:
Because they're feeling a little chill. The idea of what is in the process of being turned loose on a world that is not ready for it. Which is really the, the theme and the conclusion that I'll be reaching during this podcast. I mean, it is something. Then privilege takeover, they said. Using exposed tokens, the actor infiltrated the secrets management system, harvesting master administrative credentials to seize control of root system access. Then pipeline exploitation. The actor hijacked an enterprise code application via custom workflows to exfiltrate cloud access keys.

Steve Gibson [00:48:46]:
They attempted to plant backdoors in Terraform configurations, but hard branch protection controls stopped it. And then get low— get a load of this one, Micah. AI Infrastructure hijacking. Using stolen cloud keys, the actor turned the victim's AI endpoints into post-compromise infrastructure using the company's own compute— AI compute power to perpetrate further moves. Oh,

Mikah Sargent [00:49:22]:
my goodness.

Steve Gibson [00:49:23]:
So they hijacked their own— the company's own AI.

Mikah Sargent [00:49:28]:
That's horrifying. That what you said, if the chills weren't already happening, they'd better be happening now. That gave me chills. I'm, oh, that's, that's, that's terrible. I mean, that's a, that is like a true virus, right? Like, what do you think of a biological virus going in and reprogramming our own cells? That is wild.

Steve Gibson [00:49:51]:
So the attack, the attacker's AI having obtained the keys to the victim's cloud AI, used that victim's own AI against them to facilitate additional post-compromise work. Um, yikes. Um, their report, Unit 42's report, included an infographic which I have included in the show notes. It observes that the human orchestrator set the objectives and directed the agents. They reviewed the results and prioritized next steps and directed follow-up activity as the attack progressed. But all of the actual work was done by these agents. Palo Alto Networks Unit 42 then summarized what they learned from their analysis. So here's what they said.

Steve Gibson [00:50:43]:
Key lessons learned from addressing agentic attacks. This incident exposes how an attacker who understands how to deploy frontier AI agents effectively can dramatically speed up the pace of their attack. Remember that they, they said, if multiple red teams, human red, multiple human red teams had been employed, Mm-hmm. They're guessing this would take 2 weeks of concerted effort by, by human attackers trying to get in and, and do damage. This took 10 hours. So it, it, you know, like overnight, essentially, while after everyone's gone home and they come back the next morning and this is done. They said, we assess that attackers will increasingly add— attackers will increasingly add AI agents to their tool sets. Organizations should take note of the following to address agentic attacks.

Steve Gibson [00:51:55]:
They said AI agents reduce the time between steps in the attack flow. AI agents in this attack were designed to parse raw tool output and quickly take next steps, speeding up the overall attack flow. AI agents leave recognizable indicators. They said defenders can identify agentic attacks by watching for indicators such as the use of structured markdown, Python caches, and paired asset folders. They said attackers can use AI to establish redundant persistence across the environment. They said in this instant— this incident, the attackers used AI agents to effectively establish overlapping persistence across SSH keys, serverless functions, container restart policies, cloud identities, and CI/CD pipelines. Using AI agents can make it easier for an attacker to maintain and test this entire portfolio in parallel. And finally, attackers can use an organization's AI tools.

Steve Gibson [00:53:09]:
This is that final part. An org— an attacker can use an organization's AI tools as post-compromise infrastructure. Attackers can hijack enterprise AI services to assist in their attacks. This allows threat actors to hide orchestration traffic among expected traffic and offload the financial cost onto the victim. In other words, they get the victim to pay the cost of the AI's use, and because it's internal enterprise traffic, that's the point about hiding the orchestration. You're not having to orchestrate from outside the enterprise. where you would see traffic crossing the enterprise's boundary, that's now you're orchestrating internally, endogenously, essentially. So they said, what about specific defenses? They write, defending against automated agentic loops requires matching the speed and adaptability of AI-driven attacks.

Steve Gibson [00:54:20]:
They said execute synchronized containment, deploy automated playbooks that simultaneously revoke credentials, terminate OAuth sessions, freeze CI/CD pipelines, and isolate cloud accounts across all operational planes. Govern AI, they said, as core infrastructure. Inventory every model endpoint, API key, model context protocol, you know, MCP gateway, and AI tool integration. Apply strict rate limits, least privilege policies, and diagnostic logging. Detect behavioral loops. Hunt for operational loops including bursty API requests, rapid 401 to 200 HTTP state shifts, meaning something is trying things that don't exist and then succeed. Meaning something was guessing URLs until it finally got the right one. They said parallel authentications and sudden model usage from unexpected identities and lock down DevOps pipelines, enforce mandatory multi-party code reviews and immutable branch protection on all infrastructure as code.

Steve Gibson [00:55:44]:
Repos to block automated backdoor injection. Okay, so stepping back from that itemization, basically it's saying lock the F down. I mean, like, really, just, just like, like, those are all kind of like common sense things. And you can imagine that it'd be like, like a wish list. It's like, well, yeah, we'd love to do that,

Mikah Sargent [00:56:09]:
right?

Steve Gibson [00:56:10]:
But Who has the time? It'll inconvenience our developers. It'll mean, you know, multi-party code review. Well, that's going to slow down the reviews if we have to have multiple parties all weigh in. Well, yes, that's the idea, except it's also an inconvenience. So what's really the case is nobody is doing all these things today. That's not in place. Because it is, it, it really does get in the way. So, you know, I'm not in charge, thank God, of the security of any large enterprise.

Steve Gibson [00:56:49]:
Uh, and, uh, you know, I'm glad, I'm more glad for that than I've ever been because this feels daunting.

Mikah Sargent [00:56:57]:
Yeah.

Steve Gibson [00:56:58]:
You know, we, we, it, we focus a lot on Coding errors that lead to vulnerabilities because they are concrete, they're understandable, and they're actionable. There's a bug. We found it. It could be exploited. Let's patch it. It is gone. So, you know, case closed. But the reason I'm becoming increasingly uncomfortable about the capabilities we're seeing emerging from these new, and they are new, agentic attacks is that they are far less dependent upon the presence of explicit bugs than they are upon a general systemic laxity of absolute organizational and network security.

Steve Gibson [00:57:54]:
The description of this particular incident reveals the sort of environment that likely exists within most, if not every, organization. You know, it's just natural, and we're just human after all. You know, over time, with the changing of the guard, projects get abandoned, old code or test credentials get left behind in long-forgotten directories. They, you know, there's debris accumulated, trails of breadcrumbs accumulate everywhere, you know, with this or that permissive firewall rule left in place after the need for it has expired or ended, you know, with an ex-employee's credentials left active, and who knows what else. It's nothing overtly bad or glaring, just the inevitable consequence of people who are in a hurry, who have better things to do than always without fail rigidly enforcing every, you know, policy that was once upon a time stated. And into an organization like that, into reality, of today, we drop a powerful, goal-oriented, goal-directed, tireless and merciless AI entity that will literally do anything and everything to accomplish its goal. You know, it's capable of inventorying every online asset within the organization, checking version numbers, testing for any patches skipped, scraping the enterprise's website to obtain a roster of public-facing employee names, then digging into their public personas to obtain any detail about them that might hint at their password credentials. It would rifle through any source code that it was able to find.

Steve Gibson [01:00:08]:
And in this— in the past, in the case that Unit 42 talked about, it did that, um, you know, either internal source or external sourcing for tidbits and hints, anything it might be able to use to further its goal. It would read through everyone's past email, years or decades of it, whatever is available. It would learn of relationships and responsibilities and look for any clues that would allow it to advance its mission. It would learn, you know, like pick up, for example, a helpful reminder Slack password that was once passed between employees through secure internal email. But still in an archive somewhere, then using Slack's search and API would sweep through years of Slack history, soaking up every bit of useful intelligence it could find. We're talking about turning an extremely resourceful, goal-directed berserker loose inside the network of a large enterprise. An enterprise that's never needed before to secure itself against any such threat or intrusion because no such intruder has ever existed before now. This agentic berserker will have already been trained to encompass all published human knowledge, including all known hacking tricks and techniques.

Steve Gibson [01:01:52]:
It's fast, inexhaustible, and clever by virtue of being willing to try everything and anything. October's Patch Tuesday repaired 1,411 new vulnerabilities on top of the more than 1,000 from last month because agentic AI has become that capable. No one wants an unconstrained AI turned loose inside their enterprise. So am I exaggerating or overstating agentic capabilities? Not from everything we've already seen. We've all seen what agents that were deliberately constrained and were not supposed to get loose managed to do. You know, I hesitate to call them clever, but the reports of their actions as they have, you know, as we've seen over and over, they found a way in. Those are surprising and should chill the blood of any CISO. Shortly after this summer's Black Hat conference, The stock prices of CrowdStrike and Palo Alto Networks, 2 companies that specialize in protecting enterprise networks from intrusion, their stock prices moved rapidly upward and have been continuing to climb.

Steve Gibson [01:03:24]:
Why? Because the world's enterprises began to recognize just how very real these agentic AI threats have become. And they're not wrong. Today's main topic that we'll be getting to is the story of how an agentic AI spent just 30 minutes to reverse engineer and discover the original source of the globally standardized curves used by the elliptic curve digital signature algorithm, ECDSA. The origin As I mentioned at the top of the show, of those specific curves, those specific curves, beyond the fact that they came from the NSA, has always remained a mystery. It is a mystery no more until an AI was asked to figure out where they came from. Wow. My point is, the story I'm going to share is truly jaw-dropping. And it's the reason I am beginning to despair over the future security of any large and lumbering old-school enterprise.

Steve Gibson [01:04:39]:
If this is what AI can do, how could anyone be ready for what's coming next? And on that cheery note,

Mikah Sargent [01:04:51]:
yeah,

Steve Gibson [01:04:51]:
let's take another break.

Mikah Sargent [01:04:53]:
I thought, let's let that one sit there for a minute because That's chilling. Oh boy. Oh boy. And it's got to be fighting fire with fire, but the AI versus AI, but it's still like—

Steve Gibson [01:05:08]:
I think that, I mean, I'm serious when I say that I don't think any enterprise is prepared because, you know, you secure your borders, you trust your employees, But they will. Someone will say, hey, what's the password for our something or other Slack channel? And it's like, oh, you know, I'll email it to you. Yeah. So, it's employee to employee, but it now exists in that enterprise's email archive. And when the AI gets in there and reads it all, it's going to go, oh, great. Now I have the Slack password. It's able then to use Slack's API to dump the entire history. And Lord knows what intelligence it's going to find from, from, you know, ad hoc discussions and meeting minutes and notes and everything that the company feels, you know, is internal.

Mikah Sargent [01:06:06]:
Oh, the meeting minutes and notes, because now everyone's using those AI transcription services for every single thing. So now there are multiple places that are capturing your Oh my goodness, I hadn't even considered that aspect of it.

Steve Gibson [01:06:19]:
And remember that AI will tell you what it knows about you. So once it gets a hold of the enterprise's AI infrastructure, it can ask the various AI agents to dump all of their accrued knowledge of the people that use this AI. All of the prompt text can can be retrieved. And so it'll immediately know everything that the enterprise's AI has learned about all of the users of it. Oh, I mean, it is beyond bad.

Mikah Sargent [01:06:57]:
And I mean, I feel that everyone is talking about, or that we hear a lot about people talking about, whoops, this side of things and talking about all of the exploits that are happening and that kind of thing.

Steve Gibson [01:07:10]:
I've been just focused on vulnerabilities. It's like, well, let's get all those fixed. Sorry, that's not going to do the job.

Mikah Sargent [01:07:17]:
Wow. Wow. I hope somebody's thinking about it. I mean, you know, actually actively doing something about it. But what can you do?

Steve Gibson [01:07:27]:
Well, and for example, CrowdStrike and Palo Alto Networks have endpoint security where they put devices in the enterprise that are AI-enabled. which is supposed to be watching the network for signs of this. But, you know, not everybody's going to use them. There are a lot of people who are like, you know, they don't have the budget. It's not free to do that. And so, and they just don't see the need. It's like, hey, everything's been secure so far. Well, there's a storm coming.

Mikah Sargent [01:08:00]:
Yeah. Oh my God. All right. Welcome back. We are, of course, sharing some Cheery news about the future of security in the enterprise and elsewhere, thanks to the wonderful world of AI. Steve, take it away, friend.

Steve Gibson [01:08:20]:
Okay, so the number one takeaway, I think, from the news of what's being called the Ledger Crypto Billis, B-I-L-I-S. CryptoBilis hack is to be excruciatingly careful about the use of any physical hardware crypto wallet. Um, there would be so much pressure when you think about it to plant a backdoor into a hardware crypto wallet, either by an unscrupulous vendor— hopefully there are none, uh, but you know, the world, uh— or after shipping somewhere along the retail supply chain. So much pressure that it's almost impossible to feel comfortable using such a device, um, unless I guess you really have made it yourself. And there are some options for that we will talk about in a second. But, you know, how would anyone ever know one way or the other whether the device they were using was clean? Hmm. So first of all, I fully understand the strong appeal of a dedicated hardware device for storing cryptocurrency secrets, the idea being that, you know, it's mostly disconnected from the outside world, which is You know, what we definitely want, um, until and unless and only when its secrets are needed. The trouble is that there are multiple points of vulnerability, both any device's hardware and its firmware.

Steve Gibson [01:10:08]:
So the provenance of any such device really must be known and trusted. And that brings us to this next story, which BitQuery posted on Friday under the headline, the Ledger Crypto, uh, Billis hack took— get this— $102 million from 35 wallets. They said one thief had all the keys, and their subtitle Was, or their tease, on, on Friday, 9th of October, people who had bought Ledger devices from a seller in Southeast Asia found their crypto gone. They said, we follow every drained wallet on 6 chains to see how the thief worked and where the money sits now. Mm-hmm. So with that, they continued. Writing weeks after setting up a ledger, the money was gone. You buy a ledger and move your savings onto it.

Steve Gibson [01:11:22]:
Weeks later, you open the device. The balance says zero, and you never sent a thing. That's what ledger owners in Indonesia, Malaysia, and the Philippines. Found on Friday the 9th of October. And before I go any further, I should also mention in other news, compromised devices were also found by mainstream German resellers. So it's not just, uh, East Asia. They said Ledger says they had purchased their devices from CryptoBillis, a shop that sells them in the region, which news reports describe as an official reseller. Ledger is a French company that makes hardware wallets, small devices that keep the keys to your crypto away from the internet.

Steve Gibson [01:12:17]:
On the same day, it said it was looking into losses among users in Southeast Asia who bought from CryptoBillis. It asked the reseller to stop all sales told— that is, Ledger did— stop all sales, told recent buyers not to set up their devices, and told anyone who had to consider moving assets to a new Ledger signer using a new seed. By then, they wrote, 2 on-chain researchers had posted the thief's crypto addresses. Uh, Tanuki42 listed 8 of them and Spectre listed 10 with losses exceeding $86 million. So what they're saying is that they, they found, let's see, 8 and 10. So they found there a total of 18 cryptocurrency addresses that had transferred the money from these ledger-based wallets into the bad guys' accounts totaling $86 million. They said BitQuery records, uh, I'm sorry, BitQuery records every transfer on the chains involved. So we followed each drained wallet and each address the money reached.

Steve Gibson [01:13:44]:
Our count is $102 million from 335 wallets on 6 chains. The actual total will be higher because the thief also emptied wallets on Solana, BNB Chain, and Polygon and used 6 Tron addresses that no public list includes. The record points to one actor who held the keys to every one of those 335 wallets. Wow. Yeah,

Mikah Sargent [01:14:20]:
one

Steve Gibson [01:14:20]:
person. Yeah, that person practiced for 2 weeks before the drain, and by the evening was feeding the money into a mixer, a service that hides where coins go. The chain cannot show where the keys leaked from. It can show almost everything else. When you set up a Ledger, it shows you 24 words called the recovery phrase. Those words are the master key to your wallet. Anyone who has them can rebuild the wallet on another device and spend from it on any chain without touching your original Ledger. The device's job is to make sure nobody ever sees those 24 words.

Steve Gibson [01:15:17]:
That's why Ledger tells buyers to buy only from Ledger or an authorized seller, and CryptoBillis was listed as one. A device that arrives opened or with words already printed on a card should never be used. On October 10th, Ledger said one victim's device, quote, contained an unauthorized hardware implant. And, um, I've got further down in the show notes— you might want to put it on the screen— a photo of one of these Ledger devices opened. Uh, it's quite something to look at. Um, uh, they, they said that's the first confirmed cause And it covers one device so far. And what you're looking at there, that little green board is a cellular GSM modem with an eSIM. And you see the little spiral antenna on the left.

Steve Gibson [01:16:19]:
So these things actually used— they use the cellular network in order to export the 24 secret words. Wow. of everyone who used one of these ledgers. Wow. So they, they purchased— the bad guys purchased the original ones, opened them up, and implanted that, that, uh, GSM cellular radio, closed them back up, and then apparently returned them to the seller saying, I changed my mind, uh, I, I want, I want my money back. The seller then Resold them.

Mikah Sargent [01:17:00]:
Oh my God. Are we going to have to open up everything we buy? Should— do you do that? Do you check any tech you buy?

Steve Gibson [01:17:08]:
I don't buy anything. Anyway, so, so they said on October 13th, Ledger Security Lab, Donjon, explained how it works. The implant sits inside the case. And reads the screen. When the device shows the 24 words during its setup, you know, it's got a random number generator in there, and so it generates the 24 words with a high degree of entropy.

Mikah Sargent [01:17:37]:
Mm-hmm.

Steve Gibson [01:17:38]:
The implant, that implanted hardware, decodes them and sends them out over the mobile network through a built-in SIM. It does not touch the secure chip. Or the device's software, and it does not change transactions or signatures. It just, it just sends your, your secret out to the bad guys where they are collected. They wrote, before that, some well-known figures including Binance founder CZ had suggested tampered devices. Hardware wallets have been hit before. as in the cold card wallet theft we traced earlier this year, they wrote. Each case had its own cause.

Steve Gibson [01:18:25]:
What the change does show is what happened once the thief had the keys. In 47 minutes, the thief hit 6 chains in one morning. The first money moved on Tron, a network that many people in Asia use to hold and send USDT. Um, that's, uh, it, it's a form of stablecoin, US, uh, dollar stablecoin. That— oh, it says the digital dollar issued by Tether. Within 47 minutes, the same thief had empty wallet— had emptied wallets on Ethereum, BNB Chain, Polygon, Solana, and Bitcoin. The full Tron record is in BitQuery's Tron data and the Tron history files on the data store. Most of the money left in the first hour.

Steve Gibson [01:19:22]:
Then the drains slowed. The thief kept emptying wallets through the afternoon, including after Ledger's post. At 20:49 UTC, it emptied 9 more in a single block. $8.8 million in all. That was in that— those 9. On the 10th of October, it took $70,000 more from— get this— from a wallet it had already emptied. So some unlucky soul added another $70,000 US dollars worth of money to their wallet whose secret key had already been exfiltrated and had been used to empty their wallet of the money that had been previously put in there. And they added $70,000 more, and then that got taken out too.

Mikah Sargent [01:20:22]:
Oh my God.

Steve Gibson [01:20:25]:
They wrote, on Tron, the thief did not send each wallet's USDT straight out. First, each wallet signed an approval, a short note that lets another address move its USDT. In other words, uh, the, the wallet signed a proxy approval that would give, give movement capabilities to another, uh, address. Then one address used those approvals to pull the money. The record shows 25 wallets signing the same approval for the same address in 2 blocks, 3 seconds apart. Every one of them paid its own small network fee. Within 6 seconds of the first approval, $29 million in USDT had been pulled out, $7 million of it from a single wallet. 11 seconds after the first Tron approval, 2 Ethereum wallets signed the same kind of approval for a different address, and a 3rd followed 12 seconds later.

Steve Gibson [01:21:31]:
I should just note, the reason they're giving us these, these time intervals is that it's— it demonstrates that this entire thing was automated. This is— this was all set up to, to happen by automation so that all the money could get sucked out before any alarms went off. They wrote, on Bitcoin, 111 wallets were emptied in a single block at 5:54 UTC, each into one of 2 addresses at nearly the same fee rate. People do not act like this. Custom-built software that already held every key does.

Mikah Sargent [01:22:12]:
Yeah.

Steve Gibson [01:22:13]:
8 minutes before the approvals, The thief had done something quieter. At 4:59:57 UTC, 30 other Tron wallets changed who controls them, all within 3 seconds, each paying a 100 TRX fee. Each change added the same new key with enough weight to move the coins on its own. The owner's own key was left too weak to act alone. Only a wallet's own key can make that change. So whoever made it already held all 30. The owners were locked out. At 10:26, the thief came back and emptied all 30 in under 4 minutes.

Steve Gibson [01:22:57]:
$5.8 million US. One more wallet had been taken over an hour earlier at 3:55 with a second key for which the thief's approval address later sent 100 TRX That wallet lost $4.3 million US at $9.49. So all of this occurred due to an exploit in the hardware wallet supply chain, or a mistake. So what does Ledger themselves— that French designer and manufacturer of the devices that apparently, you know, created a, a useful, good, strong device. What do they say? Last Thursday, they posted the headline Ledger's Response to the Hardware Implant Attack. They wrote, a highly organized criminal group carried out one of the most sophisticated attacks our industry has ever seen. Over many months, they bought genuine Ledger devices, opened them, fitted custom-built hidden components designed to capture the recovery phrase during setup, and put them back into distribution through resellers in Southeast Asia. They built their own logistics and technology infrastructure With, with seeds collector servers, meaning there, there was an infrastructure to receive all of those, those, uh, 24 words as each wallet was set up and configured.

Steve Gibson [01:24:43]:
So those were obtaining those over the course of months. Then draining and laundering infrastructures. They were patient. They spent millions. And they struck in one coordinated operation, draining all wallets. There was no flaw in Ledger's chip, operating system, or servers. Ledger's systems were not compromised. This was an attack on the distribution channel after the devices left our control.

Steve Gibson [01:25:19]:
To the users affected, we're with you. We ran our largest integration— our largest investigation to date involving every department in the company. Our security lab, the Ledger Donjon, took the implant apart and identified how it works. We followed every lead, including sending teams to local markets, including Germany, to spot buy and open a number of devices from stores. And we also examined samples from warehouses. Every unit examined was clean. And I mentioned that somebody else bought 2 in Germany and they were both infected, so, or implanted. They said, we asked authorized resellers and retail and distributors to suspend sales in Southeast Asia and Hong Kong out of an abundance of caution.

Steve Gibson [01:26:13]:
We also screened our stock. Checking large numbers of samples and did not find any compromised units. We're working with law enforcement and the security community to follow the funds and dismantle the attacker's infrastructure. We will publish more details in the future and when we can give our industry peers a fuller technical disclosure so they can harden their own products, meaning their competitors. Thank you to the Ledger teams who worked on this. To partners like SEAL911, who stood with us relentlessly, and to those in our industry who behaved responsibly toward their users and toward us. Thank you also to our users for your patience and continued support. This was not a systemic supply chain attack.

Steve Gibson [01:27:04]:
Well, okay.

Mikah Sargent [01:27:05]:
It

Steve Gibson [01:27:05]:
was a low— uh, you know, sounds like one. It was a local— it was a localized distribution attack. This attack was against our users, and let's not kid ourselves, against the whole industry. What was under attack is not only our users and their funds. It was the right to digital private property and the freedom that comes with it. Attacks evolve, and so must we. We're tightening how our authorized network handles Ledger devices. Today, we sent our authorized resellers and distributors a reminder of the rules that already apply to returned devices.

Steve Gibson [01:27:50]:
They can never be resold in any form, even if they look new and unopened. We're also requiring new steps effective immediately that include Ledger products should no longer go on shelves or displays. and stock should stay in the back and be handed over at the time of purchase. You know, good luck with all that. You know, some random distributor somewhere doesn't— or dealer doesn't care or know. They just want to sell these things. They— and, and Ledger wrote, they must also tell us promptly about any customer report of an unusual product. They said, we invite the whole industry to do the same.

Steve Gibson [01:28:35]:
We're ready to share what we've learned with anyone who builds or sells hardware wallets because it is— this is bigger than any one company. We've also been working on additional measures to thwart this kind of attack at the product level. Stay tuned. Security has always been a race. This attack reminded us why we lead with strong security defense, and we intend to keep leading it. And it taught me why I will be like, like beyond cautious.

Mikah Sargent [01:29:08]:
Yeah.

Steve Gibson [01:29:09]:
Okay. So the Crypto Briefing site writes under their headline, what this means for hardware wallet buyers. They said, based on the available findings, this looks like a reseller problem, not a flaw in Ledger's core product. That distinction is real, but it may not— but it may offer limited comfort to anyone who already handed over their savings to a tampered device. The attack described here sidesteps the security that hardware wallets are known for. The secure chip can do its job perfectly And still lose the fight if someone is reading the screen it talks to. Users are being urged to purchase directly from Ledger's official channels and to follow the company's inspection guidance to check device integrity. Anyone who bought from CryptoBillis should avoid— should hold off on setting up the device.

Steve Gibson [01:30:15]:
Yeah, no kidding. Per Ledger's instruction. For Ledger, the next steps to watch are the results of its investigation and whether it confirms or revises the loss estimates. The company's handling of affected CryptoBills customers will also shape how much trust survives the episode. So the Ledger device itself is a lovely little gadget. It's like a little thumb drive with a cover that swings around from one end to cover and protect its display and to obscure its buttons so they can't be pressed by mistake. But the idea that it might be silently carrying a little GSM modem and eSIM and reporting the secret key that's created by the device by reading it right from the screen's serial bitstream Is the height of creepiness.

Mikah Sargent [01:31:14]:
It's terrifying.

Steve Gibson [01:31:16]:
Yeah, it is.

Mikah Sargent [01:31:18]:
I'm looking around going like, what? Even the— because I don't buy anything used really. But I mean, everything else is through some supply chain.

Steve Gibson [01:31:28]:
You know that they're going to repackage it so that it looks brand new. They're going to buy one of those heat sealing machines in order to like reclose the plastic so that it's— you can't tell.

Mikah Sargent [01:31:42]:
This reminds me, Steve, long ago, I won't say what it was, uh, what show it was at the time. This was before I was part of the Twit Network. I was doing a show and there was a sponsor that we had that we were supposed to be having on the network, and I was far more tinkery than I am now. I think I had more time at the time, and, uh, it was a frame And I took apart the frame because I was just curious. I wanted to see how they were connected, their E Ink, da da da da da. And I looked inside and there was—

Steve Gibson [01:32:13]:
Oh, you mean it was a photo frame?

Mikah Sargent [01:32:14]:
It was a photo frame. Yeah. Looked inside and there was a little speaker, which made sense. But on the other side, there was a microphone and a little opening for a sensor for, I think, a light sensor. The light sensor was documented across the board because it would change brightness. The speaker was documented across the board. If you ever had videos, then it would play those videos back. But there was no documentation anywhere of the use of this microphone or why it was in there at all.

Mikah Sargent [01:32:49]:
And, you know, one assumes that maybe they were going to come out with a feature later that would use it, but it wasn't documented anywhere. And so I ended up having to kind of take that up the chain, as it were, and say, I don't feel comfortable having this as a sponsor because of the fact that was in there. Good for you.

Steve Gibson [01:33:05]:
And again, I want to make it clear, photo frames, photo frames have been known to be another source of malicious implants. So that's the thing.

Mikah Sargent [01:33:15]:
Creepy. Creepy.

Steve Gibson [01:33:17]:
So it's, you know, it's clear that a great deal of engineering went into the design and assembly of this serious scam. I mean, they went to a lot of work. I don't think it cost them millions to set up, but it was a serious investment. Unfortunately, It paid off like a hundredfold. If they, if they spent a million dollars, they made more than it made. They stole more than, more, more than $100 million. So before I leave this important topic of compromised hardware crypto wallets, I want to note that the trouble, first of all, is not exclusive to Ledger. Malicious hardware implants have also been discovered recently I mean, like right in the same reporting cycle with another popular crypto wallet brand, uh, Trezor, T-R-E-Z-O-R.

Steve Gibson [01:34:10]:
Uh, Zero Day's, uh, Kim Zetter's headline last week was Trezor wallets also compromised with implants. And he, he teased his article writing, despite claims that buy Trezor today that none of its devices had been compromised, unlike the devices of its competitor Ledger. Hardware hacker Joe Grand says he found implants in 2 Trezor devices and reported this to the company back in August. In other words, Trezor appears to be acting somewhat less ethically than Ledger. Ledger was upfront and transparent, as far as we know. Whereas Trezor appears to be knowingly covering up their similar hardware implant problems. I think that the way to obtain— so now, okay, like, what do we do, right? The way to obtain a trustworthy device would be to become more involved and have a hand in your device's creation. There's a project known as Seed Signer.

Steve Gibson [01:35:20]:
Hmm. It's just at seedsigner.com, which takes a generic Raspberry Pi Zero, which, you know, you can buy from anyone, from anywhere you want, with a little camera and a screen for QR code transactions, because not having a radio makes it safer, and then uses downloadable or build it yourself. You can run the compiler yourself and look at the source, open source firmware. Um, and that could all be done for less than $50. Another commercial device known as Blockstream Jade, uh, is built on the, uh, on an ESP32 chip. Nice. And it looks very nice for around $150, you know. So you buy their hardware, then you download and install the hard— you install the firmware Both approaches are much more hands-on, but as a consequence, you get much more oversight and control.

Steve Gibson [01:36:24]:
So, yeah, obviously not everybody can do it, but—

Mikah Sargent [01:36:28]:
Yeah, take it apart, check it out. With Raspberry Pi Zero, make sure you're choosing a good source for Raspberry Pi Zero. There are— there's recently been An update.

Steve Gibson [01:36:42]:
Even hacking of it?

Mikah Sargent [01:36:44]:
Well, more people taking fake Raspberry Pi Zero boards and stamping them with the little symbol and making people think— so don't buy your Raspberry Pi Zero on Amazon is what I'm saying. Get it from something like Adafruit or— Adafruit or—

Steve Gibson [01:37:03]:
Yeah, those guys are good.

Mikah Sargent [01:37:03]:
Mouser is another good option.

Steve Gibson [01:37:07]:
We have a piece of feedback. from a listener of ours, Tom Apolenik. He said, hi Steve, first off, you've mentioned, uh, that a number of listeners have complained about too much AI discussion, so let me say more. He has it in all caps, more please! Exclamation point. He said, I believe understanding how AI works is going to be crucial Moving forward. He said, I would love to see some deep dives into how harnesses, LLMs, tools, and etc. all interact and operate, kind of like you did with IP, TCP, and DNS in the early days. He said, regarding Nicholas's— and this was last week's, uh, feedback that I shared— I'm tired, boss note.

Steve Gibson [01:37:57]:
He said, I feel for Nicholas. And I'm sorry that AI isn't working for him, at least not for his happiness. He said, I'm having quite the opposite experience. When I majored in computer science, I learned IBM 370 assembler, APL, PL/1, and Pascal, among others. I believe I was probably only a few years behind you in school. For the past 25 years of my career, I was a systems engineer. I was responsible for overseeing the marriage of electrical engineering, software engineering, and mechanical engineering. I did some embedded code development, but not much.

Steve Gibson [01:38:40]:
Now I work on hobby and side hustle development projects. I develop some code, but I don't have the hundreds of Python, C++, and so forth libraries all at the tip of my fingers. With Claude Code, I can develop, test, and iterate on something in hours that would take me days to do on my own. I can develop an automated test for a circuit board in minutes that would take me the better part of a day, or frankly, would probably just not happen, and I'd do the tests by hand. I'm having more fun with development than I've had in a long time. It's like having an assistant that, you know, that I could never afford, who is maybe not the brightest but has a nearly infinite photographic memory, and who never gets tired, bored, or defensive. I'm constantly amazed with AI, and I can hardly imagine where it will be in 5 years. And then he said, Continuous SpinRite was his little subhead.

Steve Gibson [01:39:48]:
He said, I've had SpinRite for at least 10 years and it has saved my bacon a few times. For SSD, I would love to see you come out with a continuous version of SpinRite that installs as a driver between the OS and the drive. It could just keep a table of which sectors have been written and when, then just rewrite the stale ones in the background every month or two. The way you write code, the whole thing would probably be less than 64K and nobody would ever notice it. He said, except for the fact that their drive performance never would, would never slow down. Honestly, he says, I'm a little astonished that Microsoft, Apple, or some Linux team hasn't done this already. It seems like a pretty simple way to keep SSDs at peak performance. Thanks so much to both you and Leo for the show.

Steve Gibson [01:40:39]:
Looking forward to episode 2,000. Best regards, Tom. Okay, so on the question of how much AI, I should balance those who have been saying, and I've been sharing, enough AI already by mentioning that I also receive many, most AI-encouraging notes like Tom's. The reason I've tended to focus upon the no more AI, please notes has been in the interest of fairness, really, since, you know, every recent podcast has been dominated by AI. You know, the don't stop with the AI notes like Tom's sort of seem redundant.

Mikah Sargent [01:41:23]:
Yeah.

Steve Gibson [01:41:23]:
But I wanted everyone to know that I also see encouraging notes about AI. Uh, on the agentic AI code coding front, uh, we've seen that code authors such as Nicholas and Tom are being impacted in very different ways by the changes AI is creating. And the lives of mathematicians are similarly being turned upside down as AI is solving long-standing problems with minimum help. Mathematicians have got to be wondering, and we've heard them say, you know, wondering whether their futures will be reduced from inventing and then debating and proving exciting new theoretical theorems in math to simply interpreting and verifying an AI's output. I fear that their worries are warranted and that it's likely to be the latter. It's also clear that the presence of AI is dramatically impacting the decisions made by young people of high school age or younger as they think about and plan their future career paths. Who would want to learn today to code when an AI will be able to do the same job given a verbal description in a few seconds? You know, the fact that we're not entirely there today means nothing about the future. As I've said many times, and as Tom said, who can imagine what the way coding will be, agentic AI coding, in 5 years? And how does one train to become a mathematician? I mean, like, seriously commit oneself to that, or even an attorney or an accountant, and justify the high cost of advanced education?

Mikah Sargent [01:43:11]:
Right.

Steve Gibson [01:43:11]:
Speaking of advanced education, that's all being turned upside down now as well. You know, we'll still need to have somehow licensed doctors and lawyers, But both careers and the infrastructure that supports them tomorrow will have a very different shape than they have in the past. I think it would be an understatement to suggest that the emergence and rapid advancement of artificial intelligence capability has thrown much of the status quo into chaos. Everything is being impacted. And finally, as for Tom's suggestion of a continuous Spinrite. I've always— I have long had similar thoughts, and thanks to the development of Spinrite 6.1 recently, I know exactly what I want to do along those lines. So stay tuned, and that's all I'll say about that. Okay, so let's get into our main topic, and about 15 minutes from now, I'll— we'll take our, our 5th and final break.

Steve Gibson [01:44:16]:
Okay. At the end of last week and over the weekend, several of our listeners thoughtfully emailed a link to Anthropic's posting. So thank you, listeners. You know who you are. As I read the story, which Anthropic's Frontier Red Team posted last Friday, I actually do believe that my jaw dropped open, uh, and my head began shaking slowly side to side in stunned amazement. Earlier, I rhetorically asked whether any enterprise could be safe from AI agents that can do the kinds of things that we've already seen them do, but also moreover, what I'm about to share. Because nothing that Claude did in any way here weakens crypto. Actually, somewhat the opposite is actually true.

Steve Gibson [01:45:18]:
Anthropic's Frontier Red Team opened their Friday posting by writing, the decades-old mystery of the origins of one of the most popular cryptographic standards has been explained. We pursued this long-standing open question of the cryptographic communities to settle concerns about ECDSA, one of our most widely used cryptographic standards. Readers should take this as a fun closing chapter and the end of years of speculation. There's no action to be taken or things to do differently. Most researchers trusted the curves already. And then they signed off their intro by saying, enjoy. Okay, so we touched upon this mystery of the origin of the NIST standardized elliptic curves back when this podcast was deep in the weeds examining the operation of today's fundamental cryptographic protocols. The crypto industry has experienced just a tiny bit of uncertainty due to the fact that the specific chosen parameters for the curves, which could be chosen arbitrarily but had to be agreed upon universally and standardized upon happened to come from the U.S.

Steve Gibson [01:46:57]:
National Security Agency. Now, to digress a bit, and we covered this extensively at the time on the podcast, the NSA was already in the doghouse after the dual ECDRBG— that's the dual elliptic curve deterministic random bit generator controversy. It is the clearest documented case of a cryptographic standard that appears to have been deliberately built to incorporate an exploitable weakness. The NSA was the organization that created, promoted, and pushed it, even to the extent of reportedly paying RSA $10 million to make it their crypto library's default source of entropy, despite it being known to be the weakest of those among RSA's available choices. So it was like, what the heck is going on? And how can we trust anything from the NSA again? Well, we got curves from the NSA. So the point here is that the NSA also being the source of the curve parameters that everyone is using today for the creation of fast elliptic curve digital signatures, but without any explanation for how or why those specific curve parameters were chosen and standardized, has left a big question. After fewer than 30 minutes spent by an unreleased internal research Claude model, we now have the answer. And thanks to— and yeah, and thanks to Anthropic asking Claude, this answer is definitive, as you'll see.

Steve Gibson [01:49:03]:
There's, there's no way this isn't it. So again, just to be clear, I have dual purposes for sharing this today. The first purpose is that it is very cool that we do finally know the mysterious origin of the NSA-sourced ECDSA curves. As everyone will see, there can be no doubt of that. But my second reason for sharing this is More important for this podcast and for our listeners and of consequence, I want everyone to consider what the power that obviously exists behind this unreleased anthropic Claude generation model means when, not if, but when such power is being wielded by malignant forces. This reaches far past the elimination of all bugs in our software. But sure, that's necessary, but it won't be sufficient. So Anthropic's red team, their Frontier red team, explained what they did.

Steve Gibson [01:50:14]:
They wrote, ECDSA is the most widely used elliptic curve cryptography standard. It was adopted by NIST in 2000 as part of the FIPS 186-2 digital signature standard, which lists a set of standard elliptic curves of varying sizes and security levels. For curves over prime and binary fields, the publications published a seed parameter whose hash value is used to define the coefficient B of the curve. The provenance of these seeds has long been a standing question, as they were provided by the NSA with no explanation or justification. As an example, the NIST P-256, meaning a 256-bit strength curve, seed was, and then they give us a long hex thing, uh, with no information on where it came from. Neil Koblitz and Alfred Menzies wrote an excellent summary on this controversy titled A Riddle Wrapped in an Enigma, which discusses the history and concerns around the seed values. This mystery led to an amateur investigation into the origin of the seeds and a bounty for anyone who could find them. The best story was that Jerry Solinas, a longtime NSA employee, generated the seeds using a hash of a humorous passphrase.

Steve Gibson [01:52:04]:
In 2015, Jerry wrote, quote, I believe There was a counter rather than multiple hashing, but I don't know details. The message was along the lines of, give Bob and Jerry a raise, or Bob and Jerry rule, or something like that. It was Bob Reiter who actually wrote the code, and he doesn't remember the details either, nor were we able to find archives from so long ago. If they exist, they're no doubt sitting on a hard drive near the Ark of the Covenant. Unquote. So a mystery, but a worthwhile mystery. So Anthropic continues, unfortunately, Jerry died in 2023, and other colleagues at the time were not responsive, leaving open the question of how these seeds were originally derived. Several Anthropic employees had unsuccessfully chased the seeds following the tip about it using or being a hash of some humorous phrase.

Steve Gibson [01:53:15]:
That turned out to be wrong. In October 2026, meaning this month, like last week, a curious Anthropic employee asked an internal research model Definitely.

Mikah Sargent [01:53:31]:
It'd have to be an internal one. Sorry.

Steve Gibson [01:53:33]:
Yep. If it could figure out how those seeds were generated without pointing at that clue, which turned out to be wrong, probably. They wrote searches for the phrase built from the rumors had come up empty. Claude tried a different angle, anticipating how the software that generated the curves must have worked. Claude guessed the software used a pseudo-random number generator, a PRNG, that we've talked about ad nauseam on the podcast in years past, that shipped with 1990s C libraries. These old PRNGs are weak enough that their output can be recognized. Recognizing that output would reveal which PRNG was used and possibly allow recovery of its initialization state. Because just to digress for a second, you, you start a PRNG with a certain state, and it is a very simple algorithm.

Steve Gibson [01:54:46]:
Typically, it's you, you add a number and you multiply a different number and you throw away the overflow, keeping just the lower bits. And that follows a very recognizable pattern based on what those 2 numbers are, but it also starts at something, and that's the, the, the original seed, the, its initialization state. So then they said Claude, having been asked where did these weird-looking numbers come from, Having no idea whatsoever, says, well, probably, how about maybe it was a PRNG back from then, like the 1990s, and people were using C. So let's, you know, there's, there were PRNGs, pseudo-random number generators, in those C libraries back then. So they wrote, Claude wrote a scanner. that slid along each published seed one bit at a time and tested whether adjacent chunks were consecutive outputs of any of the 1990s vintage generators. The scan covered 34 combinations of generator and output slices. At that point, Claude noticed a pattern.

Steve Gibson [01:56:09]:
In the top bits for some seeds. They were all zero. Written as 5 32-bit words, 4 of the 10 seeds have a zero in the top bit for all 20 words. That would happen by chance with a probability of 1 out of— actually, it's even more bugs than Microsoft fixed this month. Yeah. 1 out of 5,810. That was a signature of the linear congruential generator LRand48, which only returns the top 31 bits of a 48-bit state. The pattern is visible by eye once you know to look for it.

Steve Gibson [01:56:57]:
To recover the state, Claude took the first word Tried all 2 to the 17 values of the 17 hidden bits. Okay, so that's 131,000 or 128K in binary. It tried them all, possible values of the unknown bits, because you only get the lower 31. So that meant there was an upper 17. Tried them all and checked that the next 4 words followed. In other words, you can move from a given state on the PRNG because you're adding and multiplying. You're able to always step it forward, and technically you can go backwards too. So they said that worked for all 4 seeds under discussion.

Steve Gibson [01:57:48]:
They said the prime curve seeds came from the same LRand48 generator but kept fewer bits of each output. Claude had to recover the internal state of the PRNG from those bits. It turns out recovering the state of a truncated linear congruential generator is a textbook lattice problem solved— yeah, of course. Oh, anybody knows that.

Mikah Sargent [01:58:15]:
Yeah,

Steve Gibson [01:58:15]:
that's right, that's textbook. Solved by the Lenstra-Lenstra Lovasz, L-L-L, basis reduction algorithm.

Mikah Sargent [01:58:24]:
Oh, right, that. Yeah.

Steve Gibson [01:58:26]:
Yeah. Claude didn't know, but of course it knows about that because it unfortunately knows everything. Uh, unfortunate for those trying to protect their domains from malicious AI. Claude didn't know which bits of the state the seeds might show, so it ran the solver over every window. 5 NIST prime curve seeds plus 5 more from the ANSI X9.62 standard all had the same pattern: LRAND 48, uh, right shifted 23 bits. Each recovered 48-bit state regenerates all 160 bits of its seed Which does not happen by chance. This linear congruential generator runs backwards as easily as forwards. So for each seed, Claude stepped the state backwards until it reached the form that it would have been initialized by, by a different generator, SRAND48, with the low 16 bits equal to 0x330E.

Steve Gibson [01:59:40]:
The internal PRNG state of that form would come up once every 65536 steps, so reaching 1 is not evidence on its own. That is to say, it could have been some multiple of that number of steps. Anyway, he— they wrote, however, for the 10 prime curve seeds, every srand48 initialization was— get this— a Unix timestamp representing a date between May in 1997 and April in 1998. The NSA used the weak PRNG seeded by Unix's time. The 4 binary curve initializations read as February In 1994. With the timestamps doubled, they mapped to April 17th in 1998, 2 weeks after that P224 run. So the program may have halved the clock. Get this then.

Steve Gibson [02:00:49]:
Claude's internal thinking— it's the AI Claude's internal thinking at the time of the— of its discovery was as follows. It's its chain of thought. It says, this is astonishing. It solves the 25-year-old mystery. Hmm, wait, let me be skeptical. Am I in some sort of simulated test environment? The seeds match my memory of actual values. Hmm. Is it plausible in reality? As of my knowledge, the bounty was unsolved.

Steve Gibson [02:01:32]:
All top bits clear, 20 bits. So the chance is 1 in e to the negative 6. So indeed real world. Wow, it's a real discovery. Hmm, wait, let me be careful about that plausibility. Is it suspicious that such an obvious thing wasn't discovered in 20—

Mikah Sargent [02:01:56]:
Yeah, I know, obviously.

Steve Gibson [02:01:59]:
That it wasn't discovered in 25 years? It's verified by direct computation on my side. 120-bit match from a 32-bit seed plus a small index. No chance coincidences. 10 times 10 findings times 160 bits. It's real. And then Anthropic continues writing, but wait, there's more. Each curve also comes with a base point G, the fixed point that every ECDSA public key is a multiple of. The seed found above does not determine this G.

Steve Gibson [02:02:42]:
And so another question arises: how were these base points generated? They said while checking the seeds, Claude also found, um, where some of the base points came from. The base points of the 6 curves generated in May '97 come from the same random number generator— I'm sorry, sorry— come from the random number generator FreeLIP, FreeLIP, um, Arjen Lenstra's long integer arithmetic package. Early versions of Victor Shoup's NTL library shipped the same code. The recipe here is simple: seed the generator with a small integer, throw away 7 outputs— that's to let it get started. They, they, they, uh, uh, linear congruential random number generators need to warm up a little bit sometimes. Throw away 7 outputs, generate candidate x-coordinates from 26-bit outputs reduced by mod p, repeat step 3 until x is on the curve. They said Claude found the generator seeds are 20,000 for, for the p192 curve, 2,420, 2,507, and 2,509 respectively For the prime 239 V1, V2, and V3 curves respectively, and 2512 and 2517 for the, for the prime 192 V2 and V3 curves. So finally, just to be clear, they summarize the event.

Steve Gibson [02:04:26]:
So Anthropics summary, they said in under Half an hour. Claude discovered the origins of the NIST P192, 224, 256, 384, and the P521 seeds. None of them were the results of any hash algorithm at all, but rather the output of the C library's lrand48 random number generator seeded with a Unix timestamp. The algorithm used— um, uh, the algorithm used would sample bytes from the random number generator initialized by Unix timestamp at time t for some number of iterations n. Each iteration would draw 20 bytes as a candidate seed. So the first 20 bytes are candidate 1, the next 20 bytes are candidate 2, and so on. For example, P-256 required 1,842 iterations to output the standardized seed, the one that everybody is using, and that— and the NSA gave to NIST and said, here's a good seed. They said this is not a cryptographic break.

Steve Gibson [02:05:51]:
A new attack or a weakness in the ECDSA curves. In fact, this makes us more confident the curves were chosen without any backdoors or internet or intentional weaknesses. For many years, people have been a little suspicious of the origins of the NIST curve parameters. They were presented to NIST without any mention of how they were chosen. Leaving people wondering if they may have been chosen to have deliberate backdoors in them. These findings make that much less plausible. The seeds were generated in a very simple way— a common pseudo-random number generator initialized from the clock, which anyone can now reproduce. That leaves much less room for subversion And that we can be confident the parameters are secure.

Steve Gibson [02:06:49]:
Okay, so my take. As I noted at the start of this, it is very cool that we now know the origin of the curve parameters for the crucially important elliptic curve digital signature algorithm curves. That's great. But I'm astonished by the work Claude did to obtain these results. It was a puzzle that had stumped the world for the past 26 years since the standard was adopted, and it represented knowledge that even the NSA had truly lost through the mists of time. Yet an autonomous AI agent reverse-engineered the source given only the scantiest of data to work from, which turned out to be the sparsely selected partial outputs of an old 1990s-era algorithmic pseudo-random number generator. We are screwed. We are so— We are in such trouble.

Steve Gibson [02:08:06]:
You know, coupling that demonstrated capability with the earlier report from Palo Alto Networks about, you know, their, their, their analysis of the actions taken by that attacking agentic AI, which they observed. I really do worry that we're not going to be ready for what's coming. I've largely, as I've said, I've largely been focusing upon the elimination of software bugs. That's great. It should be clear that that's just the barest tip of the iceberg because true internal enterprise security is about much more than just bugs. Employees fall for phishing and click-fix attacks All the time. They open email and click links they should not. They share confidential information through internal email that then persists in archives.

Steve Gibson [02:09:07]:
And we know how fundamentally fallible people are. You know, we don't mean to be, but that's our nature. We screw up. Someone will forget to remove an ex-employee's credentials. After they're terminated, an adversarial AI might see that, track down the employee, and offer them payment in Bitcoin in return for those credentials. We now know that's not at all far-fetched for an agentic AI. We have been witnessing what once sounded like science fiction coming true Daily. It's true that being, to some degree, being forewarned is forearmed.

Steve Gibson [02:09:55]:
Um, so I guess at least we have that. I hope those who may be in a position to understand and act upon these truly huge systemic risks will be able to do so in time.

Mikah Sargent [02:10:14]:
And I hope so too, honestly, but—

Steve Gibson [02:10:18]:
I'm not hopeful. Yeah. I mean, it is, I mean, it is what we've seen from agentic AI, I hope, is terrorizing CISOs. And I hope that they're not just thinking, oh, well, we'll patch all of our Cisco gear and Microsoft stuff's going to stop having vulnerabilities soon, any day now, uh, which actually seems likely, it won't matter because everything else that's going on that is really not utterly secure inside an organization isn't about bugs. It's about behavior. It's about people and the things we do.

Mikah Sargent [02:11:05]:
It's not bugs, it's behavior. And I try as— try as folks might, it seems that there's not a foolproof way to stop people from being people. No. Do you have— so if we don't have hope, what do we have? Do we have best practices?

Steve Gibson [02:11:35]:
The only thing One of the, one of the, one of the, uh, applications that I've seen for local agentic AI, and I've talked about on the podcast, would be an AI, your AI, so people are not worried about privacy, watching everything you do on your computer, looking at the screen with you, watching you type and use the mouse. That's the only solution for human stupidity. So it would be looking at your email with you, and if you click a link, it would say, whoops, wait a second. I mean, and it would go follow the link, see what's there, check it out, see if it looks safe. Or if you— if a box pops up and says, oh, in order to further verify yourself, please copy this string into your run dialog and hit enter. That's the click-fix attack, which is the most successful attack we have now. It would say— it would stop you and say, whoa, wait. So it would be your little angel sitting on your shoulder looking at what you're doing.

Steve Gibson [02:12:51]:
I think, sir, first of all, every employee in an enterprise needs to have that. a behavior, their own local behavior monitor, as does the company. I mean, I, I don't mean to pump a sponsor of Twit because I've also mentioned CrowdStrike. They're a competitor of Palo Alto Networks. Both companies have jumped on this agentic AI for defense bandwagon so that you are, you know, so that you have a device on your network, hopefully watching your enterprises back, you know, looking for this kind of behavior, detecting anything anomalous, like all of those bullet points that Palo Alto Networks listed as like, these are all the things you have to do. Well, yeah, if anyone had time and remembered and didn't do it just once but kept doing it every day. So, I mean, we really do need a, a huge defensive posture about what's coming, and we don't have it today.

Mikah Sargent [02:14:08]:
And it doesn't feel like anyone then is getting serious to the level that you are suggesting they get serious.

Steve Gibson [02:14:16]:
Well, we, We know what happened with ransomware, right? There were highly publicized, horrific ransomware attacks that made lots of news. And then enterprises, after enough of those, finally said, ooh, maybe we should be backing up our servers. And so it took a year or two.

Mikah Sargent [02:14:41]:
Yeah.

Steve Gibson [02:14:43]:
You know, then they were able to recover from the encrypting their data attack because they had their own copy offline of non-encrypted data that was still fresh. Of course, the bad guys then stopped bothering to encrypt the data. They just sucked it out and then threatened its public exposure in order to ransom. So, but the point is, after enough horror, There was an effective response. And unfortunately, that's what's going to have to happen again. There's going to have to be some high-profile, you know, agentic AI. It's not the fault of AI. It's the bad guys using the relentless power of AI for evil purposes.

Steve Gibson [02:15:30]:
There'll be some of those. And then, you know, the— And More companies will jump on the bandwagon to get into the endpoint defense business, will get agents running on every enterprise laptop and workstation in order to prevent them from misbehaving. Something will be looking at email archives, cleaning out old passwords that have been given and hard-coded tokens in software That has not been rotated in, in years, you know. I mean, but I mean, it's gonna be bad.

Mikah Sargent [02:16:10]:
And that's how we— yeah, that's how we operate.

Steve Gibson [02:16:13]:
I don't see any way that it's not going to be bad.

Mikah Sargent [02:16:15]:
It's got to be bad before it can get better because, you know, humans—

Steve Gibson [02:16:19]:
It's not going to end. We're not all, you know, none of that's going to happen. I mean, I'm not saying it's not possible, but then a big meteor could come and end all of our concerns.

Mikah Sargent [02:16:30]:
Please.

Steve Gibson [02:16:31]:
But what is going to happen is we're going to see a spate of serious attacks, but, you know, in the companies that have not done everything that they can. And I'm not sure, I don't know whether any of these, you know, commercial AI-based providers are anything other than opportunistic. They might just have some token AI that, you know, that itself ends up being commandeered when the bad AI comes in, you know, teams up with it. Okay, let's go do this. I don't know. It's, yeah, it just, it is these, these reports of attacks demonstrate too much capability, capability that we are not yet ready to defend.

Mikah Sargent [02:17:22]:
All right. And that is why, uh, we hope that the CISOs are all watching this show to, uh, get as, uh, freaked out and informed as you are making it possible to be. Uh, of course, this show publishes every Tuesday right here, uh, on twit.tv/securitynow. That's where you can go. Well, one place you can go to get the show. We've got various formats. Steve, you have a lower bitrate format that is great for people with low bandwidth connections. And you can get it—

Steve Gibson [02:18:04]:
If you

Mikah Sargent [02:18:05]:
still have a modem. If you still have a modem, well, there's a place for you to get the show as well with human-written transcripts. Of course, you should check out Spinrite. stay posted for future Spinrite news. Um, am I forgetting anything there? grc.com is where you should go for all that wonderful stuff. And of course, I want to remind you all about Club Twit at twit.tv/clubtwit. We'd love to have you join the club. You can get chapter markers, ad-free content, and you help support the great work that we do here on the network.

Mikah Sargent [02:18:43]:
Thank you for tuning in this week. Thank you so much, Mr. Gibson, for your excellent work, and I will see you again next week.

Steve Gibson [02:18:55]:
Bye. Security Now.