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

The fourth quarter of 2025 went down as one of the most intense periods on record for high-profile, critical vulnerability disclosures, hitting popular libraries and mainstream applications. Several of these vulnerabilities were picked up by attackers and exploited in the wild almost immediately.

In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged with popular C2 frameworks throughout Q4 2025.

Statistics on registered vulnerabilities

This section contains statistics on registered vulnerabilities. The data is taken from cve.org.

Let’s take a look at the number of registered CVEs for each month over the last five years, up to and including the end of 2025. As predicted in our last report, Q4 saw a higher number of registered vulnerabilities than the same period in 2024, and the year-end totals also cleared the bar set the previous year.

Total published vulnerabilities by month from 2021 through 2025 (download)

Now, let’s look at the number of new critical vulnerabilities (CVSS > 8.9) for that same period.

Total number of published critical vulnerabilities by month from 2021 to 2025< (download)

The graph shows that the volume of critical vulnerabilities remains quite substantial; however, in the second half of the year, we saw those numbers dip back down to levels seen in 2023. This was due to vulnerability churn: a handful of published security issues were revoked. The widespread adoption of secure development practices and the move toward safer languages also pushed those numbers down, though even that couldn’t stop the overall flood of vulnerabilities.

Exploitation statistics

This section contains statistics on the use of exploits in Q4 2025. The data is based on open sources and our telemetry.

Windows and Linux vulnerability exploitation

In Q4 2025, the most prevalent exploits targeted the exact same vulnerabilities that dominated the threat landscape throughout the rest of the year. These were exploits targeting Microsoft Office products with unpatched security flaws.

Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities:

• CVE-2018-0802: a remote code execution vulnerability in Equation Editor.
• CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor.
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system.

The list has remained unchanged for years.

We also see that attackers continue to adapt exploits for directory traversal vulnerabilities (CWE-35) when unpacking archives in WinRAR. They are being heavily leveraged to gain initial access via malicious archives on the Windows operating system:

• CVE-2023-38831: a vulnerability stemming from the improper handling of objects within an archive.
• CVE-2025-6218 (formerly ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. This can lead to arbitrary code execution. We covered this vulnerability in detail in our Q2 2025 report.
• CVE-2025-8088: a vulnerability we analyzed in our previous report, analogous to CVE-2025-6218. The attackers used NTFS streams to circumvent controls on the directory into which files were being unpacked.

As in the previous quarter, we see a rise in the use of archiver exploits, with fresh vulnerabilities increasingly appearing in attacks.

Below are the exploit detection trends for Windows users over the last two years.

Dynamics of the number of Windows users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

The vulnerabilities listed here can be used to gain initial access to a vulnerable system. This highlights the critical importance of timely security updates for all affected software.

On Linux-based devices, the most frequently detected exploits targeted the following vulnerabilities:

• CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications.
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation.
• CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem.
• CVE-2023-32233: another vulnerability in the Netfilter subsystem that creates a use-after-free condition, allowing for privilege escalation due to the improper handling of network requests.

Dynamics of the number of Linux users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

We are seeing a massive surge in Linux-based exploit attempts: in Q4, the number of affected users doubled compared to Q3. Our statistics show that the final quarter of the year accounted for more than half of all Linux exploit attacks recorded for the entire year. This surge is primarily driven by the rapidly growing number of Linux-based consumer devices. This trend naturally attracts the attention of threat actors, making the installation of security patches critically important.

Most common published exploits

The distribution of published exploits by software type in Q4 2025 largely mirrors the patterns observed in the previous quarter. The majority of exploits we investigate through our monitoring of public research, news, and PoCs continue to target vulnerabilities within operating systems.

Distribution of published exploits by platform, Q1 2025 (download)

Distribution of published exploits by platform, Q2 2025 (download)

Distribution of published exploits by platform, Q3 2025 (download)

Distribution of published exploits by platform, Q4 2025 (download)

In Q4 2025, no public exploits for Microsoft Office products emerged; the bulk of the vulnerabilities were issues discovered in system components. When calculating our statistics, we placed these in the OS category.

Vulnerability exploitation in APT attacks

We analyzed which vulnerabilities were utilized in APT attacks during Q4 2025. The following rankings draw on our telemetry, research, and open-source data.

TOP 10 vulnerabilities exploited in APT attacks, Q4 2025 (download)

In Q4 2025, APT attacks most frequently exploited fresh vulnerabilities published within the last six months. We believe that these CVEs will remain favorites among attackers for a long time, as fixing them may require significant structural changes to the vulnerable applications or the user’s system. Often, replacing or updating the affected components requires a significant amount of resources. Consequently, the probability of an attack through such vulnerabilities may persist. Some of these new vulnerabilities are likely to become frequent tools for lateral movement within user infrastructure, as the corresponding security flaws have been discovered in network services that are accessible without authentication. This heavy exploitation of very recently registered vulnerabilities highlights the ability of threat actors to rapidly implement new techniques and adapt old ones for their attacks. Therefore, we strongly recommend applying the security patches provided by vendors.

C2 frameworks

In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks against users during Q4 2025, according to open sources.

TOP 10 C2 frameworks used by APTs to compromise user systems in Q4 2025 (download)

Despite the significant footprints it can leave when used in its default configuration, Sliver continues to hold the top spot among the most common C2 frameworks in our Q4 2025 analysis. Mythic and Havoc were second and third, respectively. After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above:

• CVE-2025-55182: a React2Shell vulnerability in React Server Components that allows an unauthenticated user to send commands directly to the server and execute them from RAM.
• CVE-2023-36884: a vulnerability in the Windows Search component that allows the execution of commands on a system, bypassing security mechanisms built into Microsoft Office applications.
• CVE-2025-53770: a critical insecure deserialization vulnerability in Microsoft SharePoint that allows an unauthenticated user to execute commands on the server.
• CVE-2020-1472, also known as Zerologon, allows for compromising a vulnerable domain controller and executing commands as a privileged user.
• CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, enabling remote access to a vulnerable OS and high-privilege command execution.
• CVE-2025-8088 and CVE-2025-6218 are similar directory-traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user.

The set of vulnerabilities described above suggests that attackers have been using them for initial access and early-stage maneuvers in vulnerable systems to create a springboard for deploying a C2 agent. The list of vulnerabilities includes both zero-days and well-known, established security issues.

Notable vulnerabilities

This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q4 2025 and have a publicly available description.

React2Shell (CVE-2025-55182): a vulnerability in React Server Components

We typically describe vulnerabilities affecting a specific application. CVE-2025-55182 stood out as an exception, as it was discovered in React, a library primarily used for building web applications. This means that exploiting the vulnerability could potentially disrupt a vast number of applications that rely on the library. The vulnerability itself lies in the interaction mechanism between the client and server components, which is built on sending serialized objects. If an attacker sends serialized data containing malicious functionality, they can execute JavaScript commands directly on the server, bypassing all client-side request validation. Technical details about this vulnerability and an example of how Kaspersky solutions detect it can be found in our article.

CVE-2025-54100: command injection during the execution of curl (Invoke-WebRequest)

This vulnerability represents a data-handling flaw that occurs when retrieving information from a remote server: when executing the curl or Invoke-WebRequest command, Windows launches Internet Explorer in the background. This can lead to a cross-site scripting (XSS) attack.

CVE-2025-11001: a vulnerability in 7-Zip

This vulnerability reinforces the trend of exploiting security flaws found in file archivers. The core of CVE-2025-11001 lies in the incorrect handling of symbolic links. An attacker can craft an archive so that when it is extracted into an arbitrary directory, its contents end up in the location pointed to by a symbolic link. The likelihood of exploiting this vulnerability is significantly reduced because utilizing such functionality requires the user opening the archive to possess system administrator privileges.

This vulnerability was associated with a wave of misleading news reports claiming it was being used in real-world attacks against end users. This misconception stemmed from an error in the security bulletin.

RediShell (CVE-2025-49844): a vulnerability in Redis

The year 2025 saw a surge in high-profile vulnerabilities, several of which were significant enough to earn a unique nickname. This was the case with CVE-2025-49844, also known as RediShell, which was unveiled during a hacking competition. This vulnerability is a use-after-free issue related to how the load command functions within Lua interpreter scripts. To execute the attack, an attacker needs to prepare a malicious script and load it into the interpreter.

As with any named vulnerability, RediShell was immediately weaponized by threat actors and spammers, albeit in a somewhat unconventional manner. Because technical details were initially scarce following its disclosure, the internet was flooded with fake PoC exploits and scanners claiming to test for the vulnerability. In the best-case scenario, these tools were non-functional; in the worst, they infected the system. Notably, these fraudulent projects were frequently generated using LLMs. They followed a standardized template and often cross-referenced source code from other identical fake repositories.

CVE-2025-24990: a vulnerability in the ltmdm64.sys driver

Driver vulnerabilities are often discovered in legitimate third-party applications that have been part of the official OS distribution for a long time. Thus, CVE-2025-24990 has existed within code shipped by Microsoft throughout nearly the entire history of Windows. The vulnerable driver has been shipped since at least Windows 7 as a third-party driver for Agere Modem. According to Microsoft, this driver is no longer supported and, following the discovery of the flaw, was removed from the OS distribution entirely.

The vulnerability itself is straightforward: insecure handling of IOCTL codes leading to a null pointer dereference. Successful exploitation can lead to arbitrary command execution or a system crash resulting in a blue screen of death (BSOD) on modern systems.

CVE-2025-59287: a vulnerability in Windows Server Update Services (WSUS)

CVE-2025-59287 represents a textbook case of insecure deserialization. Exploitation is possible without any form of authentication; due to its ease of use, this vulnerability rapidly gained traction among threat actors. Technical details and detection methodologies for our product suite have been covered in our previous advisories.

Conclusion and advice

In Q4 2025, the rate of vulnerability registration has shown no signs of slowing down. Consequently, consistent monitoring and the timely application of security patches have become more critical than ever. To ensure resilient defense, it is vital to regularly assess and remediate known vulnerabilities while implementing technology designed to mitigate the impact of potential exploits.

Continuous monitoring of infrastructure, including the network perimeter, allows for the timely identification of threats and prevents them from escalating. Effective security also demands tracking the current threat landscape and applying preventative measures to minimize risks associated with system flaws. Kaspersky Next serves as a reliable partner in this process, providing real-time identification and detailed mapping of vulnerabilities within the environment.

Securing the workplace remains a top priority. Protecting corporate devices requires the adoption of solutions capable of blocking malware and preventing it from spreading. Beyond basic measures, organizations should implement adaptive systems that allow for the rapid deployment of security updates and the automation of patch management workflows.