TL;DR: Multiple ransomware groups are exploiting ToolShell flaws in Microsoft SharePoint to gain unauthenticated access, steal machine keys, forge authentication tokens, and deploy ransomware, with hundreds of systems compromised globally, according to Anomali Cyber Watch. Patch status alone is no longer a sufficient control when exposed servers can be treated as already breached.
NHIMG editorial — based on content published by Anomali: Anomali Cyber Watch on PXA Stealer, ClickFix malware, fake TikTok shops, ThrottleStop, and more
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Anomali's Cyber Watch coverage of ToolShell exploitation and related threats →
ToolShell exploitation and machine key theft: what teams need to know?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: ToolShell exploitation shows how SharePoint flaws become ransomware paths