SharePoint lateral movement exposes the limits of perimeter controls

At a glance

What this is: This is an analysis of how the ToolShell SharePoint exploit turned initial code execution into stealthy lateral movement across internal Microsoft services.

Why it matters: It matters because IAM, PAM, and NHI programmes still fail when they protect the edge but not the authenticated session, token, and process identity inside the environment.

👉 Read Riptides' analysis of SharePoint lateral movement and ToolShell

Context

Lateral movement is the phase of an attack where an intruder pivots from one compromised system to others by reusing trust, tokens, or privileged sessions. In SharePoint environments, that means the security problem is not just initial exploitation, but the ease with which attackers convert one foothold into broader internal access across Microsoft services.

The article argues that traditional segmentation often stops at machines or networks, while attackers operate at the level of authenticated processes and forged identity material. That gap is directly relevant to NHI governance because service and workload identities are often assumed to be trustworthy once they are inside the boundary.

For practitioners, the key question is not whether perimeter controls detect the first exploit, but whether internal identity controls can still distinguish legitimate from hijacked execution after tokens are forged or sessions are replayed. That is the typical enterprise failure mode the post is describing.

Key questions

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. That means authenticating the calling process, not just the network location, and preventing compromised sessions from inheriting broad trust across Microsoft services.

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. Once the attacker can operate inside a valid authentication context, many network controls cannot distinguish legitimate traffic from hostile reuse of trust.

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. At that point, the session becomes a privilege bridge, and the attacker can move from one application to others without needing obvious escalation steps.

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.

Technical breakdown

How the ToolShell SharePoint exploit creates initial footholds

The campaign begins with CVE-2025-53770, a remote code execution issue on exposed SharePoint servers. Once code execution is achieved, attackers can drop a web shell and extract ASP.NET machine keys from the host. Those keys matter because they allow the attacker to create forged authentication material that looks legitimate to downstream services. The technical problem is not just code execution, but the conversion of host access into identity material that can be reused elsewhere. Practical implication: treat exposed application servers as identity-bearing assets, not just infrastructure nodes.

Practical implication: Instrument exposed application servers for web shell creation and machine key extraction, not only for network-layer exploitation.

Forged tokens and session abuse defeat network segmentation

Once attackers forge authentication tokens, they no longer need noisy privilege escalation in the traditional sense. They can impersonate users and initiate authenticated sessions that pass ordinary trust checks, including many perimeter and segmentation controls. That is why lateral movement succeeds so often after the first compromise: the attack is now operating inside valid identity contexts. The article’s point is that segmentation between machines does not stop identity misuse between processes or services. Practical implication: enforce controls that validate the identity of the calling process and the authenticity of the session, not only the source IP.

Practical implication: Require session and token integrity checks that survive host compromise and do not rely on network location alone.

Process-level identity is the real control plane for lateral movement

The article’s deepest claim is that internal trust is still too often expressed through host, service name, or VLAN assumptions. Attackers who hijack a legitimate process can use those assumptions against the environment, especially when east-west traffic is not tied to per-process identity. SPIFFE-style workload identity addresses this by binding identity to the runtime workload rather than to an address or machine label. That is the architectural shift this incident exposes. Practical implication: map east-west authorisation to workload identity and posture, not to static network boundaries.

Practical implication: Move east-west authorisation toward workload identity and posture verification instead of static network trust.

Threat narrative

Attacker objective: The attacker aims to turn one vulnerable SharePoint server into broad internal compromise across trusted Microsoft services.

1. Entry occurs through the SharePoint 0-day CVE-2025-53770 on exposed servers, giving the attacker an initial foothold inside the application boundary.
2. Credential access follows when the attacker extracts ASP.NET machine keys and uses them to forge authentication tokens and impersonate legitimate users.
3. Impact arrives as the attacker moves laterally into Teams, Exchange, and other Microsoft services with stealthy authenticated access.

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

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.

Process identity is now the practical boundary for lateral movement control. SharePoint compromise turned into internal access because the attacker could reuse trusted execution contexts inside the host and across services. The relevant control question is whether each process is authenticated as its own runtime identity, not whether the host sits in a segmented subnet. Practitioners should treat process-bound identity as the missing control plane for modern east-west security.

Standing trust in authenticated sessions is the failure mode this breach exposes. ToolShell shows that a valid session can be the attacker’s privilege bridge after the initial exploit succeeds. That means access policy built around where a request comes from is weaker than policy built around who or what is actually executing. Practitioners should re-evaluate assumptions that a logged-in session is inherently a trustworthy one.

Identity blast radius matters more than the first exploit in application compromise. The SharePoint issue was dangerous because it converted one exposed service into access across Teams, Exchange, and adjacent Microsoft services. That kind of spread reveals a wider governance gap in how organisations model internal trust propagation across interconnected services. Practitioners should map which identities can expand compromise beyond the originating workload.

From our research:

• 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.
• For teams building a response model, the The 52 NHI breaches Report is the right next step for understanding how identity exposure turns into operational compromise.

What this signals

Identity blast radius is the programme-level issue this article surfaces. Once tokens can be forged from a compromised application host, IAM and PAM teams need to know which downstream services are still reachable through trusted sessions, because perimeter controls will not answer that question.

The practical shift is toward runtime verification of workloads and processes. A useful comparison point is the OWASP NHI Top 10, which helps teams think about how identity misuse propagates after the first compromise.

With 64% of valid secrets leaked in 2022 still valid and exploitable today, per Guide to the Secret Sprawl Challenge, the longer-term programme risk is not only exposure, but persistence of trust after exposure.

For practitioners

• 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.
• Map identity blast radius for critical platforms Document which application servers, service accounts, and tokens can be used to pivot into adjacent business systems, then prioritise controls where compromise would cross service boundaries fastest.

Key takeaways

• The SharePoint campaign shows that lateral movement is now an identity problem as much as a network problem.
• Forged tokens and reused trust contexts allow one exposed server to become an internal compromise event across multiple services.
• Teams should shift from perimeter thinking to runtime identity verification, especially where authenticated sessions can outlive the original exploit.

Key terms

• Lateral Movement: The techniques attackers use to move from one compromised system or identity to others inside an environment. It often relies on stolen credentials, forged tokens, or trusted sessions rather than noisy new exploits, which is why it frequently evades controls focused only on initial entry.
• Forged Authentication Token: A counterfeit credential that lets an attacker present as a valid user or service after stealing signing material or other secrets. In practice, forged tokens matter because they inherit trust from the organisation’s own identity systems, which can make compromise look legitimate.
• Process Identity: The identity assigned to a running application or workload, distinct from the host it runs on. Process identity becomes critical when attackers hijack legitimate execution and try to reuse that runtime trust for east-west movement, service calls, or privileged internal actions.

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 Riptides covering SharePoint lateral movement and the ToolShell campaign: SharePoint Under Siege: Lateral Movement Is Still Security’s Blind Spot. Read the original.