On-Prem SharePoint Customers Targeted in ‘ToolShell’ Exploit — Advanced Analysis, Detailed Usage & Practice (English)

📌 Introduction — What is the ‘ToolShell’ Exploit?

In 2025, a critical zero-day exploit chain, dubbed “ToolShell,” emerged targeting on-premises Microsoft SharePoint Server installations. This exploit has been extensively used in the wild against thousands of organizations worldwide, affecting government agencies, enterprises, education, healthcare, and more. It combines multiple vulnerabilities to achieve unauthenticated remote code execution (RCE) and persistent system compromise on unpatched SharePoint servers.

👉 ToolShell is not a generic malware tool but an exploit chain leveraging design flaws in SharePoint’s core components, especially around unsafe deserialization and authentication bypass, allowing attackers to execute arbitrary code remotely without credentials. 

🎯 Exploit Anatomy — Technical Breakdown

🧠 Vulnerabilities in the ToolShell Exploit Chain

ToolShell primarily chains two critical vulnerabilities in on-prem SharePoint:

These vulnerabilities are variants of earlier CVEs (CVE-2025-49704 and CVE-2025-49706) that were patched, but ToolShell demonstrates how threat actors evolve exploits to bypass fixes. 

💥 How ToolShell Works — In Depth

1️⃣ Authentication Bypass (CVE-2025-53771)

• Attackers craft HTTP requests with forged headers — especially the Referer header — to bypass authentication logic.

• This effectively tricks SharePoint Server into processing malicious payloads as if they were from authenticated users.

• This step enables the next exploit phase without valid credentials. 

2️⃣ Unsafe Deserialization & RCE (CVE-2025-53770)

• The core flaw lies in insecure deserialization of untrusted data in SharePoint’s ViewState handling (e.g., /_layouts/15/ToolPane.aspx).

• Once abused, attackers can upload malicious ASPX payloads (like spinstall0.aspx) that execute arbitrary .NET code on the server.

• This leads to full system compromise without authentication. 

3️⃣ Machine Key Theft for Persistence

• Once the server is compromised, attackers steal SharePoint’s machine keys (e.g., ValidationKey, DecryptionKey).

• These keys allow attackers to craft trusted ViewState payloads for future access — even after initial patching. 

⚠️ Who Is Affected?

ToolShell affects only on-premises SharePoint Server deployments, including:

✔ SharePoint Server Subscription Edition
✔ SharePoint Server 2019
✔ SharePoint Server 2016

SharePoint Online (Microsoft 365) is not affected by these vulnerabilities. 

🛑 Real-World Impact & Active Exploitation

Threat actors are actively using ToolShell in the wild, with confirmed compromises of hundreds of organizations around the globe. Exploited servers often show signs of webshell deployment, exfiltration of machine keys, and, in some cases, subsequent malware payloads like ransomware. 

🚨 Example Indicators of Compromise (IOCs)

• Unexpected .aspx files such as:
  spinstall0.aspx, info3.aspx, etc.

• Suspicious traffic to tools like /_layouts/15/ToolPane.aspx

• Signs of machine key exfiltration

• Outbound connections to known malicious IPs
  These can be used in detection & hunting. 

🛡️ Defender’s Handbook — Best Practices & Mitigation

🔧 1. Apply Microsoft Patches Immediately

Install the latest out-of-band patches released in July 2025 for all on-prem SharePoint servers:

📌 Resolved CVE-2025-53770 & CVE-2025-53771 patches for:

• SharePoint Server Subscription Edition

• SharePoint Server 2019

• SharePoint Server 2016
  ⚠️ Unsupported legacy SharePoint versions (e.g., 2010, 2013) won’t receive fixes. 

🔑 2. Rotate ASP.NET Machine Keys

After patching:

# Generate new machineKey and update web.config
$NewValidationKey = (New-Object System.Web.Security.MembershipGeneratePassword(64,0))
$NewDecryptionKey = (New-Object System.Web.Security.MembershipGeneratePassword(32,0))

• Update SharePoint Server’s web.config with new ValidationKey & DecryptionKey

• Restart IIS
  This prevents reuse of stolen keys to craft malicious ViewState. 

🛡️ 3. Enable AMSI & Endpoint Protection

🔹 Ensure AMSI (Antimalware Scan Interface) is enabled in Full Mode.
🔹 Deploy updated Defender AV / EDR signatures.
🔹 Enforce alerts for suspicious loads or deserialization attempts.

📡 4. Network Protection

✔ Block public internet access to SharePoint servers unless absolutely required.
✔ Enforce pre-authentication (e.g., reverse proxies with MFA).
✔ Segment servers behind firewalls and monitor unusual traffic, especially on /ToolPane.aspx. 

📊 5. Detection & SIEM Rules

Use analytics to log and alert on:

// Example KQL rule
SharePointHttpLogs
| where RequestUri contains "/_layouts/15/ToolPane.aspx"
| where UserAgent !contains "Microsoft" 

• Alert on unusual .aspx file drops.

• Match indicators against known malicious IOCs. 

🧪 Post-Compromise Forensics & Remediation

If a server is suspected to be compromised:

✔ Isolate from network
✔ Perform full memory & disk forensic imaging
✔ Seek persisted webshells
✔ Regenerate all server keys (machine keys, certificates)
✔ Re-deploy from trusted backups if necessary
✔ Conduct malware scans across the environment

These steps prevent attackers from regaining access post-patch.

📌 Conclusion — Strategic Takeaways

The ToolShell exploit underscores a significant cybersecurity reality: legacy and self-managed systems, especially internet-exposed ones, remain high-value targets for sophisticated attackers. Organizations must adopt a defense-in-depth strategy combining timely patching, secure configurations, and active monitoring to safeguard critical infrastructure