- Kaspersky describes a SharePoint intrusion, consistent with Storm-2603's methods, whose access tunnel lived only in the web server's memory and wrote nothing to disk.
- Restarting the application clears that kind of implant, and it also clears evidence. The intruders had meanwhile set up other access routes.
- Ask your team whether they can see runtime behaviour on SharePoint servers, and whether memory is captured before any restart.
A clean disk does not prove a clean server
Most intrusion checks start with one question. What files did the intruder leave behind? Kaspersky describes a case where the key component left none. The lesson here is that patching and file scanning answer only part of the question. A server can look clean on disk and still be doing the intruder's work.
What Kaspersky found
Kaspersky says several groups used the ToolShell flaws in 2025. They are CVE-2025-53770 and CVE-2025-53771. They affect SharePoint servers that companies run themselves.
Microsoft tied the ransomware cases to a group it calls Storm-2603. It saw other groups focus mostly on stolen credentials, spying and data theft.
Kaspersky's December analysis found activity consistent with Storm-2603's techniques. The intruder used the IIS worker process, w3wp.exe, as a bridge into the customer's network. The researchers say the control layer stayed inside that process and wrote nothing to disk. Later steps did leave files. The bridge did not.
The intrusion came in two stages. On December 20, a request from infrastructure linked to ONYPHE tested whether the host was vulnerable. ONYPHE is an attack surface discovery platform. About 12 minutes later, a connection came from Pfcloud UG, a bulletproof hosting provider. Kaspersky says no exploitation was tried at that point.
The main activity came on December 24. It came from an address that Kaspersky identifies as a Safing Privacy Network node. That kind of network routes traffic through several relays, which can hide the true source.
How the in-memory implant works
A web server normally runs code stored in files. Here, Kaspersky says, the malicious code was never saved. It was loaded straight into the ASP.NET runtime. It was then reused on later requests.
The implant only woke up for requests with a specific User-Agent header. Other traffic found it dormant, which makes it harder to spot. When active, it talked to the intruders' server in its own binary format. It masked the data with XOR, a simple scrambling method.
It also worked as a tunnel. Kaspersky says the intruders used a proxy tool called suo5. It routed traffic through the SharePoint host to other machines in the victim's network. The SharePoint server became their gateway.
The implant carried more tools. It could raise itself to SYSTEM level, using a technique adapted from EfsPotato. It could create administrator accounts through a low-level Windows interface instead of ordinary commands. Kaspersky says this may help avoid detection.
This design has a limit. Kaspersky says the implant lasted only as long as the application domain. Recycling the application pool or restarting IIS cleared it.
The intruders did not rely on one door
Soon after the injection, the worker process installed Velociraptor. This is an open-source forensics and incident response tool. Kaspersky says the version was 0.73.4.0, which carries CVE-2025-6264. The intruders used it to run commands on the network. Kaspersky saw it support persistence, discovery, data collection and payload execution.
Cisco Talos reported in October 2025 that threat actors were using Velociraptor after gaining access. Talos tied that to Storm-2603. In this case, the intruders used Velociraptor to set up several independent tunnels. They included a small reverse proxy, Cloudflare Tunnel, VS Code's command-line tunnelling and Zoho Assist's unattended access.
Kaspersky says this let them keep access even if some tools were found and deleted. It also freed them from the IIS process and from ToolShell. So a restart that cleared the memory implant would not have ended this intrusion.
Kaspersky also found a vulnerable driver used to stop security software. It found a malicious DLL that it identifies as the Warlock ransomware tool for disabling security products. The intruders tried to start ransomware. Kaspersky says its Proactive Defense Module blocked the process. That is a vendor describing its own product.
What leaders should ask
Start with the patch record. Were the ToolShell fixes applied, and when? A patch closes the entry point. It does not show whether someone used it earlier.
Then ask about visibility. Can your security team see what happens inside the SharePoint worker process, not only what is saved to disk? Kaspersky's detection advice centres on deserialization. That is when a server rebuilds objects from data in a request. Kaspersky points to a ToolPane request followed at once by a Microsoft.GeneratedCode assembly load in the same application domain.
Ask about the response plan too. If a server looks compromised, does the plan capture memory before the application restarts? A restart first can remove useful evidence.
Finally, ask who may install forensic and remote-access tools on servers. Ask whether new installs raise an alert. In this case, a defender's tool was used to run commands for the intruder.
A clean disk shows what was written. It does not show what was running.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Kaspersky.
