SharePoint lateral movement exposes the limits of perimeter controls

At a glance

What this is: This article argues that SharePoint compromise in the ToolShell campaign turned into lateral movement because forged tokens and web shells let attackers reuse trust inside the environment.

Why it matters: It matters because IAM and PAM teams must treat authenticated internal movement as an identity problem, not only a network containment problem.

Context

SharePoint lateral movement is the abuse of trusted internal access paths after an initial foothold, usually by reusing credentials, tokens, or process trust to move from one system to another. In this article, that pattern is the core governance problem because the attacker did not need to stay at the perimeter once authenticated trust was available.

The SharePoint case shows why traditional perimeter thinking breaks down when compromised application processes can mint or reuse authentication material that looks legitimate to downstream services. For identity programmes, the issue is not just server hardening. It is whether internal service trust, session trust, and workload trust are governed with enough precision to limit post-compromise movement.

Key questions

Q: What breaks when SharePoint is compromised but downstream services still trust its sessions?

A: The control that breaks is the assumption that authenticated internal traffic is inherently safe. Once attackers can forge tokens or reuse stolen identity material, the original server breach becomes a wider trust failure across Teams, Exchange, and other services. The practical result is lateral movement that looks legitimate unless identity telemetry is tied to session provenance.

Q: Why does lateral movement remain such a serious risk after initial access is contained?

A: Because containment at the perimeter does not stop a hijacked identity from moving inside the environment. If tokens, keys, or service trust remain valid after compromise, attackers can pivot with little friction. That is why lateral movement is fundamentally an identity and trust problem, not only a network segmentation problem.

Q: What are the signs that internal service trust is too broad?

A: Common signs include service accounts with admin-like access, internal APIs that accept calls from many unrelated workloads, and little visibility into east-west traffic. If teams cannot explain why one service can reach another, or if the same credential works across many systems, the trust model is wider than the business need.

Q: Should teams treat machine keys and forged tokens as incident-response priorities?

A: Yes. Once machine keys or similar signing material may be exposed, teams should assume authentication trust has been weakened and investigate how far the blast radius extends. The key question is which sessions, services, and administrative paths were reachable before trust was revoked.

Technical breakdown

How forged tokens turn SharePoint access into trusted movement

The article describes a sequence where the attacker first gains code execution on an exposed SharePoint server, then extracts ASP.NET machine keys, and then uses those keys to forge authentication tokens. Forged tokens matter because they convert a server-side exploit into something that downstream services interpret as legitimate identity. That is why the campaign moved beyond the original SharePoint host and into Microsoft services such as Teams and Exchange. The technical break is not just exploitation, but trust reuse across systems that accept the forged session as valid.

Practical implication: validate where authentication material is minted, stored, and reused across internal services.

Why perimeter segmentation fails once the process is already trusted

The article argues that traditional network segmentation stops at machine boundaries, while modern lateral movement happens inside the host through a compromised process. A firewall or WAF can block obvious inbound traffic, but it cannot reliably distinguish a legitimate process from a hijacked one after code execution has already occurred. This is why IP-based trust and service-name trust become weak controls in post-exploitation conditions. The real control gap is process-level identity and authorization, not just subnet design.

Practical implication: govern internal trust at the process and workload level, not only at the network layer.

Why stealthy internal compromise is an identity governance problem

The campaign’s value to the attacker comes from silent reuse of valid-looking identity artefacts. Once forged tokens and escalated access are in play, movement into adjacent services can look like normal administration unless identity telemetry can distinguish intent, origin, and authorization boundary. In governance terms, this is a trust-boundary failure across application identity, service identity, and user impersonation. The attack works because the environment treats authenticated movement as inherently safe after the first compromise.

Practical implication: correlate authentication events, token issuance, and privileged service access as one control plane.

Threat narrative

Attacker objective: The objective is to turn an initial SharePoint exploit into trusted internal access that spreads across Microsoft services without triggering normal perimeter controls.

1. Entry began with exploitation of SharePoint CVE-2025-53770 on exposed servers linked to the ToolShell campaign.
2. Credential access followed when attackers planted web shells and extracted ASP.NET machine keys to forge authentication tokens.
3. Escalation and lateral movement occurred as the forged identity material enabled impersonation and pivoting into Teams, Exchange, and other Microsoft services.
4. Impact was full internal compromise with near-total stealth across connected enterprise services.

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.
• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

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

Process-level trust is now the real perimeter: The article shows that network boundaries no longer describe where compromise is contained. Once a hijacked process can mint or reuse authentication material, downstream services accept movement as legitimate. The implication is that identity governance has to extend to runtime behaviour, not stop at host or subnet controls.

Forged token reuse is a governance failure, not just an exploit detail: ASP.NET machine keys become dangerous because they collapse authentication and authorisation into artefacts attackers can replay. That means the issue is not only server compromise but also whether downstream services accept identity evidence that was never meant to survive compromise. Practitioners should treat token trust chains as a governed control surface.

Internal services cannot be trusted by default once an authenticated session is stolen: The article’s Teams and Exchange pivot is the important signal, not the initial SharePoint CVE alone. Modern lateral movement succeeds when service trust is broad, implicit, and hard to separate from valid administration. Practitioners need to re-evaluate how much privileged movement is still possible after a single application breach.

Identity blast radius is the right concept for this campaign: The attacker did not need to own every control point, only the trust relationships that let one compromise fan out into many. That is why least privilege at provisioning time is insufficient if the runtime trust graph remains wide open. The practitioner conclusion is to measure and shrink the reachable identity surface after compromise, not just before it.

OWASP-NHI exposure here is about overtrusted service material, not just secrets leakage: This case illustrates how machine keys, tokens, and application-level identity artefacts can outlive the security assumptions that created them. When those artefacts are accepted by other services, the environment has effectively outsourced trust to the attacker’s replay path. The lesson for the field is to govern non-human identity as a runtime trust problem.

From our research library:

• 82% of detections were malware-free, with attackers using valid credentials and trusted tools, according to CrowdStrike's 2026 Global Threat Report.

What this signals

Identity blast radius: The important governance question is not whether a perimeter blocked the first exploit, but how far one stolen identity artefact can travel before controls stop it. In a SharePoint compromise, the reachable set of services becomes the real exposure metric.

Perimeter controls still matter, but they no longer define the boundary of compromise once token forgery and process hijack are in play. Security teams should watch for environments where internal applications can authenticate other services with little or no additional proof of intent.

For practitioners

• Map internal trust paths from SharePoint to downstream services Identify which services accept SharePoint-derived authentication material, then reduce implicit trust between the originating application and adjacent Microsoft services. Focus on the actual replay paths, not only the server that was initially exploited.
• Review machine key handling and recovery procedures Inventory where ASP.NET machine keys are stored, who can access them, and how quickly they can be rotated after compromise. Treat key extraction as a blast-radius event, not a routine patching issue.
• Correlate token issuance with privileged service access Join authentication logs, token creation events, and privileged access records so forged or replayed sessions are easier to spot when lateral movement begins. This is especially important where internal services trust one another by default.
• Limit process-to-process trust inside the host Treat a compromised application process as an identity boundary failure and require explicit authorization for local and east-west communications. That reduces the chance that one hijacked workload can pivot quietly into more sensitive services.

Key takeaways

• SharePoint exploitation in this campaign mattered because it converted a server-side weakness into trusted internal movement.
• The attacker path combined web shells, machine keys, and forged tokens to reach adjacent Microsoft services.
• The control failure is broad internal trust, which means identity telemetry and process-level authorization now matter as much as perimeter defence.

Key terms

• Lateral Movement: A post-compromise technique where an attacker uses a compromised NHI to move through a network, accessing additional systems and escalating impact without triggering detection.
• 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.
• Session-level trust: A security model that evaluates whether a live session should continue to be trusted after authentication has already succeeded. In travel and hospitality, it uses behavior, device context, and transaction signals to decide whether access should remain valid as the user moves through booking, loyalty, and support workflows.

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 building or maturing an IAM programme, it is worth exploring.