SharePoint "ToolShell" - Unauthenticated Deserialization at ToolPane.aspx → Web Shell → MachineKey Theft → Forged __VIEWSTATE Forever → Warlock Ransomware
Around July 18, 2025, CVE-2025-53770 and CVE-2025-53771 came under active exploitation against on-premises Microsoft SharePoint Servers. A crafted HTTP POST to ToolPane.aspx triggered unauthenticated deserialization and remote code execution; attackers dropped a web shell, typically spinstall0.aspx, in the layouts folder. Then came the step that made this different from an ordinary RCE: they stole the server's ASP.NET MachineKeys - the ValidationKey and DecryptionKey - and used them to forge __VIEWSTATE payloads that SharePoint accepts as legitimate. Patching does not undo that. An attacker holding your machine keys can return through requests indistinguishable from normal traffic, and stays until the keys are rotated. Microsoft attributed some activity to Storm-2603, assessed with moderate confidence as China-based, which went on to deploy Warlock ransomware. SharePoint Online in Microsoft 365 was not affected.
ToolPane.aspx, an ordinary endpoint for managing web part settings, triggered deserialization of untrusted input and unauthenticated remote code executionUnsafe deserialization is a decades-old bug class and still one of the most reliable paths to code execution in enterprise .NET applications, because deserializing attacker-controlled data means instantiating attacker-chosen types and running their constructors. Here the reachable endpoint was ToolPane.aspx, a routine part of SharePoint's web part configuration machinery that most administrators would never think of as security-relevant. No authentication was required, so the prerequisite was simply network reachability - and on-premises SharePoint is very often published to the internet precisely so that remote staff and partners can use it.
Endpoint:
ToolPane.aspx, normally used to manage web part settingsBug class: Deserialization of untrusted data
Prerequisite: Network reachability. No credential, no user interaction
Scope: On-premises SharePoint Server only; SharePoint Online was not affected
spinstall0.aspx in SharePoint's layouts directory, giving persistent command execution and a stage for further payloadsThe layouts folder is a natural hiding place because it legitimately contains many .aspx files, so one more does not stand out to a human browsing the directory. The observed shells fetched and ran further malware from attacker infrastructure, converting a single exploited request into an interactive foothold on the server. This is the artifact most defenders went looking for once the advisories landed, and finding and deleting it feels like resolution - which is exactly the trap the next step sets, because by the time the shell is found the attacker has usually already taken something that removing it will not affect.
spinstall0.aspxLocation: SharePoint's layouts folder, which legitimately holds many
.aspx filesCapability: Persistent command execution and staging of further malware
The trap: Deleting it feels like remediation, and is not
This is the move that elevates ToolShell above a typical web application compromise. ASP.NET uses the machine keys to sign and encrypt __VIEWSTATE, the mechanism by which the framework trusts state that round-trips through the client. Whoever holds those keys can produce state the application will accept as its own. They are the server's identity to itself, and unlike a password nobody thinks of them as a credential with a rotation policy - most administrators have never touched them and many do not know they exist. Read this alongside Storm-0558 and the shared lesson is stark: theft of signing material converts a bounded intrusion into indefinite trusted access, and it is the failure that is hardest to recover from because everything downstream is designed to believe it.
ValidationKey and DecryptionKeyPurpose: Signing and encrypting
__VIEWSTATE, the framework's trusted client-side stateEffect of theft: The ability to produce state the application accepts as its own
Why they are forgotten: Rarely rotated, rarely inventoried, rarely thought of as credentials
Parallel: Storm-0558 - stolen signing material is the hardest compromise to recover from
__VIEWSTATE payloads that SharePoint accepted as legitimate, providing authenticated command execution that survives patchingA forged __VIEWSTATE signed with the real keys is not an anomaly to the application - it is a correctly signed request, and SharePoint validates it exactly as it validates its own. This is the single most important operational fact about ToolShell and the one most likely to be missed during response. Applying the patch closes the door the attacker came through and does nothing about the key they copied on the way in. Removing the web shell deletes the artifact and leaves the capability. Multiple analyses described the result as a permanent backdoor, and the phrasing is fair: until the machine keys are rotated, the attacker can return through traffic that is cryptographically indistinguishable from legitimate use, and no amount of log review will separate the two.
__VIEWSTATE payloads signed with the stolen keysApplication's view: A correctly signed, entirely legitimate request
Patching: Closes the entry path, does nothing about the copied key
Web shell removal: Deletes the artifact, leaves the capability
Required for recovery: Rotating the machine keys, then restarting IIS
On-premises SharePoint is rarely isolated. It is domain-joined, it runs under service accounts that frequently hold more Active Directory privilege than anyone intended, and it stores the corpus an intruder most wants next: network documentation, credentials pasted into pages, contracts, HR files, and project material. Reporting placed compromises at roughly 75 to 85 or more servers globally, which is a small number for a mass-exploitation event and reflects both the on-premises footprint and the targeting. The organizations that were hit tend to be the ones that kept SharePoint on-premises for regulatory or data-residency reasons, which correlates with holding exactly the material worth stealing.
Content: Network documentation, pasted credentials, contracts, HR and project files
Scale: Roughly 75-85+ servers globally assessed as compromised
Selection bias: On-prem SharePoint often means regulated data kept deliberately in house
Multiple actors moved on these CVEs, which is the normal pattern once a reliable unauthenticated exploit for widely deployed software becomes known. Microsoft tracks part of the activity as Storm-2603, assessed with moderate confidence to be China-based - note the confidence language, which is doing real work and should be preserved rather than flattened into a claim. That cluster went on to deploy Warlock ransomware. The combination is worth sitting with: an unauthenticated internet-facing RCE, a persistence mechanism that survives patching, and a ransomware payload at the end. An organization that patched promptly, removed the web shell, and did not rotate its machine keys could be encrypted weeks later and have no idea how the actor got back in.
Payload: Warlock ransomware
Multiple actors: Typical once a reliable unauthenticated exploit is public
The dangerous sequence: Patch, delete the shell, skip key rotation, get encrypted weeks later
🛡 How to Defend Against This Chain
__VIEWSTATE traffic is cryptographically valid and you will not find it in logs..aspx files including spinstall0.aspx, review IIS logs for POST requests to ToolPane.aspx, and look for unusual child processes spawned by the SharePoint worker process. Absence of a web shell is not absence of compromise - the keys may already be gone.