News

KETTLE AI commands all the headlines nowadays, but the biggest security story of the week is all about human laziness and poor password habits – just like the good old days. This week on the Kettle, host Brandon Vigliarolo is joined by US editor Avram Piltch and security editor Jessica Lyons to talk about the Klue breach, which was blamed on a "compromised legacy credential" that ought to have been deleted a while ago. The hole allowed cybercriminals to access the SalesForce environments of hundreds of companies, say researchers. The incident has caused trouble for security firm Huntress, which admitted to the breach early on, and the situation over there wasn't caused by AI either. That said, AI is playing a role in what's being described as "the summer from hell" by one security professional, but while top-tier AI models are spotting troublesome vulnerabilities, the amount of damage they've managed to cause pales in comparison to what one lazy sysadmin can cause by poorly managing passwords. You can listen to the latest episode of The Kettle by clicking on the player above, as well as on Spotify, Apple Music, or YouTube, or read the transcript of the latest episode below. It's been lightly edited for clarity. Brandon (00:01) Welcome to the latest episode of The Register's Kettle Podcast. I'm your host, Brandon Vigliarolo, and this week we have some rather interesting security stories to talk about concerning yet another Salesforce data breach affecting a whole bunch of companies, the new extortion gang behind them, and the trouble the whole thing has spelled for one of the first companies to point the whole thing out. This week I'm joined by US editor Avram Pilch and security editor Jessica Lyons to talk about this whole mess and more. Welcome to you both. Jessica Lyons (00:29) Good to be here. Avram Piltch (00:30) Hey. Brandon (00:30) Jess, let's start with that Salesforce supply chain attack that you wrote about this week. I understand there was a market intelligence connector of some sort that was behind the incident, right? Jessica Lyons (00:41) Right. So there's this company named Klue, and they provide market intelligence to more than 250,000 users worldwide. And they integrate with Salesforce. And so apparently what happened, on around June 11th, somebody used compromised legacy credentials linked to the Salesforce integration, and then by that they were able to obtain OAuth tokens and then were able to access customers' Salesforce data, Klue customers' Salesforce data from that. Brandon (01:21) Okay, was it data that Klue had on their customers in their Salesforce environment, or they pivoted to the customers' environments as well? Jessica Lyons (01:29) It was through the integration with the Salesforce databases. Brandon (01:34) That's not great. A lot of companies were exposed, and a lot of them in your article you mentioned were security companies. Is that right? Jessica Lyons (01:42) There were a ton of security ones, and then LastPass, this huge password manager. We don't know how many; Klue didn't say. Huntress, which is one of the security companies who was involved in this and who came out on the forefront and said, "Yeah, we were one of the compromised organizations," said it was hundreds. And out of 250,000 users, it could be pretty comprehensive. Avram Piltch (02:12) Do you think this makes Huntress look good? Jessica Lyons (02:17) I think it was admirable that they came out, especially as a security company, and said "we were one of the companies who were victimized." I think that's how any company should respond if they're among the companies affected. Especially if you're a security firm, you have an obligation to be transparent and tell your customers what happened. Brandon (02:43) Legally, in the United States at least, if you've got a breach, you've got to report these things to the government. There's all kinds of cybersecurity reporting standards in place. They are contradictory and overlapping sometimes, but they're there. What kind of data was exposed, Jess? Jessica Lyons (02:57) It was basically CRM data. It wasn't any of the companies' internal IP or anything like that. It was CRM data for pretty much every single company involved across the board. The cybercrime group behind this hack did leak the Huntress data a few days later. And we've heard that they're actually deleting the stolen data from LastPass. That's what LastPass is saying. We don't know if this data is actually not going to exist anymore or if they're just handing it off for other attacks or to other organizations. But it involves CRM data. Brandon (03:49) CRM data then, customer data, from the affected companies too. I'm assuming no financial information was exposed? Jessica Lyons (03:52) No, no financial information. Avram Piltch (04:02) So relatively not that bad for Huntress's reputation when you think about it. Jessica Lyons (04:08) They specifically said it's our business contacts, price quotes, and other sales related data and messaging. They said no threat data, passwords, payment card information, or engineering data related to Huntress Agent or telemetry are affected. That's pretty standard across the board. The companies who did get more specific in their disclosures about what was taken basically lost business data, leads, and contacts. Brandon (04:46) For LastPass, was it just CRM records or were consumers of their password managers affected too? Jessica Lyons (04:55) LastPass customers' data was affected. It was some sale-related data, but also the intruders took customers' names, phone numbers, email addresses, and physical addresses, plus some case support data and then also sales-related data. Brandon (05:13) Right. If you're a LastPass customer, you might want to go in and reset that Master Vault password now. Jessica Lyons (05:18) Big yes, yes, definitely. Brandon (05:22) This didn't involve Shiny Hunters, who've been the de facto kings of Salesforce attacks recently. They weren't involved, right? Jessica Lyons (05:29) Right. No, they weren't involved in that. I think it was what everybody assumed is that you've got Salesforce and you've got OAuth tokens and that just screams Shiny Hunters. They weren't involved. It was a new group called Icarus. They're a new data theft and extortion crew, and they're modeled in the same mold here as Shiny Hunters and Scattered Spider. I was wondering though, is this just a front? According to Shiny Hunters, no, they were not involved. They told me that they were kind of bummed (laughs) that this other group was able to do this. And if it had been them, they would have definitely publicized the fact that it was Shiny Hunters who did this. Brandon (06:15) Yeah, they're not exactly publicity shy. So … I I love the fact that we've got an inside line to them too, that you can be like, "Hey, was this you guys in any way?" And they're like, "No, no, we wish it was." Jessica Lyons (06:26) I think the actual response was, "We wish." Brandon (06:29) Not much is known about Icarus. I think you mentioned a couple of different countries that their IPs might have been linked to, but those very well could have been Tor or VPN exit nodes. We don't even know where they're located. Jessica Lyons (06:43) No, we don't know much about them. Their leak site has been active since late April. We've seen different IP addresses in Europe, but we don't know much about this group at all. Brandon (06:53) These groups change and move so rapidly. Who knows who they are? Are they ransoming this data? Do we know? Jessica Lyons (07:08) Yes, they were ransoming and then leaking some of the data outright. Brandon (07:20) Okay, that's standard MO for a lot of these groups. Speaking of Huntress's early identification of this, that opened up a bit of a Pandora's box for them. Because they had a jilted ex-employee who wasn't thrilled with the response, which you also wrote about. What happened there? Jessica Lyons (07:22) Right. So after Huntress came out and and they said Huntress believes in radical transparency about security incidents, including when it affects our company. That was about the Klue breach. They said that in their blog. A former security operations analyst posted their response on his LinkedIn page along with a Pinocchio GIF. And that just kind of started this whole mess. He says that he was threatened by the company with legal action. He made it very clear this has nothing to do with the Klue incident. He says this stems from an earlier incident that he found out about in December, and because of that incident, he resigned from the company. What he's alleging, and again this is all allegations at this point, is that another Huntress employee who still works for the company passed communications from US law enforcement to a cyber criminal. Now this alleged cyber criminal, according to the ex-employee, is actively targeting his family and him. He says that he can no longer work at Huntress because of this. He says in the next few weeks he's going to provide more proof, including communications and phone calls about what happened here. He says also that this alleged insider was caught by the FBI. I don't know if that means arrested, I don't know if that means questioned, but still continues to work at Huntress. Brandon (09:30) I'm assuming there's no DoJ notice of anything that ties to an arrest of someone who could be involved. Jessica Lyons (09:37) Not at Huntress. No. Not at Huntress. Brandon (09:40) What has Huntress had to say about this whole thing? Jessica Lyons (09:42) The CEO responded to me and also responded on a Reddit post. He acknowledges the concerns raised by this former employee. He said that because of our work as researchers, sometimes we need to communicate with possible cyber criminals to gather intel that supports our partners and customers. He says that he appreciates the former employee's concerns and will continue to investigate the instance. He said a little bit more directly on Reddit that he doesn't understand and he firmly disagrees with these accusations and the insider narrative. Another thing that the former employee also brought up that Huntress is prioritizing an IPO over the safety of its partners, customers, and team members. He said that "sure AF" isn't the case. He's made it very clear that the company disagrees with all of these accusations and they're continuing to work with law enforcement. He said some of this involves legal proceedings, so they can't be completely public about everything. It sounds like a continuing story that we're going to learn more about in the weeks ahead. Brandon (11:15) If this ex-employee has documents to prove his allegations, that's pretty serious. Obviously, yes, you do have to interact with some of the people that you're defending against at a security firm, but passing law enforcement communications to them – I don't see a very good reason for that. Jessica Lyons (11:22) Right. Avram Piltch (11:36) Could this be a misunderstanding about what the employee was doing? Jessica Lyons (11:44) It potentially could, but if he has these communications between law enforcement and the Huntress employee, I don't know how that could be a misunderstanding. It's one thing to talk with cyber criminals, but it's another thing to be passing them information about legal proceedings.... Brandon (12:09) Yeah, or potential operations. We'll see what comes of that. It's going to be interesting to follow that thread. These two stories aside, it seems like we've got a really busy cybersecurity summer so far, even though it is usually a lull. Jess, you were talking about that with one of your sources, right? Jessica Lyons (12:13) Right. Normally everything slows down in the summer, and I was talking to a source and they said they're already calling it the "summer of hell." For the security folks out there, that's pretty accurate. I think a lot of that has to do with AI, to be perfectly honest. Brandon (12:48) Right. Squidbleed, which you wrote about recently, was a Mythos-discovered vulnerability discovered that was old and potentially serious. Jessica Lyons (12:51) Definitely. It's been around since 1997. It was discovered by Mythos, but it was also discovered even before then by IL Security, a European startup. They have their own model that they said found this before Mythos did. You've got this 29-year-old vulnerability, it's existed since 1997. It's in Squid, which is an open source web proxy server. It's a parsing bug and it essentially allows users to access the proxy's active memory. There are a couple key points: it's only unencrypted traffic, so it's cleartext HTTP, and it also requires that Squid has the file transfer protocol, FTP server gateway features turned on. So you have to be using this older vintage technology and protocols. FTP is pretty outdated at this point. Brandon (14:07) It's a vulnerability, but maybe not a serious one. Jessica Lyons (14:11) It's serious if these two conditions are met, because then it's going to expose your password, session tokens, and API keys. Brandon (14:15) Hopefully there are not too many environments where this is the case, but we know from writing about stories like this that every time you say this is a very rare case on old software, you can easily find examples. Avram Piltch (14:33) If you're still using FTP and HTTP on your servers, then you're letting yourself in for a big security problem. That probably isn't your only problem. Brandon (14:39) Yeah, you don't want to say asking for it, but yeah. AI might be discovering these and other problems. We've seen multiple open source projects shut down bug reports because they're getting flooded with AI-discovered issues, some of which are completely legitimate. It feels like this is the summer of AI and cybersecurity convergence. The Trump administration is now haranguing OpenAI, just as much as they've been putting pressure on Anthropic not to go public with models that could be a threat. It feels like a big moment for cybersecurity, and a lot of it's being driven by AI. What do you guys think about the current moment of this pairing? Jessica Lyons (15:23) It's a perfect storm because you have these models that are really good at finding vulnerabilities and developing exploits. That's leading to a bunch of internally, with security companies finding their own bugs and pushing out patches, so then all the sysadmins need to work extra hard. Plus open source, which is a huge issue here, you have all of these bug hunters looking for and finding all kinds of vulnerabilities on open source projects. They push those to maintainers who a lot of times are volunteers themselves and they're not getting paid. There's maybe one of them for this huge project. They have this huge backlog of AI-enabled threat reports that they need to deal with. It's just coming at people from all ends here and yeah, a lot of that's because of the AI models. Brandon (16:35) Is NIST still backed up with the national vulnerability database? Last I heard they were some months behind. Not only that, but we've got a lot of big threats out there that might not be being made public because they're buried too. It's quite the mess. So before we wrap up, I did wanna touch on, like you mentioned, Jess, and and we've seen this in a number of stories that Avram's written recently for the Pwned column. AI is creating a headache for a lot of people, but there's still a group of people that are stuck dealing with this and it's sysadmins, right? It's the security professional, it's the sysadmins, NShuman human problems can still be kind of the root of this. Avram, you wrote a number of stories in your Pwn column that it was it was like all these problems, these security problems come back to bad password hygiene, administrator laziness. I mean, what are some of the things you've kind of seen? Avram Piltch (17:35) Hubris. There was a CEO that wanted to make sure that he could get in and change anybody in the company's email. We could talk about whether that's a good policy in the first place, but his method of doing it was to have an Excel file on his desktop with all of the usernames and passwords of all the employees so that if he sent out an email he shouldn't have, he could go into their inboxes and delete it. But conversely that was a wonderful target for people outside the company to find all the names and passwords they needed, even though there's software out there that will allow an admin to go into an inbox anyway. This was completely unnecessary, but things like that are constantly happening. We had another incident where somebody hadn't deleted a former employee's username and password, perhaps their password was in a breach somewhere or somebody guessed it. But Greg from auditing hadn't worked there in like ten years, but somebody used his credentials to break into a city's water system and start trying to interfere with things having to do with the water supply. The best AI in the world isn't needed to find these problems and couldn't be used to prevent them. The human element is still the biggest problem in security. Maybe when I have my agent talk to your agent, they will be much better behaved than when people get involved. But coming up in a future Pwned column, I talked to a red teamer who said he's basically able to break into almost any facility by acting like he belongs there. Brandon (19:51) That's a classic trick. It's the same thing I've said for a long time about security: you've got new tricks that come up, you've got new things like AI, but there's nothing new under the sun at the end of the day. The best way to gain access to a system isn't to swordfish your way in a la Huge Jackman, it's a con. It's lying, putting on a reflective vest, and having a clipboard. It's relying on password breaches and people being bad about their password hygiene. That's what happened with the Clue issue: an old password that was in a breach somewhere that someone used to get into the system. Nothing new under the sun. Jessica Lyons (20:26) Yeah, we see that all the time. Brandon (20:34) And it's probably going to keep being that way, and I bet we are probably going to be talking about it on the Kettle for months and years to come. Invariably, until AI fully takes over the computer world and we're all just sitting in our WALL-E couches being perpetually entertained by all these sentient machines. But until then, we will be here to talk about these things. Thanks for joining me, guys, and we will see you all again soon. ®

Microsoft has extended Windows Server 2022 hotpatching into 2027, beyond the end of mainstream support for the operating system, as confirmed on its Windows Release Health dashboard. Mainstream support for Windows Server 2022 ends on October 13, 2026, with extended support running to October 14, 2031. Hotpatching generally ends with mainstream support, but Microsoft will keep updates flowing into next year for Windows Server 2022 Datacenter: Azure Edition - likely mindful of users who depend on the technology. Hotpatching is a boon for Windows Server administrators, allowing security updates to be applied without scheduled server downtime. There's still a cumulative update once a quarter that requires a reboot, but otherwise the relentless monthly reboots required by Microsoft's updates are avoided. According to Microsoft, the technology works by patching the in-memory code of a running process. This means no restart is needed. Linux administrators might point to tools like Ksplice, which can apply patches to a running kernel without requiring a reboot, but anything that reduces the time between the discovery of a vulnerability and patching is a good idea. Microsoft would prefer administrators move to Windows Server 2025, the latest Long Term Servicing Channel (LTSC) release, but the extension gives Azure Edition users a reprieve from monthly reboots until 2027. The hotpatching extension only applies to Windows Server 2022 Datacenter: Azure Edition. On-premises Windows Server 2022 users remain out of luck, though Microsoft has never been shy about nudging users toward Azure. Hotpatch updates were also introduced for Windows 11 24H2 Enterprise clients in public preview in 2024 and are now the default for Windows Autopatch.®

Nissan has joined the growing list of Oracle customers cleaning up after a cyberattack, warning employees that payroll records, bank details, Social Security numbers, and other personal data may have been stolen. In a filing submitted to the California Attorney General on Friday, Nissan Americas said Oracle had informed it of "a cyber event" involving the personnel records of "hundreds of companies." The automaker said it later learned Nissan had been "specifically targeted" in the attack. A notification sent to current and former employees, seen by The Register, says the company believes attackers accessed a haul of sensitive info, including contact and banking information; Social Security, Social Insurance, or other national identification numbers; financial and tax records; and dependent and beneficiary details. Current and former employees in the US, Canada, Mexico, and Brazil may have been affected, although Nissan said it is still working to determine exactly whose information was exposed. Nissan said it kicked off its incident response plan after learning of the intrusion, brought in outside security specialists, and has been working with Oracle while keeping law enforcement informed. It plans to offer affected individuals credit or dark web monitoring where available. The company has also put a few extra locks on the payroll office. Employees can now access pay slips or update direct deposit details only from a corporate network or through a secure VPN, while Nissan adds extra identity checks before processing payroll requests. The accompanying employee FAQ pins the incident on "an unknown vulnerability in Oracle's PeopleSoft software" and says the campaign is affecting "hundreds of companies and institutions." The document offers no clue as to what the vulnerability is, whether Oracle has patched it, or whether the compromised PeopleSoft environment was hosted by Oracle or by Nissan itself. The disclosure lands just weeks after researchers linked the ShinyHunters extortion crew to a wave of attacks exploiting a PeopleSoft zero-day. More than 100 organizations and roughly 300 PeopleSoft instances were reportedly compromised before Oracle issued mitigation measures, with the gang claiming to have made off with HR, payroll, and other enterprise data. Oracle has said little publicly about the reported attacks and didn't respond to The Register's questions, even as organizations have continued to disclose being caught in the fallout. Nissan has not confirmed that the incidents are connected, though its California filing lists the breach period as May 27 through June 9, broadly aligning with the previously reported timeline. The carmaker didn't respond to questions about how many current and former employees are affected, when Oracle first notified it of the breach, and whether the compromise was limited to Oracle-managed systems. ®

It's going to be a "messy" summer for security folks, especially when it comes to fixing the open source code that underpins their organizations. That's according to Dan Lorenc, CEO and co-founder of Chainguard, a software supply-chain security company leading Athena, a newly formed coalition of about two dozen companies that wants to make the process of finding and fixing open source bugs "as easy to consume as possible." The members have committed to using AI to prevent attacks on open source software. In addition to Chainguard, other founding member companies include BNY, Cisco, Cloudflare, Corridor, DepthFirst, Docker, JPMorganChase, Kyndryl, LTM, and PwC. Many of these member companies are also partners with Anthropic's Project Glasswing and OpenAI Daybreak, which allow them to try out the pair's most advanced bug-hunting models. The coalition accepts vulnerability findings generated by all frontier models, according to Lorenc. Athena has already processed more than 20,000 findings and developed over 2,000 patches across 500 open source projects. In about three weeks, the coalition's first wave of bug disclosures will begin. "This is going to be a messy summer for everyone," Lorenc told The Register in a phone interview. "I know there's still a percentage of people who think it's all fake and marketing," he said, talking about the newest, most advanced frontier models like Anthropic's Mythos and OpenAI's GPT‑5.5‑Cyber. "The stats and data we're seeing are so scary – if you just keep running scans on the same libraries and same code, it just keeps finding more [vulnerabilities]," Lorenc said. "We haven't seen that curve start to bottom out yet." Chainguard isn't part of Glasswing or Daybreak, but many of its customers and partners are. "Put yourself in the shoes of someone with Glasswing access," he said. "You get this crazy, new model that can find vulnerabilities everywhere, that no one had seen and you had missed for years with all of your other tooling. You run it on your code, and it finds tons of stuff in your first-party code, the stuff that you've written, and you fix all of that." After running Mythos Preview on all of your organization's proprietary code, imagine pointing the model at an application. Most modern apps contain a mixture of code from different sources, mostly third-party. According to Lorenc, 95 percent of the code in any of these codebases is open source. "When you run [advanced models] at the application level, you find a ton of vulnerabilities in open source code that you can't fix for yourself the same way you can that first-party code," Lorenc said. "So then you're left with: what to do?" By now, most people are familiar with vulnerability disclosure processes and know they need to report these flaws to open source project maintainers. "But when the numbers start getting this large, and you're finding thousands of these [bugs] at a time, and they're across tons of projects you didn't even know you were using before you ran this tool, and you don't even know how to contact the people, you kind of get stuck," he said. The only guarantee in the entire disclosure process is that attackers are moving quickly and the time to exploit – that's the time between a CVE's public disclosure and first confirmed in-the-wild exploitation – has essentially collapsed. A clearinghouse for bug reports This may mean that your application is vulnerable to attack even before someone develops a patch. "Then you're putting yourself at risk – and you were already at risk before you ran these scans, but no one else knew about it," Lorenc said. "In an unintended way, [AI] has created this pickle for everyone." In May, Anthropic said it used Mythos Preview to scan more than 1,000 open-source projects, which also underpin much of its own infrastructure, and found an estimated 6,202 high or critical-severity vulnerabilities in these projects. "It's a super awkward, strange world and timeline we are all living in," Lorenc said. "There's a ton of pressure because all of the frontier models are getting better, and the open models are getting better, and they're going to be able to start discovering these at the same time, too. So, that's what we're trying to help with: to be that clearinghouse for critical industry." Athena coalition members submit vulnerabilities they find in open source code using any frontier model. Sometimes they find these bugs while scanning their own apps. In other cases they discover them after pointing Mythos or GPT‑5.5‑Cyber at a commonly used library, Lorenc said. The companies submit a full report to Chainguard, which acts as a clearinghouse, deduplicating, correlating, and addressing findings from members in batches across entire libraries, hardening them against classes of vulnerabilities instead of just one bug. Affected projects are rebuilt as private, hardened versions available to Athena members through Chainguard Libraries before vulnerabilities are publicly disclosed – and hopefully addressed upstream – a month later. For maintainers that can't make a permanent fix, Athena acts as a "maintainer of last resort," according to Lorenc. On Thursday, the Linux Foundation joined the effort and announced Akrites, an industry coalition to defend open source software against AI-enabled threats, by finding and fixing vulnerabilities. Akrites establishes a shared Security Incident Response Team (SIRT) and a standardized Coordinated Vulnerability Disclosure (CVD) process. Founding companies include Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft and GitHub, Nvidia, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone, and Zscaler. "As AI finds more vulnerabilities, the industry will rush to patch them. Without coordination, those fixes will fragment across different patches and forks, and maintainers who are already overwhelmed, unreachable, or haven't touched a project in years," Lorenc said, adding that Akrites provides a coordinated way to fix flaws upstream before criminals exploit them. Plus having a dedicated SIRT gives maintainers a single partner - and disclosure -to work with on remediation instead of a hundred uncoordinated reports. "Now the work is making sure there's always someone on the other end to catch them," Lorenc said. ®

It seems like nobody wants to carry a work phone and that includes even those charged with protecting the US president. The US Secret Service’s extremely lax mobile phone security practices - including using unsecured personal devices during mission operations - put America’s leaders’ and agents’ lives at risk, according to a government-issued report. Secret Service agents routinely used personal cell phones to communicate with law enforcement and each other, including during protective operations in the US and overseas, because their government-issued devices lacked the capabilities they needed to perform their missions, according to a federal review ordered after the 2024 assassination attempt against President Trump in Butler, Pennsylvania. Even when Secret Service employees did use government-furnished equipment (GFE), these mobile devices didn’t have sufficient security to “ensure real-time, continuous protection from cyberattacks by foreign adversaries or individuals,” according to a report by the Department of Homeland Security inspector general. The inspector general’s investigation also found vulnerable apps on these GFE mobile devices. In addition to being prohibited - Homeland Security policy only allows Secret Service employees to use GFE devices for official business - using personal cell phones is especially bad from a cybersecurity perspective. As we have seen time and time again, government employees’ personal devices and private communications provide highly attractive targets for foreign spies or even homegrown criminals plotting attacks against elected leaders. Secret Service agents’ phones can also reveal mission-related details, geolocation - and, by proxy, the US president, vice president, and visiting heads of state’s geolocations - as well as photos, contacts, and other personal information such as family members and home addresses. Since these personal devices are not managed or secured by the US government, it's much easier for attackers to plant surveillanceware and other malware on them. “If a personal device is jailbroken, infected with malicious code, or not up to date on security software, an adversary could intercept device communication,” according to the report. “Outdated and vulnerable apps could enable malicious actors to conduct surveillance, track locations, or record employees’ communications. Connecting to unsecured networks may also allow cybercriminals to access data or install malware.” The inspector general reviewed call and text logs from Secret Service GFE mobile device records from October 2022 through May 2025, and found more than 15,000 instances among 4.8 million calls in which employees sent and received calls from colleagues’ personal phones while working protective events. Investigators also examined travel vouchers for Secret Service employees who travelled internationally between October 2022 and April 2025. They found 30 employees who claimed reimbursement for using personal phones for official, government business. Most of these (23 of the 24 interviewed) said they needed to use their personal cell phones during nearly every foreign assignment. Plus, they used personal mobile devices as hotspots to provide internet access for government-issued laptops, or to access websites blocked on GFE phones. Even when employees did use government-issued devices on overseas trips, these phones also lacked basic security, the investigation found. For example: the Secret Service did not begin installing mobile threat defense software on any GFE phones until August 2025. Nor did the agency consistently wipe data from GFE devices after employees returned from international missions despite Secret Service policy requiring employees to do this within 24 hours of returning to the US. Do these 5 things As a result of its findings, the inspector general made five recommendations to improve mobile device security. These include implementing a formal policy to ensure government-issued devices have all the needed capabilities to ensure mission functions can be conducted securely, and also ensure all employees complete cybersecurity awareness training, as required by the Secret Service. The report also recommends the Secret Service office of the chief information officer do a better job communicating to employees that the use of personal devices is not allowed for official business, and implement controls to wipe all mobile devices returning from international missions. Finally, the inspector general also recommends an updated vulnerability testing policy be applied to all mobile app code. The Secret Service “concurred” with all five recommendations. We reached out to the Secret Service about the report and recommended actions, and a spokesperson declined to comment beyond a letter from Secret Service Director Sean Curran included in the report. Curran said, among other things, that in response to the inspector general’s findings, the agency made “several comprehensive enhancements to Secret Service communications policies and protocols to both mitigate the potential for adversaries to intercept and exploit Secret Service information, as well as further strengthen the protective environment.”®

A high-severity flaw in Amazon's AI coding assistant for Visual Studio Code meant that opening the wrong Git repository could allow an attacker to execute code on a developer's machine and potentially hand them the keys to the dev's cloud environment. The bug, tracked as CVE-2026-12957 and assigned a CVSS 4.0 score of 8.5, centers on how Amazon Q handled Model Context Protocol (MCP) server configurations. Wiz found the extension would automatically load a repository's .amazonq/mcp.json file and execute the commands it contained when a developer opened the project and activated Amazon Q. "The security model assumes the user explicitly configures these servers. After all, you're granting an AI assistant permission to run arbitrary commands on your machine. This should require informed consent," the researchers write. "The vulnerability arose when this assumption was violated: Amazon Q automatically loaded MCP configurations from .amazonq/mcp.json within the workspace – no prompt, no consent, no workspace trust check." MCP lets AI assistants launch local processes to carry out tasks. In Amazon Q's case, those processes inherited the developer's environment, giving them access to AWS credentials, API keys, authentication tokens, SSH agent sockets, and other secrets already loaded into the session. "The combination meant that a single malicious config file could execute arbitrary commands with full access to the developer's credentials – no user interaction required beyond opening the folder and activating Amazon Q," Wiz said. To prove the attack worked, Wiz built a repository with a malicious MCP configuration. Opening the project and activating Amazon Q caused the extension to execute a command against AWS using the developer's existing credentials. Amazon fixed the bug in version 1.65.0 of its language server, which powers Amazon Q's IDE integrations. Existing installations should receive the patched component automatically unless you've blocked automatic updates. "We would like to thank Wiz for collaborating with us on this issue. We have remediated this issue in language server version 1.65.0," Amazon said in an advisory, though it didn't respond to The Register's questions. Wiz argues the bug is less an Amazon problem than an industry one. More and more AI coding assistants are adopting MCP to connect models to local tools and services, allowing them to execute commands on developers' machines. According to the researchers, similar workspace configuration flaws have recently surfaced in other AI coding tools. It suggests attackers have found a new place to lurk: the hidden files that developers rarely think twice about trusting. ®

The Miasma malware campaign has claimed another victim, poisoning more than 20 versions of legitimate npm packages used by the Leo Platform and RStreams ecosystems as its operators continue refining their self-propagating supply chain worm. Microsoft Threat Intelligence said in a post on X that the attack began late on June 24 after attackers compromised an npm maintainer account, "czirker," and used it to publish poisoned updates to more than 20 packages in a "coordinated, fully automated operation completed in under three seconds." Like earlier Miasma campaigns, the malware targets developer workstations and CI runners, hunting for AWS, Azure, and Google Cloud credentials alongside GitHub personal access tokens, Kubernetes secrets, HashiCorp Vault credentials, 1Password data, npm publishing credentials, and other sensitive information. It also scrapes GitHub Actions runner memory before committing the stolen data to a GitHub repository created through the victim's account instead of talking to a traditional command-and-control server. Stealing credentials is only part of the job. The malware also tries to republish any packages the victim is allowed to maintain, sidestepping npm's two-factor authentication and giving itself another route to spread. The malware has evolved too. Earlier Miasma variants relied on npm installation hooks, but according to Sonatype, this version takes a different route, hiding its payload elsewhere in the installation process. It also downloads and executes the Bun JavaScript runtime rather than running everything under Node.js, apparently in the hope of attracting less attention from security software. Miasma is proving difficult to stamp out. The campaign first surfaced in poisoned Red Hat npm packages earlier this month before the Mini Shai-Hulud toolkit landed on GitHub, making the malware available to anyone. Microsoft is urging organizations that installed the affected package versions to assume that developer machines and CI environments may have been exposed. Sonatype recommends checking dependency lockfiles, internal package mirrors, build caches, container images, and CI runners for lingering copies of the malicious releases before rotating credentials. Swap the secrets first, and there's every chance the attackers simply steal the replacements. ®

ON CALL Supporting IT and keeping it secure is a serious endeavor. Which is why The Register lightens up Friday mornings with a fresh installment of On Call, the reader-contributed column that shares your tales of tech support trauma. This week, meet a reader we'll Regomize as "Colin" who told us about a recent gig at a customer that decided to improve the security of its Microsoft 365 implementation – chasing the Secure Score that Redmond uses to rate resilience. "We spent a good amount of time working with the customer and agreed a rollout plan to ensure multi-factor authentication (MFA) was enabled across the board in accordance with a security baseline." Colin and his crew knew what to do, so when they flicked the switch on various upgrades, all went smoothly. Until it didn't. "The following morning, one of the senior directors of the company – who was allegedly the COO of a cybersecurity company – called our service desk and started yelling." Amid the yelling and accusations, Colin and his colleagues picked out an allegation that the company had been brought to its knees by the need to register for MFA, which had crippled an invoicing system and would surely result in ruin within a disastrously short time frame. "Once she allowed us to speak, it turned out that the problem only impacted three or four phones," Colin wrote. The support team investigated and quickly learned the real problem was with the invoicing software, which promised MFA support but relied on buggy software to make it happen. The director didn't care for that explanation and ordered an instant rollback that we understand remains in place. Colin found it stunning that the former COO of a security company wasn't willing to wait for a workaround, so delivered the desired result: no MFA, and worse security. He told us this client often made nonsensical requests, such as demanding that a particular engineer – who cannot drive – visit a remote site ASAP to fix a printer. On another occasion, the same person claimed Colin's work on M365 caused a power outage! Have you ever been told to make IT worse? If so, click here to send On Call an email so we can make the column better on a future Friday. ®

Chinese cybersecurity vendor Qihoo 360 claims it’s built an AI bug-finder that’s better than Anthropic’s Mythos model. CEO Zhou Hongyi revealed the model in a speech at the 14th Beijing Cybersecurity Conference, which Qihoo 360 organizes. Chinese media outlets have transcribed the talk, in which Zhou described Mythos as “equivalent to a ‘cyber nuclear weapon’,” because the USA’s ban on foreign nationals accessing the model gives America a tool with which to find flaws in software upon which other nations rely. Zhou thinks China needs equivalent capabilities as a deterrent, but suggested replicating Mythos is not a viable approach. “Mythos follows a typical large-scale model approach: the strongest model, the strongest computing power, and the strongest chips – a strategy of sheer brute force,” he said. “However, this path has an implicit prerequisite: your model capabilities must be sufficiently strong. Objectively speaking, domestically developed models still lag behind by 20 percent to 30 percent in underlying capabilities.” The CEO therefore thinks China can’t wait for its own models to catch up and needs to find another way to build Mythos-grade bug-finders. Helpfully, Qihoo 360 has found those alternative methods by distilling its 20 years of experience fighting cyber-threats and colossal malware library into security-specific models and agents. The company has put that to work in what Zhou described as a “multi-agent swarm.” “If the American approach is about cultivating a genius hacker, the 360 approach is about organizing a professional attack and defense team,” he said. “When faced with a target, the swarm doesn't perform single-point analysis, but rather collaborates: first, it models the threat and filters high-risk attack surfaces; then, it follows the data flow across files to discover potential vulnerabilities.” The company’s agents apparently “automatically build sandbox environments, automatically generate exploit code, and conduct real-world testing. The result is that every vulnerability is ‘confirmed’ rather than just suspected. After completing a task, the swarm also summarizes and reviews its performance, becoming smarter with each use. This is something a single large model can hardly do.” Qihoo calls this approach “Tulongfeng” and says it’s already finding flaws in open-source and commercial software. “We automatically discovered a Windows kernel privilege escalation vulnerability that had been dormant for five years, an Office remote code execution vulnerability that had been dormant for eight years, and an Excel vulnerability that had been dormant for 10 years, earning official recognition from Microsoft,” Zhou boasted. The CEO said the tool found plenty of flaws in OpenClaw – a feat that human researchers have also achieved. Zhou said Qihoo 360 has created another AI-powered security tool called “Yitianzhen” that automatically simulates potential attacks against an organization’s cyber-defenses, then suggests and/or implements remediations. The company has created an alliance of local cybersecurity companies to use it and create a bulwark against Project Glasswing – the group of entities Anthropic allows to use Mythos under controlled conditions. US authorities have sanctioned Qihoo 360 on grounds that it probably supplies China’s military. China's National Computer Virus Emergency Response Center (CVERC) often cites and publicizes the company’s research, sometimes in its documents that allege the US hacks itself to make China look bad. ®

A new self-destructing backdoor called Mistic used in intrusions since April appears to be linked to a criminal gang that compromises corporate networks and then sells that access to ransomware groups, according to security researchers. This backdoor, also tracked as MLTBackdoor, was first documented by Zscaler earlier this month, with the security shop suggesting the novel malware is “likely used in ransomware attacks to establish a foothold for lateral movement.” In a Wednesday threat brief, Symantec and Carbon Black threat hunters say the backdoor has been used to access multiple organizations' networks over the past few months, including those in insurance, education, IT, and professional services. Additionally, the security sleuths reported, “Mistic may be linked to the financially motivated initial access broker (IAB) tracked publicly as KongTuke (which we track as Woodgnat) and it was used in one intrusion that also involved the group's ModeloRAT remote access trojan.” KongTuke and other IABs don’t deliver the final payload – such as ransomware – to compromised companies. Rather, they break into company systems, and then sell that foothold to other criminals, like ransomware gangs. Symantec and Carbon Black arrived at their low-confidence attribution after at least one case where Mistic was deployed in close proximity to ModeloRAT, the Python-based remote access trojan KongTuke also developed. KongTuke has previously been linked to attacks from various ransomware crews including Qilin, Interlock, Rhysida, Akira, 8Base, and Black Basta. “Our Threat Hunter Team has separately observed ModeloRAT used in attacks that deployed Qilin ransomware, linking this tool to ransomware deployment,” Symantec and Carbon Black noted. Plus, Zscaler reported Mistic being delivered in a multi-stage ClickFix infection chain, which is another pointer to KongTuke, as the group is known to use that initial access technique. In one case that Symantec and Carbon Black responded to, Mistic was side-loaded through a legitimate file, MpExtMs.exe, and then loaded from a DLL named EndpointDlp.dll, which likely helped the backdoor blend in with legitimate software. Mistic has all the usual backdoor functionality: It can upload, download, move, rename, and delete files. It can also create new folders, and check for additional commands from the attacker-controlled command-and-control (C2) server. But here’s the stealthy part: it can run remote payloads from C2 directly in memory – so it doesn’t write malicious files to the hard drive – which helps it dodge file-based detection in antivirus and endpoint detection products. When the mission is accomplished, it then terminates and deletes itself. “The fact that Mistic executes in memory and also has a kill switch built in means that it is very stealthy, potentially allowing for long-term, stealthy access for attackers,” the threat hunters wrote. ®

Security firm Huntress allegedly has a turncoat insider leaking info to a ransomware operation, according to an ex-employee who took his grievances to social media after claiming the security shop tried to “silence” him with legal threats. And it all started with a Pinocchio GIF and clown emoji. Late last week, Huntress disclosed that it is among the “hundreds of Klue customers” compromised in the supply-chain attack, stating that “Huntress believes in radical transparency about security incidents, including when it affects our company.” Ben Folland, a former security operations analyst at Huntress who left the company in February, responded with a Pinocchio GIF and clown emoji - although, to be clear, his complaints about his former employer have nothing to do with the Klue incident. These stem from an earlier incident that Folland also detailed in a series of posts. According to Folland’s resignation letter, which he also shared on LinkedIn, he left the security firm for “personal reasons, and due to a conflict of interest,” with his last day of work being February 19. This conflict, Folland alleges, arose from his December discovery that “another Huntress employee passed communications from US law enforcement to a cybercriminal, DevMan, who is actively and publicly targeting my family and me.” DevMan is a ransomware operation that first emerged in April 2025 and uses modified DragonForce code. “Since December 2025, I believe Huntress has been actively trying to conceal a serious security incident from its partners, customers, and employees involving an insider who is still employed at the company,” Folland said in a LinkedIn post. The alleged insider was “caught by the FBI,” according to Folland, and continues to work as a Huntress employee. “The incident in question would cause significant reputational damage to Huntress and, in my view, continues to put clients at risk,” his LinkedIn post continued. “With an IPO on the horizon, it appears their priority was not transparency, but keeping this away from the press.” Folland also promised to publish, over the next two weeks, “evidence supporting the claims made in my resignation email,” such as communications with the FBI and those between the Huntress employee and DevMan, recorded phone calls, internal Huntress memos, and threats targeting Folland and his family. The Register reached out to Folland for more information and did not receive a response. “If you are an employee at a cybersecurity company, you should not be helping cybercriminals,” he wrote on LinkedIn. “You should not be informing them of active investigations. You should not be engaging in cybercriminal activity yourself.” We also contacted Huntress about Folland’s accusations, and CEO Kyle Hanslovan responded via a spokesperson. "A former employee raised concerns that a teammate exercised poor judgment in communicating with a cybercriminal,” Hanslovan said. “By nature of our work as security researchers, teammates occasionally need to communicate with possible cybercriminals to gather intel that ultimately supports our partners and customers,” he continued. “I appreciate the hell out of that former employee's concerns and we've taken them seriously every step of the way. I also have to make sure Huntress upholds its responsibility to protect the confidentiality of our teammates involved and the investigation underway.” Hanslovan also assured Huntress’ partners, customers, and employees that if he learns “new information that changes our assessment of the current situation, I will take quick and appropriate action.” In a more direct response on Reddit, Hanslovan said he “firmly disagree[s]” and doesn’t “understand Ben's accusations.” His company “strongly disagree[s] with this ‘insider’ narrative,” he wrote. “We sure af didn’t prioritize an IPO over the safety of our partners, customers, or team.” And about the FBI allegations: “Some aspects of this matter involve ongoing active coordination with law enforcement and legal proceedings that prevent us from providing a complete public account,” Hanslovan wrote. “We're not gonna litigate this on LinkedIn with Ben but will likely publish some form of official comms to make our stance clear for those needing something more than my reddit reply.”®

PWNED Welcome back to PWNED, the weekly column where we school ourselves on others' security failures. This week, we’ll learn about a school where the entire network was like an open-book test … and the IT department got a zero. Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity is available upon request. Our tale of academic pwnage comes courtesy of a reader we’ll Regomize as Nathan. Nathan was 17 and attending sixth form at a UK school when he found a treasure trove of admin privileges and data at his fingertips. One day, our hero connected his laptop to his school’s Active Directory domain. There was no admin authentication required and Nathan was able to see domain controller tools in view mode, look at policy maps, and so on. Nathan then browsed the directory and located the domain administrator account. The password, “horse fence ditch,” was written right in the description field, where anyone with access to the network could view it. There were also backup accounts with passwords such as “bd” and “bigbaddog.” Once he had full God mode enabled, Nathan said, he could see student and staff data, gain Remote Desktop access to any server or domain controller, and even access LanSchool, a popular classroom management app. “I could've accessed sensitive leadership docs, reset passwords, deleted accounts, wiped the whole network, etc,” Nathan told The Register. Moreover, the entire system was synced with Google Workspace, so Nathan had access to user mailboxes as well. He even found firewall settings, security policies he could change, and keystroke histories. Because Nathan was a student and did not want to get in trouble at school, he didn’t actually use any of these privileges. He kept his head down and graduated from school without incident, but also without reporting the vulns, which might still be in place today for all we know. So what can we learn from this tale of academic malpractice? First, as we learned a few weeks ago, do not store passwords in description fields for Active Directory. In fact, do not store passwords in cleartext anywhere without serious controls! Second, Nathan should not have been able to see Active Directory domain controller tools. And it might also have helped if Google Workspace had different admin credentials. Imagine the restraint required not to change people's grades, take over their computers, or delete data. Would you have been able to exercise the same level of discipline as a 17-year-old? ®

Australia’s Security and Intelligence Organisation (ASIO) has established dedicated teams to counter nation-state attacks on critical infrastructure, the org’s director general Mike Burgess revealed yesterday. “We discovered nation-state hackers had compromised the network of an Australian critical infrastructure provider,” Burgess said yesterday in remarks accompanying the release of ASIO’s annual threat assessment, a task it performs in its role as Australia’s equivalent to the FBI and MI5. “ASIO assessed the hackers were preparing for sabotage. They weren’t planting ‘digital dynamite’ as such; they were mapping out the network and maintaining access so they could cripple it at a time of their choosing.” “In this case, a state-sponsored group didn’t just achieve access to the Australian critical infrastructure provider, it successfully acquired credentials – login details and passwords – for active users of the networks, including the IT professionals guarding it,” he added. Burgess said ASIO “identified, tracked and attributed the hack, and worked with the victim company and our security partners to remediate the compromise – work which is ongoing.” “The scale of this activity – led by one nation-state in particular – is difficult to overstate,” he added, before saying Australia is not alone in facing such attacks. “We struggle to find a single country in our region that has not been compromised by this state’s cyber apparatus.” He described cyber sabotage as “an evolving threat. I have established dedicated teams to counter it.” Burgess also shared an example of espionage targeting Australia’s military to gain information about the AUKUS pact – the US/UK/Australia defense collaboration that will see The Land Down Under acquire nuclear submarines, and which also includes collaborations around information technology capability, and intelligence activities. “A spy from a foreign intelligence service approached an Australian security clearance holder online, pretending to be from a consulting company,” Burgess revealed. “The spy paid the official to write two reports on Australia’s relationship with our Pacific neighbours, and then, thinking he’d been hooked, offered money for inside information on AUKUS.” The Australian official became suspicious, reported the incident and conducted interviews with ASIO during which Burgess said the spy agency “gained valuable insights into the foreign service’s information gaps and tradecraft.” The Australian official even handed the money they were paid by the foreign spy to ASIO. “In effect, ASIO disrupted the foreign intelligence service’s operation and made them pay for it,” Burgess crowed. ASIO then scored another win. “My officers borrowed the phone from the official and rang the so-called consultant in her home country. Thinking it was her target, the spy picked up and got a very unwelcome surprise when she realised she was speaking to ASIO,” Burgess said. “We demonstrated we knew exactly who she was, demanded she cease targeting Australian citizens, stated we have zero tolerance for spying on AUKUS, provided a quick overview of Australia’s espionage laws and pointed out the Director-General reserves the right to speak publicly about these matters. At that point the spy hung up.” ASIO officers later mentioned this incident to members of the foreign intelligence service that ran the op. Burgess seems to think that officers at that foreign agency may not have told their superiors about the op failing. “In case they did not report it up – I’m confirming it now,” he said. Burgess also pointed to abuse of online spaces continuing to represent a threat to Australia. “Instead of being radicalised by associates in the real world, individuals are often being radicalised by strangers online,” he said. “Instead of being radicalised over months and years, individuals are increasingly being radicalised in weeks. Instead of being radicalised as adults, individuals are all too often being radicalised as minors. Instead of gathering in prayer halls or backyards, radicalised individuals are frequently gathering in encrypted chat rooms.” “And, instead of spending time and resources planning sophisticated attacks, radicalised individuals are moving to low-capability attacks with little or no warning,” he said. “Traditional groups such as Islamic State and al-Qa’ida and their affiliates are growing their capability to conduct and inspire attacks, enabled both by permissive geographic and online spaces.” Burgess revealed ASIO has “resolved” 14 “significant-terror related cases” since the December 2025 terror attack at Sydney’s Bondi beach, and 31 “major terrorism plots” since 2014. He said ASIO is now “aggressively adopting new tools and techniques – including artificial intelligence – to navigate our security environment,” and invited Australians to work for the agency, perhaps as offensive hackers. “All ASIO’s teams contribute to our mission and every ASIO officer makes a difference, whether you collect the dots or connect the dots, run cables or run sources, code networks or penetrate networks,” he said. ®

It’s looking like another tough week (month? year?) for Switchzilla amid reports of new serious vulnerabilities under attack. First up is a server-side request forgery bug in its Unified Communications Manager tracked as CVE-2026-20230. Cisco disclosed and patched this flaw in early June. The comms control platform doesn’t properly validate some HTTP requests, and an attacker could exploit this bug to gain root privileges on a compromised device. At the time, Cisco said that a proof-of-concept exploit was available – and now it seems unknown miscreants are putting that exploit code to use, with threat intel company Defused warning that it observed miscreants exploiting CVE-2026-20230 over the weekend. “The observed chain abuses the WebDialer SSRF to deploy a rogue Apache Axis service, uses that service to write a first-stage JSP file-writer, then drops a second-stage command-execution shell under /platform-services/axis2-web/,” the firm noted on LinkedIn. Cisco Catalyst SD-WAN zero day Then, a Mandiant advisory on Wednesday warned that a Cisco SD-WAN zero-day tracked as CVE-2026-20245 was exploited much earlier than initially disclosed, including at a communications service provider where the attacker elevated a compromised admin account to full root-level access. While the Google-owned threat hunting biz said it can't assess the full scope of the intruders' post-compromise activity, this SD-WAN device compromise could have been dire, potentially giving the attacker total visibility across an entire corporation's internet traffic. This is what makes SD-WAN zero-days such a hot target for government-sponsored spies looking to set up shop for long-term snooping activities. It also explains the rash of attackers battering Cisco SD-WAN devices since the start of the year. Cisco had issued an advisory for CVE-2026-20245 in early June, admitting that attackers had a head start on abusing this security hole. “In June 2026, the Cisco PSIRT became aware of exploitation of this vulnerability,” the vendor said at the time. In a Wednesday report, however, Google’s Mandiant incident response and consulting biz reported that exploitation of this bug – Cisco’s sixth SD-WAN vulnerability listed as under attack since the start of the year, and the second zero-day in two months – began much earlier. “In early 2026, Mandiant identified a threat actor targeting SD-WAN infrastructure at a service provider,” Mandiant threat hunters Chester Sng, Pete Boonyakarn, and Logeswaran Nadarajan wrote. “After gaining initial access, the threat actor exploited a zero-day vulnerability (CVE-2026-20245) in Cisco Catalyst SD-WAN to escalate privileges from a compromised administrative account to root-level access.” The attacker gained initial access via an unauthorized peering connection, abusing the SD-WAN fabric to authenticate between network components and facilitate Secure Shell (SSH) access. In this case, they authenticated to the SD-WAN manager device via SSH using the vmanage-admin account on the same victim devices. Then, they changed the default password on the admin account, authenticated directly to the SD-WAN Manager web application interface using the admin account, and exfiltrated SD-WAN fabric configurations. Likely in an effort to cover their tracks and not get caught, the attacker changed the password of the admin account back to its original one before terminating their active session. Neither the vmanage-admin nor the admin accounts on Cisco Catalyst SD-WAN controllers possess root shell access, however. To gain root access, the attacker exploited CVE-2026-20245, which allows an authenticated, local attacker to execute arbitrary commands as root by supplying a crafted file to the vulnerable system. The attacker uploaded a file named evil_tenant.csv that contained the exploit payload. Upon execution, the digital intruder created a user account named troot with full root privileges. Mandiant says it later observed the miscreant accessing this new troot account from the admin account using the substitute user command. The Register reached out to Cisco about the reported exploitation of CVE-2026-20230, and Mandiant’s investigation into CVE-2026-20245. The company pointed us to its June advisory on the latter matter, and is working on response to our first question. ®

Microsoft, its friends, and international law enforcement - with an AI assist - disrupted two widely used pieces of malware and their infrastructure, in what Redmond describes as a novel approach to cybercrime disruption that targets the cyberattack supply chain instead of a single tool or service. “What’s new is how we’re combining AI analysis with an expanded use of that law,” Steven Masada, assistant general counsel for Microsoft’s Digital Crimes Unit, said in a Wednesday blog, referring to the Racketeer Influenced and Corrupt Organizations Act (RICO). Typically Microsoft uses RICO and other US laws to take legal action against a single cybercrime service or infrastructure. The disruption involved the takedown, suspension, and blocking of more than 200 domains and command-and-control (C2) servers that formed the backbone of StealC and Amadey infrastructure. Multiple security companies, including ESET, BitSight, Mitsui Bussan Secure Directions (MBSD), IBM X-Force, and Proofpoint, also played a role in dismantling the alleged operations. Combined with the earlier SocGholish disruption announced last week, a Europol-led law enforcement coalition flagged and restricted cryptocurrency assets valued at more than $47 million and recovered about 27 million stolen credentials. StealC and Amadey are two separate malwares developed by different criminal crews, but they used the same infrastructure and were operating in concert. StealC collects multiple browser credentials and cookies, cryptocurrency wallets, chats from messaging apps, and other sensitive data, and exfiltrates the stolen goods to a C2 server. It also works as a secondary loader, allowing criminals who rent the stealer to download additional malware on compromised devices. Amadey is a malware-as-a-service used to deliver StealC and other stealers, plus other types of malware including remote access trojans, cryptominers, and ransomware. In just the first two weeks of May, Amadey and StealC were linked to more than 140,000 infected computers globally, according to Microsoft. “It’s no longer enough to go after threats one by one,” said Masada. “We need to interrupt how the attacks are put together.” In this case, Redmond’s investigators used Copilot and other AI tools to analyze both malwares and their infrastructure, “asking questions in plain English instead of manually combing through complex code,” Masada wrote. “That helped surface key details, uncover hidden data, and test findings in a fraction of the time, turning what would have taken hours or days into minutes and enabling the team to spot connections faster.” One of these key details: both Amadey and StealC used the same infrastructure. This allowed Redmond’s legal team to treat both malwares as part of a single conspiracy under RICO and bring civil claims against five defendants allegedly involved across both operations. “Defendants comprise a group of cybercriminals operating a Malware as a Service enterprise that leverages malicious software commonly known as the Amadey Malware Suite and StealC Malware Suite (the "MaaS Enterprise"),” the court documents say. “Through the Maas Enterprise, Defendants and their accomplices have victimized hundreds of thousands of innocent computer users, including many users of Microsoft's software and services.” ®

The Metropolitan Police Service (MPS) will start using static live facial recognition (LFR) cameras in London's West End and Soho by the end of this year following a six-month pilot in the south London borough of Croydon. Static LFR involves the police temporarily attaching cameras to lampposts or similar infrastructure, with the feeds monitored remotely and officers on the ground stopping people whom the technology matches to images on its watchlist. The MPS said that each of the 24 deployments in central Croydon between October 2025 and March 2026 used a bespoke watchlist created up to 24 hours in advance and deleted afterward. Civil liberties campaign group Big Brother Watch, which in April lost a High Court challenge to police use of LFR, said the force was rushing ahead with deployment before Parliament has passed legislation regulating the technology's use. "We are calling on the Met to stop this experiment until, at least, Parliament has spoken," Jack Coulson, the group's head of advocacy, said in a press release. "Policing by consent is a cultural inheritance we must protect. Permanent biometric surveillance of the public square is incompatible with that ideal." He highlighted the case of Alvi Choudhury, a Southampton man arrested and held for ten hours in January after a retrospective LFR system run by Thames Valley Police matched him to a crime committed in Milton Keynes, a city he had never visited. "It is predictable, given the technology's racial bias, that Mr Choudhury was confused for another Asian man," said Coulson. The MPS said that in Croydon more than 470,000 people walked past the LFR cameras, leading to 173 arrests and one false alert, which resulted in officers stopping someone without arresting them, realizing the mistake, and letting them go. The force added that one of those arrested, a registered sex offender who was communicating with a child under 16, was subsequently sentenced to two years in prison in May for breaching a sexual harm prevention order and making indecent images of children. MPS Commissioner Mark Rowley said on June 24 that the force planned to "significantly step up our use of technology to fundamentally change how we protect the public" through the use of live LFR, a city-wide emergency services drone network, and AI to analyze the footage from the capital's one million CCTV cameras. Rowley added that the force needs to spend more on technology but its budgets for doing so have been repeatedly cut, with spending of around £6,000 per person compared with budgets of more than double that at some government agencies. Earlier this month, the commissioner said the MPS would have to cut around 700 frontline posts after London's deputy mayor for policing and crime, Kaya Comer-Schwartz, refused to approve its plan to award a major contract to controversial US supplier Palantir. ®

Japanese telco KDDI has messed up by allowing an attacker to access systems powering an email service it manages for itself and other local ISPs, and which stores info on up to 14.2 million users. The company yesterday posted a confession [PDF] that it detected unauthorized access to the email system it offers to third-party customers on June 17th. Machine translation of the confession suggests that KDDI investigated the situation and found attackers exploited a vulnerability in third-party software used on the email service, without claiming that vuln was a zero-day it had no chance of defending or an explanation of why it was running vulnerable software. There’s some good news because KDDI was able to prevent further intrusion on the same day it noticed the attack, and says it has bolstered its defences to prevent future intrusions. But the carrier also fears that up to 14.2 million email addresses and passwords may have leaked and therefore warned that third parties may have obtained personal data. Thankfully, the company had hashed and encrypted the passwords – so users only have to fear phishing and identity theft, instead of something nastier. However, some of the data KDDI thinks may have leaked pertains to dormant accounts or others that users cancelled, meaning some potential victims will be hard to contact if the attackers have indeed stolen data. KDDI is one user of the hacked platform, and also provides it to Japanese ISPs STNet, JCOM, Chubu Telecommunications Co., Nifty Corporation, and BIGLOBE. Those companies now get to explain KDDI’s failure to their own customers, and perhaps also have the chance to revisit any other outsourcing deals with the carrier. Others who rely on KDDI to provide them with various services also get to ask the company some stern questions about whether its other platforms are secure. The carrier, meanwhile, says it’s informed the relevant authorities of the situation, but is yet to complete an investigation so remains unaware of the full extent of the mess. ®

Sometimes it takes a while to detect a vuln. A 29-year-old, Heartbleed-style vulnerability in Squid, a popular open-source caching proxy server, silently leaked users' plaintext HTTP requests and potentially revealed sensitive data, including credentials and session tokens, for decades - until AI (and a few humans) saved the day. A security researcher and Mythos Preview found the flaw and reported it to project maintainers, who fixed the code earlier this month. Squid is widely used by large corporations, schools, and internet service providers to cache, filter, and monitor network traffic, and Calif.io researcher Lam Jun Rong said he came across the open source proxy while attempting to connect to the internet on a flight. “As you might expect, the version of Squid deployed on that plane was released nearly 10 years ago and is affected by the vulnerability I'm about to share with you,” Rong wrote in a blog post about the bug, which he dubbed Squidbleed and investigated with help from Anthropic's Claude Mythos Preview. Rong reported the bug, tracked as CVE-2026-47729, to Squid’s maintainers back in April, and it’s fixed in Squid v7.6, released June 8. The Reg readers may remember Calif from their earlier HTTP/2 Bomb research, uncovered by OpenAI’s Codex agent, and the AI bug-finding firm also collaborated with OpenAI on its Patch the Planet initiative, announced on Monday. According to Rong, Squidbleed leaks internal memory from every version of Squid in its default configuration with two conditions. First, Squid has to be able to read and inspect the network traffic, so it must be handling cleartext HTTP (not HTTPS) or be deployed in TLS-terminating setups. Additionally, the proxy must be allowed to reach an attacker-controlled FTP (File Transfer Protocol) server via TCP port 21. FTP is an outdated protocol for moving files between machines, and Squid supports it - which is where the problem lies. The bug exists in Squid's FTP directory listing parser, and it was injected into the open source code as a commit (bb97dd37a) created in 1997 to support old NetWare servers. NetWare is a discontinued network operating system that was popular in the 1980s and 1990s, providing file and print services across local area networks before Windows and Linux servers became dominant. NetWare FTP servers also added extra whitespace between the modification timestamp and the filename, compared to most other FTP servers that just used a single spFace. The 1997 commit fixed this NetWare issue by instructing the code to skip the extra whitespace using this loop: while (strchr(w_space, *copyFrom)) ++copyFrom;. As Mythos Preview discovered, if an attacker's FTP server doesn't provide a filename after the modification timestamp, copyFrom points to the terminating NUL character at the end of the string. “strchr treats that terminating NUL as part of the string it searches, so it returns a pointer instead of NULL, and the loop never stops,” Rong explains. “It walks off the end of the buffer, and xstrdup copies whatever follows back to the attacker as a filename.” This results in a heap overread and can leak HTTP requests that often contain passwords or API keys, and Rong demonstrated this exploit in a proof of concept. “The patch is simple: check for the null terminator before calling strchr,” Rong wrote. If you use Squid, make sure to download the June release to fix this flaw. Also, as Rong suggests, you should disable FTP unless there’s a “specific, unusual need for it.” Chromium-based browsers stopped supporting FTP years ago and for good reason. This means “most organizations running Squid are getting close to zero legitimate FTP traffic,” the security sleuth noted. “Turning it off removes this entire attack surface for free.”®

The leaders of intelligence agencies from the Five Eyes nations – Australia, Canada, New Zealand, the USA and the UK – have together issued strongly worded advice calling for leaders to nail cybersecurity basics or fall victim to ruinous AI-powered attacks. “The rapid pace of frontier AI development means cyber risk assumptions can become outdated in months, not years,” the advice warns, and calls for organizations to take rapid action to ensure their defenses remain potent. “While AI will help us improve cyber defence over time, it also accelerates the speed, scale, and sophistication of cyber threats,” the advice adds. “Frontier AI models are anticipated to exceed current industry expectations, fundamentally transforming both offensive and defensive cyber capabilities. The timeline is not years, it is months.” After all that scary stuff, the spook bosses offer some antidote: “Cyber resilience is integral to advancing business continuity, market confidence, and long-term value.” And how might one achieve that resilience? The Five Eyes have four suggestions: Understand and assess risk, readiness and accountability Prioritize foundational cyber security practices and controls Empower cyber leaders with authority and resources Stay actively engaged as threats and guidance evolve “Cyber risk can no longer be treated as a purely technical issue,” the advice points out. “This is a core business risk and leadership responsibility,” because breaches are inevitable and “Breaches will occur. Preparedness helps you contain them quickly and prevent escalation into major operational and financial crises.” The intelligence chiefs therefore want organizations to test their cyber resilience rigs. “It is not enough to have controls,” they write. “Leaders must be confident those controls will perform during a real incident. This requires reassessing long-standing trade-offs and using AI deliberately to strengthen defence – not just improve efficiency.” That last sentence is a rare moment of optimism in the advice and precedes a section in which the intelligence bosses observe “Organizations that integrate AI tools into their security operations can detect vulnerabilities earlier, improve software quality, monitor unusual behaviour, and respond faster to incidents – reducing both the cost and impact of incidents.” Readers of The Register might find this advice a little quaint given that infosec vendors have for years blathered on about the need for boards and bosses to take cyber seriously. It’s also been a couple of years since it became apparent that generative and agentic AI can fuel new and unusually potent cyber-attacks. Interest in that idea spiked in the eleven weeks since Anthropic revealed the existence of its powerful flaw-finding Mythos model and hid it behind a regwall lest criminals use it to swiftly slice holes in important software. The Five Eyes bosses address their advice to “leaders” – presumably bosses of substantial organizations – who may not have watched the Mythos mess unfurl while they worried about a global energy crisis kicking holes in their supply chains. The good news is that the spy bosses don’t think leaders need to learn a lot to cope with the advent of AI, as their advice suggests five practical actions they rate as “not new,” but “now urgent to reduce not only technical risk, but also operational, financial and reputational exposure.” For the record, those actions are: 1. Reduce your attack surface: Limit unnecessary system access and external connectivity. Challenge whether systems need to be exposed at all and isolate those that do not. 2. Accelerate patching processes: AI is shortening the time between vulnerability discovery and exploitation. Delays in patching increase risk, especially for operational systems with long update cycles. Prioritize security updates accordingly to manage risks. 3. Address legacy systems: Unsupported systems are easy targets. They are not just technical debt, they are strategic liabilities. 4. Review and strengthen identity and access controls: Limit who can access critical systems. Enforce strong authentication and regularly review permissions. 5. Prepare for incidents before they happen: Test response plans, train and prepare teams, and assume breaches will occur. Focus on fast containment and recovery. Take us, and this, to your leaders, dear readers. ®

The JavaScript development ecosystem may be a security nightmare, but it's also ripe for improvement. One such tool is the CVE Lite CLI, a free open source dependency scanner that helps reduce the risk of software supply chain attacks. It runs locally and provides actionable vulnerability fixes, if any are available. The tool, endorsed by OWASP, has recently been updated to include override auditing, which has the potential to avert transitive dependency vulnerabilities such as the March 2022 node-ipc package incident. The Shai-hulud software supply chain attacks that have been vexing security professionals for the past few months underscore how common it has become for threat actors to target the developer ecosystem, including CI/CD, package registries, and developer tooling. Software developers can reduce their risk by making sure the dependencies in their apps are up to date and free of known vulnerabilities, but that's more difficult than it should be. It's generally apparent when a particular library or module relies on a vulnerable dependency. But there isn't necessarily an available fix or clear remediation path. Modern JavaScript applications, like many other programming languages, allow developers to incorporate pre-existing solutions to particular problems in the form of packages – modular code that can be imported to implement particular functionality. These packages commonly depend on other packages, which is why they're known as dependencies. And these dependencies in turn may also depend on still more packages, referred to as transitive or indirect dependencies. A common security scenario goes something like this: A developer creates an app using some application framework. The app includes a dependency on "Package A", which itself relies on "Package B" – the transitive or indirect dependency in this situation. If the maintainers of "Package B" have deployed a patch addressing a reported CVE, but the maintainers of "Package A" haven't gotten around to incorporating that change into their code, apps incorporating "Package A" may be vulnerable to attack. Among other possible responses, affected developers may choose to create an override to replace the outdated, vulnerable version of "Package B," a configuration entry that can be removed once "Package A" gets repaired. But Sonu Kapoor, creator of CVE Lite CLI, explained to The Register that overrides represent a legitimate security tool but have limitations. "When a transitive dependency has a CVE and the upstream maintainer hasn't shipped a fix yet, you pin it via npm overrides, pnpm overrides, or Yarn resolutions," Kapoor explained in an email. "Once the vulnerability is addressed and CI passes, you move on. The problem is what happens after that." Kapoor recently added an override auditing tool to the CLI. When he scanned four popular JavaScript open source projects, he found that three of the four had broken overrides. "Cal.com has 90 override entries and 11 that are silently doing nothing," he said. "Jest has an override for its own package name pointing at nothing in the resolved tree. NoCoDB has entries using wildcard patterns that never matched any path in the graph. Next.js was the only clean one with zero findings, which tells me the tool is finding a real pattern, not noise." This can be dangerous, he said, when a project migrates between package managers (e.g. npm to pnpm) that looks for overrides in a different location. "npm reads from overrides, pnpm from pnpm.overrides, Yarn from resolutions," he explained. "When a team migrates package managers and forgets to move their security pins, the package manager silently ignores them. No error, no warning, the vulnerable package ships unconstrained." Kapoor said that AI coding assistants commonly advise developers to add override entries when asked to fix a transitive dependency vulnerability. "That advice is correct at the moment," he said. "None of them ever tell the developer to come back and verify the entry still works." CVE Lite CLI, Kapoor said, does not recommend overrides as the way to properly address a vulnerable dependency. "Overrides look like a security fix in package.json, but routinely outlive their purpose – they can point at packages no longer in the dependency tree, apply to the wrong package manager entirely, or shift to an unintended version on every install," he said. "The override hygiene feature exists precisely because of this failure mode: teams add an override to address a CVE, move on, and years later, the override does nothing while they still believe they're protected." ®