ToolShell exploitation shows why SharePoint identity hardening matters

At a glance

What this is: This is Anomali's detection-focused breakdown of ToolShell, a SharePoint exploitation chain that uses CVE-2025-53770 to move from unauthenticated access to persistent control.

Why it matters: It matters because SharePoint machine keys, request handling, and process telemetry sit inside the identity perimeter defenders must govern, not outside it.

Context

ToolShell is a SharePoint post-exploitation chain, not a standalone tool. It starts with unauthenticated access through a vulnerable web endpoint and then pivots into cryptographic material that lets an attacker forge trusted payloads.

For identity teams, the important point is that SharePoint machine keys behave like credentials. Once those keys are harvested, the attacker can keep executing even after the original web flaw is addressed, which turns a patching issue into a governance issue.

The article's starting position is typical for an actively exploited enterprise application flaw: one exposed server-side trust boundary becomes a durable access path when key material and telemetry are not treated as governed security assets.

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. The platform can continue accepting malicious sessions until the compromised keys and any derived tokens are rotated or retired. That is why key exposure changes the incident from a software flaw to an identity trust failure.

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. If those keys are recovered, removing the original web shell does not end the incident, since the attacker can still generate payloads the server will accept as authentic.

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. Seen together, those signals suggest the exploit has progressed from access to execution and external control.

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.

Technical breakdown

How ToolShell turns a web request into trusted execution

ToolShell begins with a crafted request to the vulnerable ToolPane.aspx path in SharePoint Server 2016, 2019, and Subscription Edition. The exploit abuses request handling to bypass authentication, then drops a reconnaissance payload such as spinstall0.aspx. That payload is not a classic interactive web shell. Its job is narrower: extract ValidationKey and DecryptionKey values from memory or configuration so the attacker can later produce signed payloads that SharePoint will accept as legitimate.

Practical implication: treat SharePoint request paths and machine-key access as part of the authentication surface, not just application logging.

Why stolen machine keys create persistent ViewState abuse

After code execution, the observed pattern shifts to child processes from w3wp.exe, PowerShell activity, in-memory .NET reflection, and outbound connections to known command-and-control infrastructure. Those signals matter because they distinguish benign SharePoint traffic from post-exploitation behaviour. In practice, the strongest detections combine web, process, and network telemetry. A single log source is usually too thin to show the full chain from request abuse to persistence.

Practical implication: correlate IIS, EDR, and network logs around SharePoint rather than relying on web logs alone.

Threat narrative

Attacker objective: The attacker aims to convert one vulnerable SharePoint endpoint into durable remote code execution and persistent access.

1. Entry occurs through a spoofed HTTP POST to ToolPane.aspx with a forged Referrer header that bypasses SharePoint authentication checks.
2. Credential access follows when the attacker drops spinstall0.aspx and harvests ValidationKey and DecryptionKey values from memory or web.config.
3. Escalation happens when the stolen keys are used to forge signed ViewState payloads that trigger unauthenticated remote code execution.
4. Impact appears as persistent post-exploitation activity, including PowerShell execution, reflective loading, and outbound command-and-control traffic.

Breaches seen in the wild

• ToolShell SharePoint exploitation 2025: ToolShell attackers exploited on-premises SharePoint and stole ASP.NET machine keys, keeping code execution alive after patching.
• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Web exploitation becomes identity persistence when trust is replayable: The breach pattern shows that patching the vulnerable endpoint is not the same as removing the trust relationship that the endpoint enabled. A forged ViewState payload can continue to pass validation after the original entry path is closed if the keys remain valid. Practitioners should read this as a failure of trust invalidation, not just a failure of secure coding.

ToolShell exposes the identity blast radius of a single SharePoint server: One exposed server can yield key material, code execution, and C2 reach without needing separate credentials for every stage. That compresses the boundary between application risk and identity risk. The right governance question is not whether the web server is patched, but whether its cryptographic trust artifacts are inventoried, rotated, and monitored like credentials.

Detection needs to move from event hunting to trust-hierarchy monitoring: The attack chain only becomes visible when IIS activity, process spawning from w3wp.exe, and network egress are correlated. That is a governance problem as much as a detection problem, because isolated telemetry cannot show when a trusted application has stopped behaving as a trusted identity boundary. Teams should treat anomaly correlation as part of SharePoint hardening, not as after-the-fact forensics.

What this signals

Identity blast radius: ToolShell shows how a single SharePoint trust boundary can expand into durable access once cryptographic material is harvested. That makes machine-key governance a lifecycle issue, not just a patching issue, because the real control point is when trusted state can no longer be replayed.

Detection teams should expect the exploit chain to surface in layers rather than in one log source. Web request anomalies, child processes from w3wp.exe, and unexpected outbound traffic are separate symptoms of the same trust failure, so correlation is the control that matters.

SharePoint hardening should now include explicit ownership of server-side cryptographic material. When ValidationKey and DecryptionKey values are handled like credentials, the programme can finally align patching, telemetry, and rotation around the same identity boundary.

For practitioners

• 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.
• Correlate IIS, EDR, and network telemetry Investigate w3wp.exe spawning cmd.exe or powershell.exe, then match that behaviour to outbound traffic toward known ToolShell infrastructure or similar command-and-control patterns.

Key takeaways

• 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.
• The article shows a practical progression from crafted web requests to key harvesting, forged ViewState, and persistent execution, with w3wp.exe and outbound traffic providing the clearest post-exploitation signals.
• SharePoint machine keys must be governed like credentials if defenders want to break the trust replay path that makes this class of attack persistent.

Key terms

• Machine key: A machine key is cryptographic material used by an application to sign, validate, or protect trusted state. In practice, it behaves like privileged identity material because anyone who steals it may be able to forge content or session trust that downstream systems accept as legitimate.
• ViewState Forgery: ViewState forgery is the creation of tampered application state that still passes signature checks because the attacker has the signing material. It matters in identity security because the platform treats the forged payload as trusted server output, allowing unauthenticated or attacker-controlled actions.
• Post-Exploitation Payload: A post-exploitation payload is code used after initial access to expand control, extract data, or establish persistence. ToolShell uses a reconnaissance-style ASPX payload to harvest keys, which is a narrower and more durable objective than a conventional web shell.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.