Storm-2603’s Fileless SharePoint Intrusion Explained

On-premises Microsoft SharePoint servers can become more than an initial foothold when attackers place their control layer inside the application runtime. An incident analyzed by Securelist, Kaspersky’s threat research publication, demonstrates how exploitation of the ToolShell vulnerabilities enabled Storm-2603 to execute code in the IIS worker process, maintain an in-memory web shell, tunnel traffic through the compromised host, and stage further tools.

The case is significant because the first-stage access mechanism did not depend on a conventional executable or a persistent service. The core implant was loaded into w3wp.exe, the IIS worker process used by SharePoint, and remained active within the application domain. Later activity did create files and processes, including forensic-response tooling and a ransomware component, but the bridge used for command and control initially remained memory-resident.

Securelist attributes the incident to Storm-2603 with moderate confidence. That assessment is based on the combination of SharePoint exploitation, behavior associated with Warlock ransomware, use of tunneling tools, and post-compromise activity that Kaspersky says is consistent with previously documented Storm-2603 operations. Microsoft tracks Storm-2603 as a separate actor, but the supplied research does not establish links to other groups.

From a low-signal probe to code execution

The intrusion unfolded in stages rather than as one continuous burst. Securelist observed an initial HTTP request on December 20 aimed at a SharePoint administrative endpoint associated with ToolPane. The request was interpreted as a vulnerability-fingerprinting action for CVE-2025-53770. It used a harmless marker and was associated with infrastructure operated by ONYPHE, an internet-scale attack-surface discovery service.

About 12 minutes later, a connection from infrastructure associated with Pfcloud UG was observed. Securelist did not identify exploitation in that connection and described it as possible follow-on reconnaissance. The next three days contained no observed malicious activity. On December 24, the same SharePoint host received a crafted request that led to execution in w3wp.exe. The initial probe was not connected to the later activity until retrospective investigation.

This sequence illustrates a practical incident-response problem: vulnerability scans and exploitation may be separated by enough time to defeat simplistic event correlation. A probe that appears benign or low priority can acquire a very different meaning when correlated with later application, host, and network telemetry.

The broader ToolShell activity involved CVE-2025-53770 and CVE-2025-53771. According to Securelist, these vulnerabilities affected on-premises SharePoint and enabled remote code execution through crafted HTTP requests. The report does not provide a complete exploit procedure, and this analysis does not reproduce one.

A web shell inside the ASP.NET runtime

The injected component was a modular, in-memory C# framework. Its main component, identified by researchers as G.cs, registered a custom ASP.NET VirtualPathProvider. This allowed the implant to participate in virtual-path processing and dynamic compilation without requiring a conventional web-shell file on disk.

Securelist reported that the implant used reflection to inspect and alter internal application state, including state associated with ASP.NET compilation. The researchers classify this behavior under the MITRE ATT&CK technique T1553, as stated in the source report. The runtime modifications were designed to allow the provider to operate even when the application was precompiled.

The implant did not process every request equally. It used a particular HTTP User-Agent value as a trigger, allowing ordinary requests to pass without activating the malicious logic. This selective behavior can reduce visible anomalies in application logs and makes detection based only on generic web traffic less reliable.

The implant’s lifetime was tied to the affected application domain. It survived in memory while the relevant runtime remained active, but its state could be lost when the application pool recycled or IIS restarted. That limitation did not make the access harmless: while active, the implant provided a control channel and a platform for further operations.

Traffic tunneling and host interaction

The same runtime component implemented a custom binary communication protocol with XOR-based obfuscation. Securelist says the implant used HTTP request headers to recognize operator traffic, parse data, and, when required, establish TCP connections to hosts inside the victim network.

The result was a full-duplex proxy capability. The SharePoint server acted as an intermediary between the external operator and internal systems, supporting access to arbitrary network destinations reachable from the compromised environment. Researchers also observed use of the suo5 tool for traffic proxying. The report describes the mechanism as capable of supporting interactive control and internal network pivoting; it does not provide evidence that every possible internal target was accessed.

The framework also manipulated .NET thread-pool settings to support concurrent operations. Its entry point, referred to as Prog.cs, dispatched commands to modules responsible for runtime hooking, system discovery, file retrieval, package installation, and account operations.

Those modules included collection of logged-on users, running processes, network interfaces, and active connections. A file-download component could place files in the Program Data directory, while another module silently installed and executed MSI packages. The framework could also create administrative accounts through the native Windows SAM RPC interface instead of relying on ordinary command-line account-management tools.

Securelist further reported a privilege-escalation capability based on local token impersonation through the EFSRPC interface and a malicious named pipe. The behavior was designed to obtain a SYSTEM-level process from the IIS worker context. This is a researcher-documented capability of the observed framework, not an indication that every compromised SharePoint host will exhibit the same sequence.

When the attack moved beyond SharePoint

Shortly after the web shell was injected, the compromised worker process launched msiexec.exe to install a remote MSI package hosted on Supabase. The package contained Velociraptor version 0.73.4.0, which the report says was vulnerable to CVE-2025-6264. In this incident, the open-source digital forensics and incident-response platform was used for persistence, discovery, data collection, command execution, and deployment of additional payloads.

The attackers attempted to create redundancy by deploying several tunneling or remote-access mechanisms. Securelist identified Zoho Assist Unattended Support, VS Code CLI tunneling, Cloudflare Tunnel, and a lightweight reverse proxy utility. This changed the operational picture: access was no longer dependent solely on the SharePoint process or the ToolShell vulnerability.

The report also describes attempts to weaken endpoint defenses. A vulnerable driver was found at C:\ProgramData\rsndispot.sys, with SHA-256 value 054a32d6033b1744dca7f49b2e466ea2. Researchers also identified a DLL associated with Warlock ransomware’s security-tool termination behavior. The observed ransomware attempt was blocked by Kaspersky Endpoint Security’s Proactive Defense Module. Thus, ransomware deployment was attempted but was not confirmed as successful in the analyzed case.

Detection opportunities in memory and telemetry

Securelist emphasizes that file-based scanning alone is insufficient for this type of intrusion. One detection path involves correlating CLR loader activity with suspicious ToolPane processing. The researchers observed App_Web_toolpane.aspx-related assemblies and Microsoft.GeneratedCode in the same application domain and execution window. These assemblies can also appear during legitimate ASP.NET and serialization activity, so neither is conclusive in isolation.

Higher-confidence evidence comes from the combination of loader events, memory inspection, and metadata associated with dangerous object graphs. Securelist specifically identifies strings such as ObjectDataProvider, ExpandedWrapper, and LosFormatter as useful indicators when they appear in the relevant runtime context. The report also references Kaspersky’s CLRDeserializationExploitFinder project as a defensive detection aid.

A second detection path focuses on virtual content. The Microsoft-Windows-IIS-Configuration ETW provider is highlighted as useful telemetry. Events 25 and 47 can show that IIS and ASP.NET resolve a resource to a physical path even though no corresponding file exists. For ordinary disk-backed content, events 17, 18, 19, and 21 normally reflect file-change monitoring. A resolved path without the expected file and monitoring chain can indicate a virtual-path provider or another runtime-backed resource.

Administrators should first inventory legitimate VirtualPathProvider implementations. The mechanism is not inherently malicious, so detection should focus on unexplained registrations, mismatches between virtual and physical paths, unusual memory in w3wp.exe, and request patterns that activate hidden application logic.

What organizations should do now

• Prioritize exposed SharePoint servers. Confirm the state of systems affected by CVE-2025-53770 and CVE-2025-53771, follow Microsoft’s applicable security guidance, and avoid treating an exploit-related alert as resolved merely because the initial request was blocked.
• Preserve volatile evidence. If compromise is suspected, collect IIS logs, application telemetry, CLR loader data, ETW records, and memory from relevant w3wp.exe processes before recycling application pools or restarting servers where operationally safe.
• Hunt for runtime-backed content. Compare IIS configuration resolution with the filesystem, review unexpected virtual-path providers, and investigate missing file-change-monitoring events for resources that appear to exist.
• Correlate application and host activity. Look for unusual child processes from w3wp.exe, including msiexec.exe, unexpected network connections, administrative-account creation, named-pipe activity, and token-impersonation behavior.
• Review remote-access and tunneling tools. Investigate unexpected Zoho Assist, VS Code tunneling, Cloudflare Tunnel, reverse proxies, or newly introduced DFIR tooling. Legitimate installations should be tied to documented owners and approved use.
• Check identity and cryptographic material. Following confirmed SharePoint code execution, rotate exposed credentials and relevant SharePoint machine keys as part of a broader compromise assessment, and review newly created privileged accounts.
• Use the supplied indicators carefully. Block or investigate known malicious infrastructure only within an organization’s normal change-control process. Indicators should supplement, not replace, behavioral hunting.

Selected indicators

Securelist lists the following artifacts from the incident: 45[.]91[.]94[.]204; 49[.]51[.]132[.]100; 91[.]224[.]92[.]121; 199[.]232[.]210[.]172; 204[.]76[.]203[.]219; the web-shell hash 0xFD91321BF7FF7245DDA9B7B5D791ACE0; the driver hash 0x054a32d6033b1744dca7f49b2e466ea2; and the Warlock-associated DLL hash 0x2d9ebf9c042f596f435865b40edad928. The report also identifies infrastructure including hxxps://vdfccjpnedujhrzscjtq[.]supabase[.]co/, hxxps://auth[.]qgtxtebl[.]workers[.]dev/, and hxxps://files[.]catbox[.]moe/. These values should be validated against local telemetry before being used for response decisions.

Conclusion

The central lesson from Securelist’s analysis is that a SharePoint compromise can move quickly from an application vulnerability to a memory-resident control plane, internal traffic proxy, host discovery, privileged access, and ransomware staging. Defenders need visibility into runtime behavior, process ancestry, ETW and IIS telemetry, memory, identity changes, and network tunneling—not only files written to disk. Correlating reconnaissance with later activity is equally important: the quiet probe may be the first chapter of the intrusion.

Sources

Securelist: “The SOC Files 5: Ghost in the pipeline, or a fileless SharePoint breach by Storm-2603”