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 exposure conditions that make on-premise deployments attractive targets.

Why it matters: It matters because SharePoint sits inside identity-connected enterprise workflows, so unauthenticated remote code execution can quickly become a broader IAM and NHI risk.

By the numbers:

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

👉 Read Orca Security's analysis of the ToolShell SharePoint exploit chain

Context

ToolShell is a SharePoint Server exploit chain that turns a patched collaboration platform into a remote code execution foothold when on-premise instances remain exposed. The primary security problem is not just the presence of two CVEs, but the way internet-facing SharePoint servers sit close to identity stores, document workflows, and administrative trust paths.

For IAM and NHI teams, the lesson is straightforward: collaboration platforms are often treated as application infrastructure, but their compromise can open paths into Active Directory, Microsoft 365 integrations, and privileged service relationships. That makes patch status, exposure management, and machine account governance part of the same control conversation.

The typical starting position here is unfortunately common rather than exceptional. Many organisations still run self-hosted SharePoint in environments where exposure, patch lag, and operational dependency combine to widen the blast radius once the first request lands.

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 do on-premise collaboration platforms increase identity-related blast radius?

A: They sit close to the systems that manage access, documents, and administration, so a server compromise can become a path into identity-adjacent trust relationships. When collaboration systems are integrated with directory services and cloud workflows, the compromise can extend far beyond the initial application boundary.

Q: How do security teams know whether ToolShell remediation is actually complete?

A: They should verify that every affected SharePoint instance is patched, publicly exposed systems are removed from reach until fixed, and machineKey values have been rotated with IIS recycled. If logs still show suspicious ToolPane.aspx traffic or unexpected ASPX files remain on disk, remediation is not complete.

Q: Who is accountable when a patched SharePoint server is still reachable from the internet?

A: Accountability sits across infrastructure, application, and identity governance teams because the failure is shared. Vulnerability management owns the fix, but exposure review, privileged integration mapping, and lifecycle control over the server's trust relationships are what prevent the next exploit from becoming an enterprise incident.

Technical breakdown

How the ToolShell chain bypasses SharePoint authentication

ToolShell works by chaining a spoofing flaw with a deserialization flaw. In the first step, the attacker forges request context so SharePoint treats an unauthenticated call as if it were authorised. In the second step, malicious payload data is deserialized on the server, which gives the attacker code execution. The important mechanism is not just that both bugs are critical, but that the second bug becomes reachable because the first bug defeats the trust check guarding the endpoint.

Practical implication: patching one side of the chain is not enough if the underlying request-validation logic remains exposed.

Why the web shell turns a CVE into persistent access

Once code execution is achieved, attackers can drop an ASPX web shell inside the SharePoint layout path. A web shell is a server-side script that accepts commands and runs them on demand, which creates persistent remote access even if the initial exploit path is later blocked. That persistence matters because it turns a momentary vulnerability into an operational foothold that can be reused for reconnaissance, credential theft, and staged follow-on actions.

Practical implication: hunt for unexpected ASPX artefacts and treat them as evidence of post-exploitation persistence, not just web noise.

How machineKey theft extends the compromise beyond the first server

The article describes attackers stealing machineKey values, specifically the ValidationKey and DecryptionKey. Those keys let an attacker forge signed ViewState payloads that the server will trust as legitimate. This matters because the compromise then outlives the original exploit request, and the attacker can keep generating valid payloads until the keys are rotated and IIS is recycled across the affected estate.

Practical implication: rotate machineKey material everywhere and confirm the change has actually propagated, not just been configured.

Threat narrative

Attacker objective: The attacker objective is to gain persistent server-side execution on exposed SharePoint instances and use that access to expand control across the enterprise environment.

1. Entry occurs through a forged request to SharePoint's ToolPane endpoint that bypasses authentication checks and reaches vulnerable server-side logic.
2. Escalation follows when the attacker uses deserialization abuse to plant an ASPX web shell and then extract machineKey values for trusted payload forgery.
3. Impact comes from persistent unauthenticated remote code execution across exposed SharePoint servers, creating a durable foothold for further compromise.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

Internet-facing SharePoint is not just an application exposure problem, it is an identity boundary problem. SharePoint deployments commonly sit next to directory services, federated authentication, and administrative workflows, which means compromise rarely stays local to the web tier. Once the server is trusted inside the enterprise control plane, the blast radius is determined by what it can reach next. Practitioners should treat collaboration-platform exposure as a governance issue, not a patch-only issue.

ToolShell shows how quickly a patched environment becomes unpatched in practice when the trust boundary is still reachable. The article's 13% vulnerable deployment figure and 6% direct-internet exposure rate are a reminder that patch availability does not equal risk removal. Mature programmes need to know which systems remain externally reachable, not just which ones have a ticket closed. The practitioner conclusion is that exposure reduction is part of vulnerability management.

MachineKey theft is a named concept here: trusted payload forgery. The attack works because the server's signing material can be stolen and reused to generate requests SharePoint will accept as legitimate. That turns a single web shell into a broader trust-abuse problem, where forged ViewState payloads become a second execution path. Security teams should recognise this as trust material abuse, not only remote code execution.

SharePoint compromise should be analysed as a machine-identity adjacency event. Even when the exploit is not stealing a service account directly, the server is usually embedded in workflows that depend on tokens, application identities, and privileged integrations. The practical governance issue is that application servers often inherit implicit trust across human IAM, NHI, and infrastructure layers. Practitioners should map those downstream dependencies before the next incident does it for them.

Patch lag is only one symptom of a deeper lifecycle failure. On-premise collaboration platforms often remain in service because offboarding, hardening, and exposure review are treated as separate queues. The result is an identity-adjacent asset that stays reachable after the patch window closes. Practitioners should fold collaboration systems into the same lifecycle discipline used for high-value non-human identities and privileged infrastructure services.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• Read Top 10 NHI Issues for the control failures that most often turn exposed systems into persistent access paths.

What this signals

Trust boundary drift is now the common failure mode in identity-adjacent infrastructure. SharePoint is a useful example because it looks like application infrastructure until exploitation turns it into a trust amplifier. The lesson for practitioners is to treat externally reachable collaboration systems as part of the identity control surface, especially when they bridge human access, machine accounts, and cloud integrations.

The exposure gap matters more than the product label. When a service sits one hop away from directory services or privileged workflows, patching without exposure reduction leaves the same attack path available to the next actor. That is why lifecycle control over internet-facing infrastructure now belongs in the same conversation as privileged access and secrets governance.

For teams building better prioritisation, the signal is simple: if a system can bridge user-facing workflows and backend trust, it needs the same scrutiny as a high-value NHI. Map those dependencies early, because the next exploitation wave will follow the fastest route through your trust graph.

For practitioners

• Harden internet exposure for on-prem SharePoint Inventory every self-hosted SharePoint instance, confirm whether it is directly reachable from the internet, and remove public access until the July 2025 fixes and required KBs are verified on each host.
• Rotate machineKey material across the estate Regenerate ValidationKey and DecryptionKey values on every SharePoint server, then recycle IIS so the new keys are enforced consistently across the environment.
• Hunt for post-exploit web shells and request forgery Sweep SharePoint directories for unexpected ASPX files, inspect HTTP logs for suspicious ToolPane.aspx requests, and treat the Referer spoofing pattern as an indicator of active exploitation.
• Prioritise patching by exposure and integration risk Rank vulnerable SharePoint systems ahead of lower-value assets when they sit close to authentication services, document repositories, or Microsoft 365 integrations that could widen the impact.

Key takeaways

• ToolShell demonstrates that an internet-facing collaboration server can become a durable identity-adjacent foothold when authentication and deserialization flaws are chained together.
• Orca Security's exposure data shows that vulnerable SharePoint instances remain common enough to matter operationally, especially when public reachability is still present.
• The decisive control is not only patching, but also removing exposure, rotating machineKey material, and checking for post-exploit artefacts before assuming containment.

Key terms

• Deserialization exploit: A deserialization exploit occurs when a system converts attacker-controlled data into live objects and then executes unsafe behavior. In identity-adjacent systems, this can become remote code execution, allowing the attacker to run commands as the application itself and pivot into adjacent trust relationships.
• 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.
• 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.
• Exposure management: Exposure management is the practice of identifying which assets are reachable by attackers and reducing that reach before exploitation occurs. For collaboration systems like SharePoint, it is not enough to know that a patch exists, because public accessibility changes the speed and likelihood of attack.

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.

This post draws on content published by Orca Security: Microsoft pushes out-of-band fixes for ToolShell-related SharePoint vulnerabilities. Read the original.