Securelist (Kaspersky) report published November 5, 2026; coverage November 6, 2026
Nothing on Disk, Everything in Memory: Storm-2603 Hid a SharePoint Backdoor Inside the IIS Worker Process
Securelist, the Kaspersky research arm, published a case study on November 5 of a Storm-2603 intrusion against an on-premises SharePoint server, reconstructed from a December review of a customer logs. The entry was ToolShell, CVE-2025-53770 and CVE-2025-53771, the patch bypasses for CVE-2025-49704 and CVE-2025-49706, through a crafted request to the ToolPane endpoint. A single fingerprinting request on December 20 was rated low priority, in part because it came from ONYPHE scanning infrastructure; three quiet days later, on December 24, the full chain ran and loaded a webshell directly into the IIS worker process, w3wp.exe. The implant wrote nothing to disk: its main component registered a custom VirtualPathProvider so ASP.NET would serve pages that exist only in memory, it woke only for requests carrying a specific User-Agent, spoke a custom binary protocol with XOR obfuscation, proxied traffic inward with the suo5 tool, and escalated to SYSTEM with a named-pipe technique drawn from EfsPotato. From there the worker process installed Velociraptor 0.73.4.0, a legitimate forensics tool vulnerable to CVE-2025-6264, from Supabase storage, and the actor layered backup access through Zoho Assist, VS Code tunneling, Cloudflare Tunnel, and a small reverse proxy, dropped a vulnerable driver to disable endpoint protection, and attempted to launch Warlock ransomware, which Kaspersky Proactive Defense Module blocked before encryption. Securelist attributes the case to Storm-2603 with moderate confidence, based on the ToolShell use, the Warlock tooling, and the Velociraptor pattern; Microsoft ties Storm-2603 to the ransomware side of ToolShell exploitation while other actors used the same flaws mainly for espionage and credential theft. The defensive guidance in the reporting is sequenced: apply the SharePoint updates, enable AMSI in Full Mode, run Defender or an equivalent, rotate ASP.NET MachineKeys, and restart IIS, but preserve memory and IIS telemetry before restarting, because a restart erases the implant and the evidence with it.
Executives
The uncomfortable fact in this case is the calendar: a probe on December 20 looked routine, and the real attack arrived on Christmas Eve, when staffing was thin. The second fact is that patching in July would have prevented a December incident, because the flaws were known and fixed months earlier. For any on-premises SharePoint still in service, the executive ask is direct: is it on current updates today, and if an exploitation were confirmed tomorrow, does the team know to capture memory before restarting, since the restart that feels like cleanup destroys the evidence.
CIO / CISO
Treat any unpatched internet-facing SharePoint as a compromise review, not a patch ticket. The implant leaves no file to scan for, so closure evidence is telemetry: IIS and ETW records for VirtualPathProvider registrations and path mappings with no file on disk, w3wp.exe spawning installers or child processes, and the presence of unsanctioned remote access tooling, Velociraptor, Zoho Assist, VS Code tunnels, or cloudflared, on a server that should run none of them. Follow the Microsoft sequence in the reporting, updates, AMSI in Full Mode, MachineKey rotation, and IIS restart, with memory and logs preserved first, and hunt for the layered tunnels even after the SharePoint foothold is closed, because the tunnels were built to survive its removal.
Engineers
Build the hunt around the worker process. Alert on w3wp.exe launching msiexec or writing installers, on new VirtualPathProvider instances, and on outbound connections from the SharePoint host to tunnel and file-hosting services. Check for the vulnerable driver rsndispot.sys and for Velociraptor installations you did not deploy; version 0.73.4.0 carries CVE-2025-6264. If you find exploitation, capture a memory image and the IIS logs before any application pool recycle, and rotate MachineKeys as part of the same incident, since stolen keys let an attacker forge the authentication the webshell relied on.
Everyone (non-IT)
Nothing in this story asks anything of SharePoint users in a browser. The version worth remembering is simple: attackers hid their tool inside the normal memory of a work server, in a way that left no file for ordinary scans to find, and they timed the real attack for a holiday. It is a good example of why IT teams sometimes ask for maintenance windows and evidence capture before a restart, even when restarting feels like the obvious first move.