Anatomy of a SharePoint ToolShell In-Memory Attack

In late December 2025, threat actors targeted on-premises Microsoft SharePoint deployments by exploiting critical remote code execution (RCE) deserialization flaws known as the sharepoint toolshell vulnerabilities (CVE-2025-53770 and CVE-2025-53771). Microsoft attributed this ransomware-focused intrusion activity to the threat actor Storm-2603, distinguishing it from concurrent campaigns operated by other threat groups whose primary objectives were restricted to espionage, credential harvesting, and silent data exfiltration.

The defining technical operational security (OpSec) characteristic of Storm-2603 was its fileless access layer. The adversary manipulated the Common Language Runtime (CLR) and ASP.NET execution context within the Internet Information Services (IIS) worker process (w3wp.exe). By remaining resident purely within the memory domain of the web server application pool, the bridge used to maintain control left zero executable binaries or script artifacts on the host file system for its core operational phase.

This technical analysis examines the complete attack lifecycle documented in threat intelligence telemetry: from initial internet-scale vulnerability fingerprinting and multi-day operational latency to memory-resident ASP.NET pipeline subversion, local privilege escalation via RPC named pipe coercion, native SAM API user creation, and Bring Your Own Vulnerable Driver (BYOVD) security tool termination attempts.

Introduction to the ToolShell attack surface

The attack surface exploited by Storm-2603 centers on CVE-2025-53770 and CVE-2025-53771, located within SharePoint administrative endpoints associated with the ToolPane component. In standard Microsoft SharePoint architectures, ToolPane handles dynamic UI rendering and web part configuration. Under the hood, these endpoints process structured, serialized state payloads sent via HTTP POST or GET requests.

Unsafe deserialization occurs when an application deserializes untrusted user-supplied data without validating the object graph structure or class types being instantiated. In the .NET Framework, historical formatters such as BinaryFormatter or complex XML deserializers read incoming byte streams and construct corresponding object instances in memory. If an attacker controls the class metadata within the stream, they can force the CLR to instantiate arbitrary types, invoke property setters, and execute arbitrary code paths during object reconstruction—all within the security context of the parent IIS application pool.

Storm-2603’s intrusion strategy demonstrated a clear division between initial access validation and high-intensity post-exploitation. Telemetry recorded by security researchers at Kaspersky identified a distinct 72-hour operational gap between the initial vulnerability identification probe on 20 December 2025 and full-scale exploitation on 24 December 2025. This temporal gap was designed to exploit defender holiday schedules and bypass correlation windows in automated Security Information and Event Management (SIEM) solutions.

Reconnaissance, fingerprinting, and tactical latency

The initial interaction with the victim’s SharePoint host occurred on 20 December 2025. The request targeted the administrative ToolPane endpoint to verify the host’s susceptibility to CVE-2025-53770. Forensic analysis revealed that this initial probe originated from infrastructure managed by ONYPHE, an attack surface management platform.

Unlike passive search engines that index publicly exposed services based on banners or SSL certificates, ONYPHE performs active, non-intrusive checks. According to analysis published by Kaspersky, the probe implemented a verification methodology originally authored by researcher Niels Hofmans (hazcod). This technique injects a harmless, non-destructive execution marker into the server’s ASP.NET processing pipeline to determine if the payload reaches vulnerable deserialization logic:

• The target web application accepted structured HTTP requests through the ASP.NET pipeline without dropping the connections at perimeter filters.
• The request URI reached the target ToolPane endpoint handler capable of processing serialized parameters.
• The application layer executed the marker without triggering Web Application Firewall (WAF) blocking mechanisms or unhandled application exceptions.

Approximately 12 minutes following the ONYPHE probe, a secondary inbound connection hit the server from IP infrastructure belonging to Pfcloud UG, a hosting provider operating under a bulletproof hosting (BPH) model. Given the IP address’s recorded history of malicious scanning activity, this secondary connection represented follow-on reconnaissance against the confirmed vulnerable endpoint. The exact operational mechanism by which the threat actor accessed or leveraged the ONYPHE probe results remains undisclosed.

# Telemetry Timeline Breakdown
2025-12-20T11:48:00Z - ONYPHE vulnerability check (ToolPane endpoint probe for CVE-2025-53770)
2025-12-20T12:00:00Z - Pfcloud UG secondary reconnaissance connection detected
2025-12-21 to 12-23  - Tactical Latency (72-hour period of operational silence)
2025-12-24T02:14:00Z - High-intensity RCE execution initiated from HostHatch SPN node (45.91.94.204)
2025-12-26T08:30:00Z - Security Operations Centre (SOC) incident discovery and retrospective analysis

Following reconnaissance, Storm-2603 enforced a deliberate 72-hour period of tactical latency between 21 December and 23 December 2025. In enterprise environments, automated triage systems often auto-close low-severity vulnerability scanning alerts if no immediate secondary alerts (such as anomalous process spawning) occur within a 24- to 48-hour correlation window. By remaining dormant over three full days, the actor ensured the original December 20 probe was categorized as background noise.

On 24 December 2025—Christmas Eve, when staffing levels in Security Operations Centres are historically reduced—Storm-2603 executed the main RCE chain. The attack originated from IP address 45.91.94.204 (hosted by HostHatch, LLC under ASN 63473). This IP operated as an exit node for the Safing Privacy Network (SPN).

Unlike standard commercial Virtual Private Networks (VPNs) or Tor, SPN routes traffic through multi-hop VPN topologies, offering Layer 3 support (including TCP, UDP, and ICMP), application-specific routing, and simultaneous multi-identity egress endpoints. Its fixed-size packet padding and low-latency throughput make it effective at bypassing standard IP reputation blocklists and anonymising operational command traffic.

Fileless in-memory architecture of the C# webshell

When the high-intensity exploitation request hit the SharePoint server on 24 December 2025, it executed directly inside the IIS worker process (w3wp.exe). Rather than executing disk-backed staging files or dropping .aspx shells into SharePoint physical directories (such as C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS), the payload compiled and linked dynamically into the active ASP.NET runtime domain.

The core execution framework consisted of a modular C# payload composed of several distinct compilation units. The central orchestrator module, identified in threat research as G.cs, managed runtime lifecycle persistence, session handling, and C2 routing.

+---------------------------------------------------------------------------------+
|                                IIS Worker Process (w3wp.exe)                    |
|                                                                                 |
|  +-------------------+      Reflection Injection     +-----------------------+  |
|  | ASP.NET Runtime   | ----------------------------> |  BuildManager Class   |  |
|  | AppDomain Context |                               |  (State Fields Reset) |  |
|  +-------------------+                               +-----------------------+  |
|            |                                                     |              |
|            | Subversion of Virtual Path Processing               |              |
|            v                                                     v              |
|  +---------------------------------------------------------------------------+  |
|  | Custom VirtualPathProvider (Registered via RegisterVirtualPassProviderInternal)|
|  +---------------------------------------------------------------------------+  |
|            |                                                                    |
|            v                                                                    |
|  +---------------------------------------------------------------------------+  |
|  | Interception Point: GetCacheKey() Method Hook                              |
|  | - Inspects incoming HTTP headers for specific User-Agent                  |
|  | - Matched: Extracts binary C2 payload & executes in-memory                 |
|  | - Unmatched: Delegates execution back to original VirtualPathProvider       |
|  +---------------------------------------------------------------------------+  |
+---------------------------------------------------------------------------------+

To establish persistence inside the running application domain without file system modifications, G.cs executed the following runtime manipulations:

1. Custom Provider Registration: It registered a custom VirtualPathProvider by invoking the internal, non-public method RegisterVirtualPassProviderInternal located within the System.Web.Hosting.HostingEnvironment class. This injected the custom provider directly into the ASP.NET path resolution chain.
2. Lifetime Policy Delegation: To prevent runtime crashes and ensure stability, G.cs delegated the custom provider’s .NET Remoting lifetime policy to the previously registered provider in the chain, maintaining standard garbage collection parameters.
3. Trust Control Subversion (T1553): Precompiled ASP.NET applications prohibit dynamic registration of virtual path providers at runtime. To bypass this restriction, G.cs used reflection to inspect internal private fields within the System.Web.Compilation.BuildManager class. It cleared state flags indicating precompilation, allowing reflection to force dynamic provider injection into precompiled SharePoint application domains.

For request execution, G.cs used the GetCacheKey() method as its execution hook. On every incoming HTTP request to the SharePoint site, the modified ASP.NET pipeline routed path resolution through GetCacheKey(). The code inspected incoming request headers, looking for a specific, hardcoded User-Agent string. If the header matched, the webshell intercepted the request, parsed the payload, and returned execution output. If the header was absent or incorrect, control passed to the legitimate VirtualPathProvider, leaving normal SharePoint traffic unaffected.

C2 communications and the suo5 tunneling protocol

The command-and-control mechanism built into G.cs avoided standard HTTP GET/POST beacons or external executable agents. Instead, it used a custom binary protocol with XOR-based obfuscation layer to encode bidirectional telemetry directly within legitimate HTTP request and response structures.

To handle network traffic proxying, the actor integrated the open-source suo5 forward-proxying tool into G.cs. The suo5 framework establishes full-duplex TCP tunnels through web servers located in restricted networks where direct outbound internet access is blocked by firewall policy.

/* Conceptual representation of the ThreadPool adjustment in G.cs */
using System;
using System.Threading;

public class ThreadPoolModifier 
{
    public static void OptimiseExecutionLimits() 
    {
        int minWorkerThreads, minCompletionPortThreads;
        ThreadPool.GetMinThreads(out minWorkerThreads, out minCompletionPortThreads);
        
        // Increase worker and completion port threads to prevent proxy bottlenecks
        ThreadPool.SetMinThreads(250, minCompletionPortThreads);
        ThreadPool.SetMaxThreads(1000, 1000);
    }
}

The suo5 implementation inside G.cs operates by pairing concurrent HTTP connections into unified full-duplex channels:

• Target-to-Attacker Channel: An HTTP response stream remains open, constantly streaming internal TCP data back to the C2 server.
• Attacker-to-Target Channel: Incoming HTTP POST requests deliver chunked binary data streams from the C2 server into the local socket context.
• Socket Pairing: Active internal socket connections are indexed in-memory within static dictionary objects, mapping unique session identifiers to local network sockets.

High-volume TCP proxying through an IIS worker process can exhaust the default .NET ThreadPool, leading to thread starvation, HTTP 503 errors, and process crashes. To maintain high throughput during network scanning and lateral movement, G.cs modified default System.Threading.ThreadPool settings. Via reflection and runtime API calls, it increased the minimum and maximum worker thread allocations and extended execution timeouts for pending I/O operations.

Privilege escalation via EfsPotato and SAMRPCNative

The initial execution context obtained by w3wp.exe runs under the service account assigned to the SharePoint IIS Application Pool (typically IIS APPPOOL\SecurityValidation or a dedicated domain service account). While these accounts possess restricted user privileges, default IIS installations assign them SeImpersonatePrivilege rights.

Storm-2603 used a modular execution chain to process commands. The primary command-line parser, Prog.cs, parsed input arguments and passed context to uk/London.cs. If the suo5 parameter was supplied, London.cs triggered G.cs to initialize the memory-resident webshell. When local privilege escalation was required, London.cs initiated an EfsPotato attack flow.

# Conceptual Privilege Escalation Flow via uk/London
1. London.cs creates a local named pipe (e.g. \\.\pipe\uk_london_pipe)
2. EfsrTiny initializes an RPC binding to LSASS.exe over EFSRPC
3. EfsRpcEncryptFileSrv is invoked with path: \\localhost\pipe\uk_london_pipe\file.tmp
4. LSASS.exe (running as SYSTEM) connects to the malicious named pipe
5. London.Exp executes ImpersonateNamedPipeClient() to steal SYSTEM token
6. CreateProcessAsUser() spawns post-exploitation binary as NT AUTHORITY\SYSTEM

The local token impersonation technique relied on the Encrypting File System Remote Protocol (EFSRPC) interface via an embedded module designated as EfsrTiny (a minimal implementation of the public EfsPotato exploit tool):

1. The uk/London class creates a local, malicious named pipe server.
2. The EfsrTiny class initiates an RPC connection to the local LSASS.exe RPC server.
3. The London.RpcThread function executes the EfsRpcEncryptFileSrv RPC function targeting a path set to \\localhost (pointing directly to the attacker’s created named pipe).
4. This forces LSASS.exe—which executes under the NT AUTHORITY\SYSTEM context—to attempt an RPC connection to the local named pipe.
5. The London.Exp function calls ImpersonateNamedPipeClient to capture the incoming security context of LSASS.exe, acquiring a primary SYSTEM token.
6. The module calls CreateProcessAsUser to execute subsequent commands with elevated system privileges.

To implement this privilege escalation cleanly without relying on external system binaries, the uk namespace constructed a custom, low-level Microsoft Remote Procedure Call (MSRPC) client layer. By explicitly defining structural definitions including RPC_CLIENT_INTERFACE and MIDL_STUB_DESC in C#, the payload spoofed RPC stubs and communicated directly with the Windows RPC runtime (Rpcrt4.dll). This approach bypassed standard MIDL compiler requirements and evaded security software monitoring higher-level RPC wrappers.

For administrative persistence, the actor avoided using standard system shell utilities (such as net.exe user add or net localgroup administrators), which generate process creation event logs (Event ID 4688 / Sysmon Event ID 1). Instead, Storm-2603 included a custom assembly namespace named SAMRPCNative.

SAMEnums.cs

Enumeration Definitions

Defines constant bitwise flags mapping SAM access rights, user account control flags, and system return codes.

SAMStructs.cs

Structure Alignment

Defines unmanaged memory structures for P/Invoke marshalling, aligning native SAM data models.

SAMMethods.cs

Native API Import

Contains P/Invoke declarations importing native functions from samlib.dll (e.g., SamConnect, SamCreateUserInDomain).

Assembly File	Namespace Role	Technical Execution Mechanism

Using SAMRPCNative, the User.cs module connected directly to the local Security Account Manager (SAM) database via native RPC calls to samlib.dll, creating administrative accounts directly within the registry registry keys without invoking cmd.exe or PowerShell execution contexts.

Post-exploitation tooling and EDR-evading drivers

Following successful privilege escalation to SYSTEM, the compromised w3wp.exe process initiated an execution chain to deploy secondary persistence and network access mechanisms. The worker process executed msiexec.exe to download and install a remote Windows Installer package hosted in Supabase cloud storage.

The downloaded MSI package installed Velociraptor version 0.73.4.0—an open-source digital forensics and incident response agent. This specific version was vulnerable to CVE-2025-6264. Storm-2603 repurposed the tool as an operational command-execution and persistence engine across the internal network. The specific lateral movement steps taken across the target’s internal network post-privilege escalation and prior to security product intervention remain undisclosed in public technical sources.

To prevent loss of access if the primary IIS worker process recycled or the SharePoint application pool was restarted, Storm-2603 established multiple redundant tunneling pathways:

• Zoho Assist: Installed in Unattended Support mode to provide direct graphical remote access.
• VS Code CLI Tunneling: Executed to expose an encrypted development tunnel out of the host network.
• Cloudflare Tunnel: Deployed as a persistent lightweight outbound daemon for HTTP/TCP proxying.
• Custom Reverse Proxy: Lightweight standalone TCP redirection tools executed to forward network ports back to external C2 IP addresses.

Once system-level access was established, the adversary attempted to disable local Endpoint Detection and Response (EDR) software. Storm-2603 used a Bring Your Own Vulnerable Driver (BYOVD) attack methodology, dropping a vulnerable signed kernel driver file to disk at C:\programdata\rsndispot.sys (SHA-256: 054a32d6033b1744dca7f49b2e466ea2).

The driver was paired with a malicious dynamic link library (SHA-256: 2d9ebf9c042f596f435865b40edad928) loaded via DLL sideloading. This DLL served as an AV-killer component, sending IOCTL request codes to the rsndispot.sys driver to leverage its kernel-level privileges. The driver issued kernel memory writes to terminate registered EDR driver callbacks, unhook process monitoring filters, and forcibly kill protective user-mode security services.

Following defensive software termination attempts, Storm-2603 dropped a secondary malware payload identified as Warlock ransomware. However, as documented by Kaspersky Securelist, the Proactive Defense Module in Kaspersky Endpoint Security detected and blocked the execution of the Warlock ransomware DLL, halting the attack chain before file encryption commenced.

Hunting for deserialization and CLR assembly artifacts

Detecting fileless ASP.NET deserialization attacks requires looking beyond static file-on-disk analysis. Security teams must monitor Common Language Runtime (CLR) assembly instantiation, HTTP request header patterns, and native API execution.

During the initial ToolPane deserialization phase, specific dynamic compilation artifacts manifest within the SharePoint web application’s AppDomain. Defenders inspecting process memory or Event Tracing for Windows (ETW) logs will observe the simultaneous presence of two dynamic assemblies:

• App_Web_toolpane.aspx.[hash].dll: Generated by IIS during dynamic compilation of the requested SharePoint ToolPane page.
• Microsoft.GeneratedCode: Dynamically created by the .NET XmlSerializer or CLR object formatters during serialization processing.

Under the hood, formatters like BinaryFormatter deserialize data encoded using the NetDataContractSerializer or .NET Remoting Binary Format (NRBF). NRBF streams define object graphs using structured record types (such as ClassWithMembersAndTypes or SystemClassWithMembers). When an attacker crafts an NRBF payload, the stream explicitly specifies the target assembly, class identity, and property setter parameters that the CLR must instantiate.

# PowerShell Diagnostic Script (Test in Staging)
# Checks running w3wp processes for anomalous VirtualPathProvider registration or suspicious dynamic assemblies

Get-CimInstance Win32_Process -Filter "name = 'w3wp.exe'" | ForEach-Object {
    $procId = $_.ProcessId
    Write-Host "Analyzing w3wp.exe PID: $procId" -ForegroundColor Cyan
    
    # Query loaded modules for anomalous non-standard assemblies
    Get-Process -Id $procId | Select-Object -ExpandProperty Modules | 
        Where-Object { $_.ModuleName -like "*Microsoft.GeneratedCode*" -or $_.ModuleName -like "*App_Web_toolpane*" } |
        Select-Object ModuleName, FileName, BaseAddress
}

To detect these deserialization workflows and post-exploitation mechanisms, security operations teams should correlate host and network telemetry against known anomalous indicators.

Assembly Instantiation

Assemblies loaded from GAC or precompiled bin directories.

Dynamic loading of Microsoft.GeneratedCode immediately following HTTP calls to ToolPane endpoints.

Worker Process Execution

w3wp.exe handles web traffic; child processes limited to legitimate search indexers.

w3wp.exe spawning msiexec.exe, cmd.exe, or net.exe to fetch cloud-hosted payloads.

ASP.NET Pipeline Modifications

Static array of registered VirtualPathProvider instances.

Reflection modifications to HostingEnvironment and clearing of BuildManager precompilation flags.

User Account Creation

Accounts managed via Active Directory Administrative Tools or Central Admin.

Direct calls to samlib.dll APIs (e.g., SamCreateUserInDomain) bypassing standard command line events.

Kernel Driver Activity

Approved hardware and security drivers loaded from C:\Windows\System32\drivers.

Unsigned or known vulnerable drivers dropped to staging locations (e.g., C:\programdata\rsndispot.sys).

Telemetry Category	Legitimate SharePoint Baseline	ToolShell Attack / Storm-2603 Indicator

Key takeaways for platform and security engineers

The Storm-2603 ToolShell campaign highlights the limitations of relying purely on perimeter controls and disk-based antimalware solutions when defending complex enterprise platforms like Microsoft SharePoint. When an adversary weaponises an unpatched deserialization vulnerability, network perimeters process the malicious payload as valid application-layer HTTP traffic.

Platform engineers must treat unsafe deserialization as an architectural risk rather than a simple patch management item. While Web Application Firewalls (WAFs) can filter known public exploit signatures, minor mutations in NRBF stream encoding or HTTP header structures easily bypass pattern-matching rules. Complete remediation requires applying vendor security updates that remove or replace vulnerable deserialization formatters directly within the SharePoint core codebase.

Endpoint protection strategies must prioritize behavioral ETW telemetry over file-hash detection. Once an attacker obtains fileless code execution inside w3wp.exe, disk scanners remain blind until secondary stage tools or BYOVD drivers are staged. Security teams should implement the following defensive actions across all on-premises SharePoint environments:

• Restrict Worker Process Privileges: Verify that IIS Application Pool accounts are configured with the minimum required user rights. Ensure service accounts do not hold domain administrative rights. Where technically feasible, evaluate removing SeImpersonatePrivilege from dedicated web service accounts.
• Egress Traffic Filtering: Restrict outbound network connections originating from IIS worker processes. A SharePoint web front-end rarely requires arbitrary outbound TCP access to external cloud providers (such as Supabase) or direct outbound connection capabilities on non-standard ports. Blocking unexpected outbound web traffic prevents tools like suo5, Cloudflare Tunnels, and VS Code CLI from establishing functional C2 channels.
• Kernel Driver Block Rules: Enable Microsoft Vulnerable Driver Blocklist policies or Hypervisor-Protected Code Integrity (HVCI) to prevent attackers from loading known vulnerable drivers like rsndispot.sys to kill security agents.
• Audit RPC Named Pipe Usage: Monitor local named pipe creation events targeting LSASS.exe over EFSRPC interfaces. Detect anomalous calls to samlib.dll functions originating from non-system processes.

Common implementation mistakes

A common error made by incident response teams when dealing with memory-resident web shells is relying solely on application pool recycling (e.g., executing iisreset) to clear compromised environments. While restarting IIS clears memory-resident implants like G.cs from w3wp.exe, it does not remediate secondary persistence mechanisms established by the adversary—such as installed Velociraptor agents, Zoho Assist unattended access services, or newly created local administrative accounts.

Another operational oversight is assuming that precompiled ASP.NET web applications are immune to dynamic web shell injection. As demonstrated by Storm-2603’s subversion of the BuildManager class, reflection allows attackers with code execution context to alter private runtime flags, enabling dynamic VirtualPathProvider injection regardless of precompilation states.

Frequently asked questions

What are CVE-2025-53770 and CVE-2025-53771?

They are critical remote code execution vulnerabilities in on-premises Microsoft SharePoint servers targeting administrative handlers associated with the ToolPane component. Exploitation occurs when untrusted, maliciously crafted serialized payloads are processed by ASP.NET formatters, allowing unauthenticated attackers to execute arbitrary C# code within the IIS worker process.

How does the Storm-2603 webshell achieve persistence without writing files to disk?

The webshell (G.cs) injects directly into the runtime memory of w3wp.exe. It uses reflection to register a custom VirtualPathProvider via internal ASP.NET methods and clears precompilation checks in the BuildManager class. Incoming requests are intercepted in-memory via the GetCacheKey() method whenever a specific User-Agent header is detected.

What role does the suo5 tool play in this attack chain?

The suo5 utility is an open-source forward-proxying framework integrated into the memory-resident webshell. It pairs concurrent HTTP GET and POST channels to create a full-duplex TCP tunnel. This allows the threat actor to proxy arbitrary internal network traffic through the compromised SharePoint server, even in restricted environments where outbound direct connections are blocked.

How does the EfsPotato exploit achieve local privilege escalation from IIS?

The exploit creates a local named pipe server and uses the EFSRPC interface (via EfsrTiny) to call EfsRpcEncryptFileSrv targeting a \\localhost pipe path. This coerces LSASS.exe (running as SYSTEM) to connect to the pipe. The exploit then calls ImpersonateNamedPipeClient to steal the SYSTEM token and spawn elevated processes using CreateProcessAsUser.

What indicators should defenders look for to detect ToolPane deserialization exploitation?

Defenders should monitor ETW logs for the simultaneous loading of App_Web_toolpane.aspx and Microsoft.GeneratedCode assemblies within the same w3wp.exe application domain. Additionally, look for w3wp.exe spawning installer utilities like msiexec.exe, direct P/Invoke calls to samlib.dll for user creation, and driver load events involving rsndispot.sys.

Sources and further reading

• How to detect fileless attacks exploiting ToolShell: analyzing the Storm-2603 incident (Kaspersky Securelist)

This article was drafted with AI assistance from the publicly cited sources and passed automated checks for structure and sourcing. Verify critical details against the vendor advisories linked above before acting.