Red Team

Storm-2603 hid in SharePoint memory, then left four backup tunnels

Kaspersky details a fileless ToolShell intrusion by Storm-2603: an in-memory IIS webshell, then four legitimate tunnels before a Warlock ransomware try.

Server rack graphic with the headline Storm-2603 hides in SharePoint memory

Kaspersky has published a detailed reconstruction of a Storm-2603 intrusion in which the attacker ran its whole control layer from the memory of an on-premises SharePoint server. Before trying to launch Warlock ransomware, the attacker also set up four separate remote access channels, all built on legitimate software.

What happened

On 5 November 2026, Kaspersky researchers Alexander Rodchenko and Rodrigo Wanderson published the fifth instalment of the company’s “SOC Files” series. It covers an intrusion against a SharePoint Server customer that Kaspersky attributes, with moderate confidence, to Storm-2603. Microsoft assesses, with moderate confidence, that Storm-2603 is China-based. In July 2025 Microsoft linked it to Warlock and LockBit ransomware deployments that followed exploitation of the SharePoint flaws now known as ToolShell (CVE-2025-53770 and CVE-2025-53771).

The attack ran in two phases, with a deliberate pause between them. On 20 December, a single request checked whether the server’s ToolPane endpoint was exploitable. It came from infrastructure belonging to ONYPHE, a commercial attack surface scanner that actively tests for specific CVEs. Around 12 minutes later, a host at a bulletproof hosting provider connected to the same server. Then nothing happened for three days. On Christmas Eve, a period when many security teams run on skeleton staff, the full exploit chain arrived through a Safing Privacy Network relay. Kaspersky says the 20 December probe was first rated low priority because nobody tied it to what came later. The incident was discovered on 26 December.

The intrusion ended with an attempt to run Warlock ransomware, which Kaspersky’s endpoint product blocked. The report does not name the victim or its sector.

The technical picture

The attacker’s foothold never needed a file on disk. The webshell was loaded straight into the ASP.NET runtime inside the IIS worker process, w3wp.exe, where it registered a custom VirtualPathProvider, the component that decides how page paths are resolved. It used reflection to tamper with compilation state so the provider worked even in precompiled applications. It ignored all traffic except requests carrying one particular User-Agent string, so it stayed quiet for normal visitors. For command and control it used a custom binary protocol hidden with XOR inside ordinary web requests. It also used the open source suo5 proxy to turn the SharePoint host into a TCP pivot into the internal network.

Kaspersky describes a modular C# toolkit whose components fetched files, silently installed MSI packages, enumerated users, processes and connections, and created local administrator accounts through the SAM RPC interface rather than command-line tools. To reach SYSTEM, the operator used a cut-down EfsPotato variant, which tricks LSASS into connecting to a named pipe and then steals its token. This works because IIS worker processes hold SeImpersonatePrivilege.

The tradecraft that matters most for defenders came next. The worker process started msiexec and installed Velociraptor, a legitimate open source forensics tool, from Supabase cloud storage. The version was 0.73.4.0, which is vulnerable to CVE-2025-6264. Cisco Talos had already reported in October 2025 that Storm-2603 uses Velociraptor as an execution framework. The actor then set up four independent routes back in: Cloudflare Tunnel, Zoho Assist unattended access, a VS Code tunnel and a small reverse proxy. None of them needed the webshell or the ToolShell bug. The operator also dropped a vulnerable driver, rsndispot.sys, and sideloaded a DLL that Kaspersky identifies as Warlock’s antivirus killer, before the ransomware launch was stopped.

Timeline of the Storm-2603 intrusion from a 20 December SharePoint probe to a blocked Warlock ransomware launch

Why it matters for UK organisations

Many UK organisations still run SharePoint on premises. ToolShell has been public for over a year, but an organisation that patched late, or patched without rotating its ASP.NET machine keys, may still have an attacker inside.

Warlock is already known in the UK. In August 2025 the group claimed an attack on London-headquartered Colt Technology Services that took customer support and voice API platforms offline. At the time, researcher Kevin Beaumont suggested on Mastodon that Colt had probably been breached through CVE-2025-53770. That was his assessment only; Colt did not confirm the entry route and the link remains unproven. The Kaspersky case does not involve Colt. What it shows is the playbook that a ToolShell-to-Warlock intrusion follows once the attacker is in.

The tool choice is also awkward for UK SOCs: Zoho Assist, Cloudflare Tunnel, VS Code and Velociraptor are signed, common and often allow-listed, so their traffic rarely stands out.

Expert view

In red team work, the hardest step is rarely getting in. It is staying in after the blue team spots the first implant. Storm-2603 has dealt with that by building redundancy. Each of the four tunnels is legitimate software that an administrator could plausibly have installed, and none of them depends on the others. Incident responders who find and remove a webshell can be tempted to declare victory too early. This case shows why that is dangerous.

The timing deserves attention too. A three-day gap between a vulnerability check and exploitation, followed by an attack on a bank holiday eve, is a deliberate choice. Most correlation rules look at short time windows. If a single scanner hit is triaged as noise and nobody looks back at it, the attacker has effectively been told that the target is vulnerable and that nobody is watching.

The fileless design also punishes a common habit. Kaspersky notes that the implant vanishes when the application pool recycles, so restarting IIS before capturing memory destroys the key evidence while the other tunnels survive.

What to do now

  1. Confirm SharePoint is fully patched and rekeyed. Apply the current SharePoint security updates, enable AMSI in Full Mode, rotate ASP.NET machine keys and restart IIS once memory has been captured. This falls under the Cyber Essentials security update management control.
  2. Hunt for remote access tools you did not deploy. On servers, look for cloudflared, Zoho Assist agents, VS Code or VS Code Insiders tunnels, Velociraptor and unfamiliar reverse proxies. Remove anything without an owner and a change record.
  3. Treat w3wp.exe child processes as high severity. Alert when the IIS worker launches msiexec, makes unexpected outbound connections or shows named pipe impersonation behaviour.
  4. Use the IIS telemetry Kaspersky highlights. In the IIS-Configuration ETW provider, events 25 and 47 that point to paths with no file on disk, combined with no file-change monitoring events for those paths, suggest a virtual path implant. Keep an inventory of legitimate VirtualPathProvider implementations.
  5. Audit local administrator accounts. The implant created accounts through SAM RPC, so compare current local admin groups with a known baseline. This sits under the Cyber Essentials user access control.
  6. Look back at low-priority alerts. Review isolated scanner hits against internet-facing applications over a window of at least a week, not just minutes. Make sure holiday cover includes someone authorised to contain a host.
  7. Block vulnerable drivers. Turn on Microsoft’s vulnerable driver blocklist to blunt EDR-killing attempts.

Bottom line

Storm-2603 did not need any new exploit here. It used a year-old SharePoint bug, held its access in memory, and then put four legitimate backup channels in place so that losing any one of them did not matter. UK organisations with on-premises SharePoint should assume that removing a webshell is the start of an investigation, not the end of one, and should check their servers for remote access software they never approved.

Sources

Related Posts