SharePoint exploit exposure shows identity observability gaps in IAM

At a glance

What this is: This is an analysis of active exploitation of CVE-2025-53770 and how identity blind spots let attackers turn SharePoint access into persistence and lateral movement.

Why it matters: It matters because IAM, NHI, and PAM teams need visibility into exposed systems, reused secrets, and silent control bypasses before incidents become untraceable blast-radius events.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read AuthMind's analysis of the SharePoint CVE-2025-53770 exploitation path

Context

Microsoft SharePoint CVE-2025-53770 is being actively exploited to gain unauthenticated remote code execution on on-premises servers, then pivot into trust abuse using stolen machine keys. The primary identity security problem is not just the vulnerability itself, but the fact that many organisations cannot see how exposed systems, keys, and machine identities connect before an attacker uses them.

In identity programmes, this is a visibility and control-plane problem. Event-driven tools can miss the path because the attacker forges trusted payloads, bypasses normal authentication signals, or operates through unmanaged assets that never produce the right telemetry. That leaves IAM, PAM, and NHI teams looking at fragments instead of a usable access graph.

Key questions

Q: What breaks when an exposed application can mint trusted access without a normal login event?

A: The first break is visibility. If the application can validate or create trust after an exploit, the organisation loses the login event it normally relies on to trigger IAM, PAM, and SIEM workflows. That means compromise can progress through trusted context while controls remain silent, so teams must govern the application as part of the identity perimeter.

Q: Why do stolen machine keys create such a large identity security problem?

A: Because they let attackers impersonate trust, not just a user or service account. A stolen key can sign or validate content that downstream systems accept as legitimate, which allows persistence and lateral movement without obvious authentication anomalies. This is why application keys belong in the same governance conversation as privileged credentials.

Q: How can security teams tell whether identity controls are actually catching real attacker movement?

A: Look for evidence that controls still fire when access comes from exposed assets, unmanaged identities, or forged application context. If MFA, PAM, or policy enforcement only works in clean, expected login paths, the programme is failing in the conditions attackers use. Valid testing should prove whether traceability survives abnormal trust flows.

Q: What should teams do first after confirming active exploitation of a public-facing identity-linked server?

A: Contain the blast radius before focusing on clean-up. Isolate the exposed host, revoke or rotate any keys or tokens that may have been accessible, and reconstruct reachable assets using identity-aware telemetry. The priority is to stop trust from propagating further, then determine how far the attacker moved.

Technical breakdown

Unauthenticated remote code execution on exposed SharePoint servers

CVE-2025-53770 matters because it removes the normal identity checkpoint at ingress. An unauthenticated RCE bug lets an attacker execute code on a public-facing server without first presenting valid credentials, so the first meaningful boundary is the host itself, not an IAM control. In practice, this means perimeter exposure and application patch state become identity-security issues when the server sits in a trust path that leads to other assets. Once code runs, the attacker can interrogate local context, harvest configuration material, and prepare trust abuse without tripping standard login telemetry.

Practical implication: treat public-facing application exposure as an identity-control issue, not just a vulnerability-management task.

Stolen machine keys and forged trusted payloads

Machine keys are cryptographic material used to sign or validate application state, tokens, or session content. When attackers steal them, they can forge payloads that look legitimate to the application and downstream controls, which is why the article emphasises blending in with trusted activity. This is a classic identity-layer abuse pattern: the attacker is no longer impersonating a user at login, but impersonating trust itself inside the application workflow. That makes signature material, secret storage, and key scope part of the attack surface.

Practical implication: inventory and protect application signing material with the same rigor used for privileged credentials and tokens.

Identity observability and blast-radius mapping

Identity observability is the ability to reconstruct access paths across identity, infrastructure, and policy telemetry. The article’s central point is that detection alone is insufficient when attackers can exploit systems without clean authentication events or can bypass controls silently. Observability fills that gap by correlating who or what accessed a system, whether policy enforcement occurred, and how far the attacker could move after initial execution. For IAM and NHI teams, the technical challenge is not only seeing alerts, but building enough context to answer where the compromise went and what trust relationships were touched.

Practical implication: correlate identity, network, and application telemetry so lateral movement can be traced even when alerts are absent.

Threat narrative

Attacker objective: The attacker wants durable access and wider reach inside the environment while remaining indistinguishable from legitimate application activity.

1. Entry occurs through active exploitation of CVE-2025-53770 on an exposed on-premises SharePoint server, giving the attacker unauthenticated remote code execution without a normal login event.
2. Credential access follows when stolen machine keys are used to forge trusted payloads, allowing the attacker to operate with application-level legitimacy instead of noisy counterfeit credentials.
3. Impact comes from persistence, lateral movement, and blend-in activity that expand the blast radius while evading standard detection paths.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity observability is the control layer that failed here, not just patching discipline. The article shows that attackers could exploit an exposed system, forge trusted payloads, and move without generating the signals most teams expect. That means the operating assumption that identity events will reveal meaningful compromise is too weak for modern attack paths. Practitioners should treat visibility into access paths as a governance requirement, not a monitoring enhancement.

Machine keys are privileged identity material, even when they sit inside an application rather than an IAM vault. Once those keys are stolen, attackers inherit trust relationships that bypass ordinary authentication logic. This is why NHI governance must extend to application trust artifacts, not stop at service accounts and API tokens. The implication is that secret scope, storage, and rotation have to be governed as part of the identity perimeter.

Public-facing infrastructure becomes an identity problem the moment it can mint or validate trust on behalf of the organisation. SharePoint is not just a web application in this scenario. It is a trust boundary that can hand an attacker application legitimacy, then obscure the movement that follows. Teams that still separate vulnerability management from identity governance will continue to miss how compromise propagates through trusted systems.

Identity blind spots create identity blast radius debt. The article’s core warning is that organisations often discover the compromise only after trust has already been abused across multiple assets. That debt accumulates when unmanaged accounts, exposed systems, and silently bypassed controls are left outside the visibility model. Practitioners should view every unobserved trust path as pre-positioned blast radius.

Continuous identity observability should be treated as a response capability, not a reporting layer. The post makes clear that knowing what happened is less useful than knowing what controls were bypassed and what assets were reachable at the time. In NIST CSF terms, that is a detect-and-respond issue with governance implications, not a dashboard problem. Practitioners should build for traceability before the next exploit lands.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Another finding from our research shows that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• For a broader breach context, see The 52 NHI breaches Report for root-cause patterns across real incidents.

What this signals

Identity blast radius is becoming the more useful planning concept than isolated alert volume. Once attackers can exploit an exposed application, reuse trust material, and bypass ordinary authentication signals, the practical question is how much of the environment becomes reachable before containment starts. Teams that cannot trace that path in real time will keep discovering compromise after the attacker has already blended into normal access patterns.

The operational signal to watch is whether exposed systems, secret custody, and policy enforcement are managed as one control plane or three disconnected ones. When they are disconnected, remediation is slow, and the organisation inherits the same exposure pattern repeatedly. That is why the programme response should centre on traceability, not just stronger perimeter hardening.

If your identity team still treats machine keys as application detail, this topic should change your roadmap. The governance boundary now includes anything that can mint, sign, or validate trust on behalf of the enterprise, because that is where attackers turn compromise into movement. A partial view of access is no longer enough for response or prevention.

For practitioners

• Map exposed systems to identity trust paths Build an inventory of public-facing servers that can authenticate, sign, or validate downstream access. Include SharePoint, RDP, reverse proxies, and application servers where machine keys or session material could alter trust.
• Treat machine keys as privileged secrets Move application signing material into managed secret storage, restrict who can read it, and rotate it on a schedule tied to exposure risk rather than convenience. Separate key custody from app deployment where possible.
• Correlate identity, network, and application telemetry Use cross-layer telemetry to reconstruct access paths when authentication logs are absent or incomplete. The goal is to answer whether an exposed asset was reached, what trust was abused, and which internal systems became reachable next.
• Test for silent control bypasses Validate whether MFA, PAM, and policy enforcement still fire when access originates from unmanaged assets or forged application context. If the control does not produce an observable event, assume the control is only partially effective.

Key takeaways

• This exploit shows that public-facing application flaws become identity incidents when trust material can be stolen and reused.
• The evidence points to a familiar scale problem. Most organisations still struggle to see secrets, service accounts, and machine identities well enough to trace attacker movement.
• The limiting control is not another alert rule. It is identity observability that can map exposure, trust abuse, and blast radius in one path.

Key terms

• Identity observability: Identity observability is the ability to reconstruct how access actually works across identities, applications, and infrastructure. It goes beyond authentication logs by correlating policy enforcement, trust material, and movement paths so teams can see when access is legitimate, abnormal, or silently bypassed.
• 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.
• Identity blast radius: Identity blast radius is the set of assets, trust relationships, and control paths that become reachable after an identity-linked compromise. It is broader than a single breached account because it includes the systems that trust the compromised identity material and the paths that were never visibly constrained.

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 AuthMind: Understanding Exposure, Tracing Movement, and Mapping the Blast Radius. Read the original.