In July 2025, a widely exploited zero-day vulnerability, CVE-2025-53770 & 53771, named ToolShell, hit on-premises Microsoft SharePoint Server systems, triggering a large-scale compromise.
The ToolShell exploit gave attackers unauthenticated remote code execution in on‑premises SharePoint by chaining a spoofed Referer vulnerability with an insecure deserialization bug. Once inside, attackers deployed web shells to extract the server’s machine keys, specifically the ValidationKey and DecryptionKey, from configuration files or memory. With those keys, they forged trusted ASP.NET tokens, bypassed authentication controls, and maintained persistent access even after the system was patched.
We can see that static secrets embedded in enterprise systems can create permanent trust relationships that can’t be easily revoked. Once leaked, they turn into master keys for attackers.
Dissecting The ToolShell Exploit
ToolShell exploited a spoofing flaw in SharePoint’s request‑handling logic that lets attackers bypass authentication using a forged REFERER header. A hacker manipulates the REFERER field in an HTTPS request to make it look like it appeared from a trusted workflow. Here’s how the exploit happened in real-time:
Initial Entry (Authentication Bypass – CVE-2025-53771)
The attacker sends a crafted POST request to (/_layouts/15/ToolPane.aspx?DisplayMode=Edit) with a forged Referer header (/_layouts/SignOut.aspx). This header spoofing flaw tricks SharePoint into treating the request authentically, bypassing standard access controls.
Delivering The Payload (Remote Code Execution – CVE-2025-53770)
The attacker exploits an insecure deserialization vulnerability (CVE-2025-53770) in ToolPane.aspx. By submitting a malicious payload in the POST body, they force SharePoint to deserialize attacker‑controlled data without validation, resulting in remote code execution.
This step is used to deploy a stealthy ASPX web shell (e.g., spinstall0.aspx) in a trusted directory such as:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\
The web shell grants ongoing remote access.
Key Extraction
The attacker dumps critical cryptographic material like the ValidationKey and DecryptionKey from SharePoint’s machineKey configuration with help from the stealthy webshell.These keys sign and encrypt ASP.NET ViewState data, effectively serving as SharePoint’s trust anchors.
Remote Code Execution
Now, the attacker uses tools like ysoserial to craft malicious __VIEWSTATE cryptographically signed payloads. Because SharePoint trusts the signatures, it deserializes and executes the attacker‑controlled payloads. This allows unauthenticated remote code execution, even post-patch, cementing full control over the server, turning the initial compromise into a permanent backdoor until the keys are rotated.
Real-Time Examples: The Broader Pattern of Static Trust
The static trust model exploited in ToolShell isn’t unique to SharePoint, but a recurring design flaw across enterprise infrastructure.
For example, HP Aruba networking appliances contain static cryptographic keys in their firmware, meaning every device of that model shares the same trust secret. VPNs and identity bridges often rely on long‑lived shared secrets or embedded certificates for machine‑to‑machine communication, with no automated rotation or revocation mechanism.
Similarly, many internal tools and service APIs continue to treat possession of a static API key or machine credential as sufficient proof of trust, ignoring context or device posture. In these cases, compromise of a single secret can provide attackers with wide‑ranging access across environments, with no reliable way to distinguish legitimate use from malicious impersonation.
The Architecture Lesson: Static Trust = Permanent Compromise
The real architectural flaw in ToolShell wasn’t simply that SharePoint used machine keys stored in web.config, but that the platform relied on a static trust model. It relied on a single machine key that was used across all the SharePoint on-premise servers and applications.
Organizations rotate these keys as part of patch cycles and Microsoft’s own post-ToolShell advisories. In spite of key rotations, an attacker can compromise the active key; they can forge valid, signed payloads and operate with full privileges until the next rotation occurs.
The fragility comes from trusting static keys alone rather than layered verification. SharePoint offers no identity-based verification for machine key usage, meaning maliciously crafted payloads are indistinguishable from legitimate ones. The problem is compounded by the absence of additional posture checks, identity validation, or contextual risk assessment before accepting a signed payload.
While NIST SP 800-57 Part 1 emphasizes timely key rotation, revocation, and lifecycle management, its guidance also supports architectures where the compromise of a single key does not grant indefinite or unrestricted access.. Static trust designs do not use identity, integrity, and authorization. Instead, they use a single key, which, when compromised, can turn into a master key for the entire environment.
This is exactly what happened in the ToolShell exploit.. The attackers exfiltrated the key to forge cryptographically valid ViewState payloads, bypass authentication, and execute code across the entire system without triggering alarms, even after the underlying vulnerabilities were patched.
How to Secure Hybrid and Legacy Environments Against Static Key Risks
You can begin securing legacy infrastructure by first identifying static keys as high-risk trust anchors. In hybrid environments where legacy systems can’t be replaced immediately, focus on mitigation efforts, increase visibility into their use, and ensure they can be revoked quickly:
Here’s how static keys can move from being permanent liabilities into manageable, temporary credentials without disrupting critical services in the process:
- Rotate machine keys immediately after patching, especially in systems like SharePoint, where leaked keys may still be trusted post-exploit. Use PowerShell or Central Admin workflows to consistently apply updated secrets across the farm. You can use a Hardware Security Module (HSM) to store machine and cryptographic keys for maximum security. HSMs provide tamper-resistant storage, enforce strict access controls, and enable secure key generation and lifecycle management.
- Enable runtime threat detection by integrating tools like AMSI and Microsoft Defender to scan for malicious deserialization, web shell execution, or abnormal process behaviors in real time. In the context of machineKey abuse, look out for suspicious ViewState deserialization, unusual processes launched by IIS, and signs of credential dumping, as they are signs of stolen cryptographic keys being used to bypass security controls.
- Enforce network segmentation to contain compromise by automatically segmenting sensitive systems like SharePoint; a server breach can be isolated and prevented from spreading laterally across the broader network. Segmentation ensures that even if attackers gain a foothold, their ability to move into adjacent workloads or data stores is sharply limited.
- For private SharePoint environments, enforcing certificate-based authentication on VPNs provides a strong access boundary. This ensures that only verified devices and users can reach the server in the first place, reducing the attack surface and strengthening overall identity control for service accounts and end users.
To combat a potential threat, you should ask yourself, “if a single server or service is compromised, can we revoke its access without disrupting the rest of our infrastructure?” Your ability to do so determines your actual resilience.
Enabling Networks For Context-Based Access Control
With changing network environments and most of the applications and infrastructure on the cloud, trust should be earned continuously, rather than being a one-time event. Static machine keys should be replaced with short‑lived certificates with a 90-day expiry (ideally), reducing exposure windows and removing reliance on manual processes. This is a widely adopted security baseline, but modern identity platforms can issue certificates with lifespans measured in hours or even minutes, drastically shrinking the window an attacker has to exploit a compromised credential. Context-aware access should grant credentials only to devices with strict compliance and encryption requirements.
Network solutions should be able to use device state, user identity, and session risk, enforcing granular, adaptive policies instead of relying on static keys. The implementation of Mutual TLS (mTLS) ensures client-server authentication. In mTLS, the client and the server present their certificates from a trusted root authority to each other, ensuring only genuine devices and endpoints connect to the server.
When combined with dynamic, short-lived certificates, mTLS provides strong, traceable, and instantly revocable machine identities that align with modern security principles. Dynamically issued, role‑based identities provide traceability and immediate revocation capabilities that align with NIST recommendations.
Start Your Transition From Static to Dynamic Trust
The SharePoint ToolShell exploit was a structural failure rooted in static trust. It exposed how vulnerable enterprise systems become when machine identity relies on long-lived secrets that can’t be revoked or monitored.
Start by identifying where machine keys, shared credentials, and embedded secrets exist across your infrastructure. Replace long-lived secrets with short-lived, automatically rotated certificates tied to device identity, posture, and expiration policies. As an organization, you can use a managed Public Key Infrastructure (PKI) to handle the entire lifecycle of machine identities without manual intervention. Finally, integrate with MDM, EDR, and identity providers to ensure only healthy, managed devices can request and maintain trust, and revoke it instantly when risk changes.
Anusha Harish