Storm-2603 SharePoint intrusion used an in-memory IIS implant
An investigation into activity associated with Storm-2603 found an attack against an on-premises Microsoft SharePoint server that used a memory-resident implant inside the IIS worker process. The implant provided command-and-control and a route into the victim’s network while avoiding a persistent webshell file on disk. Later actions did create disk artifacts, including tools and a ransomware component.
The activity analyzed took place in December 2025 and involved the ToolShell vulnerabilities, CVE-2025-53770 and CVE-2025-53771. Microsoft has associated Storm-2603 with ransomware-related ToolShell activity, distinguishing it from other observed actors whose activity focused mainly on credential theft, espionage and data theft. In this incident, endpoint protection blocked the ransomware process, according to the investigation.
A probe preceded exploitation by four days
The first recorded interaction was on December 20, when an HTTP request to a SharePoint ToolPane administrative endpoint checked whether the server was vulnerable to CVE-2025-53770. The request came from infrastructure associated with ONYPHE, a platform that performs active checks of internet-exposed systems. About 12 minutes later, a connection from infrastructure associated with Pfcloud UG was observed. Investigators reported no exploitation in that connection.
After three days without observed activity, the attacker returned on December 24. A crafted request from 45.91.94.204 led to code executing in w3wp.exe, the IIS worker process. The address was identified as a Safing Privacy Network node, a detail that does not establish the operator’s original location. The incident was discovered on December 26. Investigators said the time gap initially made it harder to connect the earlier probe with the later compromise.
SharePoint memory became the control channel
The implant was loaded into the ASP.NET runtime rather than written to disk. It remained in the application domain for the lifetime of that runtime state and would be lost if the application pool recycled or IIS restarted. Its main component, G.cs, registered a custom VirtualPathProvider and used runtime techniques to insert itself into ASP.NET request processing, including when the application was precompiled.
The implant checked incoming request headers for a specific User-Agent value. Matching requests activated its functions; other requests left it dormant. G.cs also implemented a custom, obfuscated communications protocol and could establish a bidirectional TCP tunnel through the SharePoint host to systems inside the victim’s network. Investigators identified use of the suo5 tool for proxying traffic.
Other components supported file downloads, collection of logged-on user and process information, network connection enumeration, MSI execution, and account creation through the Windows SAM RPC subsystem. The framework also included a privilege-escalation technique based on named-pipe impersonation through the Encrypting File System Remote Protocol. These capabilities meant the implant could support both host discovery and access to internal systems while residing in the web server process.
Follow-on tooling expanded access
Shortly after implant deployment, w3wp.exe launched msiexec.exe to install a remotely hosted MSI. The package contained Velociraptor version 0.73.4.0, which the attackers used for command execution and activities including persistence, discovery, data collection and payload execution. The investigation notes that this version was vulnerable to CVE-2025-6264.
The actor also deployed several ways to maintain remote access, including Zoho Assist-Unattended Support, VS Code CLI tunneling, Cloudflare Tunnel and a lightweight reverse proxy. These options reduced reliance on the SharePoint process and the original ToolShell entry point. Investigators also reported an attempted endpoint-defense disruption involving a driver at C:\programdata\rsndispot.sys and a malicious DLL identified as an AV-killing component associated with Warlock ransomware. The supplied driver hash was 054a32d6033b1744dca7f49b2e466ea2; the DLL hash was 2d9ebf9c042f596f435865b40edad928. The ransomware launch was blocked by Kaspersky Endpoint Security’s Proactive Defense Module.
Detection should connect runtime and endpoint evidence
For defenders, the case illustrates why a disk-only search can miss an important part of a SharePoint intrusion. The investigators recommend correlating ToolPane requests with CLR loader activity and application-domain evidence. In the observed case, the presence of the dynamically compiled App_Web_toolpane.aspx assembly alongside a Microsoft.GeneratedCode helper assembly was notable. Both can appear during legitimate operation, so their presence alone is not proof of compromise; timing and association with a suspicious ToolPane request matter.
Security teams can use IIS and SharePoint request telemetry to identify unusual access to ToolPane, then correlate it with process creation by w3wp.exe, unexpected MSI installations and changes in runtime assembly loading. Memory and CLR metadata inspection can help identify unexpected types and serializer-related structures. Monitoring should also look for newly created administrative accounts, unusual tunneling tools and suspicious driver or DLL activity.
The broader lesson for SIEM teams is to preserve and correlate events across a longer window than a single shift or alert cycle. A low-priority vulnerability check followed days later by exploitation may only become meaningful when analysts can link HTTP activity, CLR behavior and endpoint events. In this incident, that correlation exposed an attack whose initial access mechanism was fileless, even though subsequent post-exploitation actions left evidence on disk.
