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.

UserAssist artifacts

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.

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:

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.

Dark Project, an emerging financially motivated ransomware operation, has claimed 38 victims across eight countries in the supplied threat intelligence snapshot, with manufacturing and healthcare bearing the heaviest exposure. The group combines data theft, system encryption, and public disclosure threats with an affiliate program designed to scale intrusions. The figures represent allegations published through criminal […]

The post Dark Project Ransomware Gang Claims 38 Victims Across 8 Countries, Targeting Healthcare and Manufacturing appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

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.

The attack chain, from reconnaissance to infrastructure compromise

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.

Intrusion timeline

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.

Fingerprinting with ONYPHE

The request characteristics were consistent with ONYPHE’s vulnerability checks, which use active, non-intrusive probes to identify internet-exposed systems vulnerable to specific CVEs. For ToolShell, ONYPHE adopted the approach used by Niels Hofmans (hazcod). Namely, it attempts to inject a harmless marker into the target server to find out if it is vulnerable.

OFFICIAL ONYPHE CVE CHECKER (TOOLSHELL)

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

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

A connection from an IP address belonging to Pfcloud UG BPH

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.

Webshell components

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

Bidirectional TCP tunnel initialization

G.cs establishes a full-duplex proxy tunnel to support interactive control. It stores active target sockets in memory to pair concurrent HTTP read and write channels.

TCP connections from the C2 server to arbitrary hosts inside the target network are supported for pivoting and lateral movement. The traffic is proxied through the SharePoint host.

Target-to-attacker data channel

Attacker-to-target data channel

As can be seen in the screenshots, the attackers used the suo5 tool to implement traffic proxying. Its authors promote it as a stable forward-proxying tool for scenarios where outbound internet connections are prohibited.

To increase its performance, G.cs manipulates ThreadPool by raising its limits for concurrent operations and maximum timeout.

ThreadPool manipulation

“Prog.cs”: 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

HYFLOCK ransomware operators have developed successive Windows encryptors that lock files, access network shares, and attempt to obstruct recovery, while implementation flaws create sharply different outcomes for victims. The investigation distinguishes demonstrated functionality from promotional claims. Although researchers confirmed encryption and scheduled-task registration, they did not establish successful domain-wide propagation or reliable execution after remote […]

The post Hackers Develop New HYFLOCK Ransomware That Encrypts Files and Attempts to Block Recovery appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

Overview 

The UK's National Cyber Security Centre (NCSC) has put a date on a threat that security teams across Europe have been bracing for. In its 2026 Annual Review, The State of the Cyber Nation, the agency assesses it is highly likely that AI-powered malware will be used in a ransomware attack on UK Critical National Infrastructure by 2028. 

That is not a distant, speculative scenario. It is a two-year window, and it lands alongside a second judgement. By 2028, China, Russia and other nation-states will highly likely be using AI-enabled cyber capabilities routinely to pursue geopolitical goals, with the UK facing sophisticated attacks at greater scale and speed. 

The review also recorded that UK and EU member states jointly attributed a December 2025 attack on Poland's energy grid to Russia's FSB Centre 16. Had it succeeded, roughly 500,000 citizens could have lost power. Europe is not watching this threat from the sidelines; it is where the playbook is being tested. 

Key Takeaways 

• 2028 is the marker. The NCSC judges AI malware will highly likely be used in ransomware against UK CNI before the end of 2028. 

• Europe's grid is already a target. Russia's FSB Centre 16 was attributed to the December 2025 attack on Poland's energy grid, and a July 2026 advisory from 18 partners in 12 countries flagged the same group exploiting vulnerable routers to reach CNI networks worldwide. 

• China is best positioned to use AI against CNI. The NCSC rates China's activity as the most sophisticated and sustained cyber challenge facing the UK. 

• AI speeds up old tricks rather than inventing new ones. For large organizations, 88% of incidents the NCSC handled began through just four initial access vectors. 

• A "patch wave" is coming. AI-assisted vulnerability discovery will shrink the time defenders have between disclosure and exploitation. 

• The gap is widening. Organizations with legacy technology and slow remediation will become the preferred targets of both states and criminals. 

The 2028 Warning 

The NCSC's assessment is precise about where AI makes the difference. It calls AI an almost certain "force multiplier" that improves reconnaissance, social engineering, vulnerability discovery and exploit development. The biggest effect, it says, will be faster and larger versions of existing tactics rather than brand-new attack vectors. 

Ransomware is where that acceleration hits CNI hardest. The review expects criminal adoption of AI to raise the scale and efficiency of ransomware, social engineering and exploitation. It also warns that open-source AI tools built for security researchers are likely to be repurposed to automate criminal workflows, cutting costs and raising attack volumes against less resilient targets. 

The agency is careful not to overstate today's reality. Its Incident Management team has begun to see attackers using AI tools, but none of the observed uses enabled a new class of attack. Human operators remain essential, and the NCSC notes that losing control of an agentic AI is likely to hinder threat actors from reaching their goals. 

The review's pessimistic 2028 scenario shows why that caveat may not last. In it, frontier AI is available to everyone from state actors to novice hackers, jailbroken models are sold in criminal marketplaces, and attribution becomes harder as capability spreads. It even describes a realistic possibility of an automated cyber actor operating beyond its operator's control. Cloud-controlled CNI and AI-driven robotics raise the chance that a digital compromise causes physical harm. 

The NCSC stresses this is an illustration of the cost of inaction, not a forecast. But it is a scenario written by the agency responsible for defending UK infrastructure, and it is set just two years out. 

Europe: The Proving Ground for CNI Attacks 

If the UK is looking at 2028, continental Europe is already living with the threat. The NCSC names Russia as the most audacious cyber threat to the UK today. GCHQ Director Anne Keast-Butler goes further in the review's foreword, warning that tactics Russia developed against Ukraine are now being turned more widely on states and their institutions. 

Three data points from the review frame the European picture: 

• Poland's energy grid (December 2025). The UK and EU member states formally attributed the attack to FSB Centre 16. If successful, it could have cut electricity to around 500,000 people. 

• Router exploitation on a global scale (July 2026). The NCSC and 18 international partners from 12 countries issued a joint advisory on FSB Centre 16 actors exploiting vulnerable routers to target CNI networks worldwide. On the same day, the UK sanctioned 24 individuals and entities tied to destructive cyber and hybrid operations, including criminals running proxy networks linked to Russian intelligence. 

• Operational technology in crosshairs. The review points to recent attacks on programmable logic controllers (PLCs) as evidence that organizations failing to modernize are falling behind. 

The pattern matters for anyone running energy, water, transport or telecoms in Europe. Grids, interconnectors and supply chains cross borders, and a disruptive attack in one country can cascade into its neighbors. The review also describes how cyber threats to the UK can escalate rapidly and without warning during periods of geopolitical tension. 

Add AI to this mix and the timeline compresses. A state actor that today relies on patience and known router flaws could, with AI-assisted discovery and exploitation, find and weaponize new weaknesses across thousands of European edge devices far faster than defenders can patch them. 

China is Best Positioned to Turn AI on Critical Infrastructure 

While Russia is the loudest threat, the NCSC sees China as the most capable. It judges that China highly likely has both the intent and the best position to use AI against CNI and other strategic targets. Its frontier AI programmes are expected to sharpen vulnerability identification, targeting efficiency and access operations. 

Data sits at the center of that strategy. The review describes China collecting large volumes of information from the UK and elsewhere, then using it to train models and improve capability. In the AI era, stolen data is no longer just espionage material; it is fuel. 

The UK has already acted on this. In December 2025, it sanctioned two China-based firms: i-Soon, which targeted more than 80 government and private IT systems globally, and Integrity Technology Group, which the FBI has linked to the Flax Typhoon intrusions. In April 2026, the NCSC and 15 partners across nine other countries published guidance on the covert networks most China-linked actors use to hide their activity. 

The 2028 scenario adds a further concern: China, as a leading developer, may help spread advanced AI-cyber capability to other actors, letting them hide in the noise and making attribution harder for European defenders. 

AI Runs the Old Playbook, Only Faster 

The most useful finding in the review is also the least dramatic: attackers are still getting in through the basics. Over the past year, the NCSC received 1,831 reports of cyber attacks. Of these, 337 needed its direct support, and 80 were classed as nationally significant. 

For large organizations, 88% of incidents started through four initial access vectors: 

1. Exploiting public-facing applications 

2. Phishing 

3. Misuse of valid accounts 

4. Exploiting external remote services 

Even state-linked intrusions often used flaws for which patches already existed but had not been applied quickly enough. As the review puts it, sophisticated actors do not need to be sophisticated to gain initial access; their skill shows in what they do once inside. 

This is exactly where AI changes the economics. The NCSC expects AI-assisted vulnerability discovery to give attackers more chances to hit systems before owners patch them. It is urging every organization to prepare for a "patch wave": a surge of security updates across the technology stack, many of them critical, as AI exposes years of technical debt. 

Two further risks deserve attention: 

• Shadow AI. Staff moving sensitive data to personal devices to use unsanctioned AI tools leaves organizations blind to where that data goes, and open to both APT groups and criminals. 

• The widening gap. Mature, well-resourced organizations will use AI to detect and fix faster. Those running legacy systems will fall further behind and become more attractive targets. 

The financial stakes are already clear. UK government research cited in the review puts the annual cost of malicious cyber activity to UK organizations at about £14.7 billion. The 2025 attack on Jaguar Land Rover alone cost the company around £196 million in direct costs and contributed to UK GDP growing just 0.1% in Q3 2025. 

How the UK Is Fighting Back With AI 

The NCSC's answer is to meet machine-speed attacks with machine-speed defense. Several initiatives in the review stand out: 

• Cyber Shield. A joint NCSC and DCMS programme to build a national agentic cyber defense ecosystem over five years. The NCSC supplies the platform and intelligence, while defensive agents are built by the security market and open-source community. Early phases focus on detection and blocking, where automation is already practical. 

• Project DROMOS. Launched in 2026 by the Government Cyber Coordination Centre and the AI Security Institute, it used frontier AI models to review government codebases. Expanded into live environments, it surfaced hundreds of potential security issues, including critical vulnerabilities. 

• National Detect Strategy. A pilot aiming, by 2030, to ensure defenders across critical systems can detect and respond to known vulnerabilities and attacker techniques at organizational, community and national scale. 

• Regulation and benchmarks. The Cyber Security and Resilience Bill brings new sectors into scope and adds national security powers. The new CAF Core Profile sets a minimum resilience baseline for essential services. 

There are early results. Under the Government Cyber Action Plan, the median time to fix domain-related vulnerabilities fell from 50 days to 8. The Early Warning service now covers 19,922 organizations, up 52% on last year. 

For Europe, the lesson is that partnership is now part of the defense. The review highlights the world's first AI security standard developed through ETSI, the European standards body, as proof that allies can shape AI security while the technology is still evolving. 

National defense at machine speed also depends on seeing adversaries before they reach the network. Groups like FSB Centre 16 and China-linked operators plan, recruit, and trade access in places most defenders never look. As AI makes attribution harder, government agencies, national CERTs, and defense bodies need intelligence that tracks threat actors across the open, deep, and dark web and connects that activity to the infrastructure being targeted. Cyble Hawk is built for exactly this. It gives national security teams sovereign threat intelligence, adversary profiling, and investigative support. That means early warning of campaigns against critical infrastructure and stronger attribution when an attack does land. Book a demo to see how your agency can move from reacting to incidents to anticipating them. 

Recommendations for CNI Operators in the UK and Europe 

The NCSC's core message is that AI did not create these weaknesses; it is exposing them faster. Operators of critical infrastructure should act on the following now: 

1. Harden the edge first. Inventory and patch internet-facing applications, VPNs, routers, and remote access services. These are the routes FSB Centre 16 and others are actively exploiting. 

2. Prepare for the patch wave. Build processes to test and deploy security updates more often, faster and across suppliers. Track time-to-remediate as a board-level metric. 

3. Kill password-based access where you can. Move privileged and remote users to phishing-resistant authentication such as passkeys, and audit valid accounts for misuse. 

4. Segment IT from OT. Limit the paths from corporate networks to PLCs and industrial control systems, and monitor those boundaries continuously. 

5. Govern AI use internally. Map what data AI tools and agents can access, what actions they can take, and how they are monitored. Close off shadow AI with approved alternatives. 

6. Rehearse recovery, not just prevention. Test ransomware response playbooks against scenarios where operational systems must run during disruption. Use the NCSC's guidance on recovering from highly disruptive attacks. 

7. Lock down the supply chain. Require baseline controls such as Cyber Essentials, or equivalent standards in EU frameworks, from suppliers with access to critical systems. 

8. Use threat intelligence that moves at AI speed. Monitor for exploitation of newly disclosed flaws, stolen credentials, and chatter about your sector, so you can act before an incident escalates. 

9. Start post-quantum planning. The NCSC wants discovery and migration planning finished by 2028, priority migrations by 2031 and full migration by 2035. 

Conclusion 

The NCSC has given Europe a deadline. By 2028, AI-powered ransomware against UK critical infrastructure moves from possibility to expectation, and state actors will be using AI as a routine part of their operations. The Poland grid attack and the global router campaign show the targeting is already in place; AI simply adds speed and scale. 

The agency's own framing is a "moment of choice." Organizations that modernize, patch fast, and build resilience now will be able to absorb what comes next. Those that defer will find AI exposing their technical debt faster than they can repay it. 

For CNI operators across the UK and Europe, the next two years are the window to close the gap. Continuous visibility into emerging vulnerabilities, active exploitation and threat actor activity will be central to staying ahead of attacks that move at machine speed. 

Source 

• NCSC Annual Review 2026: The State of the Cyber Nation 

The post AI-Powered Ransomware Is Coming for UK Critical Infrastructure, and Europe Is Already the Testing Ground appeared first on Cyble.

Synology warns of ransomware attacks exploiting a 2024 flaw in outdated NAS devices, urging users to update DSM immediately.

A security fix released in 2024 is now at the centre of ransomware attacks against Synology NAS devices. The company has found attackers targeting systems that still run outdated versions of DiskStation Manager (DSM), putting files stored on these network storage devices at risk of encryption and extortion.

Synology disclosed the attacks on October 29, 2026. Its investigation found that threat actors are taking advantage of a vulnerability that the vendor had already addressed in December 2024. “These attacks aim to encrypt data and extort ransom.” The warning highlights how devices left without security updates can remain exposed long after vendors have released a fix.

The company hasn’t identified the exact vulnerability used in the attacks. Instead, it refers customers to Synology-SA-24:20, a security advisory published on November 5, 2024, which documents three flaws affecting DSM. The advisory was updated as fixes became available across different software branches, with the DSM 6.2 update released on December 5.

The three vulnerabilities have different security implications. CVE-2024-10441 is the most severe, with a CVSS score of 9.8. It affects the system plugin daemon and could allow an unauthenticated remote attacker to execute arbitrary code on a vulnerable device.

CVE-2024-50629 has a CVSS score of 5.3 and affects the DSM webapi component. It could allow remote attackers to read limited files. The third issue, CVE-2024-10445, is rated 4.3 and concerns improper certificate validation in the update functionality. It could allow an attacker in an adjacent network position to write limited files.

Synology hasn’t confirmed which of these vulnerabilities attackers are exploiting. The three flaws should therefore be considered part of the security advisory, not three confirmed entry points in the current ransomware campaign.

The vendor has released corrected builds for all the affected DSM branches. Users should check the full version number installed on their NAS and compare it with the minimum fixed releases listed in the advisory:

• DSM 7.2.2: 7.2.2-72806-1 or later.
• DSM 7.2.1: 7.2.1-69057-6 or later.
• DSM 7.2: 7.2-64570-4 or later.
• DSM 7.1: 7.1.1-42962-7 or later.
• DSM 6.2: 6.2.4-25556-8 or later.

The impact of a ransomware infection on a NAS can extend well beyond the storage device itself. Businesses often use these systems to keep shared documents, operational files and backup copies in one place. If attackers encrypt that data, employees may lose access to essential information, while recovery can become much harder if the NAS also holds the backups needed to restore other systems.

Updating DSM is therefore an immediate priority for administrators and home users alike. Synology is also advising customers to enable automatic updates so that future security fixes don’t depend entirely on someone checking for them manually.

“Synology also recommends enabling automatic updates to keep DSM up to date at all times.” concludes the advisory.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, NAS)

A ransomware affiliate known as 3AM compromised a UK school network using a mix of traditional intrusion techniques and patterns suggesting the involvement of artificial intelligence. According to Bitdefender’s investigation on November 3, this operation appears to follow a suspected hybrid workflow: a human operator selects the targets while a language model may handle repetitive […]

The post 3AM Ransomware Hackers Use AI-Assisted Attacks to Breach UK Schools and Spread Across Windows Domains appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

The National Institute of Standards and Technology (NIST) released new cybersecurity guidance to help solo business owners protect themselves against threats like phishing, ransomware, and account compromise. Published on November 2, 2026, NIST Cybersecurity White Paper 50 simplifies the Cybersecurity Framework 2.0 and offers practical actions for businesses with limited IT infrastructure. The publication, Small […]

The post NIST Releases New Cybersecurity Guidelines to Protect Small Businesses From Phishing and Ransomware Attacks appeared first on GBHackers Security | #1 Globally Trusted Cyber Security News Platform.

A widespread Synology NAS ransomware wave targets exposed devices via patched DSM vulnerabilities. Update firmware immediately to prevent encryption.

Related Posts:

• NIK C2 Framework Integrates OpenAI API to Analyze Stolen Data in Live Attacks
• Rust Doorway Botnet Exploits Routers, Cameras, and Servers
• Malicious Claude Code Extension Injects SSH Backdoor in Cursor Marketplace

The post Synology NAS Ransomware Targets Unpatched Devices appeared first on Daily CyberSecurity.

Synology NAS devices are facing C3RB3R ransomware attacks linked to 2024 security flaws, prompting the company to urge users to update outdated DiskStation Manager versions and packages.

The warning followed reports from the 360 Security Team and Solar Emergency Response Team on October 29. Victims found their files encrypted with the .L0CK3D extension and a ransom note named read-me3.txt.

Security teams provisionally identified the ransomware as C3RB3R. The available reporting does not establish how many devices have been compromised.

The Synology security advisory, tracked as Synology-SA-24:20, covers three vulnerabilities disclosed following Pwn2Own 2024. Published on November 5, 2024, it received several updates as fixes became available across DSM branches.

Although Appinn described the weaknesses as fixed by December 2024, Synology’s revision history shows that several patches arrived during November.

Cyber Security News previously examined the critical CVE-2024-10441 flaw in Synology DSM, which carries a CVSS score of 9.8 and allows unauthenticated remote code execution without user interaction.

Synology NAS Hit by C3RB3R Ransomware Attacks

The advisory also lists CVE-2024-50629, a webapi flaw that lets remote attackers read limited files, and CVE-2024-10445. This update certificate validation flaw lets an adjacent attacker write limited files. These carry scores of 5.3 and 4.3, respectively.

Public reporting has not established which individual vulnerability was used in each ransomware incident or whether attackers combined them.

Early coverage raised concerns because Solar reportedly investigated an affected device running DSM 7.4.1-90080 Update 1. At that stage, researchers were still examining the entry point and had not ruled out an unknown vulnerability.

The later report attributed Synology’s findings to older, patched weaknesses. The published accounts do not explain the apparent mismatch or confirm a new zero-day attack.

Synology NAS devices have faced ransomware threats before. Cyber Security News covered the Diskstation ransomware investigation, involving criminals who targeted Synology storage systems. That separate case provides background on the threat to NAS users. However, the available reports do not establish any connection to C3RB3R.

Synology’s advisory lists fixed releases including DSM 7.2.2-72806-1, 7.2.1-69057-6, 7.2-64570-4, 7.1.1-42962-7, and 6.2.4-25556-8. These are historical patch thresholds, not a recommendation to stop updating. Administrators should install the latest release supported by their NAS model and update official packages and third-party components.

Appinn’s initial incident report recommends removing direct internet access to DSM management and SSH, using a VPN for remote connections, and checking for unusual logins, unknown administrators, and scheduled tasks.

It also advises enabling two-factor authentication and keeping independent offline or off-site backups. For affected users, those separate backups may provide a route to recover encrypted files. Updating remains necessary, but it does not itself restore files already encrypted by ransomware.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Hackers Exploit Patched Synology NAS Vulnerabilities to Deploy C3RB3R Ransomware and Encrypt Files appeared first on Cyber Security News.

Acronis analyzes Qilin ransomware after 900+ attacks in 2026. See how ESXi Qilin ransomware scripts hijack VMware hosts and leak data on WikiLeaksV2.

Related Posts:

• Malicious Claude Code Extension Injects SSH Backdoor in Cursor Marketplace
• INJ3CTOR3 FreePBX Malware Steals 17 Configuration Files for Off-Box Toll Fraud
• CyberDakait Deploys Seven Android Trojan Families Against 17,960 Indian Banking Devices

The post Qilin Ransomware Targets VMware ESXi Servers and Healthcare Networks After Claiming 900 Victims in 2026 appeared first on Daily CyberSecurity.

Hackers reduced the GMO Internet ransom demand from $50M to $1M and leaked victim files after the Japanese conglomerate ignored multiple bug warnings.

Related Posts:

• UAT-11473 Deploys KeyDrift Malware on Cisco SD-WAN Controllers via CVE-2026-20127
• Chained PHP2Shell Exploit Roots 25 Firewall Servers Including US Government Systems
• Hive Ransomware Affiliate Artem Stryzhak Sentenced to 70 Months in US Prison

The post GMO Internet Ransom Demand Slashed After Cloud Breach appeared first on Daily CyberSecurity.

Artem Stryzhak gets 70 months in prison for Hive and Nefilim ransomware attacks, while the FBI offers $11 million for his alleged co-conspirator.

A federal court in Brooklyn has sentenced Artem Stryzhak, a Ukrainian national, to 70 months in prison for using ransomware to extort millions of dollars from victims. The U.S. Attorney’s Office for the Eastern District of New York announced it in a press release, and it also says an $11 million reward remains for a co-conspirator who’s still at large.

“Earlier today, in federal court in Brooklyn, Artem Stryzhak, a Ukrainian national, was sentenced by United States District Judge Pamela K. Chen to 70 months in prison for using ransomware to extort millions of dollars from victims.” reads the DoJ’s press release. “The defendant pled guilty in December 2025 to conspiracy to commit fraud, extortion, and related activity in connection with computers.  “

In December, Artem Aleksandrovych Stryzhak pleaded guilty in the U.S. for Nefilim ransomware attacks. The Ukrainian citizen was arrested in Spain in 2024 and extradited to the US in April 2025. He pleaded guilty to conspiracy to commit computer fraud, extortion, and related activity

Nefilim ransomware was used to encrypt networks worldwide, including in the Eastern District of New York, causing millions in losses from ransom payments and system damage. Attackers employed a customized ransomware executable in each attack, generating unique decryption keys and tailored ransom notes for victims. In June 2021, Nefilim administrators granted Artem Stryzhak access to the ransomware code in exchange for 20% of his ransom proceeds, which he deployed via his account on the administrators’ online platform.

Stryzhak and co-conspirators researched victims using online databases to collect information on their net worth, size, and contacts. After gaining network access, they stole data to pressure companies into ransom payments. Nefilim notes warned that stolen data would be posted on publicly accessible “Corporate Leaks” sites maintained by the administrators if victims did not comply.

Volodymyr Tymoshchuk, Stryzhak’s co-defendant and Nefilim admin, is a serial ransomware cybercriminal who is still at large. 

According to court documents, his first role was with Nefilim. Starting around June 2021, he joined the ongoing Nefilim conspiracy as an affiliate and got access to the ransomware. In exchange, he agreed with one of the group’s administrators, Volodymyr Tymoshchuk, to pay the administrators 20 percent of the ransom proceeds. Even crime has licensing fees.

One of those attacks came in June 2021, when Stryzhak stole data from a company in the oil and gas transportation industry. About a week later, he created email addresses that went into a ransom note sent to the victim. He kept deploying Nefilim ransomware through at least October 2021.

Separately, he also joined the Hive ransomware group as one of its earliest affiliates. From June 2021 to January 2023, Hive’s conspirators attacked about 1,500 victims worldwide, including government entities, hospitals and businesses. The attacks caused major disruption to daily operations around the world and affected responses to the COVID-19 pandemic. One hospital had to give up digital technology to treat its patients and couldn’t take in new ones right after the attack.

As a Hive affiliate, Stryzhak and his co-conspirators hit seven victims, including law firms, a dentist’s office and a healthcare provider, during the pandemic. Those victims couldn’t get to their encrypted data. The FBI, as part of a months-long effort to disrupt Hive, gave a decryption key to one of Stryzhak’s victims, so that victim recovered its data without paying a ransom.

U.S. Attorney Joseph Nocella, Jr. thanked the FBI’s New York Field Office, the Justice Department’s Office of International Affairs and its Computer Crime and Intellectual Property Section, and Spanish law enforcement for helping to capture him.

“Ransomware attacks like those committed by the defendant wreak enormous havoc—harming victim companies that pay millions in remediation and ransoms, preventing hospitals and other critical facilities from accessing data, and putting sensitive information in the hands of bad actors,” stated United States Attorney Nocella. “Today’s sentence reflects that cybercriminals cannot hide from law enforcement and will face significant punishment for their criminal conduct. We remain determined to capture Volodymyr Tymoshchuk, a serial ransomware developer and Stryzhak’s co-conspirator.”

The State Department’s Transnational Organized Crime Rewards Program is offering up to $11 million for information that leads to the arrest, conviction or location of Tymoshchuk.

Anyone with information can call the FBI at +1-917-242-1407 or email TymoTips@fbi.gov, contact a local field office if in the United States, or reach the nearest U.S. Embassy if overseas.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)