ToolShell shows why on-prem SharePoint exposure still matters

At a glance

What this is: This is an analysis of the ToolShell SharePoint exploit chain and the persistent exposure of on-prem SharePoint servers, showing that patched flaws still left many environments reachable and exploitable.

Why it matters: IAM and security teams need to treat SharePoint as a high-risk trust boundary because exposed on-prem deployments can turn a single bypass into unauthenticated code execution and key theft.

By the numbers:

• 13% of cloud environments run vulnerable self hosted SharePoint components, according to Orca Security.
• 6% expose them directly to the internet, according to Orca Security.

Context

ToolShell is the name used for a SharePoint exploit chain that combines authentication bypass and code execution to turn exposed on-prem SharePoint servers into remote footholds. In identity terms, the problem is not just a software flaw but a service boundary that is trusted too broadly once the server is reachable.

SharePoint often sits close to Active Directory, Microsoft 365, and internal document workflows, which means compromise can spill into broader identity and collaboration trust relationships. When the platform is self-managed and internet-facing, patch delay and key reuse can turn a single server issue into a systemic access problem.

The article’s core warning is that on-prem SharePoint remained operationally important enough for attackers to keep targeting, even after Microsoft pushed fixes for the original vulnerabilities. That makes the exposure pattern typical, not exceptional, in organisations with legacy collaboration infrastructure.

Key questions

Q: What breaks when SharePoint servers stay exposed after ToolShell-style flaws are disclosed?

A: What breaks is the assumption that patching alone contains the risk. If an on-premise SharePoint server remains internet-facing, attackers can chain authentication bypass and deserialization flaws into persistent code execution before defenders finish normal remediation. Exposure management, not just patch status, determines how quickly exploitation can begin.

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: How should security teams reduce risk from internet-facing collaboration servers?

A: They should treat collaboration servers as privileged service assets, not generic application hosts. That means tracking exposure, patch status, and cryptographic trust material together, because each one changes how easily an attacker can turn a vulnerability into repeatable execution.

Q: How should security teams respond when an authenticated SharePoint vulnerability moves from patch availability to active exploitation?

A: Treat the issue as both a patching and investigation problem. Prioritise deployment of the fixed build across every SharePoint server, then review IIS logs, authentication events, and process creation telemetry for signs of misuse before remediation. Focus on suspicious Site Member activity, unexpected child processes, and web shells. Patching stops further exposure, but retrospective hunting determines whether compromise already occurred.

Technical breakdown

How the ToolShell chain bypassed SharePoint trust checks

ToolShell combined a spoofing flaw with insecure deserialization to bypass SharePoint’s normal request validation. The attacker first forged the Referer header to make SharePoint treat the request as authenticated, then delivered a malicious payload that executed server-side code. That sequence matters because the exploit did not depend on stolen user credentials at the front door; it abused the server’s own trust logic. Once the request path accepted the attacker as legitimate, the rest of the chain became a code execution problem rather than an access control problem.

Practical implication: Treat server-side request trust checks as attack surface, not just application logic, and review any endpoint that gates execution on headers or implicit session state.

Why machine keys turned one server compromise into persistent access

After initial execution, the web shell could extract ASP.NET machineKey values used to sign and validate ViewState payloads. Those keys let an attacker generate trusted payloads that SharePoint would accept as authentic, which turns one compromised instance into a mechanism for repeatable, stateless execution. This is the critical persistence layer in the chain: the attacker no longer needs the original exploit every time. The server’s own cryptographic trust material becomes the credential that keeps the compromise alive.

Practical implication: Rotate and isolate machineKey material per server and assume exposed signing keys are equivalent to credential compromise.

Why on-prem SharePoint exposure remains a cloud-era identity problem

The article shows that self-hosted SharePoint inside cloud environments still inherits classic internet exposure risks while remaining tightly linked to identity and content systems. That combination expands blast radius because the server is not an isolated workload; it is a trusted collaboration service with deep directory and platform dependencies. From an NHI perspective, the danger is standing trust at the service boundary, not just the bug itself. Patch status, public exposure, and key handling all have to be governed together.

Practical implication: Inventory on-prem SharePoint as a privileged service asset and govern exposure, patch state, and signing keys as one control plane.

Threat narrative

Attacker objective: The attacker wants durable, unauthenticated code execution on exposed SharePoint servers and the signing material needed to keep that access alive.

1. Entry occurred when the attacker sent a forged request to /_layouts/15/ToolPane.aspx?DisplayMode=Edit and made SharePoint treat it as authenticated by spoofing the Referer header.
2. Credential access followed when the web shell dumped ASP.NET machineKey values, giving the attacker signing material that could be reused across payloads.
3. Escalation and persistence came from forging signed __VIEWSTATE payloads that SharePoint trusted and executed as code, even after the initial shell was removed.
4. Impact was unauthenticated, persistent remote code execution on on-prem SharePoint servers, with the ability to maintain access and broaden follow-on compromise.

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.

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

ToolShell is not just a SharePoint bug chain, it is a trust-boundary failure. The attack works because the server accepted implicit trust signals that should never have been enough to authorize execution. Once that assumption failed, the rest of the compromise moved from authentication bypass into persistent server control. The practitioner implication is that collaboration platforms exposed to the internet must be governed as privileged identity surfaces, not ordinary application endpoints.

MachineKey persistence is the real control gap this incident exposes. The exploit becomes materially worse once attackers can recover ASP.NET machineKey values and use them to mint trusted payloads. That turns a single compromise into repeatable execution and invalidates any assumption that patching alone clears the risk. The governance lesson is that signing material on internet-facing workloads must be treated with the same urgency as any other credential estate.

Standing trust in tightly integrated collaboration systems creates identity blast radius. SharePoint is rarely isolated, so compromise can extend into directory-linked workflows, content services, and adjacent Microsoft 365 dependencies. That makes this a governance problem across exposure, credential material, and service ownership rather than a narrow vulnerability response. Practitioners should read it as a case for asset-level identity governance over legacy collaboration platforms.

ToolShell illustrates why patch compliance and attack surface management cannot be separated. A patched server that remains internet-facing, self-hosted, and tightly coupled to key material is still an attractive target. The article’s exposure data shows that the residual risk is not hypothetical, which means programme owners need to track public reachability and cryptographic trust state alongside remediation status. The implication is that exposed collaboration services require continuous governance, not periodic cleanup.

SharePoint exposure is a reminder that legacy platforms often sit outside modern NHI assumptions. NHI controls are usually discussed for APIs, service accounts, and cloud workloads, yet a collaboration server with machine keys, directory trust, and internet reachability behaves like a privileged identity system. That is why this class of incident belongs in identity governance discussions, not just vulnerability operations. Practitioners should fold exposed collaboration servers into the same governance model used for other high-trust non-human assets.

What this signals

Identity governance needs to include exposed collaboration platforms. SharePoint is often managed as an application, but incidents like ToolShell show that internet-facing collaboration systems behave like privileged trust brokers. If their signing material, reachability, and patch status are not governed together, the security programme is leaving a large non-human identity surface outside review.

Machine-key handling is a lifecycle control, not a cleanup task. When attackers can reuse signing material to forge payloads, the compromise survives the original exploit path. That means renewal, rotation, and removal of trust material need to be part of the operational baseline for self-hosted collaboration systems, especially when they are exposed to the internet.

For practitioners

• Harden exposed SharePoint servers Patch all on-prem SharePoint instances to the July 2025 fixes, verify the required KBs are present, and remove public exposure until every instance is confirmed remediated.
• Rotate ASP.NET machine keys Regenerate ValidationKey and DecryptionKey values on every SharePoint server and recycle IIS so stolen signing material cannot be reused for forged payloads.
• Sweep for web shell artefacts Search SharePoint layouts directories for unexpected ASPX files such as spinstall0.aspx and review HTTP logs for ToolPane.aspx requests and spoofed Referer values.
• Enable AMSI and endpoint detection Turn on AMSI where possible, confirm Defender AV or EDR is current, and treat any SharePoint server that cannot support AMSI as higher exposure until isolation is complete.
• Track SharePoint as a privileged service asset Maintain an inventory of SharePoint hosts, their patch status, and their internet exposure so exposed collaboration systems are governed alongside other high-risk service identities.

Key takeaways

• ToolShell shows that SharePoint compromise can begin with trust confusion and end with persistent code execution, not just a one-time vulnerability hit.
• Orca Security’s data shows that a meaningful share of cloud environments still run vulnerable self-hosted SharePoint components and expose some of them directly to the internet.
• The control that matters most is not patching alone but patching, exposure reduction, and machine-key rotation as one governance action.

Key terms

• SharePoint trust boundary: The point where a collaboration platform decides whether a request, file, or payload is allowed to behave as trusted system activity. In ToolShell-style incidents, the boundary is weaker than teams assume because server-side logic, headers, and signing keys can be abused together.
• MachineKey: A machineKey is the signing and encryption material used by ASP.NET applications to protect payloads such as ViewState. If an attacker steals it, they can forge data the server trusts, turning a single compromise into a broader trust-abuse problem across the application tier.
• Web shell: A web shell is a script placed on a server that accepts commands over HTTP and executes them on demand. It creates persistent server-side access, which means defenders may remove the original exploit path while the attacker still retains a reusable foothold.
• Internet-facing service asset: A service host that is reachable directly from the public internet and therefore subject to external attack before any internal control can intervene. For collaboration platforms, this makes exposure, patch status, and trust material governance issues, not just infrastructure details.

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.