SharePoint zero-day exploitation exposes machine key persistence risk

At a glance

What this is: This is an analysis of active exploitation of a SharePoint zero-day that turns machine-key theft into post-patch persistence.

Why it matters: It matters because identity and access teams need to treat cryptographic material, token integrity, and exposure paths as part of incident response, not just software patching.

Context

CVE-2025-53770 affects on-premises SharePoint deployments through a deserialization flaw in ToolPane.aspx that allows unauthenticated remote code execution. The article’s core governance problem is that a patch can remove the initial exploit path while leaving stolen machine keys and forged authentication tokens in place.

For IAM and NHI programmes, the lesson is that SharePoint server compromise is not only an application vulnerability event. It becomes an identity persistence problem when attackers can mint trusted tokens from compromised cryptographic material, especially in hybrid environments where on-prem systems coexist with Microsoft 365.

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 does compromised SharePoint infrastructure create an identity persistence problem?

A: Because the attacker is no longer relying only on the original exploit. Once machine keys or signing material are stolen, they can mint tokens that the platform accepts as legitimate, which turns application compromise into durable access. That is why identity teams must treat cryptographic artefacts as part of the incident surface.

Q: How do security teams know whether SharePoint compromise is still active after patching?

A: They should look for signs that the attacker still controls identity material, such as forged tokens, strange server-side files, suspicious logins, or repeated access from unexpected sources. Patch status alone is not enough. If the environment still trusts compromised signing material, the intrusion is not over.

Q: What should teams do when SharePoint and cloud collaboration services are mixed in one environment?

A: Separate the exposure models clearly. Microsoft 365 and SharePoint Online are not affected by this flaw, but on-premises SharePoint can still be vulnerable and can become a local identity compromise source. Teams should document which systems are cloud-hosted, which are self-managed, and which trust artefacts each one owns.

Technical breakdown

Unauthenticated code execution in ToolPane.aspx

The exploit path begins with a deserialization flaw in a legacy SharePoint endpoint, ToolPane.aspx. Deserialization bugs are dangerous because attacker-supplied objects can be interpreted as executable logic rather than inert data, which turns a request into code execution without authentication. In this case, the zero-day gives the attacker a foothold before any identity control is consulted. That matters because perimeter trust, user authentication, and session controls never get a chance to intervene once the endpoint itself is processing hostile input as code.

Practical implication: treat the endpoint as compromised at the application layer before you focus on access control cleanup.

Machine-key theft and forged authentication tokens

After execution, attackers steal machine keys and related cryptographic material used to sign or validate SharePoint authentication artefacts. Once those keys are exposed, the attacker no longer needs the original exploit path to stay active. They can forge auth tokens that appear legitimate to the platform, which is why the compromise persists after patching. In identity terms, the trust anchor itself has been abused. This is a classic boundary failure between application compromise and identity assurance, where cryptographic trust becomes the attacker’s persistence mechanism.

Practical implication: rotate machine keys and authentication certificates as part of containment, not as a later hardening step.

Why patching alone does not remove persistence

Patching closes the vulnerable code path, but it does not invalidate already stolen tokens, session state, or signing material. That is why remediation must address both the exploit and the artefacts left behind by the attacker. In hybrid deployments, this distinction is especially important because teams may wrongly assume a fixed patch window equals restored trust. The article shows that once cryptographic material is harvested, the incident changes from vulnerability management to identity recovery, with token revocation and forensic review becoming mandatory.

Practical implication: pair emergency patching with token invalidation, key rotation, and log review for forged or anomalous sign-in activity.

Threat narrative

Attacker objective: The objective is durable access to on-prem SharePoint environments that survives patching and supports continued compromise of data and identity trust.

1. Entry occurs through CVE-2025-53770 in ToolPane.aspx, where unauthenticated deserialization enables remote code execution on vulnerable on-premises SharePoint servers.
2. Credential access follows when attackers steal machine keys and related cryptographic material used to sign or validate authentication artefacts.
3. Escalation to persistence happens when forged tokens are used to remain trusted even after patches remove the original exploit path.
4. Impact includes continued control of compromised environments, stolen documents, and potential spillover into phishing or lateral movement.

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.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity trust has become the persistence layer: This breach worked because SharePoint machine keys were not just credentials, they were trust anchors. Once attackers could forge authentication tokens, patching the vulnerable endpoint no longer removed the attacker’s presence. The practitioner lesson is that incident scope must expand from vulnerable software to the signing material that makes sessions believable.

Patch-first thinking is incomplete when cryptographic artefacts are already exposed: Security programmes often treat remediation as a software maintenance task, but this attack turns it into an identity recovery exercise. Patching closes the door, yet forged tokens can keep walking through it if the keys are still valid. That is why the control failure is not just delayed patching, but failure to revoke compromised trust material.

Machine-key persistence risk should be treated as a named governance concept: The real issue is not simply “post-patch compromise” but identity persistence through stolen cryptographic material. That concept matters because it forces teams to correlate application compromise, token validity, and offboarding of trust artefacts in one incident model. Practitioners should stop viewing application recovery and identity recovery as separate workstreams.

Hybrid SharePoint environments expose a split-brain trust problem: Many organisations still run on-premises SharePoint for control or legacy integration while assuming cloud service boundaries reduce risk. This case shows that the security model diverges sharply once on-prem identity material can be stolen and replayed locally. The implication is that hybrid collaboration platforms need governance that follows the trust artefact, not the deployment label.

Nation-state style targeting is consistent with trust-theft tradecraft: The scale of confirmed victims, the precision of the exploit, and the use of persistence mechanisms all point to an actor looking for durable access rather than one-time disruption. That shifts the governance priority from routine vulnerability closure to identity-centric containment and verification. Security teams should assume the attacker is interested in long-term authentication abuse, not just code execution.

What this signals

Machine-key persistence risk: This incident shows why application patching and identity recovery cannot be managed as separate queues. Once an attacker can forge tokens from stolen signing material, the trust boundary has already moved from the endpoint to the identity layer, and response has to follow that shift.

Hybrid collaboration environments need clearer trust ownership. If teams cannot quickly distinguish between cloud-hosted services and self-managed on-prem systems, they will misread exposure and underreact to the systems that still control their own signing material.

For practitioners

• Rotate SharePoint machine keys and auth certificates Treat machine-key rotation as mandatory containment when on-prem SharePoint compromise is suspected, because forged tokens can survive the patch cycle.
• Invalidate session tokens and authentication artefacts Force revocation of any tokens that could have been signed by compromised keys, and confirm that old sessions cannot be replayed against the environment.
• Hunt for web shells and forged-token activity Review SharePoint logs, EDR telemetry, and unusual .aspx files for signs that the attacker established persistence before or after patching.
• Restrict external exposure of on-prem SharePoint Remove or tightly control internet-facing access paths for affected servers, and place them behind stronger network and zero trust access controls where possible.
• Separate cloud and on-prem blast radius assumptions Document which collaboration services are truly cloud-hosted and which remain on-prem so responders do not confuse Microsoft 365 exposure with local SharePoint compromise.

Key takeaways

• This breach shows that SharePoint compromise becomes an identity problem when machine keys and token-signing material are stolen.
• The article says confirmed intrusions already span government and enterprise organisations, which indicates active exploitation rather than a theoretical flaw.
• The decisive control is not patching alone but revoking forged-token capability through key rotation, token invalidation, and focused hunting.

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 Forging: Token forging is the creation of authentication artefacts that a system accepts as legitimate because the underlying signing or validation secret has been stolen or abused. In identity incidents, it converts a one-time exploit into persistent access and complicates patch-based recovery.
• Post-Patch Persistence: Post-patch persistence is the state where an attacker remains in an environment after the vulnerable software has been fixed. It usually means the compromise extended beyond the bug itself into keys, tokens, accounts, or other trust material that still needs to be revoked.
• On-Premises SharePoint: On-premises SharePoint is a self-managed deployment of Microsoft SharePoint running within an organisation’s own infrastructure. It differs from SharePoint Online because the organisation retains responsibility for patching, configuration, and the cryptographic material that underpins local trust.

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.