Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

SharePoint zero-day exploitation: what IAM teams need to do now


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9016
Topic starter  

TL;DR: CVE-2025-53770 is actively exploited against on-premises SharePoint through unauthenticated code execution and machine-key theft, allowing attackers to persist even after patching, according to Abnormal AI. Patching alone does not remove forged-token footholds, so identity teams have to treat cryptographic material, session state, and exposure paths as part of the incident surface.

NHIMG editorial — based on content published by Abnormal AI covering CVE-2025-53770 in on-prem SharePoint: ToolShell exploitation, machine-key theft, and post-patch persistence

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • Rotate all server-side trust material Rotate machine keys, auth certificates, and any session-signing material on affected SharePoint servers after confirming exposure.
  • Hunt for forged-token activity Review logs for unusual .aspx files, suspicious logins, and token patterns that do not match normal user behaviour.
  • 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.

What's in the full article

Abnormal AI's full research covers the operational detail this post intentionally leaves for the source:

  • The specific exploit sequence used against ToolPane.aspx and how the deserialization flaw was weaponised
  • Indicators of compromise that help distinguish active persistence from a patched but fully remediated server
  • The incident-response sequencing behind key rotation, certificate retirement, and token invalidation
  • Context on victim sectors and the broader implications for hybrid collaboration environments

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

SharePoint zero-day exploitation: what IAM teams need to do now?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8472
 

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.

A few things that frame the scale:

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

A question worth separating out:

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.

👉 Read our full editorial: SharePoint zero-day exploitation exposes machine key persistence risk



   
ReplyQuote
Share: