CVE-2025-53770 SharePoint Zero-Day Vulnerability and “ToolShell” Campaign

A widespread attack campaign, dubbed “ToolShell,” is actively exploiting a critical zero-day vulnerability in on-premises Microsoft SharePoint Server installations. The vulnerability, tracked as CVE-2025-53770, enables unauthenticated remote code execution (RCE), and allows an attacker to gain complete control of a vulnerable server over the network without requiring any form of authentication or user interaction.

Patching alone will not remove the attacker’s access, therefore it is imperative that after applying the emergency security updates, administrators perform a mandatory rotation of the SharePoint MachineKey across all servers in the farm.

CVE-2025-53770: is a critical unauthenticated Remote Code Execution (RCE) vulnerability affecting on-premises versions of Microsoft SharePoint Server. The flaw allows a network-based attacker to send a specially crafted serialised object to a SharePoint server, which, when processed, leads to arbitrary code execution in the context of the SharePoint application pool.  

Relationship to Previous Flaws

This vulnerability is a bypass or a more robust variant of CVE-2025-49704, a code injection flaw that was addressed in the July 2025 patch.

CVE-2025-53771:  is a vulnerability described as an Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’). This flaw allows an
authorised attacker to perform a spoofing attack over the network and does require the threat actor to be authenticated with low-level privileges.  

Relationship to Previous Flaws: This is a variant of CVE-2025-49706, an authentication bypass/spoofing vulnerability also addressed in the July 2025 update.  

The “ToolShell” campaign is not the result of a single flaw but rather the culmination of an evolving exploit chain involving four distinct vulnerabilities. The in-the-wild exploitation of CVE-2025-53770 follows a precise and devastatingly effective four-phase process.

Phase 1: Unauthenticated Initial Access

The attack commences with a specially crafted HTTP POST request “/layouts/15/ToolPane.aspx” directed at the targeted SharePoint server. Attackers set the value of the HTTP Referer header to /_layouts/SignOut.aspx in order to bypass authentication . This specific referer appears to trick the SharePoint application logic into an insecure state causing it to process the subsequent malicious payload within the ToolPane context without first validating the user’s session or credentials.

Phase 2: Payload Delivery and Execution  

The deserialisation vulnerability (CVE-2025-53770) is triggered, allowing the attacker’s payload contained in the POST requests to be executed. The execution often involves PowerShell commands to write a malicious ASPX file to the server’s filesystem.

The consistently observed payload in this campaign is a file named spinstall0.aspx. This file is typically dropped into a legitimate SharePoint directory, such as C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\ (or its PROGRA~1 short path equivalent), making it appear as a plausible system file to a cursory inspection.

Phase 3: Post-Exploitation – The MachineKey Heist

The payload lacks the typical features of a webshell, such as interactive command execution or command-and-control (C2) callback logic.  The sole function is to invoke internal.NET methods to read the SharePoint server’s MachineKey configuration and exfiltrate it. This is typically achieved via a simple GET request to the dropped spinstall0.aspx file.

The exfiltrated data contains the cryptographic ValidationKey and DecryptionKey. These keys are the foundation of ASP.NET’s __VIEWSTATE mechanism, which SharePoint uses to maintain page and control state across stateless HTTP requests. The MachineKey ensures the integrity and confidentiality of this state data.

Phase 4: Achieving Persistent, Authenticated RCE  

The theft of the MachineKey is the goal of the initial intrusion, as it provides the attacker with a powerful and persistent method of control. Threat actors act as a cryptographically trusted entity and can generate malicious __VIEWSTATE payloads signed with the server’s legitimate ValidationKey but containing arbitrary commands. The server decrypts the payload with its DecryptionKey and executes the embedded commands.

Vulnerable and mitigations versions:  

• Microsoft SharePoint Server Subscription Edition update
• Microsoft SharePoint Server 2019 update and Microsoft SharePoint Server 2019 Language Pack update
• Microsoft SharePoint Server 2016 update and Microsoft SharePoint Enterprise Server 2016 Language Pack update
• Microsoft SharePoint Online (part of Microsoft 365) is not affected by these vulnerabilities.

Recommendations:  

• Attack Signature: Monitor for inbound HTTP POST requests to the URI path /_layouts/15/ToolPane.aspx and that also contain the HTTP Referer header with a value of /_layouts/SignOut.aspx

• Assume Compromise: All internet-facing on-premises SharePoint servers must be treated as potentially compromised until proven otherwise through forensic analysis

• Network Isolation: If AMSI cannot be enabled or verified immediately, the affected SharePoint servers should be disconnected from the internet

• Enable AMSI: Ensure the Antimalware Scan Interface (AMSI) integration is enabled for SharePoint and that a capable antivirus solution is deployed and active.

• Apply Security Updates: Install the emergency out-of-band security updates released by Microsoft on July 21, 2025. Supported versions: SharePoint Server 2016, 2019, & SharePoint Subscription Edition

• Rotate Machine Keys: This is the most vital step in the remediation process and must be performed after the security updates have been applied. Rotating the ASP.NET MachineKey invalidates any keys that were previously stolen by attackers, effectively locking them out of their persistent access mechanism.

• Procedure: Administrators can trigger the key rotation by navigating to Central Administration > Monitoring > Review job definitions, finding the Machine Key Rotation Job, and selecting Run Now. Alternatively, this can be scripted via PowerShell.

• To update the machine keys for a web application using PowerShell:

Generate the machine key in PowerShell using Set-SPMachineKey -WebApplication <SPWebApplicationPipeBind>.

Deploy the machine key to the farm in PowerShell using Update-SPMachineKey -WebApplication <SPWebApplicationPipeBind>.

• Restart IIS: After the MachineKey rotation job has successfully completed on all servers in the farm, a full restart of Internet Information Services (IIS) is required. This can be accomplished by running iisreset.exe from an administrative command prompt on each SharePoint server. This step ensures that all SharePoint services unload the old keys from memory and load the newly generated ones.