SharePoint zero-day exploitation exposes machine key persistence risk

At a glance

What this is: This is an analysis of an actively exploited SharePoint zero-day that turns machine-key theft into durable post-patch persistence.

Why it matters: It matters because on-prem identity-adjacent infrastructure can remain compromised after patching, which changes how IAM, PAM, and security teams handle containment, rotation, and trust recovery.

By the numbers:

• 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.

👉 Read Abnormal AI's analysis of CVE-2025-53770 and SharePoint persistence

Context

On-premises SharePoint is part of the identity trust boundary because it issues and validates authenticated access paths, even when it is not itself the system of record for identities. In this case, the problem is not only remote code execution, but the ability to steal machine keys and forge auth tokens that survive normal patch cycles.

That distinction matters for IAM and security operations. Once cryptographic material is exposed, patching the application removes one exploit path but does not automatically invalidate the attacker’s ability to impersonate trusted sessions or maintain access.

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 do on-prem collaboration servers create identity recovery problems after exploitation?

A: On-prem collaboration servers often mint or validate authentication material locally, so compromise can affect both application integrity and trust primitives. That means incident responders have to recover keys, certificates, and sessions, not just close the vulnerability. The recovery burden is higher because trust may persist long after the original exploit path is patched.

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: Who is accountable when machine-key theft turns a SharePoint breach into persistence?

A: Accountability usually spans application owners, infrastructure teams, and identity governance leaders because the compromise crosses software, cryptography, and access control. The key question is whether anyone owns the recovery steps that revoke trust after compromise. NIST Cybersecurity Framework and OWASP NHI both point to explicit ownership of identity-critical assets.

Technical breakdown

ToolPane.aspx deserialization and unauthenticated code execution

The exploit chain begins with a deserialization flaw in a legacy SharePoint endpoint, ToolPane.aspx. Deserialization bugs are dangerous because untrusted input is reconstructed into executable objects or logic, which can let an attacker run code before normal authorization checks meaningfully apply. In this case, the flaw is exploitable without authentication, so the attacker does not need a valid user account or prior access. That makes the endpoint a direct entry point into the server process and the surrounding trust environment.

Practical implication: isolate exposed on-prem SharePoint instances and treat any internet-reachable endpoint as part of the attack surface.

Machine key theft and forged authentication tokens

After code execution, attackers can steal cryptographic machine keys and related authentication material. Those keys are used by the application to sign or validate tokens, which means possession of the key can let an attacker mint credentials that look legitimate to the platform. This is a governance problem as much as a technical one, because the trust anchor is no longer the user’s identity alone. The attacker now controls the proof mechanism that the application relies on to accept sessions and requests.

Practical implication: rotate machine keys, auth certificates, and session tokens as part of containment, not just patching.

Post-patch persistence through token forgery

The persistence risk comes from the fact that patching the vulnerable code path does not invalidate already stolen keys or forged tokens. An attacker can retain access by continuing to present credentials that the application still trusts, even after the original flaw is fixed. That creates a split between vulnerability remediation and access remediation. In practice, the compromise lasts until the cryptographic trust chain is broken, logs are hunted, and any compromised tokens or keys are retired from use.

Practical implication: pair patch deployment with forensic review and credential invalidation to eliminate attacker footholds.

Threat narrative

Attacker objective: The attacker objective is durable access to on-prem SharePoint environments that survives remediation and can be used for document theft, lateral movement, and continued control.

1. Entry occurs through CVE-2025-53770 in ToolPane.aspx, where unauthenticated deserialization enables arbitrary code execution on vulnerable on-premises SharePoint servers.
2. Credential access follows when attackers steal SharePoint machine keys and related auth material, allowing them to forge tokens that the application will trust.
3. Impact persists after patching because forged authentication tokens continue to authorize access, leaving the environment exposed to long-term misuse and follow-on intrusion.

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

Patch management fails when the trust anchor is already compromised. This breach worked because remediation was treated as a code problem even though the attacker had stolen the machine keys that validated trust. Once signing material is exposed, the application can continue to accept attacker-authored sessions after the vulnerable code path is fixed. The implication is that containment must include identity and cryptographic trust recovery, not just software patching.

Machine-key compromise is a governance failure, not only an exploitation detail. The operational assumption that a server patch resets the risk state was false here because the attacker kept the ability to forge auth tokens. That means the true failure mode is persistent trust after compromise, a condition that falls directly under OWASP-NHI and ZT-NIST-207 thinking. Practitioners should treat server-side signing keys as identity-critical assets whose exposure changes the meaning of every downstream authentication event.

Identity blast radius expands when collaboration systems sit inside hybrid trust boundaries. On-prem SharePoint often persists because of legacy integration, compliance, or admin preference, but that also means it inherits the full burden of key rotation, token invalidation, and exposure management. The scale of confirmed victims across government, higher education, energy, and telecoms suggests this is not an isolated misconfiguration. Security teams need to map which collaboration platforms can still mint trusted identity artifacts and why.

Forged-token persistence is the failure mode this incident makes explicit. The control gap is not simply delayed patching, but the absence of a response model that assumes attacker possession of signing material. That is the premise collapse: a system cannot be considered recovered while it still trusts secrets the attacker may already control. The implication is that recovery criteria have to include key retirement and token revalidation.

This incident also shows why identity and application teams must share ownership of server-side secrets. SharePoint machine keys, auth certificates, and session tokens sit at the boundary between infrastructure security and identity governance. When those materials are compromised, access reviews and user-focused controls cannot prove safety because the attacker is no longer using the human’s or service account’s original credentials. Practitioners should align incident response with identity control owners before the next server-side breach.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 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 related identity governance context, read Ultimate Guide to NHIs , Why NHI Security Matters Now for the lifecycle controls that determine whether compromise becomes persistence.

What this signals

Forged-token persistence is now a programme-level assumption test: if a platform can mint or validate trust locally, patching will not end the incident unless recovery also retires the underlying keys. Teams running on-prem collaboration systems should map which assets can still create authentication artefacts and where those artefacts outlive remediation.

The practical shift is toward recovery gates that sit after emergency patching and before business re-entry. That means explicit validation of key retirement, token invalidation, and forensic closure, backed by identity and platform owners who can sign off on trust restoration.

The scale of secrets exposure across modern environments shows why this pattern is not confined to SharePoint. As credential leakage rises, the boundary between application security and identity governance keeps narrowing, and organisations that still treat them separately will miss the persistence layer entirely.

For practitioners

• Rotate all server-side trust material Rotate machine keys, auth certificates, and any session-signing material on affected SharePoint servers after confirming exposure. Treat key rotation as the step that breaks attacker persistence, not as a housekeeping task.
• Hunt for forged-token activity Review logs for unusual .aspx files, suspicious logins, and token patterns that do not match normal user behaviour. Correlate EDR, AMSI, Defender, and application logs before declaring the environment clean.
• Segment exposed on-prem collaboration servers Remove or tightly restrict public access to on-prem SharePoint through VPN, proxy, or zero trust controls, and keep high-risk instances isolated until trust is rebuilt.
• Separate patching from recovery sign-off Require a second recovery gate after emergency patching that verifies key retirement, token invalidation, and forensic closure before business owners resume trust in the platform.

Key takeaways

• This breach shows that server compromise becomes an identity problem once attackers can steal signing material and keep forging trusted access.
• The evidence points to broad, coordinated targeting across public-sector and enterprise environments, which raises the likelihood of repeatable post-exploit persistence playbooks.
• Patch, then revoke trust: machine keys, auth certificates, and session tokens have to be retired before an on-prem SharePoint environment can be considered recovered.

Key terms

• Machine Key: A machine key is a cryptographic secret used by a server application to sign or validate authentication material. In SharePoint and similar systems, compromise of this key can let an attacker forge trusted tokens and preserve access after the original vulnerability has been patched.
• Forged Authentication Token: A forged authentication token is a credential artifact created or altered by an attacker to impersonate a legitimate session. It is especially dangerous when a server still trusts locally generated signing material, because the token can survive normal remediation unless the underlying key is revoked.
• 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.

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 Abnormal AI covering CVE-2025-53770 in on-prem SharePoint: ToolShell exploitation, machine-key theft, and post-patch persistence. Read the original.