Illustrative image: a data centre. Image: via Wikimedia Commons.
TL;DR: The Storm-2603 SharePoint fileless backdoor explained in short: Kaspersky's 5 November 2026 report shows how the group used the ToolShell flaws to plant a webshell that lived entirely inside the SharePoint server's memory — no file on disk — then lined up Warlock ransomware, which was blocked before it could encrypt anything. If you run SharePoint on-premises, the fix is patching, machine-key rotation and memory-aware detection, not just a file scan.
📌 Key Highlights
- Kaspersky's Securelist team published its analysis of the Storm-2603 intrusion on 5 November 2026 — the attack itself happened in December, and the new report is what makes this worth reading now.
- The attackers probed a SharePoint server on 20 December, went quiet for three days, then struck on Christmas Eve, when many security teams run on skeleton staffing.
- The backdoor was fileless: it ran inside the IIS worker process (w3wp.exe) and vanished if the server restarted — so a normal file scan would find nothing.
- After the backdoor, the group installed the legitimate forensics tool Velociraptor, set up four separate tunnels for backup access, and tried to launch Warlock ransomware — which Kaspersky's endpoint protection blocked.
- Kaspersky attributes the intrusion to Storm-2603 with moderate confidence. Microsoft tracks Storm-2603 as a standalone threat actor previously linked to Warlock and LockBit ransomware.
What happened?
On 5 November 2026, Kaspersky's Securelist research team published "The SOC Files 5", a detailed reconstruction of an intrusion into a customer's on-premises Microsoft SharePoint server. The incident itself unfolded in December: a single probe on the 20th, three quiet days, a full attack on Christmas Eve, and discovery on 26 December during retrospective log analysis. The three-day gap is part of the story — it initially made the probe look like a low-priority event, so nobody connected it to the later attack.
The entry point was ToolShell, the name for a chain of SharePoint flaws: CVE-2025-53770 and CVE-2025-53771, which bypass the earlier patches for CVE-2025-49704 and CVE-2025-49706. All four let an attacker run code on an unpatched on-premises SharePoint server through specially crafted web requests. Microsoft disclosed the wave in July 2025, and CISA added CVE-2025-53770 to its Known Exploited Vulnerabilities catalogue on 20 July 2025, with a one-day federal deadline — a sign of how actively the flaws were being used.
What makes this incident different from the July 2025 wave is not the entry point but what the attackers did with it. Instead of dropping a webshell file on disk — the classic move, and the one most defences are built to catch — they injected their implant straight into the server's memory.
| Date | What happened | Why it matters |
|---|---|---|
| 20 December | A single request probed the SharePoint ToolPane endpoint to check whether the server was vulnerable to CVE-2025-53770. The request came via ONYPHE infrastructure, a service that actively tests whether internet-facing systems are vulnerable. | One quiet probe is easy to dismiss — and that is the point. It looked low-priority. |
| 21–23 December | Silence. No further malicious activity was observed. | The gap broke the link between the probe and the attack in the defenders' view. |
| 24 December | The full remote-code-execution chain ran from a Safing Privacy Network node, loading a webshell directly into the IIS worker process (w3wp.exe). Christmas Eve, when staffing is thinnest. | Timing was deliberate: fewer people watching, slower response. |
| 26 December | Kaspersky spotted the intrusion during retrospective analysis and connected the 20 December probe to the attack. | Only looking backwards joined the dots — the hallmark of a patient intrusion. |
| 5 November 2026 | Kaspersky published the full technical analysis, including detection guidance. | The public lesson: file-based detection alone misses this class of attack. |
Storm-2603 SharePoint Fileless Backdoor: How It Worked
The implant was a modular C# framework whose main component, called G.cs, orchestrated everything from inside the server's memory. It registered a custom VirtualPathProvider — a legitimate ASP.NET mechanism that lets an application serve pages that do not exist as files. That is the trick at the heart of the attack: the backdoor behaved like a normal part of the web application, so there was no webshell file to scan, quarantine or hash.
It stayed dormant unless an incoming request carried a specific User-Agent value, so ordinary traffic never triggered it. When it did wake up, it talked to its operators over a custom binary protocol with simple XOR obfuscation, and it built a TCP tunnel with the suo5 proxy tool so the attackers could reach other machines inside the network through the compromised SharePoint host.
Illustrative image: a data centre. Image: via Wikimedia Commons.
The implant also escalated its own privileges. Using a named-pipe technique borrowed from the EfsPotato tool, it tricked the LSASS process into handing over its token and spawned a new process with SYSTEM rights — the highest privilege on a Windows machine. It could do this because IIS worker processes hold the impersonation privilege the technique needs.
Later stages of the attack did leave traces on disk, which is an important nuance: only the access layer — the backdoor itself — was fileless. Shortly after the webshell ran, the worker process launched msiexec.exe to install Velociraptor version 0.73.4.0, a genuine open-source digital-forensics tool that itself carries a known flaw (CVE-2025-6264). The attackers used it for command execution, discovery and persistence. Cisco Talos had already tied this exact Velociraptor abuse to Storm-2603 in October 2025.
Why it matters: tunnels, an EDR killer and a blocked ransomware launch
Once inside, the group built redundancy into its access. Through Velociraptor it installed Zoho Assist for unattended remote access, set up VS Code CLI tunnelling, deployed Cloudflare Tunnel and added a small reverse proxy. The point was to stay in even if the ToolShell foothold was found and removed — by that stage, the attackers no longer depended on the SharePoint flaw or the IIS process at all.
Then came the ransomware phase. The attackers uploaded a vulnerable driver (rsndispot.sys) and a malicious DLL identified as Warlock ransomware's AV killer — tools designed to switch off endpoint protection before encryption starts. They tried to launch Warlock ransomware on the network. In this incident, it did not work: Kaspersky's Proactive Defense Module blocked the ransomware process before it could encrypt anything. That is the good news in this report, and it is also the warning — the same chain, against a target without that protection, ends in encryption.
For Indian readers, the honest picture is this: Kaspersky did not name the victim, its country or its sector, and no India-specific victim or CERT-In advisory for this incident was found at the time of writing. But the exposure is not hypothetical for India — on-premises SharePoint is widely used by Indian enterprises, government bodies and large educational institutions, and the same unpatched server anywhere in the world is vulnerable to the same chain. The July 2025 ToolShell wave hit organisations globally, and this report proves unpatched servers were still being exploited months later.
What to check and fix now
Microsoft's standing guidance, repeated in the Securelist analysis, is straightforward — but the report adds one step most teams get wrong. If you run SharePoint Server on-premises, work through this list:
| Action | Detail |
|---|---|
| Patch SharePoint | Apply the latest SharePoint Server security updates. The July 2025 patches close ToolShell; later cumulative updates include further hardening. Do not assume a July patch means you are done. |
| Enable AMSI in Full Mode | Antimalware Scan Interface in Full Mode lets Defender inspect the content SharePoint processes handle, including in-memory activity. |
| Rotate ASP.NET machine keys | Storm-2603 stole SharePoint MachineKeys in the July 2025 wave. Rotating them invalidates forged authentication tokens from a past compromise. |
| Preserve evidence FIRST | Before restarting IIS or the server, capture memory and IIS telemetry. A restart erases a fileless implant — and with it, the evidence of what happened. |
| Then restart IIS | Restarting clears any memory-resident implant. Only do this after the evidence is preserved. |
| Hunt, don't just scan | Look for the detection signals in the next section. A clean antivirus scan proves nothing against a fileless backdoor. |
For detection, Kaspersky's report gives defenders concrete signals. A request to the ToolPane endpoint that immediately loads the Microsoft.GeneratedCode helper assembly alongside the App_Web_toolpane.aspx assembly indicates the runtime is processing attacker-supplied serialised data. And for the VirtualPathProvider implant, the tell is in IIS telemetry: events 25 and 47 (a path being resolved) appear, while the file-change-monitoring events 17, 18, 19 and 21 that a real on-disk file would produce are absent. A path that exists for IIS but not on disk is the smoking gun. Kaspersky has also published two free tools on GitHub — CLRDeserializationExploitFinder and VirtualPathProvider Lab — to help teams hunt for exactly this.
Should you care?
✅ Yes, if you run SharePoint on-premises — patch now, rotate machine keys, and check for the memory-resident signals above, because this report proves the July 2025 flaws were still being exploited months later and that file scans alone will not find the backdoor.
⏳ Less urgent if you only use SharePoint Online (Microsoft 365) — the ToolShell flaws affect on-premises SharePoint Server, not the cloud service. Still worth knowing: the same "living off legitimate tools" pattern — Velociraptor, Cloudflare Tunnel, VS Code tunnelling — shows up in intrusions everywhere, so unusual appearances of remote-admin tools on any server deserve a second look.
The broader lesson is the one Kaspersky closes with: detection has to move beyond file-based webshell hunting toward runtime behaviour — strange activity in w3wp.exe, unexpected outbound connections, token impersonation, and legitimate tools appearing where they should not be.
FAQs
What is the Storm-2603 SharePoint fileless backdoor?
It is a memory-resident webshell that the Storm-2603 group planted in an on-premises SharePoint server using the ToolShell flaws (CVE-2025-53770 and CVE-2025-53771). Instead of writing a malicious file to disk, the implant loaded directly into the IIS worker process, w3wp.exe, so file-based antivirus and webshell scans could not see it.
What is ToolShell?
ToolShell is the name for a chain of Microsoft SharePoint vulnerabilities disclosed in July 2025. CVE-2025-53770 and CVE-2025-53771 bypass earlier patches for CVE-2025-49704 and CVE-2025-49706. Together they let an unauthenticated attacker run code on an unpatched on-premises SharePoint server through crafted web requests. CVE-2025-53770 was added to CISA's Known Exploited Vulnerabilities catalogue on 20 July 2025.
Did the Warlock ransomware attack succeed?
No — in this incident, Kaspersky's Proactive Defense Module blocked the Warlock ransomware process before it could encrypt anything. The attackers had already disabled defences in preparation and had Warlock's AV-killer tool ready, so the outcome depended on the endpoint protection in place. Microsoft has previously linked Storm-2603 to Warlock and LockBit ransomware attacks after ToolShell exploitation.
How can I tell if my SharePoint server was hit by a fileless attack?
A clean file scan is not enough. Check IIS telemetry for the pattern Kaspersky describes: events 25 and 47 for a path, without the file-change events 17, 18, 19 and 21 that a real file would produce. Also look for ToolPane requests that load the Microsoft.GeneratedCode assembly, unexpected Velociraptor, Zoho Assist, VS Code tunnel or cloudflared processes, and preserve memory and IIS logs before restarting anything.
Takeaway: ToolShell was patched in July 2025, but Storm-2603 proved months later that unpatched SharePoint servers were still open — and that the backdoor they plant may leave no file behind at all. Patch, rotate your machine keys, and hunt in memory, not just on disk.
If you administer a SharePoint Server, check your patch level against Microsoft's July 2025 security updates today — and if anything in the detection list above looks familiar, preserve your memory and IIS logs before you restart the server.
Related reading: our explainers on the SonicWall SSL-VPN flaw that bypasses SAML and MFA, the Barracuda Email Security Gateway chained RCE, and the Plex2Shell vulnerability chain — three more actively exploited flaws patched in the same season.
Sources
- Kaspersky Securelist — How to detect fileless attacks exploiting ToolShell: analyzing the Storm-2603 incident (5 November 2026)
- Microsoft Security Blog — Disrupting active exploitation of on-premises SharePoint vulnerabilities (22 July 2025)
- CISA — Known Exploited Vulnerabilities Catalog (CVE-2025-53770 added 20 July 2025)
- Cyber Security News — Storm-2603 Hackers Exploit SharePoint ToolShell Flaws to Hide Fileless Backdoor and Launch Ransomware Attack (6 November 2026)
- Cyber Press — Hackers Exploit Microsoft SharePoint ToolShell Vulnerabilities to Deploy Fileless Backdoor That Hides in Memory (6 November 2026)
Comments
Post a Comment