TL;DR: The ToolShell campaign linked to SharePoint CVE-2025-53770 shows how an RCE on exposed servers can become internal compromise through web shells, forged tokens, and privilege escalation into Microsoft services, according to Riptides. Perimeter controls are no longer enough when attackers pivot through authenticated sessions and process-level trust.
NHIMG editorial — based on content published by Riptides covering SharePoint lateral movement and the ToolShell campaign: SharePoint Under Siege: Lateral Movement Is Still Security’s Blind Spot
Questions worth separating out
Q: How should security teams stop lateral movement after a SharePoint compromise?
A: Security teams should assume the initial foothold is already inside the boundary and focus on whether internal calls still require independent identity proof.
Q: Why do segmentation controls often fail against modern lateral movement?
A: Segmentation often fails because it separates machines and subnets, while attackers pivot through stolen tokens, forged identities, and trusted sessions.
Q: What breaks when organisations trust internal sessions by default?
A: Default trust breaks when a compromised session can still access downstream services after the original host is hijacked.
Practitioner guidance
- Harden exposed application servers as identity-bearing assets Detect web shells, monitor for machine key extraction, and treat SharePoint as a credential source after compromise rather than only as an application vulnerability target.
- Bind east-west trust to runtime identity Use process-level identity and mutual authentication for internal service calls so that a hijacked host cannot automatically inherit trust across Teams, Exchange, or other downstream systems.
- Reduce reliance on forged session trust Revisit whether authenticated sessions can still reach sensitive services after host compromise, and add verification that survives token replay or token forgery.
What's in the full article
Riptides' full analysis covers the operational detail this post intentionally leaves for the source:
- The specific SharePoint exploit chain and the triage indicators used to spot ToolShell-style compromise.
- The kernel-level enforcement model the vendor describes for process identity and east-west control.
- The implementation view of SPIFFE-based workload identity and mTLS enforcement in internal traffic paths.
- The article's own explanation of how local and service-level trust assumptions break during lateral movement.
👉 Read Riptides' analysis of SharePoint lateral movement and ToolShell →
SharePoint lateral movement in 2025: are your controls keeping up?
Explore further
Perimeter segmentation failed because the attack operated through identity, not just traffic. The article makes clear that once attackers forged authentication tokens, network controls lost most of their value. That is not a tuning problem, it is a governance problem where east-west trust was assumed to live at the machine boundary. Practitioners should conclude that internal authorisation must follow identity context, not just network location.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to Guide to the Secret Sprawl Challenge.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who is accountable when forged tokens enable internal compromise?
A: Accountability sits with the team that owns the application, identity, and segmentation model together, because the failure spans all three. In practice, organisations should align incident ownership with the service that issued or accepted the trusted identity context, not only the team that detected the exploit.
👉 Read our full editorial: SharePoint lateral movement exposes the limits of perimeter controls