Attackers are actively chaining a deserialization vulnerability in on-premises SharePoint Server with an authentication bypass to gain remote code execution without credentials—then stealing the server's cryptographic keys to embed persistent backdoors. In one observed case, the intrusion culminated in a failed ransomware deployment attempt. The four critical CVEs driving these attacks—CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, and CVE-2025-53771—have been exploited in the wild since at least mid-July 2025. Government agencies, healthcare, higher education, and large enterprises are all in the crosshairs, and any internet-facing SharePoint server should be assumed compromised until proven otherwise.

The central weakness is unsafe deserialization in SharePoint's handling of serialized objects, a classic and recurring vulnerability class. Combined with a spoofing flaw that lets attackers bypass request-level validation, the chain opens a direct path to code execution under the IIS worker process (w3wp.exe). Once inside, threat actors drop web shells—most commonly a file named spinstall0.aspx—that exfiltrate the ASP.NET machineKey values from web.config. With those keys in hand, they can forge signed ViewState payloads that SharePoint will trust even after the initial vulnerability is patched. "Patching alone is insufficient to fully evict the threat," warns the Unit 42 threat intelligence team at Palo Alto Networks.

Why deserialization in SharePoint is a recipe for disaster

Deserialization is the process of turning a stream of bytes back into an object. When done without strict validation, an attacker can embed code in that object that runs unexpectedly during reconstruction. SharePoint's attack surface is particularly large because it often runs with high-privilege application pool accounts, stores sensitive documents, and integrates deeply with Office, Teams, OneDrive, and Outlook. Many organizations still self-host SharePoint for regulatory or integration reasons, and those instances frequently sit behind insufficient network protections.

The ToolShell exploit chain: from spoofed POST to machineKey theft

The attack chain, named "ToolShell" by the researcher who first demonstrated it at Pwn2Own Berlin, consists of two linked stages. First, an attacker sends a crafted POST request to /_layouts/15/ToolPane.aspx?DisplayMode=Edit with a Referer header pointing to /_layouts/SignOut.aspx. This bypasses server-side validation, allowing file upload into SharePoint's _layouts directory. Then, the attacker delivers a serialized payload—often an encoded .aspx file or a malicious ViewState—that triggers deserialization and writes a web shell to disk.

Unit 42 observed three exploitation variations in the wild. In Variation 1, a PowerShell command scanned for web.config files and exfiltrated their contents to debug_dev.js. Variation 2 dropped the now-infamous spinstall0.aspx web shell under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\, then decoded a Base64-encoded command to steal ValidationKey, DecryptionKey, and CompatibilityMode. Variation 3 used the same technique but targeted SharePoint 2013-style paths (15 instead of 16). The web shell’s sole purpose is to pipe-delimit those cryptographic values and send them to the attacker.

A botched ransomware attempt and evolving attacker tradecraft

On July 27, 2025, a failed exploitation led to the discovery of 4L4MD4R ransomware, a variant of the open-source Mauri870 ransomware. The attack chain downloaded a UPX-packed GoLang executable from hxxps://ice.theinnovationfactory[.]it/static/4l4md4r.exe, which decrypts an AES payload in memory and encrypts files, dropping a ransom note demanding 0.005 BTC. The same PowerShell command also attempted to disable real-time monitoring and bypass certificate validation.

Unit 42 internally tracks a threat cluster as CL-CRI-1040, which overlaps with Microsoft’s Storm-2603. This group first probed for vulnerable servers using recon requests from SPN exit nodes, then exploited CVE-2025-53770 with a static targeting list. Over just a few days in mid-July, they pivoted from delivering custom .NET modules (qlj22mpc, bjcloiyq) to web shell payloads, then back to .NET modules after public blogs highlighted the web shell. "The actors show an ability to adjust their tactics and techniques during an operation," Unit 42 notes.

Indicators of compromise every admin must hunt for

Defenders should immediately hunt for these forensic fingerprints:

  • Web shell files: spinstall0.aspx or similar unknown .aspx files in the following directories:
  • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\
  • C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\
  • HTTP traffic: POST requests to /_layouts/15/ToolPane.aspx?DisplayMode=Edit with a Referer of /_layouts/SignOut.aspx.
  • Process behavior: w3wp.exe spawning encoded PowerShell or unusual cmd.exe/powershell child processes.
  • Suspicious IPs: Exploitation sources such as 96.9.125[.]147, 107.191.58[.]76, 104.238.159[.]149, and many others listed in Unit 42’s IOC table.
  • Artifact hashes: SHA256 for spinstall0.aspx (92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514), .NET modules, and the ransomware sample (33067028e35982c7b9fdcfe25eb4029463542451fdff454007832cf953feaf1e).

Microsoft and CISA have published hunting queries for Defender, Splunk, Elastic, and other SIEM tools. Unit 42 also provides XQL queries for Cortex XDR to detect DotNet telemetry referencing ToolPane.aspx, file writes in the layouts folder, and encoded PowerShell commands spawned from w3wp.

The mitigation trifecta: patch, rotate machineKeys, and harden

  1. Patch first: Microsoft released emergency updates for SharePoint Server Subscription Edition, 2019, and 2016. The update for CVE-2025-53770 replaces the earlier fix for CVE-2025-49704 with more robust protections; similarly, the CVE-2025-53771 update supersedes CVE-2025-49706. Confirm the specific KB articles for your environment.
  2. Rotate machineKeys: This step is mandatory. Even if you patch, attackers may already hold your ValidationKey and DecryptionKey, allowing them to craft signed ViewState payloads that survive patch application. Use the Set-SPMachineKey and Update-SPMachineKey cmdlets or the Central Administration Machine Key Rotation job, then perform an iisreset across all SharePoint hosts. Microsoft’s guidance: patch, rotate keys, restart IIS.
  3. Enable AMSI and Defender AV: The Antimalware Scan Interface (AMSI) integration for SharePoint can intercept script-based and memory-based payloads during processing. Run Defender Antivirus in Full Mode on SharePoint servers. If AMSI cannot be enabled immediately, isolate the server from direct internet exposure.
  4. Hunt for and remove web shells: Search layouts directories for spinstall0.aspx and other anomalous files. If found, capture forensic artifacts, isolate the host, and follow a full incident response playbook.
  5. Harden network exposure: Deploy WAF rules to block requests to /_layouts/15/ToolPane.aspx?DisplayMode=Edit, constrain Referer headers, and filter base64-heavy POST bodies. Use IP allow-lists, VPN gateways, or reverse proxies to restrict access.
  6. Increase monitoring and logging: Enable comprehensive IIS and SharePoint logging, correlate the IOCs above, and subscribe to trusted threat intelligence feeds.

Why patching alone isn’t enough

Several security vendors and Microsoft explicitly warn that a patch without a machineKey rotation leaves organizations vulnerable. The theft of machineKey material is a powerful persistence mechanism. "Attackers who extracted machineKey values can generate valid signed payloads even after code fixes are applied," the guidance states. Organizations should assume breach if any indicators are found, then rotate credentials, service accounts, and certificates across the environment.

Outlook and residual risk

The SharePoint exploitation campaign of July 2025 is a textbook example of chained application-layer flaws leading to full server compromise at enterprise scale. Rapid publication of guidance and IOCs by Microsoft, CISA, and vendors like Palo Alto Networks gave defenders a head start, but operational challenges remain: legacy SharePoint versions (2010, 2013) cannot receive patches and must be isolated or retired; machineKey rotation in clustered farms requires careful coordination; and sophisticated memory-only attacks can evade file-based detection.

For IT admins, the priority is clear: inventory every on-prem SharePoint instance, apply emergency updates, rotate machineKeys, and hunt for signs of compromise. Assume any internet-facing server is already breached until a thorough incident response assessment proves otherwise. With the exploitation still active and proof-of-concept code publicly available, every hour of delay increases the risk of ransomware, data exfiltration, and lateral movement into the wider Microsoft ecosystem.