ToolShell exploitation shows how SharePoint flaws become ransomware paths

At a glance

What this is: This is a threat briefing on active ToolShell exploitation against SharePoint servers, showing how attackers turn public-facing application flaws into token forgery and ransomware deployment.

Why it matters: It matters because SharePoint exploitation is not just a patching issue, it is an identity and access problem when stolen machine keys let attackers mint valid sessions and bypass normal trust controls.

👉 Read Anomali's Cyber Watch coverage of ToolShell exploitation and related threats

Context

ToolShell exploitation is a reminder that public-facing application flaws become identity problems once attackers can steal signing material or forge valid sessions. In SharePoint environments, machine keys and authentication tokens sit on the boundary between application security and access control, which is why patching alone often leaves a residual trust gap.

The article focuses on how ransomware crews reused an exploit path first associated with espionage, then applied it for disruption and extortion. That pattern is typical of modern exploitation campaigns: once a working path is public, multiple actors will reuse it until defenders remove exposure, rotate secrets, and verify that no forged trust remains.

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 internet-facing application flaws often become identity risks?

A: Because web application compromise frequently exposes the components attackers need to reach identity controls, including configuration files, session tokens, admin interfaces, or service credentials. Once those are in play, the incident is no longer only about application security. It becomes a credential, privilege, and account governance problem as well.

Q: What do teams get wrong about patching exposed collaboration servers?

A: Teams often assume patching ends the incident, but exposed collaboration servers may already have leaked signing material or session artifacts. If those secrets are still valid, the attacker can remain active without touching the original exploit again. Containment should include key rotation, session revocation, and forensic validation of trust boundaries.

Q: Who is accountable when a former employee account or stolen token is used in a breach?

A: Accountability sits with the organisation that failed to revoke, monitor, or scope the identity before it was abused. In practice that means IAM, platform, application, and security owners all share responsibility for lifecycle closure and privileged access oversight. If no one owns revocation, no one controls persistence.

Technical breakdown

How ToolShell turns a SharePoint flaw into unauthenticated access

ToolShell chains SharePoint vulnerabilities to reach code execution or privileged application logic without a normal login flow. Once attackers can interact with the server as if they were trusted, they can inspect configuration material, drop web shells, or query components that expose signing secrets. The critical issue is not only initial access, but the collapse of the authentication boundary. When machine keys or equivalent signing material are available, the attacker no longer needs to keep exploiting the vulnerability to remain inside the environment.

Practical implication: treat exposed SharePoint servers as potential identity compromise events, not just patching events.

Why machine key theft enables token forgery and persistence

ASP.NET machine keys are used to sign and validate cookies, forms authentication tokens, and other application artifacts. If an attacker steals those keys, they can forge valid tokens and impersonate legitimate users or services without brute force or password theft. That makes the compromise durable, because the attacker can regenerate trust artifacts even after the original vulnerability is patched. In identity terms, the signing key becomes the real credential, and its exposure extends the breach beyond the original application flaw.

Practical implication: rotate machine keys and invalidate existing sessions whenever compromise is suspected.

Why ransomware operators target the same exploit path as espionage actors

Ransomware crews often adopt the same entry points used by more advanced actors because the exploit path is already proven and the target population is broad. The difference is the objective: espionage seeks long dwell time and stealth, while ransomware seeks fast operational disruption and leverage. Once a public exploit exists, attackers can scale it quickly, especially when underground forums lower the skill threshold by sharing tooling or payloads. That creates a short window in which exposed services become high-value commodities for many threat types at once.

Practical implication: pair emergency patching with exposure reduction, isolation, and post-compromise hunts.

Threat narrative

Attacker objective: The attacker objective is to convert a SharePoint exposure into trusted access that can be used for ransomware deployment and operational disruption.

1. Entry occurs when attackers exploit public SharePoint vulnerabilities to gain unauthenticated access to on-premises servers.
2. Escalation follows when machine keys are extracted and used to forge authentication tokens, giving attackers durable valid-session access.
3. Impact occurs when ransomware is deployed to encrypt systems, disrupt operations, and pressure victims into payment.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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 shows that application vulnerabilities become identity failures once signing material is exposed. The breach path does not end at unauthenticated access. It continues when machine keys, cookies, or token-signing secrets can be stolen and reused to mint trusted sessions. That is why the control question is not only whether the server is patched, but whether forged trust can still exist after exposure. Practitioners should treat signing material as a high-value identity asset.

Standing trust in public-facing collaboration platforms is the real weakness here. SharePoint is often positioned as an application security problem, but the exploit becomes dangerous because downstream controls continue to trust what the server issues. That means session validation, token integrity, and secret rotation matter as much as vulnerability remediation. The broader lesson is that access controls built on static trust are fragile when attackers can steal the trust anchor itself.

Machine key exposure is the named failure mode this campaign illustrates. Once an attacker has the key material used to sign authentication artifacts, patching the original flaw does not automatically revoke the attacker’s ability to stay in the environment. This is a classic example of a standing credential exposure window, except the credential is embedded in application trust rather than a user password. Practitioners should focus on eliminating that persistence path.

The campaign validates a shift from exploit management to trust reassessment. Multiple actors can reuse the same weakness for espionage, intrusion, or ransomware because the exploit path is commoditised. That puts pressure on defenders to re-evaluate what constitutes a contained incident in web applications, especially where application identity, tokens, and keys are involved. The field is moving toward post-exploitation trust invalidation, not just patch-and-pray remediation.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Forward look: Read Guide to NHI Rotation Challenges for the operational constraints that make secret rotation slow in real environments.

What this signals

Machine-key compromise creates a trust reset problem, not just a patching problem. For identity and security teams, the operational question is whether downstream session and token trust can be invalidated fast enough to matter. Where secret exposure is slow to detect or rotate, the attacker’s usable window extends far beyond the original exploit, which is why rotation and revocation need to sit in the incident playbook alongside patching.

For teams running collaboration platforms and other public-facing applications, this is a strong signal to align web application recovery with identity governance. The practical issue is not only service restoration, but whether every trusted artifact issued by the compromised system has been retired. That is where controls from NIST SP 800-207 Zero Trust Architecture and NIST SP 800-53 Rev 5 Security and Privacy Controls become operational rather than theoretical.

For practitioners

• Rotate machine keys immediately after suspected exposure Invalidate existing SharePoint trust artifacts, restart dependent services, and verify that token-signing material has been replaced across all affected servers.
• Hunt for forged session artifacts and web shells Review IIS logs, SharePoint request patterns, and authentication anomalies for POSTs to ToolShell-related paths, suspicious referrers, and reused session tokens.
• Isolate exposed SharePoint servers until trust is re-established If patching cannot happen immediately, remove internet exposure, segment the host, and assume the application boundary has already been crossed.
• Rebuild the recovery plan around identity revocation Plan for secret rotation, token invalidation, and service revalidation before returning systems to production rather than treating remediation as patch installation alone.

Key takeaways

• ToolShell matters because SharePoint exploitation can become a token-forgery problem, not just a server patching issue.
• The article shows how stolen machine keys extend attacker access beyond the original vulnerability window and complicate recovery.
• The control that changes the outcome is fast trust invalidation, including key rotation, session revocation, and post-exploitation hunts.

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.
• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.

What's in the full analysis

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

• Per-threat indicator lists for ToolShell, PXA Stealer, ClickFix, and other campaigns covered in the briefing.
• Attack-specific IoCs that ThreatStream users can load into logs and detections for validation.
• Campaign-by-campaign context on how the attacks spread, persist, and evade detection across environments.
• Source material for cross-checking malicious activity against current observations in your own telemetry.

👉 Anomali's full Cyber Watch post includes the IoCs and campaign details behind these threats.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity principles into operational control across recovery, rotation, and access review.