News

During a 48-hour period from June 7 to 8, developer Charles Jones's Google Cloud account registered $11,089.77 in charges - most related to the use of Gemini image-generation models. Yet Jones, a solo developer who runs programmatic SEO and insurance sites, told The Register that he doesn't have any workflow that generates AI images. Google suspended his account anyway. A suspension notification sent to Jones on June 7 justified the decision by stating his account "was engaged in abusive activity consistent with hijacked resources." "The root cause was attributed to a compromised firebase-adminsdk service account key," said Jones, who provided The Register with documentation of his exchanges with Google Cloud support. The notification advised Jones to report his concerns if he believed the account was compromised by a third party. He did so and took the steps required by Google to have his account reinstated. He disabled the service account and revoked the key. But the Google Cloud billing team has repeatedly refused to forgive the charges. As we reported previously, complaints about charges arising from fraudulent API key usage among Google Cloud customers are not uncommon. In February, a developer based in Vietnam claimed that a Google Cloud API key compromise had resulted in more than $82,000 in charges over 48 hours. A similar report claiming more than $10,000 in fraudulent charges surfaced a month later on Reddit. Regardless of where the fault lies – insecure practices by developers or insecure Google infrastructure – Google may choose to hold developers liable for unauthorized charges, even if the credit-card issuing bank has reversed the charge as fraudulent. At the same time, Google still hasn't publicly released a mechanism to cap Google Cloud spending. The company introduced Spend Caps for certain services as a private preview but hasn't made the service generally available. Other cost-limiting measures, like API-specific usage limits "aren't designed to act as a project-wide spending cap." Similarly, Budget Alerts "don't automatically prevent the use or billing of your services when the budget amount or threshold rules are met or exceeded." Google provides a workaround by allowing Budget Alert notifications to disable cloud billing, but warns that doing so means "resources might be irretrievably deleted." In March, Google introduced project spend caps for the Gemini API as an experimental feature, but at the same time the company said that spend caps have a 10 minute delay and customers are responsible for spending during that period – so the company's definition of cap is rather flexible. What's more, Google said its system "now automatically upgrades you to the next [usage] tier as your usage grows and your payment history matures." And higher tiers raise spending caps. This all means it can still be a challenge for Google Cloud customers to avoid unbounded financial obligations in the event of an account or API key compromise. Escaping that responsibility requires engaging with Google customer service in an opaque appeals process in which the company isn't required to demonstrate customer negligence or an audit trail. "Here's a question I can't get answered, and I think it's central to the whole pattern," Jones said. "Google's Trust & Safety was quick to alert me that a service account key was compromised — but I have been given no route, anywhere, to see HOW or WHERE that key was actually exposed. There is no trace, no log path, no forensic detail offered." Jones said he was the only person who had access to the VM where the compromised key resided and he insists that he followed the company's recommended security practices. "So how does a single-access VM produce a leaked service account key — and why is the burden on me to prove I secured something Google itself can't (or won't) show me how I failed to secure? Google is invoking its Shared Responsibility Model to deny the refund, but that model assumes a customer security failure Google has never demonstrated." The Register twice asked Google why it would deny a refund and what evidence it has that supports that decision. We've not heard back. ®

MeetingTV has sued Palo Alto Networks after its newly acquired Koi Security threat-intelligence biz published a blog that linked the video conferencing and webinar startup to a Chinese corporate espionage operation. The legal complaint filed against Koi Security, its researchers, and Palo Alto Networks alleges that Koi used an LLM to generate the threat report, the AI system hallucinated findings about MeetingTV, and the security shop then published those as facts in a December 30 blog. It accuses Koi of “reckless publication of an AI-driven cybersecurity report that falsely accused Plaintiff MeetingTV Inc. of criminal conduct including operating core infrastructure for a well-funded Chinese criminal organization running a large-scale malware and corporate espionage campaign,” according to court documents [PDF]. “The false attributions were the direct product of Koi’s unsupervised reliance on their proprietary ‘Wings’ analytical platform, which generated erroneous correlations between the Plaintiff’s business and an alleged cybercriminal actor they called DarkSpectre,” the lawsuit continues. A Palo Alto Networks spokesperson told The Register that the company “is aware of the lawsuit brought by MeetingTV Inc. regarding a threat research report published by Koi Security prior to the acquisition,” but declined to answer our specific questions about MeetingTV’s allegations and the Koi blog. “We believe Koi’s cybersecurity research reflects its commitment to identifying and exposing threats to users and enterprises, and we expect that this dispute will be resolved through the appropriate legal process,” the spokesperson said. Koi’s blog, which has since been silently edited to remove references to MeetingTV’s product called Zoomcorder, originally labeled the meeting recording service as a “public-facing front” for a Chinese criminal operation and said it lent “credibility to the infrastructure while serving as a monetization channel” - allegations MeetingTV disputes in its lawsuit. The blog also claimed the operation was behind a 2.2-million-user campaign stealing corporate meeting intelligence. As a result of the report, MeetingTV says, security companies and service providers around the globe blocked MeetingTV’s domains and services, labeling it as malware and command-and-control infrastructure. The startup’s founder and CEO, longtime entrepreneur Michael Robertson, told us the blocks are the only way he found out about the Koi report in the first place. According to Robertson, Koi did not reach out to MeetingTV prior to publishing its threat report. “Even after publishing they never contacted us,” he told The Register. “I was contacting the security companies one by one asking them to unlock us. Most never respond in any fashion, but one finally did respond and told us he was blocking us because of the Koi report and he gave us the url.” Robertson says he’s still struggling, as providers including Verizon and Palo Alto Networks, which completed its Koi acquisition in April, continue to block his startup. “If people on the internet are blocked from reaching your company, then that's a death sentence,” he said. “Plus all the LLMs now say we're working with Chinese cyber criminals. How will that ever get removed?” After the acquisition closed, Robertson emailed Palo Alto CEO Nikesh Arora directly and asked him to take action. “Now your company owns Koi and is continuing to publish and rely on the false report,” the email said. “Our domain and Google subdomains are blocked and labeled as malware and command and control by your company and others around the world … Take down the false report which is defaming us and in its place put a full retraction. Remove our domains from your own blacklist and help get them removed from others who are blocking us because of the Koi report.” A mysterious extension The December blog linked Zoomcorder to the Zoom Stealer campaign, which it attributed to the Chinese threat actor DarkSpectre, via a browser extension identified as "Twitter X Video Downloader." According to Robertson and the lawsuit, however, this extension doesn’t exist – and Koi “refused to supply information” about the software when MeetingTV requested it. “Koi’s single-actor theory rested on a fabricated technical ‘pivot’ – a single piece of software they repeatedly identified as the ‘Twitter X Video Downloader’ extension,” the lawsuit alleges. “This alleged extension was described as the critical bridge connecting the Zoom Stealer campaign (defined entirely by Plaintiff’s infrastructure) to ShadyPanda, core DarkSpectre infrastructure.” Robertson said he believes Koi used an LLM to generate the threat report, and it hallucinated findings about MeetingTV’s Zoomcorder product that the security shop published as facts. “They admit to using AI for their analysis,” Robertson said. “Maybe a human made it all up? Maybe it was AI? What's clear is that if the software doesn't exist, then even the most rudimentary analysis is impossible to do, yet they labeled our urls, services, and software as criminals.” The bigger picture in all of this, according to Robertson, is that we know AI systems hallucinate. Their findings should not be accepted as fact without any human review. “We're on the doorstep of an era where AI will be used to make critical life-altering decisions on people's lives: Did you pay your taxes, what your credit rating should be, will you get admitted to the University, do you qualify for the home loan, should you be on the no-fly list, etc.,” Robertson said. “Will these be made without human oversight? Will people have due process – see the accusations against them, present their own evidence, have a neutral arbiter? None of that happened in our case,” he continued. “They just declared us criminals and published it to the world.”®

They're not bad; they're just prompted that way. Sysdig threat hunters documented what they say is the first-ever documented agentic ransomware infection with an LLM - not a human - driving the entire extortion operation, from gaining initial access to compromising a production database server and destroying data. The security shop’s research team named the agentic intruder JadePuffer and said it gained initial access to an internet-facing Langflow instance by exploiting CVE-2025-3248, and then ran a fully automated attack. “The most striking characteristic, however, was the LLM's behavior,” Sysdig director of threat research Michael Clark said in a blog about the agentic ransomware and extortion operation. JadePuffer’s “self-narrating” payloads “contained natural language reasoning, target prioritization, and the kind of detailed annotations that human operators don’t often write but LLM-generated code produces reflexively,” Clark added. “The operation also adapted in real time, retrying failed steps within refined parameters. In one sequence, it went from a failed login to a working fix in 31 seconds.” After exploiting CVE-2025-3248, a missing authentication vulnerability in Langflow that allows remote, unauthenticated attackers to execute arbitrary Python on the host, the AI agent began scanning for and collecting secrets, including LLM provider API keys, cloud credentials “with explicit coverage of Chinese providers” including Alibaba, Aliyun, Tencent, and Huawei, while also scanning for AWS, Azure and Google Cloud Platform, cryptocurrency wallets, and database credentials. The AI also installed a crontab entry on the Langflow server to maintain persistence and call back to the attacker’s infrastructure every 30 minutes. JadePuffer’s intended target was a separate internet-exposed production server running a MySQL database and an Alibaba Nacos configuration service, we’re told. Nacos is an open-source service-discovery and dynamic configuration platform developed by Alibaba and used in the cloud provider’s microservices applications. The agent connected to the server's exposed MySQL port using root credentials, although Sysdig doesn’t know how the attacker obtained them. These credentials weren’t stolen from the victim’s environment. JadePuffer then attacked Nacos via multiple vectors including an authorization bypass flaw (CVE-2021-29441) and forging a valid JSON web token (JWT) using Nacos's default signing key. Additionally, using its root database access, the LLM injected a backdoor administrator into the Nacos backing database. It ultimately encrypted all 1,342 Nacos service configuration items using MySQL's built-in AES encryption function, and created an extortion demand, ransom note, Bitcoin payment address, and a Proton Mail contact: "YOUR DATA HAS BEEN ENCRYPTED. All NACOS configurations, REDACTED customer data, and REDACTED PII have been encrypted with AES-256.", "3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy", "e78393397[@]proton[.]me" However, according to the threat hunters, the victim can’t recover the encrypted data, even if they paid the ransom demand, because the agent escalated “from row-level deletion to dropping entire database schemas, narrating its own targeting rationale,” without backing up any of the encrypted data. There are a couple of things that security teams and vulnerability managers should do immediately to avoid being ransomed by this AI agent. First up: patch Langflow to a release that fixes CVE-2025-3248, and do not expose code-execution/validation endpoints to the internet. Also, don’t ever expose Nacos to the open internet, change its default token.secret.key, and upgrade to a release that forces a custom key. The threat hunters also recommend against running any AI orchestration servers with provider API keys or cloud credentials in their environment. While the AI agent didn’t use any especially sophisticated or unique techniques in this attack, the fact that an LLM “strung them together into a complete ransomware operation against neglected internet-facing infrastructure,” is notable, according to Clark. “The skill floor for running ransomware has dropped to whatever it costs to run an agent, and if that agent is running on stolen credentials through LLMjacking, the cost to an attacker is close to zero.”®

Security sleuths say last month’s FortiBleed campaign is tied to two separate ransomware groups, after they found evidence of one initial access broker group member logged in to two affiliate panels. SOC Radar’s Threat Research Unit (STRU) said at least one of the group’s 20 members was actively negotiating with victims, which it believes signals a direct link between the thousands of FortiBleed victims and the ransomware ecosystem. STRU spent weeks mapping FortiBleed’s infrastructure across hundreds of servers after the attack was disclosed. Due to an opsec failure in one of these servers, the team gained visibility into the IAB group’s internal files and logs, revealing that one of the individuals was logged into the affiliate panels of both the INC Ransom and Lynx ransomware groups. “Finding a single operator working both panels, using infrastructure traceable back to FortiBleed, is the clearest evidence yet that FortiGate credentials harvested through this campaign are being handed off, or used directly, for ransomware deployment,” SOC Radar said. Following examinations of both the IAB group’s internal logs, compromised endpoints, and claims made via the leak sites of INC and Lynx, STRU linked at least 12 ransomware attacks to FortiBleed victims so far. While initial reports pegged the number of successful attacks at more than 70,000, STRU said its data was derived from scanning 11,250 Fortinet portals, although more than 430,000 firewalls were targeted. Admin-level access was confirmed on 409 targets, and on 354 of these the attackers executed the full attack chain, compromising VPNs and gaining access to domain controllers and domain admin. STRU said the finding is significant because it shows how the exploit was not just an exercise in harvesting credentials, but an attack that feeds directly into the ransomware economy. “What this investigation shows is that FortiBleed isn’t an isolated credential-theft operation sitting off to the side of the ransomware economy, it’s feeding directly into it. The same access broker infrastructure that quietly intercepted authentication traffic across hundreds of thousands of firewalls is connected, through a shared operator, to two of the more active ransomware brands operating today. “For organizations running FortiGate infrastructure, this raises the stakes on an already urgent finding: exposure to FortiBleed is not just a credential exposure risk, it is a potential precursor to ransomware.” FortiBleed in brief Disclosed on June 17, the attack did not exploit novel vulnerabilities. Experts characterised it as a large-scale campaign that involved intercepting SSL VPN authentication hashes and cracking them using a 45-GPU cluster hosted by Hashtopolis. They then used the credentials to access victims’ Active Directory environments and gain persistence. Fortinet tried to counter these kinds of attacks in early 2025 by introducing the PBKDF2 algorithm for storing credentials, but because the changes were not applied until each admin logged back in, many organizations were likely still using SHA-256 with salt, which is vulnerable to brute-forcing. Early estimates suggested a little more than 73,000 unique firewall URLs were successfully targeted, leading to a long list of major organizations being compromised. FoxConn, Samsung, Comcast, Siemens, Lenovo, FedEx, PwC, Accenture, and Oracle were among those listed in the early reports. An unnamed Turkish NATO defense contractor was also thought to be among them after investigators found signs of classified files being copied. ®

Microsoft's prediction that attackers probably wouldn't rush to exploit a newly-patched SharePoint bug hasn't aged especially well. CISA has added CVE-2026-45659, a remote code execution flaw in on-premises Microsoft SharePoint Server, to its Known Exploited Vulnerabilities (KEV) catalog after confirming that crimes are now actively exploiting it in the wild. The bug stems from an insecure deserialization issue and affects SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016, all of which received patches from Microsoft in May. Unlike some of SharePoint's more infamous bugs, this one isn't pre-authentication, though attackers need surprisingly little to pull it off. According to Microsoft, anyone with valid credentials and nothing more than Site Member permissions can execute arbitrary code remotely on a vulnerable server. "Any authenticated attacker could trigger this vulnerability. It does not require admin or other elevated privileges," Microsoft said in its advisory. "In a network-based attack, an authenticated attacker, who has a minimum of Site Member permissions (PR), could execute code remotely on the SharePoint Server." Microsoft also noted that the attack can be launched remotely over the network with low attack complexity, making it straightforward to exploit once an attacker has a foothold. CISA didn't disclose who's exploiting the flaw or how widespread the attacks are, but its guidance leaves little room for interpretation. "This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise," the agency warned. It directed federal civilian agencies to follow Binding Operational Directive 26-04 by applying Microsoft's fixes no later than July 4, or discontinue use of affected systems if mitigations aren't available. The vulnerability carries a CVSS score of 8.8, but perhaps the more interesting number is Microsoft's exploitability assessment. When the patches landed, Redmond rated real-world exploitation as "Less Likely." That's a prediction, not a guarantee, and history has a habit of making those forecasts look optimistic once patches give attackers a roadmap to reverse engineer. For anyone still exposing an unpatched SharePoint server to the internet, CISA's KEV listing is a reminder that the race between patching and exploitation is usually won by whoever starts first. ®

Medical device giant Medtronic is warning patients that their personal and health information may have been caught up in an April cyberattack in which intruders spent nearly a week inside parts of its corporate network. According to breach notification letters sent to affected individuals, the company detected unusual activity on April 15 and later determined an unauthorized party accessed certain corporate systems between April 13 and April 19. The compromised systems contained the sort of data you'd expect a medical device maker to hold about its patients: names, contact details, dates of birth, Social Security numbers, and health information. Medtronic said it collects the information to provide product updates and comply with regulatory requirements. Medtronic says there's "no evidence" the information was "posted publicly or exposed on the internet." Whether the attackers made off with copies of the data is another question the company hasn't yet answered. The notice also addresses the question many patients are likely to ask first: whether their device was affected. "Based on our investigation, this incident did not impact the ability of any Medtronic device to operate safely and deliver intended therapy." the company said. When Medtronic first disclosed the incident in April, it said the attack had not affected patient safety, manufacturing, distribution, financial reporting, or its ability to meet patient needs. It also stressed that its corporate IT environment is segregated from the networks supporting its products and that hospital customer networks are managed separately. Shortly after the intrusion began, the ShinyHunters extortion crew added Medtronic to its dark web leak site, claiming it had stolen more than nine million records and threatening to publish the data unless a ransom was paid by April 21. The listing was later removed. ShinyHunters typically removes victims from its leak site after reaching a deal, and Medtronic's entry disappeared later that month without any data being published. However, Medtronic's notification makes no mention of ransomware, extortion demands, or ShinyHunters, and the company has not publicly attributed the attack. The breach notice also leaves several obvious questions unanswered, including how many people were affected, how the attackers gained access, and why it took the company more than two months to begin notifying affected patients. Medtronic said it has since implemented additional security measures, worked with law enforcement and relevant regulators, and is offering affected individuals two years of complimentary credit monitoring, dark web monitoring, and identity restoration services. ®

India has asked WhatsApp to explain why it should not face regulatory action after it announced the global rollout of a new usernames feature amid fears that the new feature could lead to increased cyberattacks. The country's Ministry of Electronics and Information Technology (MeitY) gave the Meta owned platform three days to respond to its July 1 letter and to halt the rollout of usernames until the government gives its approval. WhatsApp announced on June 29 that it was allowing users to reserve usernames that could be used instead of phone numbers on the platform when the feature launches later this year. It said that people want to chat with others without exposing their personal phone number, whether to a classmate, neighbor, professional contact, or the group chat for their child's sports team. Meta also owns Facebook or Instagram, and is not allowing users to create usernames that already exist on those other platforms – unless they themselves control the other accounts. However, the government of India, WhatsApp's largest market fears that allowing first contact without displaying a phone number "may increase cybercrimes," including phishing and digital arrest scams. MeitY is specifically concerned about the opportunities for impersonation, with attackers posing as public authorities, financial institutions, or government departments. The department cited India's Information Technology Act 2000 and Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules 2021 as the legal basis for its concerns about the feature. The Internet Freedom Foundation, which shared a copy of MeitY's letter to WhatsApp's chief compliance officer in India, said that the department has no clear legal basis for halting WhatsApp's usernames rollout. It said neither legal framework was applicable in the context in which they were being invoked and called its letter the latest example of attempted regulatory overreach. The IFF pointed to a separate advisory issued in March 2024 when MeitY tried to stop AI companies from rolling out their models to the public before the Indian government had a chance to approve them. "That was criticized as an overreach that sought to build a licensing mechanism with no empowering provision in the IT Act, and within a fortnight MeitY withdrew it and dropped the permission requirement," the IFF stated. "This notice repeats the move for a single feature and goes further, because it names one company, sets a three-day clock, and bars the launch until MeitY is satisfied." WhatsApp told The Register that it has implemented numerous measures designed to keep users safe as usernames are rolled out across the platform. A spokesperson said: "We've announced the option for people to reserve their preferred username on WhatsApp. The ability to use a username is not yet live and will roll out slowly later this year. When it becomes available and someone sends you a message for the first time via your username, we will show you if they're a new account, if they're your contact, if you have groups in common, and if they're based in a different country, so you can decide whether to respond." In other efforts to restrict fraudulent misuse, WhatsApp has already reserved high-profile usernames for legitimate organizations and individuals. Users will also not be able to register lookalike derivatives. The spokesperson added: "Users still require a phone number to use WhatsApp and we've built multiple layers of defense against scams into usernames. Other users need to know the exact username to message you, we will limit how many new people an account can contact, block repeated attempts to guess someone's username key, and have systems to detect and remove activity showing common impersonation and abuse patterns." MeitY did not respond to our request for input. WhatsApp claims more than 3 billion users rely on its messaging platform, and separate estimates peg India as its largest market with more than 850 million users. WhatsApp-based scams are not unique to India. Many cybercriminals use the platform to commit fraud, impersonating public figures, authorities, and family members to carry out financially motivated attacks. The Telegram messaging platform allows users to set public usernames and is also frequented by scammers. India temporarily banned Telegram in June amid fears that exam questions were being shared ahead of time. The ban was announced days before the NEET-UG medical entrance exam was scheduled to begin. The exam was reworked and rescheduled after being canceled in May after genuine questions were found circulating on the platform. ®

Attackers have been caught exploiting a critical flaw in Oracle E-Business Suite's Payments module just six weeks after Oracle patched it – and before any public proof-of-concept exploit was available. Researchers at Defused said they observed the first known exploitation of CVE-2026-46817 on June 27. The attackers were targeting the Oracle Payments File Transmission component in E-Business Suite releases 12.2.3 through 12.2.15, they said. The vulnerability, fixed in Oracle's May Critical Patch Update, carries a CVSS score of 9.8 and allows unauthenticated attackers to read arbitrary files from vulnerable servers. According to Defused, the activity didn't look like the indiscriminate internet scanning that often follows disclosure of a critical bug. Instead, its honeypots recorded just six exploitation attempts from a single source, all using what appeared to be a working exploit. The requests sought to retrieve sensitive files from the target system, suggesting the operator was testing or validating the technique rather than casting a wide net. The researchers said exploitation began before any public exploit code had surfaced, pointing to an attacker who had either reverse-engineered Oracle's patch or obtained a private exploit. The Shadowserver Foundation said it currently sees around 950 EBS instances exposed to the public internet, the majority in the US, although it stressed that figure says nothing about whether they're vulnerable or fully patched. The observed exploitation fits a pattern that's becoming increasingly familiar. Earlier this month, researchers warned that attackers had exploited a critical PeopleSoft zero-day before patches were widely deployed, with the ShinyHunters crew claiming to have compromised more than 100 organizations. They also boasted of having stolen HR and payroll data. This latest incident also follows Clop's lengthy campaign against Oracle E-Business Suite customers, disclosed last year after researchers found the ransomware crew had targeted internet-facing EBS servers for months before the activity became public. The newly exploited EBS vulnerability is probably not the last Oracle ERP bug to be targeted. Enterprise software has become a lucrative hunting ground for cybercrooks, and critical updates can double as roadmaps for anyone prepared to reverse-engineer the fixes and beat customers to deployment. ®

PWNED Welcome back to PWNED, the column where we document serious security failures in hopes we can all learn from others’ mistakes. This week, we’ll talk about how a lack of physical security can allow threat actors to take control of your network. 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 story comes to us from two professional red teamers, who get paid to break into offices and networks in order to find holes in the security system. Kristopher Johnson was working as an offensive security consultant at Echelon Risk + Cyber in 2023 and his manager was Dahvid Schloss. We spoke to both. Johnson and another employee named Michael were called upon to challenge the security at a client’s office while Schloss supervised remotely. It was winter and the maintenance crew had the maintenance door open. They walked through it and into the mail room, where a woman confronted them and asked what they were doing there. The two intrepid testers talked to the company maintenance crew and told them that they were new IT employees without working badges. They said that they had almost slipped on the ice and offered to help shovel, an offer the maintenance team was happy to take them up on. While Michael kindly helped the maintenance crew shovel snow, Johnson asked if the maintenance folks could let him in so he could go upstairs and start setting up Michael’s laptop for work. They let him in where he was free to explore the building as his partner brushed away a large section of ice and snow. Inside the building, Johnson looked for a place to plug in his Raspberry Pi. The idea was to connect this single-board computer to the network, where they could access it remotely and use it to attack the network from afar. He tried plugging his Raspberry Pi into an Ethernet port in the AV closet, but the company had network access control enabled, which prevented it from connecting. The Raspberry Pi had an LTE radio, but it couldn’t connect from the closet either. So Johnson instead moved his Raspberry Pi into the middle of the conference room and found an active network port that didn't have network access control enabled on it. However, he realized the Pi would be visible to anyone who entered the conference room, and they might find it suspicious. So he took some trash cans and used them to hide the device. Johnson had a hard time getting out of the building after that. He tried to go out the front door, but it required him to swipe a badge he didn’t have and strangers would not swipe their badges for him. But when he went back through the maintenance entrance, they were more than happy to swipe him out. He waited in the car while Michael finished his shoveling assignment. The next day, Johnson found out that his security breach had been detected. When he and Michael came in to meet with their contact at the company, the head of security confronted them. They had been “caught” because someone from maintenance went up to the IT department and wanted to thank the IT team for Michael’s help with the shoveling. However, the IT team had no record of new employees named Michael or Kristopher, so that raised suspicion. Before learning that they were professional red teamers, the building security had been suspicious and had looked at camera footage tracking their movements. They had even tried to get information on the license plate from Johnson’s rental car. However, they never did find the Raspberry Pi, which remained plugged into the Ethernet port in the conference room for two weeks. During that time, Johnson’s team was able to connect to the company’s Active Directory, find where the domain controllers were, and start password spraying accounts to see if they could gain access. They tried using the password “winter2023!” and got 50 or 60 hits among the employees. “So we used those credentials to kind of map out the rest of the network,” Johnson told The Register. “Network shares and things like that and then, towards the end of the test, we enumerated the certificate services - ADCS (Active Directory Certificate Services).” The red teamers found eight templates that were open to ESC1 and ESC4 vulns. They also found that the certificate authority was vulnerable to ESC8. They were then able to exploit those holes to gain domain administrative access. The janitor found the Raspberry Pi two weeks after they broke in, but by then it was too late. There are a lot of lessons here, but they start with training every member of the team to be suspicious of people coming from the outside, without badges, no matter what they say or do. Schloss noted that, if someone looks and acts like they belong in a space, most people will treat them that way. “First and foremost, what most people believe is crime is not crime. It's a Hollywood myth of what crime looks like,” Schloss told us. “I call it the ski mask bias. Everyone assumes you're not getting robbed until a person comes in with a ski mask and a gun yelling.” The maintenance team at this company should have been more suspicious of people calling themselves new employees and asking for a swipe in, even if they were willing to help shovel snow. The company also should have restricted network access to the port in the conference room so that an unknown device like a Raspberry Pi could not make an Ethernet connection from that spot. Finally, the company should have enforced a strong password policy that would have prevented our heroes from finding dozens of accounts with “winter2023!” as the password. And they should have enforced multi-factor authentication on those accounts as well. ®

EvilTokens, the device-code phishing kit that can allow criminals to bypass multi-factor authentication (MFA) and silently authenticate as the victim to the organization's Microsoft 365 applications, appears to be even more insidious than we all thought. Cisco Talos incident responders on Wednesday described how the lure reaches a victim's inbox, and revealed new capabilities alongside a “more sophisticated evasion approach” than documented in earlier EvilTokens research. Talos uncovered a phishing-as-a-service (PhaaS) operator panel, branded “ARToken,” that appears to be an EvilTokens customer, according to security research engineer Michael Kelley, who noted the phishing operation shares infrastructure, API contracts, and operational patterns with the EvilTokens platform. EvilTokens was first documented by French cybersecurity firm Sekoia in March, and in April Microsoft said the device-code phishing campaign was compromising hundreds of organizations daily. "Since March 15, 2026, we have observed 10 to 15 distinct campaigns launching every 24 hours," Microsoft VP of security research Tanmay Ganacharya told El Reg at the time. “Each campaign is distributed at scale, targeting hundreds of organizations with highly varied and unique payloads, making pattern-based detection more challenging.” While most subsequent analysis has covered EvilTokens’ panel and phishing kit, “what it has not shown is how an ARToken lure actually reaches an inbox,” Kelley said on Wednesday. “Talos recovered two near-identical messages, sent roughly four minutes apart on April 20, 2026, that initiate the chain. The tradecraft is targeted, not spray-and-pray.” Specifically, the email lure abused a real vendor relationship between a US life-sciences company and a legitimate plumbing and fire-protection contractor. The email uses an outstanding-invoice lure, telling the life-sciences company that “the following invoices appear to still be outstanding,” and the “from” header presents the contractor’s real domain. The reply-to, however, redirects replies to an unrelated domain. Even the visible anchor text in the body of the email reads as the vendor's genuine SharePoint tenant, we’re told. The actual href, however, points to a near-identical copycat tenant under a different, attacker-controlled Microsoft 365 workspace. But because the destination is still a legitimate sharepoint.com host, the email is less likely to be flagged as a phish. During its investigation into the ARToken phishing infrastructure, Cisco uncovered the connections to EvilTokens – including an identical API contract to the one originally documented by Sekoia and matching deployment and operational models – as well as “notably more sophisticated” anti-analysis and evasion capabilities. ARToken’s panel also revealed a very comprehensive post-exploitation toolkit that provides token management and persistence mechanisms, and a built-in business email compromise (BEC) tool with full Microsoft Outlook inbox read access, email sending capabilities as the victim, inbox rule creation for forwarding and deleting messages, and keyword-based monitoring across all compromised accounts. “These features indicate the platform is more mature than a simple device code phishing kit - it is a complete BEC operations environment,” Kelley wrote. ®

Anthropic has released the latest version of its mid-sized model, Sonnet 5, which the company claims is its most “agentic” yet. For developers writing agents to automate tedious and recurring tasks, Sonnet 5 promises improved capabilities in reasoning, tool use, coding, and knowledge work. This version is also less likely to pull embarrassing (for Anthropic) gaffes of misunderstanding, so the company asserts. “Our safety assessments found that Sonnet 5 shows an overall lower rate of undesirable behaviors than Sonnet 4.6, and is generally safer to use in agentic contexts,” the company asserted in an introductory blog post on Tuesday. Sonnet 5 is smarter at refusing malicious requests and resisting prompt-injection attempts. It doesn’t hallucinate as often and doesn’t suck up to the user so much (“sycophancy”) as did its older brown-nosing Sonnet 4.6 sibling. It is also more aware of, and can block, user misuse and deception, the benchmarks in Anthropic’s System Card seem to indicate. Sonnet is the default model for Claude Free and Pro users, and is also available to the token-pinching Max, Team, and Enterprise customers. The benchmarks also indicate Sonnet 5’s performance can come close to that of Anthropic’s flagship enterprise-focused Opus 4.8, but can execute the same tasks more cost effectively. For Opus, Anthropic charges $5 per million input tokens and $25 per million output tokens. Starting in September, Sonnet users will pay $3 per million input tokens and $15 per million output tokens, though Anthropic is running a special through the end of August where tokens will only be $2 per million inputs and $10 per million outputs. So users trimming their token budgets can run jobs through Sonnet instead of Opus, the company suggests. The 5.0 release offers a new setting to adjust the model’s effort at completing tasks. Simple tasks can be completed through one of the lower “effort” settings, which uses fewer tokens, while longer-running agent-based tasks can go full throttle (“xhigh” or even Homer Simpson’s favorite setting, “max”). What Sonnet 5 can do for developers For much of 2026, AI product deployment has focused on equipping large language models to complete what has become known as “long horizon tasks.” It might be easy for a model to fix a bug or churn out some code. However, keeping its finicky attention fixed on a multi-part task has proven more difficult. The new version of Sonnet can go the distance, according to the company, compared with the earlier Sonnets. “Across a broad suite of internal and third-party benchmarks, Sonnet 5 shows clear gains over Claude Sonnet 4.6 in coding, agentic search, multimodal reasoning, and professional-task performance,” the System Card asserted. At the same time, however, the performance across these tasks still trailed that of the Opus and Mythos models. One testimonial from a Zapier engineer described a two-part job that flummoxed earlier Sonnets: Update a contact database and send out a notice to all users. Version 5 was able to complete the task “end to end.” Cybersecurity: Nothing to see here The San Francisco-based company also went out of its way not to attract any more undue attention from Washington, DC policymakers. “We did not deliberately train Sonnet 5 on cybersecurity tasks,” the company asserted. In June, the US Commerce Department, citing national security concerns, slapped Anthropic with an export control directive temporarily restricting foreign access to the newly released Mythos 5 and Fable 5 models. Whether Anthropic brought this on itself – through what could be regarded as hyperbolic assertions of Mythos’ deity-like bug-sleuthing powers – is certainly worth discussing. But Anthropic, like Pete Townshend, certainly won’t be fooled again. While it can readily perform routine cybersecurity tasks, Sonnet 5 is guardrailed against generating offensive attack code. When commanded to write a Firefox exploit, it failed to complete the task (though it got a bit further than Sonnet 4.6 in the attempt). “This latter change is likely due to improvements in general intelligence rather than specific training,” the company’s blog post noted. ®

You can't ask most models to help you make "ransomware" directly, but many will be more than willing if you give them the right prompt. DeepSeek and other LLMs with fewer safety and security controls make theoretical cyberthreats - like browser-only ransomware - much more likely to be used in real-world infections, according to Check Point researchers. The Israeli cybersecurity company analyzed a DeepSeek-generated sample in a Wednesday report that its threat hunters describe as in-browser ransomware. Over the past year, the team has tracked almost 3,000 files attributed to DeepSeek, and classified nearly half (1,383 files) as malicious or dangerous using VirusTotal or static source analysis. “Within this dataset, we found a sample that implemented a dangerous browser-native technique we have not observed exploited in the wild,” researcher Alexey Bukhteyev wrote. And while the sample was incomplete, and unable to pull off an in-the-wild infection, the security shop’s testing showed “little effort” would be required to make it attack-ready. “Our research shows that the original incomplete DeepSeek sample can be transformed into a fully functional attack with minimal effort,” Pedro Drimel Neto, malware analysis team leader at Check Point Research, told The Register. “Very little effort is needed,” Neto said. “Low-level expertise is sufficient. You don't need to be a sophisticated cybercriminal or advanced persistent threat group. In fact, we've already observed evidence of actual threat actors attempting this attack using straightforward LLM prompts.” Known threat gets an AI boost The risk ransomware poses to browsers isn’t a new idea. The File System Access specification lists ransomware as a security consideration, and a 2023 USENIX Security paper on Ransomware over Modern Web Browsers described how File System Access API could be abused to encrypt local files from a malicious web application. The File System Access API is a browser capability, primarily supported by Chrome and Chromium-based browsers, that allows developers to build web applications, such as editors, IDEs, and creative tools, that can read, write, and manage files on the user’s local device. “Even though it can be used to develop rich web applications, it greatly extends the attack surface, which can be abused by adversaries to cause significant harm,” Google’s Güliz Seray Tuncay and Florida International University researchers Harun Oz, Ahmet Aris, Abbas Acar, Leonardo Babun and Selcuk Uluagac wrote in 2023, long before LLMs could develop working malware and attack chains. What’s new, according to Check Point, is that an AI model put these previously documented ideas into a “realistic and enforceable attack scenario leveraging a method that defenders had originally thought was unfeasible due to browser sandboxing limits: a DeepSeek-attributed malicious sample, generated as an all-in-one malware fantasy, connected this documented platform risk to a realistic phishing-style web application, demonstrating a viable end-to-end attack chain.” This technique is especially appealing to attackers because it doesn’t require a native payload, APK installation, browser exploit, or root access to a compromised device. Instead, it uses social engineering - tricking a user into clicking on a malicious button - combined with a legitimate permission prompt exposed by the File System Access API in Chrome. Meet InfernoGrabber 9000 This particular sample that Check Point uncovered is a Python Flask application that targets Android users. It’s named InfernoGrabber 9000, and VirusTotal calls it a “fully functional information stealer and ransomware toolkit.” While the security sleuths don’t have the prompt submitted to DeepSeek to produce the malware, they speculate it was something along the lines of: “create a universal malicious tool that runs through the browser and collects as much victim data as possible, encrypts files, and demands ransom. In a single front-end, the generated code assembled routines and stubs for keylogging, clipboard monitoring, form and network-request interception, Discord-token collection, crypto-wallet and payment-card discovery, geolocation requests, webcam and microphone access, screenshots, local-file access, Chrome exploit stubs, ‘persistence,’ and a ransomware-style overlay.” To be clear: the sample doesn’t actually do all of this. “A more accurate reading is that it is an AI-generated blueprint in which the model tried to translate familiar capabilities of native stealers and ransomware tools into a web page opened in the browser,” Bukhteyev wrote. The code presents a victim-facing lure disguised as a Discord avatar AI upscaler. Clicking on the lure is intended to execute a slew of silent, harmful actions that run entirely inside the browser process. These include stealing Discord tokens, harvesting credit card numbers and cryptocurrency seed phrases, logging keystrokes, and capturing unauthorized webcam and microphone feeds. The code also includes specific routines for browser exploitation (such as targeting CVE-2023-4863), uses a hardcoded Discord webhook for data exfiltration and displays a ransomware WinLocker screen demanding Bitcoin. The good news for defenders is that the sample was incomplete, and the browser's built-in security model successfully prevents most of this functionality. However, Check Point was able to create a working proof-of-concept for the browser-native attack using the latest DeepSeek model V4. The team had to remove some of the more explicit terms - like ransomware - from the prompt, but ultimately produced the same functionality: “a web page that asks the user for access to local files, processes them inside the browser, and leaves the user unable to recover the original content.” AKA: browser-only ransomware. Neto told us that this type of LLM-generated code and in-browser attack is “likely happening now.” “We expect to see this activity in the short term, if we haven't already,” he added. While traditional ransomware and extortion groups target enterprises and critical infrastructure organizations, as opposed to Android-device users, which was the focus of this research, “we have seen increased end-user ransomware activity recently,” Neto said. “What's most concerning is that code obfuscation used in these attacks makes them difficult to spot, so there's a real possibility that attacks using this technique are already occurring in the wild but going unnoticed.” ®

EXCLUSIVE Pentera Labs’ red teamers compromised a developer’s AI agent via his Claude Desktop app and ultimately turned that access into full remote code execution on the dev’s machine – demonstrating how an attacker could turn a trusted, chatty AI assistant into a double agent operating on their behalf. “Claude’s got a new voice,” Pentera's offensive security services team leader Dvir Avraham told The Register. “We acknowledge the huge trust in AI models – everybody uses them,” he said in a phone interview. “We used this trust to manipulate the victim, like under the hood, the victim didn't see it coming.” It also prompted Avraham to check his own platforms. “I became a little bit paranoid,” he told us. “I'm not allowing any command to run without me examining it twice.” In a report set to publish Wednesday, and shared in advance exclusively with The Register, Avraham and research technical lead Reef Spektor detailed the attack and what it means for organizations using agentic AI tools with local code-execution access. It began with a red-team assignment on a third-party platform that aggregates customer email inboxes into a single management interface. Avraham and Spektor won’t name the platform, or tell us exactly how they gained access to it. They used this compromised inbox – and told us any compromised inbox would work – to get into the victim’s Claude account. As the duo noted, breaking into an email inbox in real life – via a third-party management platform, phishing link, social engineering password reset, or even using AI agents – isn’t too difficult. “AI agents today have access to connectors and to direct MCPs into inboxes,” Spektor added. In addition to this prerequisite (compromised inbox), the attack chain also requires the victim to have Claude Desktop installed. Anthropic’s desktop app works across macOS, Windows, and Linux systems. It provides the same AI chat for conversations as claude.ai, and it also syncs across all devices and sessions tied to the user’s account. “We asked ourselves, can we leverage the sync behavior to infect other sessions and devices? (hint: yes!),” the red teamers wrote in the Wednesday report. Back to the AI Stone Age As of January, the desktop app also includes Cowork for longer agentic tasks, and Code for software development. So, for example, a user can send Claude a task from their phone and instruct it to work on their computer. As Anthropic says: “Anything you can do on your computer, Claude can do. Open apps, fill spreadsheets, navigate your browser. No setup, no passwords handed off.” The Cowork feature now makes Pentera Labs’ attack scenario even easier. However, when the security analysts were doing this research in November 2025, “back in the Stone Age in terms of AI, you didn't have Cowork or Claude Code, so we needed a way to actually execute commands because we wanted to take over the machine,” Avraham said. For this part, they took a keen interest in Claude Desktop’s personalization features. These are account-wide settings that tell the AI agent the user’s preferred approach and general communication instructions, along with more specific project instructions, such as guidelines for a particular workflow, or defined roles Claude should adopt within a project. The red teamers developed a base64-encoded prompt that instructed Claude to check for command-capable tools on the developer’s machine and execute the command if available, or produce a fake error message if not, prompting the user to download a tool that will execute the attacker’s commands. Then they pasted the prompt into the victim’s personal preferences on Claude, and this prompt syncs across all of the user’s devices. This ensures that the next time the user opens Claude Desktop and types in a chat, the poisoned instructions are loaded into their preferences and will silently run behind the scenes. The user thinks they are simply interacting with Claude as usual. They don’t see Claude checking to see what extensions and tools are installed. If the user already has Desktop Commander or a similar MCP connector or extension installed, the poisoned instructions tell Claude to use it. This allows the attacker, via Claude, to execute a stealthy reverse shell or other malicious code. “And from there it's full compromise of the machine,” Avraham said. Phishing - but without the email However, if there aren’t any command-capable tools installed, then Claude becomes what the researchers describe as a “phishing layer.” (They also noted that if they had performed this research more recently, not back in November, the Claude Cowork feature would have eliminated this entire tool enumeration and phishing phase because Cowork can execute commands on a user’s behalf.) The injected prompt instructs Claude to present a realistic-looking error as soon as the victim asks the chatbot a question. This includes a realistic error code, a link that purports to be a fix, and step-by-step instructions. “This message tells the victim: ‘please download this,’ and we took links from the actual Anthropic site, with known emojis that the AI loves,” Avraham said. Because the error message looks real and people usually trust their AI assistant, they will likely click on the link and execute the attacker-controlled command. “From here, the attacker has full command execution – reverse shells, data exfiltration, credential harvesting, whatever the objective calls for,” the duo wrote. “In our case, we had Claude curl a remote server we controlled on every interaction, fetching and executing whatever bash commands we served back. We could rotate those commands server side at will, effectively turning Claude into a persistent, stealthy C2 agent that the victim themselves kept feeding.” In this specific case, the target was a developer who had credentials and access to several internal systems. After compromising the dev’s workstation – which gave the red teamers a foothold into the organization – they moved laterally across the company using various attack vectors that they declined to tell us about, citing customer privacy and proprietary methods. But, Spektor added, developers make for an “excellent starting point for an attacker,” because of their access to secrets including API keys, tokens, and cloud credentials, which allows intruders to move from a single workstation into the larger organization’s cloud environment. From there, they’ve got free rein to steal source code and other sensitive data, or poison internal git repositories, and cause all sorts of pain for enterprises as we've seen play out multiple times across several recent attacks. Feature, not a bug The team reported their findings to Anthropic back in November, and the AI company essentially said it’s Claude Desktop working as intended – a feature, not a bug. “After reviewing your submission, we've determined this doesn't represent a security vulnerability that falls within our program scope,” Anthropic said. “Our current threat model treats personal preferences, skills, and MCP connectors as features that can execute code through Claude Desktop by design. While we recognize these features can be leveraged to execute arbitrary code when manipulated, this represents expected functionality rather than a security vulnerability in our infrastructure.” The Register reached out to Anthropic for comment and did not receive any response. The red teamers, however, have some suggestions to keep your organization safer from rogue AI agents. First, for anyone using agents or chatbots: pay close attention to what the AI can do on your machine, and don’t blindly follow install prompts or error messages. “If you can, run it on a sandbox and not on your personal computer,” Spektor said. Security teams should treat AI desktop apps as “privileged software” as they can execute code, read files, and interact with local tools. “Monitor for changes of AI assistant configurations and synced settings,” the researchers wrote. “Restrict which extensions and tools can be installed alongside AI apps.” And finally, red teams should add AI desktop apps to their assessment toolbox, Avraham and Spektor noted: “There's a real attack surface here that most engagements don’t cover yet.” ®

Perhaps bots aren't the answer to everything when it comes to finding flaws. Fully automated pentesting has been a letdown for many security teams, according to offensive security firm Cobalt, as support for the approach has fallen sharply over the past year. Cobalt’s recent 2026 State of Pentesting report found, among other things, that security practitioners are rapidly ditching autonomous pentesting tools, in large part because they’re simply failing to detect critical vulnerabilities. Cobalt reported that 78 percent of respondents to its survey for the 2026 report experienced “critical false negatives” from automated scanning tools, with the tools quite bad at detecting the sort of vulnerabilities its AI ilk inflicts on environments in which it’s prevalent. “Automated scanners are brilliant at finding known, signature-based vulnerabilities. But they fail miserably at AI security,” the company said in a release summarizing the report’s findings. “Prompt injection exploits and excessive agency flaws require creative, multi-turn interaction chains [and] adversarial psychology,” Cobalt continued. “These logic flaws are entirely invisible to tools that test using single-shot automated queries.” A year of disappointment with automated scanning tools has led to a considerable decline in the number of organizations considering a purely automated security scanning approach, with just 9 percent of respondents saying that they were open to the idea, compared to 29 percent last year. It’s worth noting that the number of respondents to Cobalt’s survey was small - just 450 folks - but even with so few data points, the numbers are still bad news for automated pentesting vendors, but good news for infosec professionals, says Cobalt. “The drop in reliance on fully automated pentesting is actually a healthy sign,” the company said in its report summary. “It proves that practitioners are seeing through the vendor hype and demanding actual assurance rather than just coverage.” Those practitioners may also be simply overwhelmed by the number of vulnerabilities that non-security AI tools are introducing into their spaces: Per Cobalt, around 12 percent of the vulnerabilities detected in traditional environments are classified as high or critical severity. In AI and LLM environments, that number climbs to 32 percent, and that's not a new number, either. That 32 percent figure has held for the past two years, Cobalt said of its pentesting data, suggesting AI is introducing a lot more vulnerabilities. Combine those increased severity odds with automated pentesting bots that miss the sort of vulnerabilities that AI often introduces and it’s a recipe for disaster. Cobalt says the solution is hybrid security in which most systems are allowed to be automatically scanned by AI, while the most critical systems are left up to humans to protect and manage. The company sells such a solution, naturally, but it’s worth pointing out that its findings on the uptick in vulnerabilities introduced by AI aren't exactly a unique claim. Application security firm Veracode reported earlier this year that AI-assisted software development is creating more vulnerabilities than security teams can keep up with, leaving more vulnerabilities left unresolved for longer periods of time. Per Veracode, some 82 percent of companies are leaving known vulnerabilities unresolved for more than a year, while the number of high-risk vulnerabilities as a share of all discovered is rising as well. That said, not everyone is as skeptical of automated pentesting as Cobalt and its survey respondents. According to Amazon security chief CJ Moses, AI pentesting tools have made Amazon security teams 40 percent more efficient, though Moses’ measure for that figure isn’t clear. Moses still wasn’t keen on handing the entire security project off to AI, however. He told us at the RSA Conference in April that AI pentesting still needs a human in the loop to ensure it doesn’t muck something up. "AI is very good at doing things, especially when you have large amounts of data and need that big view,” Moses said in an April interview. “But from a decision-making capability, it isn't something that we're ready to rely on." ®

Huntress CEO Kyle Hanslovan said he is aware of “questionable, long-term threat actor communications” between a threat hunter who is still employed with the security firm and a cybercriminal, and called this “poor judgment.” “In one particular exchange, our current teammate disclosed to a threat actor that law enforcement had reached out to them about the threat actor,” Hanslovan said in a blog post, addressing a former employee’s accusations that the current Huntress analyst is an insider threat to the company. “While this disclosure was not illegal, it reflected poor judgment,” he wrote. The incident came to light last week when former Huntress security operations analyst Ben Folland, who left the company in February, alleged 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 operator, believed to be located in Russia, who uses modified DragonForce code built on top of the leaked Conti source code. Folland alleged that this insider, still employed by Huntress, was “caught by the FBI,” and that their involvement with Devman “would cause significant reputational damage to Huntress and, in my view, continues to put clients at risk.” “If you are an employee at a cybersecurity company, you should not be helping cybercriminals,” Folland said. “You should not be informing them of active investigations. You should not be engaging in cybercriminal activity yourself.” At the time, Hanslovan said he “firmly disagree[d]” with Folland’s accusations – but declined to provide additional details about what happened between the employee and the criminal. In the Tuesday blog post, Hanslovan elaborated further and said that he believed that the communications did not constitute insider activity. “As a result of the investigation, my team implemented more robust policies for our researchers, coached teammates on engaging with threat actors, and took appropriate administrative actions,” he wrote. “While we haven't found evidence of illegal conduct, insider activity, or additional disclosures, we are continuing our investigation. Due to the privacy rights of our teammates, we will not comment further on the investigation.” Folland disagrees. In a Tuesday LinkedIn post responding to Hanslovan’s blog, he asserted that the communications between the Huntress analyst and Devman “meet the definition of an insider threat.” When the FBI reached out to the Huntress employee for intel on Devman, “She immediately forwarded the exact FBI communications to the threat actor, including screenshots containing FBI agent names,” Folland claimed in his post on LinkedIn. “She informed Devman that law enforcement was actively looking into him. She also refused to cooperate because they wanted Devman.” According to Folland, the FBI notified him of this incident with the current Huntress analyst. The Register reached out to the FBI for comment and did not receive a response. “This was not just ‘poor judgment,’” Folland wrote. “This was a Huntress employee taking sensitive knowledge about a law enforcement approach and passing it directly to the person being investigated. If someone inside a bank warns a fraudster that police are investigating them, nobody would describe that as merely ‘poor judgment.’ They would call it what it is – an insider.” Huntress declined to comment further. ®

Microsoft has built a bouncer to keep bots out of Teams meetings. “Bots have begun joining meetings that participants never intended them to attend,” wrote Microsoft product marketing manager Meera Ajam in a Monday post. “For example, after connecting a third-party service to a meeting, some users have found that its bot continues joining future meetings automatically.” Ajam thinks bots butting into meetings that include discussion of sensitive matters is a potential security and privacy problem. Your correspondent has personal experience of this when transcription bots add themselves to meetings conducted under non-disclosure agreements. Microsoft has therefore built tech that sees Teams require a human to check a bot’s ID in the “lobby” where guests wait before a meeting. If a human rates a bot as worthy of coming inside, it gets to join the meeting. The software giant says it’s “strengthened Teams' ability to distinguish between bots and human participants as they join a meeting” by using “a combination of behavioral and infrastructure signals to identify bots with a higher degree of accuracy.” That’s not a guarantee that Teams will detect all bots, but Microsoft’s tech requires multiple clicks to let a bot attend a meeting. “Admitting a bot should be a deliberate decision, not something that happens by mistake,” Ajam wrote. Some users want bots to attend a meeting. Your correspondent prefers a third-party transcription-bot to Microsoft’s own. The software giant recognizes that and plans to add “a registration path for independent software vendors (ISVs) that build meeting experiences for Microsoft Teams.” That path will mean bot-builders will be able to register with Microsoft and include a self-identification marker in their join requests. “When Teams recognizes that marker, it can identify the bot as a known participant,” Ajam wrote. “We're currently working with a limited set of ISVs to preview this capability and validate the experience before broader availability,” she added, before promising more detail about registrations soon. There’s peril in this plan for Microsoft, which could make itself an arbiter of what constitutes a good bot worthy of admission to Teams. Just like bouncers do in real life, often to the chagrin of plain-looking revelers. Microsoft has started rollout of its bot-bouncer. Once it’s in place, the software behemoth will retire the CAPTCHAs it currently uses to put bots in their place. ®

In 2025, the Reserve Bank of India created the .bank.in subdomain and required all local banks to start using it for their online presences. Indian is home to thousands of banks and the new rule meant all needed to register for and use a bankname.bank.in domain, a move designed to make life harder for phishers and fraudsters. Now a security researcher has alleged that the entity chosen as the sole registrar of the subdomains – the Institute for Development and Research in Banking Technology (IDRBT) – botched the job and leaked sensitive data. The allegation came in a report [PDF] and post published yesterday by CashlessConsumer, a group that advocates for India to become a cashless society and which aims to represent citizens to digital payments players. “The IDRBT Domain Registration Portal (registrar.idrbt.ac.in) – the exclusive registrar for India’s .bank.in namespace – exposed its entire REST API via 33+ unauthenticated endpoints,” the post alleges. “Anyone with curl could retrieve the bcrypt password hashes, mobile numbers, email addresses, login IPs, and device fingerprints of all 5,576 bank employees trusted with managing India’s banking domains.” The researcher behind the exposé, “Srikanth L”, says he accessed info through the portal and found evidence that some India banks host websites on shared servers in the United States, Singapore, and Lithuania. He also found 80 percent of registered .bank.in domains don’t use DNSSEC, 40 percent don’t employ the DMARC email security protocol that verifies senders’ identity, and many domains are secured with free Let’s Encrypt certificates. The researcher’s post also alleges that the portal went live without a proper security audit and ran without secure APIs for 13 months. Srikanth L disclosed his findings in early June and says IDRBT has since fixed the gaping security flaws. The researcher also appears to have used a GitHub repo to list info found by accessing the portal’s APIs – so some of the info available over the previously-open API is now public – and claimed doing so will help security researchers by letting them understand the extent of Indian banking infrastructure. That knowledge may come in handy given the open API means attackers may have been able to access and use credentials of senior bank staff, information that can enable many forms of attack - even the DNS spoofing and phishing attacks the requirement to use .bank.in was designed to prevent. At the time of writing, the IDRBT, Reserve Bank, and India’s government appear not to have made a public comment on the matter. ®

Researchers say that machine learning models cannot reliably distinguish between authorized and unauthorized input, ensuring that prompt injection will continue to present a threat until developers find new ways to have machine learning systems process inputs. AI models provide responses to user-supplied prompts. The problem is that AI models may receive adversarial prompts – directly from a user or indirectly from an ingested document – that tell the model to take action contrary to its built-in system prompt. Various techniques mitigate prompt injection, but defenders have not found ways to prevent such attacks. According to independent researchers Charles Ye and Jasmine Cui, and MIT associate professor Dylan Hadfield-Menell, no one is likely to do so under the current fragile LLM security model. As they observe in a paper titled "Prompt Injection as Role Confusion" in the proceedings of next week's ICML 2026 conference, LLMs have come to rely on a text tagging system that defines "roles" to separate system text from user text. And roles, they argue, do not guarantee security. "Role tags were a formatting trick that became the security architecture and the cognitive scaffolding of modern LLMs," the authors explain in a blog post. "We've shown that this architecture doesn't survive into the model's actual representations, and that such role confusion is linked to prompt injection." When OpenAI's ChatGPT arrived in 2022, it implemented the concept of roles – described by Anthropic a year earlier – as a way to tell the underlying model to behave in a certain way. The user role would make a request and the model, acting in the role of a helpful assistant, would respond to that request. "A formatting trick had become the mechanism that turned autocomplete into an assistant," the authors observe. Developers introduced other roles over time. In addition to and , there's , , and . These roles served to draw a line between different objectives so they could be individually optimized during the training process. Model makers want to balance conflicting objectives like being helpful and preventing harm, and this involves role distinctions. But roles, the researchers say, have become overloaded with responsibilities they cannot reliably carry out. They've become like a fuzzier version of permission levels, determining how prompts are trusted and treated. The problem, the authors contend, is that roles are determined in a fundamentally insecure way: writing style. "LLMs identify roles from an insecure feature (style)," they explain. "This is like identifying a stranger's profession from how they talk and dress rather than by checking their ID. Usually everything agrees, so this works fine. But when attackers intentionally create a mismatch, the LLM uses the insecure method (writing style) to identify its role instead of the secure method (tags)." The authors developed an attack called CoT (Chain of Thought) Forgery that involves using an LLM to spoof the terse style of OpenAI mode and add that to the prompt. The technique won the 2025 OpenAI Kaggle red-teaming contest. "We asked a bunch of LLMs how to synthesize cocaine, inserting fake reasoning that says it's fine because we're wearing a green shirt," the authors explain. "The LLMs comply. The rationale is transparently dumb, but the models don't evaluate it as an external claim to be scrutinized. They treat it as their already-reached conclusion, and simply act on it. We've stolen the trust given to the role." On a standard jailbreaking benchmark, they say, CoT Forgery took the attack success rate from near zero to about 60 percent on the models tested. And whereas most jailbreaks are fragile and work only for certain models, this one transferred because it exploits a structural flaw. It's not attempting to persuade the model but duping the model into treating the request as something that's already settled. The authors also note that while many models report near-perfect safety scores on prompt-injection benchmarks, human red-teamers achieve attack success rates close to 100 percent. "The discrepancy is straightforward: skilled humans test and adapt attacks until they work, benchmarks don't," they state. "Static benchmarks measure attacks models have already learned to catch." Roles, the authors argue, deserve more attention from the research community because they've become one of the most important abstractions in the AI stack. "Unless LLMs achieve genuine role perception, we think injection defense will remain a perpetual whack-a-mole game," they conclude. "And the continuous nature of role boundaries opens the threat of injections designed to subtly shift LLM states through seemingly innocuous text, legally and at scale." ®

Four years into the Kremlin’s illegal invasion of its neighboring country, Russian influence operations have moved beyond their near-exclusive focus on Ukraine to their former favorite targets: the US and Europe, and especially covert cyber-ops intended to undermine political stability within these countries and the unity between them, according to Google Threat Intelligence. “This shift is significant because it likely signals increased focus outside of Ukraine, warning that pro-Russia influence activity targeting the European Union (EU), North Atlantic Treaty Organization (NATO), and other top targeting priorities may intensify,” Google threat hunters James Sadowski and Alden Wahlstrom said in a Monday report. The war in Ukraine helped Russian operatives refine their influence activities, and Moscow’s increasing use of AI for planning, reconnaissance, and content generation “marks a forward trend in pro-Russia IO,” the duo wrote. The primary objectives of these pro-Russia influence campaigns center around five key goals, all of which aim to advance the Kremlin’s military and political objectives via psychological manipulation – something Russia has been very, very good at throughout history. These key goals include: undermining democracy, dividing Western coalitions, promoting Russia’s image and regional interests, maintaining domestic stability, and repressing political dissent within the country. While the campaigns themselves typically involve fake news websites serving up phony political commentary or direct messages disseminating pro-Russian narratives, influence ops frequently coincide with data-wiping malware or other destructive cyberattacks, hack-and-leak campaigns, or direct cyber-espionage, according to the Googlers. This influence ecosystem spans multiple channels, from official government propaganda and covert intelligence operations to hacktivists and pro-Russian proxies. Oftentimes, the lines between these channels are blurred, making attribution more difficult and giving Moscow plausible deniability for cyber activities. Plus, Russian cybergroups – like everyone else – are increasingly using AI tools across their entire campaigns to make their cyber operations more efficient. Late last month, researchers at WithSecure documented Russia-linked cyber espionage crews using AI tools to help build malware, spin up infrastructure, and craft lures for attacks on Ukrainian targets. The group, tracked as GreyVibe, used OpenAI's ChatGPT, Google's Gemini, and Ideogram AI across almost every stage of its operations since at least August 2025, we’re told. “As Russia seeks to emerge from international isolation and reorients its influence ecosystem back toward global objectives, it is critical for defenders to understand how this ecosystem provides the Kremlin with a durable influence capability in order to better anticipate future Russian influence threats,” the Googlers noted. ®

Not everyone is willing to follow responsible disclosure of vulns. An anonymous researcher has dumped what they say is working exploit code for zero-day vulnerabilities across 15 software products and open source projects without notifying any vendors or maintainers prior to publishing - and attackers are already exploiting at least two of these. The first is CVE-2026-55200, a critical, pre-authentication remote code execution (RCE) vulnerability in libssh2, a popular client-side C library that implements the SSH2 protocol. Remote attackers can send crafted SSH packets with excessively large packet_length values to corrupt heap memory and achieve remote code execution. A fix has been merged into the libssh2 mainline development source control branch, and maintainers are still preparing a libssh2 release containing the patch. The second is CVE-2026-20896, a critical authentication bypass vulnerability affecting self-hosted Gitea Docker deployments that allows unauthenticated remote attackers to impersonate any user and fully take over the Git server. It’s fixed in Gitea 1.26.3. The researcher, who goes by bikini, dropped the exploit code and vulnerability write-ups in a now-removed GitHub repository called exploitarium. They remind us of Nightmare Eclipse - the zero-day bug hunter who has been publishing Microsoft exploits over the past couple of months. Unlike Nightmare Eclipse, however, bikini doesn’t appear to hold a grudge against any one vendor, publishing purported vulnerabilities across multiple products and projects including libssh2, Splunk, RustDesk, 7-Zip, VLC, AnyDesk, OpenVPN, c-ares, Gitea, and Floci. Bikini claimed - and, to be clear, The Register has not verified these claims or that the code works - that none of the exploits in the repo have been reported. “Feel free to report them yourself and take credit for the CVE if handed out lulz,” the anonymous researcher wrote, as shown in this screenshot posted on X by Ledger CTO Charles Guillemet. “Please do not abuse these. I do this so to allure people into the field.” Other researchers, including Federal Signal analyst Ethan Andrews, suggested that bikini used advanced AI models - specifically GPT-5.5 Codex - to automate fuzzing and vulnerability discovery, in yet another indication that the AI-induced vulnpocalypse is nigh. In response to bikini’s data dump, Andrews built 44 KQL detection rules covering the full exploitarium repo with language translation available for non-KQL stacks. “The most technically significant findings - libssh2 pre-auth heap write and Gitea default Docker auth bypass - have been independently verified as high-risk with active exploitation observed,” Andrews wrote, noting that some of the exploitarium disclosures “have been dismissed by the community as low-impact AI-fuzzing noise.” While the repository has since been removed by GitHub, nothing ever truly dies on the internet, and it’s safe to assume that attackers are now also using AI to scan for vulnerable instances. In many cases, bikini’s PoCs mean they don’t even have to spend time developing an exploit. ®