ToolShell exploitation shows how SharePoint flaws become ransomware paths

At a glance

What this is: Anomali says ToolShell exploitation in Microsoft SharePoint is now being reused by ransomware gangs to move from unauthenticated access to machine key theft and ransomware deployment.

Why it matters: It matters because SharePoint patching is only the starting point when attackers can already have exposed systems, forged tokens, and persistence paths that outlast the initial flaw.

Context

ToolShell is a SharePoint exploitation path, not just a single bug, and it shows how public-facing application flaws can become full compromise chains when attackers can reach key material after entry. Once machine keys are stolen, authentication controls can be bypassed even if the original vulnerability is later patched.

The identity angle is direct: the attack turns a server-side flaw into token forgery, which means the access boundary is no longer just network exposure but trust in machine credentials and session material. For IAM and PAM teams, this is a reminder that service-side identity material has to be treated as a breach objective, not only a configuration detail.

Key questions

Q: What happens after an attacker steals SharePoint machine keys from a compromised server?

A: Once machine keys are stolen, attackers can forge signed ViewState payloads and keep regaining remote code execution even after the original vulnerability is patched. That is why patching alone is not enough. Teams must rotate machine keys and restart IIS to invalidate the attacker’s ability to reuse trusted tokens and maintain persistence.

Q: Why does unauthenticated access to SharePoint create ransomware risk?

A: Because public-facing access can become authenticated control if attackers can reach the server's signing material. Ransomware crews then use that foothold to move from entry to token forgery and finally to operational disruption. The risk is highest when the server sits on a path to business-critical data or recovery infrastructure.

Q: What signs suggest ToolShell exposure has already been abused?

A: Look for suspicious authentication patterns, unusual SharePoint activity, token anomalies, and any evidence that the server continued to issue trusted sessions after exposure became public. If attackers had time to extract machine keys, the compromise may not leave obvious malware on disk, so integrity checks and authentication telemetry matter more than endpoint scans alone.

Q: How should teams respond when an exposed SharePoint server is still online?

A: They should isolate it from internet reachability, invalidate the trust material that could be used to forge sessions, and treat the instance as an incident response priority rather than a routine patch job. Recovery should include forensic review and assurance that all related authentication artefacts have been reissued.

Technical breakdown

How ToolShell turns a web flaw into authenticated access

ToolShell is the label for a chain of SharePoint vulnerabilities that gives attackers unauthenticated access to on-premises servers. The important architectural point is that public application exposure is only the first step. Once code execution or equivalent access is obtained, attackers can inspect the application environment, reach server-side secrets, and use them to impersonate legitimate sessions. In identity terms, the compromise is not limited to the login surface. It extends into the trust fabric that signs and validates SharePoint authentication material.

Practical implication: treat internet-facing SharePoint as a credential-bearing system, not just an application server.

Why machine keys matter after initial compromise

ASP.NET machine keys are cryptographic material used to protect and validate tokens, cookies, and related authentication data. If attackers extract those keys, they can forge trusted artefacts that appear legitimate to the platform. That changes the threat from a transient exploit to a durable trust break because the attacker can keep using valid-looking authentication material after the original vulnerability is patched. This is why machine key theft matters more than file-based malware alone. The compromised server itself becomes a source of identity fraud inside the application stack.

Practical implication: rotate application keys after exploitation, not just after patching.

Why ransomware operators favour public-facing enterprise software

Public-facing enterprise software gives attackers a scalable entry point, especially when one exploit path can be reused across many organisations. In this case, ransomware crews are using the same exploit chain that espionage actors used earlier, but changing the objective from stealth to extortion. That reuse lowers operational cost and broadens the attacker base, particularly when tooling is shared in underground forums. The core security issue is that externally reachable business systems often blend application trust, service identity, and recovery dependencies in one place.

Practical implication: inventory externally reachable business apps as part of your ransomware exposure review.

Threat narrative

Attacker objective: The objective is to convert SharePoint exposure into authenticated access and then into ransomware-driven disruption and extortion.

1. Entry occurs when attackers exploit ToolShell flaws to reach SharePoint servers without valid authentication.
2. Credential access follows when machine keys are extracted and used to forge trusted authentication tokens.
3. Impact occurs when ransomware is deployed on compromised servers, disrupting operations and forcing recovery.
4. Post-compromise persistence is reinforced when exposed servers remain reachable and can be treated as already breached.

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 a trust-break problem, not just a patching problem. The exploit path matters because it moves from application exposure into token forgery, which means the attacker can operate with application-level legitimacy. That changes the governance question from whether the server is patched to whether the server's trust material should still be believed. Practitioners should treat server-side identity material as compromised until it is rotated and revalidated.

Machine key theft is the control failure the breach pattern exposes. Once machine keys are harvested, the attacker no longer depends on the original vulnerability staying open. The breach works because the organisation has allowed a long-lived trust anchor to remain valid after compromise. That is a classic NHI governance failure inside application infrastructure, and it should be handled as key compromise, not routine remediation.

Ransomware operators are exploiting the same compromise path that espionage actors used first. That reuse shows how quickly threat activity moves from reconnaissance-grade access to monetised disruption. The lesson for security teams is that a public exploit is rarely a one-purpose event. Once a server has been touched, recovery and assurance controls have to assume token abuse, not just malware cleanup.

SharePoint exposure now belongs in identity governance conversations. The article shows that a server compromise can become an authentication compromise when machine keys and forged tokens are in play. This is where NHI governance and application security intersect: service-side credentials, signing material, and trust boundaries need lifecycle control, not ad hoc incident handling. Teams should align response runbooks with identity assurance, not only with endpoint containment.

What this signals

ToolShell has shifted SharePoint from a patch-management issue into an authentication-governance issue. The practical lesson for readers is that compromise may now live in the trust material, not just the vulnerable code path. That means response plans need explicit steps for key rotation, session invalidation, and post-patch assurance.

SharePoint exposure should be triaged like a credential event, not a simple application defect. Once attackers can forge tokens, the distinction between application security and identity security disappears for that system. For IAM, PAM, and security operations teams, the boundary to watch is whether a server can still mint trusted access after exposure.

Machine key compromise is a named concept worth operationalising. It captures the point at which server-side trust material becomes the attacker’s persistence mechanism. Teams that track only vulnerable binaries will miss the more durable failure mode, so remediation has to include trust-material revocation and validation.

For practitioners

• Treat exposed SharePoint as already breached Assume unauthenticated access may have already occurred if ToolShell exposure was public. Move directly into containment, forensic review, and trust-material validation rather than waiting for file-based indicators alone.
• Rotate machine keys and related signing material Reissue the application trust material that attackers can use to forge tokens, and validate that old keys are no longer accepted anywhere in the environment.
• Hunt for forged token activity Review authentication and IIS artefacts for token anomalies, unusual session issuance, and signs that trusted access continued after the patch window.
• Reduce internet exposure of SharePoint servers If immediate hardening is not possible, isolate the servers from direct internet reachability so an exposed application cannot continue serving as a live foothold.
• Expand ransomware response playbooks to include application trust compromise Add steps for key rotation, session invalidation, and post-patch integrity checks so remediation covers both the exploit path and the identity material it exposed.

Key takeaways

• ToolShell exploitation shows how a public SharePoint flaw can become a credential and trust compromise, not just a server exploit.
• The article ties the attack to ransomware groups that use stolen machine keys and forged tokens to stay effective after patching.
• The control that matters most is not patching alone but key rotation, session invalidation, and isolation of exposed servers.

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.
• Token Forgery: Token forgery is the creation of a valid-looking authentication token without legitimate authorization from the identity provider. It usually depends on exposing signing keys, encryption secrets, or recovery material. In identity programmes, forgery matters because it bypasses login controls and turns stolen secrets into direct impersonation.
• Public-Facing Application Exploitation: Public-facing application exploitation is the abuse of internet-accessible software to gain unauthorized access, execute code, steal data, or disrupt services. It typically targets exposed web apps, APIs, portals, and remote access interfaces, using flaws such as injection, authentication bypass, deserialization, or misconfiguration to move from external reachability to internal compromise.
• Endpoint Trust Boundary: The part of the security model where a device is treated as sufficiently trusted to hold or use sensitive data locally. For offline vault access, the endpoint becomes part of the identity control plane, so device loss, reassignment, and malware risk all matter.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is a fit for practitioners who need to turn identity assurance into operational control across complex environments.