Topic starter
02/08/2026 12:31 pm
TL;DR: ToolShell is a SharePoint post-exploitation chain that abuses CVE-2025-53770 to gain unauthenticated RCE, harvest cryptographic keys, forge signed ViewState payloads, and sustain access, according to Anomali. The pattern shows how a single web entry point can turn into persistent control when machine keys and logging are not governed as identity assets.
Editorial analysis by NHI Mgmt Group, based on content published by Anomali: “Detecting the ToolShell SharePoint Exploit”.
Key questions
Q: What breaks when SharePoint machine keys are exposed in a server compromise?
A: When machine keys are exposed, patching the vulnerable code no longer guarantees recovery because the attacker may still be able to forge trusted authentication tokens.
Q: Why does machineKey theft make SharePoint compromise harder to contain?
A: Because the machine keys are the signing material that lets an attacker forge trusted ViewState payloads.
Q: What signs show a SharePoint exploit has moved from entry to post-exploitation?
A: The strongest signs are a suspicious ASPX drop such as spinstall0.aspx, followed by w3wp.exe spawning cmd.exe or powershell.exe, and then outbound connections that do not match normal SharePoint behaviour.
Practitioner guidance
- Harden SharePoint request paths Monitor POST requests to ToolPane.aspx with DisplayMode=Edit and forged Referrer headers to SignOut.aspx, because that combination is the exploit trigger the article highlights.
- Rotate machine keys after exposure Treat ValidationKey and DecryptionKey values as credentials and rotate them after compromise or suspicious access to prevent replay of signed ViewState payloads.
- Hunt for dropped reconnaissance payloads Look for spinstall0.aspx and other unexpected ASPX files in LAYOUTS, inetpub, wwwroot, and Microsoft Shared paths, because the payload is a key extraction step rather than a normal web asset.
Bottom line: ToolShell is a SharePoint exploitation chain that turns request handling flaws into trusted payload replay, which is why it belongs in identity hardening discussions as much as patching discussions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:29 pm
SharePoint machine keys are identity material, not configuration detail: ToolShell works because the platform's trust decisions depend on ValidationKey and DecryptionKey values that can be harvested and replayed. Once those values are exposed, the application no longer knows whether a signed payload was issued legitimately or forged by an attacker. The implication is that key governance for server-side identity material belongs in the same control plane as access governance.
A question worth separating out:
Q: How should teams respond when SharePoint is used as an identity boundary?
A: Teams should treat the server's cryptographic keys, request handling, and telemetry as governed identity controls, not only application maintenance items. That means validating suspicious ToolPane.aspx activity, rotating compromised machine keys, and correlating logs across web, process, and network layers before the attacker can extend control.
👉 Read our full editorial: ToolShell exploitation shows why SharePoint identity hardening matters