Public ToolShell reporting often centres on a web shell written to disk, such as the spinstall0.aspx family that Microsoft lists. Kaspersky’s Securelist analysis, published on 5 November 2026 as “The SOC Files 5”, describes a 2025 intrusion where no such file existed in the first stage. The attackers exploited the ToolShell flaws in on-premises SharePoint and ran their control layer entirely inside the IIS worker process.
This deep-dive follows the chain in order, explains why the implant left no file, and then maps detection onto each step. Kaspersky attributes the intrusion to Storm-2603 with moderate confidence, and Microsoft had already linked that actor to ToolShell-based ransomware attacks.
- Single probe for CVE-2025-5377020 December, one request to a ToolPane endpoint, from a scanning service
- Three quiet days21 to 23 December, no follow-up seen
- Full exploit chain24 December, request through a privacy networkTechnique T1190 (MITRE ATT&CK, opens in a new tab)
- Webshell in memoryRuns inside w3wp.exe, nothing written to diskTechnique T1505.003 (MITRE ATT&CK, opens in a new tab)
- SYSTEM through token impersonationEFSRPC coercion of LSASSTechnique T1134.001 (MITRE ATT&CK, opens in a new tab)
- Remote tools and tunnelsVelociraptor, Zoho Assist, VS Code CLI, Cloudflare TunnelTechnique T1219 (MITRE ATT&CK, opens in a new tab)
- EDR removal and Warlock attemptVulnerable driver and DLL sideloadingTechnique T1562.001 (MITRE ATT&CK, opens in a new tab)
Only T1553 is an ATT&CK technique that the Securelist article names itself. We left the first step unmapped because Kaspersky ties that request to a commercial scanner. The other identifiers in this diagram are our mapping of Kaspersky’s description to ATT&CK, so treat them as a starting point for your own detection tagging.
What Happened Before the Storm-2603 ToolShell Exploit?
On 20 December, one request reached a SharePoint administrative endpoint tied to the ToolPane component. Kaspersky says the request came from infrastructure linked to the ONYPHE scanning service and matched ONYPHE’s non-intrusive check for CVE-2025-53770, which injects a harmless marker. About 12 minutes later a connection arrived from a bulletproof hosting provider, which looked like follow-on reconnaissance. Kaspersky says the actor tried nothing more at that point.
Then came three quiet days. Kaspersky points out that this gap delayed correlation, and the probe was rated low priority. On 24 December the full remote code execution chain ran against the same endpoint. It came from an address behind the Safing Privacy Network, a multilayer service that obscures where traffic originates.
The lesson is about timing, not about the probe itself. Internet scanners hit SharePoint all the time, so a single request means little alone. It means more when the same endpoint is exploited days later, which is why Kaspersky recommends correlating low-signal reconnaissance with later privileged activity.
How Does ToolShell Reach Code Execution?
Microsoft lists four related CVEs for the July 2025 wave. CVE-2025-49706 is a spoofing flaw and CVE-2025-49704 allows remote code execution.
CVE-2025-53770 is a ToolShell authentication bypass and RCE related to CVE-2025-49704, and CVE-2025-53771 is a path traversal and bypass of the fix for CVE-2025-49706. Microsoft says they affect on-premises SharePoint servers only, not SharePoint Online.
Our CVE-2025-53770 page and the ToolShell incident record cover the original campaign. They give the background for the 2025 flaws used here.
Kaspersky ties the ToolPane activity in this case to LosFormatter-based deserialization, with gadget types such as ObjectDataProvider and ExpandedWrapper. In plain terms, the server accepts a crafted object and rebuilds it, and the rebuilt object runs attacker code. Kaspersky notes that Microsoft calls BinaryFormatter unsafe, and says similar warnings apply to LosFormatter, which the vulnerable page used.
| Aspect | Security update | Language pack update |
|---|---|---|
| SharePoint Server Subscription Edition | KB5002768 | Not listed |
| SharePoint Server 2019 | KB5002754 | KB5002753 |
| SharePoint Server 2016 | KB5002760 | KB5002759 |
Microsoft says to install both updates where two are listed. Its guidance also says to rotate the ASP.NET machine keys on every SharePoint server and then restart IIS with iisreset.exe. This case shows why: a patch closes the door, but it does not remove a payload that already lives in a running process.
Why Was There No File on Disk?
The payload ran inside w3wp.exe and, according to Kaspersky, lived for the lifetime of the application domain. A recycle or an IIS restart cleared it. That makes the restart in Microsoft’s guidance a cleanup step as well as a patch step, and it also means a restart without memory capture destroys the evidence.
The main module, called G.cs, registers a custom VirtualPathProvider through a non-public ASP.NET method. It uses reflection to inspect whether the application is precompiled and to change internal BuildManager state. Kaspersky maps this to trust control subversion, T1553.
The module then hooks GetCacheKey() to see every request. A specific User-Agent value triggers the implant, and every other request leaves it dormant. The traffic to the implant uses a custom binary protocol with XOR obfuscation, so it blends into normal application requests.
Further modules ran as separate in-memory classes. They listed processes, logged-on users and network settings, and downloaded files into the ProgramData directory. One installed MSI packages silently, and another created administrator accounts through the native SAM RPC subsystem, which Kaspersky says may evade detection and can outlive the webshell. Full-duplex TCP tunnels let the actor pivot from the SharePoint host into the internal network.
How Did the Actor Get SYSTEM and Stay In?
The IIS worker holds the SeImpersonatePrivilege, and Kaspersky says the actor used it. The technique is adapted from EfsPotato: the implant creates a malicious named pipe and calls EfsRpcEncryptFileSrv with a localhost path. That makes LSASS connect to the pipe, the implant impersonates its token, and a SYSTEM process starts.
Shortly after the webshell injection, the worker process launched msiexec.exe to install a remote MSI from cloud storage. The payload was Velociraptor 0.73.4.0, which Kaspersky notes is vulnerable to CVE-2025-6264. The actor used it for persistence, discovery, data collection and payload execution.
Several independent tunnels followed: Zoho Assist Unattended Support, VS Code CLI tunneling, Cloudflare Tunnel and a lightweight reverse proxy. Kaspersky says that by this stage the attackers no longer relied on the IIS process or on ToolShell. Fixing the SharePoint flaw at that point would not have removed them.
What Did the Ransomware Stage Look Like?
Later activity left disk artifacts. The actor dropped a vulnerable driver to terminate security products, together with a malicious DLL for sideloading that Kaspersky identified as the AV killer of Warlock ransomware. It then tried to launch Warlock ransomware, and Kaspersky Endpoint Security blocked the attempt through its Proactive Defense Module.
Microsoft says Storm-2603 deployed Warlock and LockBit before, and names Warlock in the July 2025 campaign. For the group background, see our Warlock ransomware profile and the Warlock Group analysis of GOLD SALEM.
How Do You Detect an Implant With No File?
Detection has to follow the chain, because no single log line proves the intrusion. Kaspersky describes deserialization and VirtualPathProvider signals, and its conclusion adds runtime behaviour. It says several of these signals can also come from legitimate workflows.
- Deserialization. Watch for App_Web_toolpane.aspx* and Microsoft.GeneratedCode loading in the same execution window. Search memory and helper assemblies for ObjectDataProvider, ExpandedWrapper and LosFormatter, and use CLR loader ETW events to identify the assemblies and application domains. Kaspersky also offers its CLRDeserializationExploitFinder tool for ysoserial.net gadget chains.
- VirtualPathProvider registration. Inventory the legitimate providers on each farm and treat any new one as anomalous. In the Microsoft-Windows-IIS-Configuration ETW provider, events 25 and 47 map a configuration path to a physical path or directory. A provider-backed path shows these events with no physical file and without the file-change monitoring events 17, 18, 19 and 21.
- Runtime behaviour. Look for anomalous w3wp.exe activity, unexpected outbound connections, RPC coercion toward LSASS, token impersonation, and new remote-management or forensic tools after an application compromise.
Microsoft’s own list adds file and script signals for the original campaign. These include the spinstall0.aspx family of files under the SharePoint LAYOUTS paths, encoded PowerShell spawned by w3wp.exe, and its Defender detection names for the sign-out request exploit. Those signals fit the first wave, while this intrusion shows what a quieter variant leaves behind.
What Should SharePoint Teams Do First?
The steps below follow Kaspersky’s and Microsoft’s guidance, with our ordering. We also recommend checking the Velociraptor version on any host where you did not install it, because the actor used a vulnerable build.
- Install the July 2025 updates for your SharePoint version and confirm the build number on every farm server.
- Turn on AMSI in Full Mode and run Defender Antivirus or an equivalent EDR on all SharePoint servers, as Microsoft advises.
- Rotate the ASP.NET machine keys, then restart IIS. Capture memory first if you suspect compromise.
- Review new administrator accounts, MSI installs launched by w3wp.exe, and remote-management tools you did not deploy.
- Investigate by tactic and technique, not only by indicators, because Kaspersky lists hashes, domains and addresses that the actor can swap at will.
Kaspersky publishes the indicator types for this case: addresses, hashes, URLs and domains, and file paths. Take the values from the Securelist report itself and load them into your tooling. Our own hunting should start with the behaviours above, since those survive a change of infrastructure.
