ToolShell exploitation shows why SharePoint identity hardening matters

At a glance

What this is: ToolShell is a SharePoint exploitation chain that turns unauthenticated access into key theft, forged payloads, and persistence.

Why it matters: It matters because SharePoint servers often sit inside identity-trusted zones, so a web exploit can quickly become an identity and access control problem for both NHI and platform teams.

👉 Read Anomali's analysis of the ToolShell SharePoint exploit chain

Context

ToolShell is a post-exploitation chain against Microsoft SharePoint that starts with unauthenticated access and ends with forged signed payloads and persistence. In identity terms, the relevant assets are not only the server itself but also the machine keys, tokens, and trusted execution context that make SharePoint accept attacker-controlled activity.

The reporting is focused on detection and hunting, which makes the governance gap clear. When machine keys and service execution paths are treated as ordinary configuration rather than protected identity material, defenders lose the ability to distinguish legitimate SharePoint behaviour from attacker-created state.

This is a classic case of application trust being converted into access authority. The starting position is not unusual for internet-facing enterprise platforms, but the speed at which it becomes a credential and execution problem is what makes it dangerous.

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 do web application exploits become identity problems in SharePoint environments?

A: Because the real target is often the trust material that underpins server-side authority, not just the login surface. When an attacker can harvest cryptographic keys, they can impersonate the application’s own identity and use that authority to execute actions the platform would normally allow.

Q: How should security teams detect post-exploitation activity after a SharePoint zero-day?

A: Correlate HTTP request anomalies, file creation or access events, suspicious child processes from w3wp.exe, and outbound traffic from the affected server. A single signal is rarely enough. The strongest indicators appear when exploitation, payload deployment, and command execution happen in sequence on the same host.

Q: Who is accountable when SharePoint trust material is exposed and reused by attackers?

A: Accountability usually spans application owners, platform engineers, and identity teams because the exposed material functions like a privileged secret. The right governance question is who owns the lifecycle of machine keys, who rotates them after exposure, and who monitors their misuse as part of privileged access control.

Technical breakdown

How ToolShell turns unauthenticated web access into trusted execution

ToolShell begins with a crafted request to ToolPane.aspx that bypasses normal authentication checks through header manipulation and request shape. Once that entry point is reached, the attacker can drop a reconnaissance payload or move directly into key harvesting. The important technical detail is that SharePoint’s trust boundary is not just the login layer. It also includes server-side components that will accept requests if they are formatted to satisfy the application’s internal assumptions. That makes the exploit an identity problem, not just a vulnerability problem.

Practical implication: monitor the exact request paths and headers that can cross the SharePoint trust boundary, especially ToolPane.aspx and referrer spoofing.

Why machine keys turn a web exploit into signed payload abuse

After initial access, the attacker’s objective is to extract ValidationKey and DecryptionKey values from memory or configuration. Those keys let the attacker generate valid ViewState payloads that SharePoint will accept as authentic. This is the critical escalation step because the application no longer sees malicious input as foreign. It sees a signed object that appears to come from the platform itself. In governance terms, the keys function like high-value NHI secrets because they confer authority to impersonate trusted server-side state.

Practical implication: treat machine keys as privileged secrets, rotate them after exposure, and alert on any access pattern associated with key extraction.

What post-exploitation activity looks like after SharePoint compromise

Once ViewState forgery works, the attacker can run commands, deploy payloads, and establish outbound communication from the SharePoint host. The report highlights suspicious child processes such as cmd.exe and powershell.exe from w3wp.exe, plus network traffic to known command-and-control infrastructure. This is typical of a compromise that has moved beyond exploitation into active operational use. At that point, the incident is no longer about a single web request. It is about an abused trusted execution environment that has been converted into an attacker-controlled platform.

Practical implication: correlate web logs, process creation, and network telemetry to detect when SharePoint’s trusted worker process becomes an execution pivot.

Threat narrative

Attacker objective: The attacker wants persistent control of SharePoint by converting trusted server-side keys into authenticated-looking execution and follow-on access.

1. Entry occurs through a spoofed POST request to ToolPane.aspx with a forged Referrer header, allowing unauthenticated interaction with the vulnerable SharePoint endpoint.
2. Escalation follows when the attacker drops or invokes a reconnaissance payload, extracts ValidationKey and DecryptionKey, and uses them to forge signed ViewState content.
3. Impact comes from unauthenticated command execution, persistence modules, and outbound command-and-control from the compromised SharePoint server.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Microsoft SAS Key Breach — Overly permissive Azure SAS token exposes 38TB of Microsoft internal data including secrets and credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ToolShell is an identity trust failure before it is an application vulnerability. The exploit succeeds because SharePoint accepts server-generated authority as if it were still trustworthy after exposure. Once machine keys are harvested, the attacker inherits the application’s identity assumptions and can create signed objects that look legitimate. Practitioners should treat this as a collapse of trusted execution, not a narrow patch-management issue.

Machine keys are privileged secrets, not routine configuration. ValidationKey and DecryptionKey values grant the ability to mint content that the platform will trust. That means the governance model for these values belongs closer to NHI secret protection and privileged credential handling than to ordinary application settings. The implication is straightforward: if these keys are exposed, the application’s authentication boundary is already weakened.

Detection must follow the identity chain, not just the exploit string. A request to ToolPane.aspx matters, but the deeper signal is the sequence from web access to payload deployment, key extraction, forged ViewState, and child-process execution. Security teams that only hunt for the initial URL will miss the operational phase where the attacker turns trust into persistence. The better model is end-to-end identity abuse visibility.

SharePoint compromise creates a platform-level blast radius because the worker process already sits inside a trusted execution zone. When w3wp.exe begins spawning PowerShell or cmd.exe, the environment has crossed from web abuse into identity-mediated command execution. That matters for IAM and PAM teams because the compromise is now using the organisation’s own trust pathways. The practical conclusion is that server trust zones need identity-grade monitoring, not only vulnerability scanning.

What this signals

Machine-key governance should move into the same control conversation as privileged access. SharePoint exposes a common enterprise blind spot: many teams secure the front door but not the trust material that makes the door useful. The better programme view is to treat application signing keys as identity assets with ownership, rotation, and monitoring requirements.

The operational lesson extends beyond SharePoint. Any platform that converts cryptographic material into authenticated behaviour can be abused the same way if logs, secrets, and runtime telemetry are not joined up. That is why identity teams should align detection engineering with application trust boundaries, not just with account inventories.

For practitioners

• Hunt for ToolPane.aspx exploitation patterns Search IIS and proxy logs for POST requests to /layouts/15/ToolPane.aspx or /layouts/16/ToolPane.aspx, especially when DisplayMode=Edit and a forged Referrer header points to /layouts/SignOut.aspx.
• Protect SharePoint machine keys as privileged secrets Inventory every ValidationKey and DecryptionKey instance, rotate exposed keys after patching, and treat them as high-impact secrets because they allow forged ViewState payloads.
• Correlate worker-process child execution Alert when w3wp.exe spawns cmd.exe, powershell.exe, or unusual .NET reflection activity, then tie that activity back to the preceding web request and file events.
• Track suspicious .aspx artefacts in SharePoint paths Look for dropped files such as spinstall0.aspx under LAYOUTS, inetpub, wwwroot, and Microsoft Shared, and treat access to those files as a high-confidence indicator of post-exploitation activity.
• Build network detections for campaign infrastructure Flag outbound communication from SharePoint hosts to known ToolShell IPs and any other anomalous connections that begin after a suspicious ToolPane.aspx request.

Key takeaways

• ToolShell shows how a web exploit becomes an identity compromise once attackers can harvest the server’s trust material.
• The campaign’s scale is driven by the reuse of machine keys, forged signed payloads, and trusted worker-process execution.
• Teams should govern SharePoint keys like privileged secrets and detect the full sequence from web request to command execution.

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.
• Worker Process Abuse: Worker process abuse occurs when an application host process, such as w3wp.exe, is used to launch commands or payloads after exploitation. This is a strong sign that the attacker has moved from vulnerability exploitation into runtime control of a trusted service context.

What's in the full report

Anomali's full article covers the operational detail this post intentionally leaves for the source:

• The four Anomali Query Language hunting patterns for HTTP requests, file artefacts, process execution, and network indicators.
• The exact log field combinations used to distinguish exploitation attempts from routine SharePoint traffic.
• The mitigation notes on patching and post-patch key rotation for SharePoint machine keys.
• The IOC-driven detection logic for suspicious .aspx files and campaign IP addresses.

👉 Anomali's full post covers the AQL queries, indicator patterns, and mitigation notes.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.