ToolShell — SharePoint Unauthenticated RCE
via Deserialization Chain

01 Overview

On 19–20 July 2025, Microsoft and CISA jointly confirmed active zero-day exploitation of CVE-2025-53770, a critical unauthenticated remote code execution vulnerability in on-premises Microsoft SharePoint Server. The vulnerability was being exploited in the wild before Microsoft had even published an advisory — a textbook zero-day scenario.

The flaw is the second iteration of what researchers call the "ToolShell" exploit chain — named after ToolPane.aspx, a SharePoint management endpoint that serves as the attack entry point. ToolShell was originally demonstrated at the Pwn2Own Berlin competition in May 2025 by Viettel Cyber Security, which chained two SharePoint vulnerabilities (CVE-2025-49704 and CVE-2025-49706) to achieve unauthenticated RCE. Microsoft patched those in their July 2025 Patch Tuesday rollout — but within ten days, attackers had found a bypass, and CVE-2025-53770 was born.

In this writeup, Grey Shield's research team breaks down the complete two-bug exploit chain — the authentication bypass mechanism, the deserialization flaw, web shell deployment, observed attacker post-exploitation behavior, detection rules you can deploy today, and the exact remediation steps to take right now.

02 Background: From Pwn2Own to Mass Exploitation

To understand CVE-2025-53770, it helps to understand its predecessor. In May 2025 at Pwn2Own Berlin, researchers from Viettel Cyber Security chained two SharePoint vulnerabilities for the first time and named the chain ToolShell:

• CVE-2025-49706 — A spoofing/authentication bypass vulnerability in SharePoint's request handling. By forging the Referer header to point to /_layouts/SignOut.aspx, attackers could make SharePoint treat requests as coming from a legitimate, authenticated session.
• CVE-2025-49704 — An insecure deserialization vulnerability. Once an unauthenticated request was accepted, SharePoint would deserialize attacker-controlled data, leading to arbitrary code execution.

Microsoft patched both vulnerabilities on 8 July 2025 as part of the July Patch Tuesday release. The security community collectively exhaled — briefly. Within ten days, Eye Security observed real-world compromises using fresh bypasses of the two patched bugs. Microsoft assigned the bypass variants new CVE identifiers: CVE-2025-53770 (the deserialization bypass) and CVE-2025-53771 (the auth bypass variant).

03 Affected Versions

CVE-2025-53770 exclusively affects on-premises SharePoint Server deployments. SharePoint Online (Microsoft 365) is completely unaffected — the vulnerability is in the on-premises codebase. EOL versions (SharePoint 2010 and 2013) are also vulnerable, but Microsoft has not released patches for them.

04 Technical Deep Dive: The Two-Bug Chain

Bug 1 — Authentication Bypass via Referer Header Forgery (CVE-2025-53771)

The authentication bypass exploits a logic flaw in how SharePoint validates the origin of requests made to privileged management endpoints. When SharePoint processes a request, it performs a lightweight check of the HTTP Referer header to determine whether the request is coming from within a legitimate SharePoint session.

The flaw: if the Referer header is set to /_layouts/SignOut.aspx, SharePoint's request-handling logic treats the incoming request as originating from a valid session context — specifically, it coerces the server into executing embedded commands associated with the management endpoint. The server is tricked into treating an unauthenticated external request as if it were initiated by an authenticated internal user.

# Attacker crafts a POST to SharePoint's ToolPane management endpoint
POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx HTTP/1.1
Host: sharepoint.target.internal
Content-Type: application/x-www-form-urlencoded
Referer: https://sharepoint.target.internal/_layouts/SignOut.aspx
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) ...
Content-Length: [payload_size]

# The forged Referer header causes SharePoint to treat this unauthenticated
# request as originating from a valid session, granting access to the
# privileged ToolPane.aspx management endpoint.

# NOTE: This is the authentication bypass component (CVE-2025-53771).
# CVE-2025-53770 (the deserialization payload) is sent in the body.

Bug 2 — Insecure Deserialization of Untrusted Data (CVE-2025-53770)

Once authentication is bypassed, the attacker exploits the core deserialization vulnerability. SharePoint's ToolPane.aspx endpoint accepts POST data that includes serialized .NET objects. In vulnerable versions, SharePoint deserializes this data without adequate validation of its origin or contents.

The attack uses tools like ysoserial.net — a well-known .NET deserialization payload generator — to forge a signed __VIEWSTATE payload. The crafted payload embeds a malicious .NET gadget chain that, when deserialized by SharePoint's ASP.NET runtime, executes arbitrary code in the context of the SharePoint application pool — which runs as NT AUTHORITY\IUSR or higher.

The particularly dangerous aspect: SharePoint trusts the signature on the ViewState because the attacker extracts the machine key from SharePoint's configuration files (web.config) as part of the exploit chain. With the machine key in hand, the attacker can forge properly signed ViewState payloads that SharePoint accepts and deserializes without question.

# This is what attackers use to generate the deserialization payload.
# Shown here for DEFENSIVE understanding — to recognize what security
# tools should block and what logs will contain.

# Step 1: Extract SharePoint machine key from config (requires file read access)
# Machine key is located in: C:\inetpub\wwwroot\wss\VirtualDirectories\[port]\web.config
# <machineKey validationKey="..." decryptionKey="..." />

# Step 2: Use ysoserial.net to craft signed ViewState payload
# (Attacker runs this locally after obtaining the machine key)
.\ysoserial.exe -p ViewState `
  --generator="CA0B0334" `
  --validationalg="SHA1" `
  --validationkey="[EXTRACTED_KEY]" `
  -c "powershell -enc [base64_encoded_payload]"

# Step 3: Submit forged ViewState in POST body to ToolPane.aspx
# SharePoint verifies the signature (valid, because attacker has the key),
# deserializes the .NET gadget chain, and executes the embedded command.

The Complete Exploit Chain Step by Step

05 Observed Attacker Behavior & Post-Exploitation

CVE-2025-53770 is not a theoretical vulnerability being hoarded by nation-state actors — it was exploited by multiple distinct threat actors within days of the original PoC being posted. Analysis of observed intrusions reveals a consistent post-exploitation playbook.

Web Shell Deployment

The first action in nearly every observed intrusion was dropping an ASPX web shell into the SharePoint web root. The most commonly observed file names include spinstall0.aspx, upload.aspx, and randomized names ending in .aspx. These web shells provide persistent, browser-accessible command execution on the server.

# Hunt for recently created .aspx files in SharePoint web directories
# Run on the SharePoint server itself or via a trusted admin session

# Check all SharePoint virtual directory roots for new .aspx files (last 30 days)
Get-ChildItem -Path "C:\inetpub\wwwroot\wss\" -Recurse -Filter "*.aspx" |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
  Select-Object FullName, LastWriteTime, Length |
  Sort-Object LastWriteTime -Descending

# Specifically hunt for known ToolShell web shell indicators
Get-ChildItem -Path "C:\inetpub\wwwroot\wss\" -Recurse -Include "spinstall*.aspx","upload.aspx"

# Check SharePoint 14/15/16 hive directories for planted files
Get-ChildItem -Path "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\" `
  -Recurse -Filter "*.aspx" |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) }

Machine Key Harvesting for Token Forgery

A distinctive element of ToolShell campaigns is the targeted extraction of SharePoint's cryptographic machine keys. With these keys, attackers can forge valid authentication tokens that are indistinguishable from legitimate ones — meaning they can re-enter the environment at any time without triggering authentication anomaly alerts, even after patching.

# Check for suspicious reads of web.config (machine key location)
# Enable Object Access auditing first if not already enabled

# Search security event log for file access to web.config
Get-WinEvent -FilterHashtable @{
  LogName   = 'Security'
  Id        = 4663
} | Where-Object {
  $_.Properties[6].Value -like "*web.config*"
} | Select-Object TimeCreated, Message | Format-List

# Also check IIS logs for unusual access to the ToolPane.aspx endpoint
Get-ChildItem "C:\inetpub\logs\LogFiles\" -Recurse -Filter "*.log" |
  Select-String -Pattern "ToolPane\.aspx" |
  Select-Object -Last 100

Observed Post-Exploitation Activity

Beyond web shell planting, threat actors observed in ToolShell campaigns performed the following actions on compromised SharePoint servers:

• PowerShell payload execution: Encoded PowerShell commands executed via the deserialization chain or web shell, downloading second-stage payloads from attacker-controlled infrastructure.
• Lateral movement: SharePoint servers often have service accounts with broad Active Directory privileges. Attackers dumped credentials from memory using tools such as Mimikatz and pivoted to domain controllers.
• Data staging and exfiltration: SharePoint document libraries were enumerated and staged for exfiltration, targeting business-critical documents, credentials files, and configuration exports.
• Ransomware pre-staging: In Warlock ransomware campaign intrusions, attackers used ToolShell access as the initial beachhead, spending days in the environment performing reconnaissance before deploying ransomware payloads.
• Backdoor accounts: Local administrator accounts with randomized names were created on the SharePoint host for redundant access.

06 Detection & Threat Hunting

ToolShell leaves several detectable signals across IIS logs, Windows event logs, and endpoint telemetry. The following detection content targets each stage of the attack chain.

IIS Log Detection — Sigma Rule

title: CVE-2025-53770 SharePoint ToolShell Exploitation Attempt
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: stable
description: Detects exploitation attempts of CVE-2025-53770, the SharePoint
  deserialization RCE. Targets POST requests to ToolPane.aspx with the
  SignOut.aspx Referer bypass and suspicious payload sizes.
references:
  - https://greyshield.in/research/toolshell-cve-2025-53770/
  - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770
author: Grey Shield Research Team
date: 2025/07/25
logsource:
  category: webserver
  product: iis
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains: 'ToolPane.aspx'
    cs-uri-query|contains:
      - 'DisplayMode=Edit'
      - 'ToolPane.aspx'
  referer_bypass:
    cs-Referer|endswith: '/_layouts/SignOut.aspx'
  large_payload:
    cs-bytes|gte: 7000
  condition: selection and (referer_bypass or large_payload)
falsepositives:
  - Legitimate SharePoint administrative activities (rare for this endpoint/referer combo)
level: high
tags:
  - attack.initial_access
  - attack.t1190
  - cve.2025.53770

PowerShell — Quick IIS Log Hunt

# Hunt through IIS logs for CVE-2025-53770 indicators
# Run on the SharePoint server or access IIS log share

$logPath = "C:\inetpub\logs\LogFiles\W3SVC1\"

# Hunt 1: POST requests to ToolPane.aspx (core exploit path)
Write-Host "[*] Searching for ToolPane.aspx POST requests..."
Get-ChildItem $logPath -Filter "*.log" | ForEach-Object {
  Select-String -Path $_.FullName -Pattern "POST.*ToolPane\.aspx.*DisplayMode=Edit"
} | Select-Object -Last 50

# Hunt 2: Referer-based auth bypass (SignOut.aspx referer to management endpoint)
Write-Host "[*] Searching for SignOut.aspx Referer bypass pattern..."
Get-ChildItem $logPath -Filter "*.log" | ForEach-Object {
  Select-String -Path $_.FullName -Pattern "SignOut\.aspx"
} | Where-Object { $_ -match "POST" } | Select-Object -Last 50

# Hunt 3: Check for web shell access patterns after initial exploitation
Write-Host "[*] Checking for web shell access (spinstall, unusual .aspx 200s)..."
Get-ChildItem $logPath -Filter "*.log" | ForEach-Object {
  Select-String -Path $_.FullName -Pattern "spinstall.*aspx.*200|upload\.aspx.*POST.*200"
} | Select-Object -Last 20

Windows Event Log Indicators

Post-exploitation activity generates Windows events that complement IIS log detection. Key event IDs to monitor on SharePoint servers:

• Event ID 4688 (Process Creation) — Watch for w3wp.exe spawning unusual children: powershell.exe, cmd.exe, wscript.exe, or certutil.exe. IIS worker processes should almost never spawn shells.
• Event ID 4698 (Scheduled Task Created) — Attackers often create scheduled tasks for persistence after initial access. Any new task created by SYSTEM or NT AUTHORITY\IUSR is suspicious.
• Event ID 4720 (User Account Created) — New local accounts created post-exploitation for redundant access.
• Event ID 4663 (File Access) — Reads of web.config by unusual processes indicate machine key harvesting.

07 Remediation & Hardening

1. Patch Immediately — Priority One

The only complete fix for CVE-2025-53770 is applying Microsoft's July 2025 Cumulative Update for your SharePoint version. Do not attempt any workaround as a substitute for patching on supported versions.

# Run in SharePoint Management Shell (elevated)
$farm = Get-SPFarm
Write-Host "SharePoint Build Version: $($farm.BuildVersion)"
Write-Host "Farm Products:"
$farm.Products | ForEach-Object { Write-Host "  $_" }

# Check patch status for all servers in the farm
Get-SPServer | ForEach-Object {
  $server = $_
  Write-Host "Server: $($server.Name)"
  $server.NeedsUpgrade | ForEach-Object {
    Write-Host "  NeedsUpgrade: $_"
  }
}

# Minimum safe build numbers (July 2025 CU):
# SharePoint 2016: 16.0.5517.1000 or later
# SharePoint 2019: 16.0.10413.20000 or later
# Subscription Edition: 16.0.17928.20000 or later

2. Block ToolPane.aspx at the WAF / Reverse Proxy

As an immediate mitigation while patching proceeds, block external access to the ToolPane.aspx endpoint at your WAF or web application firewall. This endpoint should never be reachable from the internet or untrusted network segments.

<!-- Add to SharePoint web.config or apply at reverse proxy -->
<!-- IIS URL Rewrite rule to block ToolPane.aspx access from untrusted sources -->

<rewrite>
  <rules>
    <rule name="Block ToolPane CVE-2025-53770" stopProcessing="true">
      <match url=".*ToolPane\.aspx" />
      <conditions>
        <!-- Block if Referer is SignOut.aspx (auth bypass indicator) -->
        <add input="{HTTP_REFERER}" pattern=".*SignOut\.aspx.*" />
      </conditions>
      <action type="CustomResponse" statusCode="403"
              statusReason="Forbidden"
              statusDescription="Access Denied by Security Policy" />
    </rule>
  </rules>
</rewrite>

# Nginx equivalent (place in server block):
# location ~* /ToolPane\.aspx {
#   if ($http_referer ~* "SignOut\.aspx") { return 403; }
# }

3. Rotate Machine Keys Immediately

If there is any possibility your SharePoint server was reached by exploitation attempts — even unsuccessful ones — rotate the machine key. Attackers who extracted the key can forge auth tokens that survive patching.

# WARNING: Rotating machine keys will invalidate all active user sessions
# and ViewState. Schedule during a maintenance window.
# Run in SharePoint Management Shell (elevated, on each WFE server)

# Locate web.config (adjust path for your environment)
$webConfigPath = "C:\inetpub\wwwroot\wss\VirtualDirectories\[port]\web.config"

# Generate new random keys
$rng = [System.Security.Cryptography.RNGCryptoServiceProvider]::new()
$validationKey = New-Object byte[] 64
$decryptionKey = New-Object byte[] 24
$rng.GetBytes($validationKey)
$rng.GetBytes($decryptionKey)

$newValidationKey = [BitConverter]::ToString($validationKey).Replace("-","")
$newDecryptionKey = [BitConverter]::ToString($decryptionKey).Replace("-","")

Write-Host "New validationKey: $newValidationKey"
Write-Host "New decryptionKey: $newDecryptionKey"
Write-Host "Update web.config machineKey element with these values on ALL WFE servers."

# After updating web.config, perform IISRESET on each WFE server:
# iisreset /restart

4. Isolate EOL SharePoint Servers Immediately

SharePoint Server 2010 and 2013 will not receive patches for CVE-2025-53770. If you are running these versions and they are reachable from the internet or untrusted networks, your only safe options are to take them offline or place them behind a network control that prevents access to the /_layouts/ path from untrusted sources.

5. Additional Hardening Controls

• Network segmentation: SharePoint servers should never be directly internet-facing without a reverse proxy or WAF in front. All /_layouts/ administrative paths should be blocked at the edge for unauthenticated sources.
• Principle of least privilege for SharePoint service accounts: The SharePoint application pool identity should not have domain admin privileges. Review and constrain service account permissions.
• Enable and monitor Windows Defender Credential Guard: Reduces the attacker's ability to harvest credentials from memory post-compromise.
• Deploy Sysmon with Process Creation logging: The single most valuable detection investment for catching w3wp.exe spawning shells post-exploitation.
• Asset inventory of SharePoint instances: Use Censys or Shodan searches for your IP ranges to find any forgotten SharePoint deployments you may have missed.

08 Real-World Impact Assessment

CVE-2025-53770 strikes at one of the most dangerous targets in an enterprise environment: SharePoint servers sit deep inside corporate networks, often run with elevated service account privileges, hold sensitive business documents and credentials, and are frequently overlooked for patching because they are considered "internal" infrastructure.

Censys analysis at the time of disclosure identified approximately 16,000+ publicly exposed on-premises SharePoint instances globally reachable from the internet. The actual number of vulnerable instances — including those on internal networks reachable from a compromised perimeter — is far larger. Any attacker who has achieved initial network access (via phishing, VPN vulnerability, or another perimeter breach) can use ToolShell as a highly reliable lateral movement path to SharePoint servers.

The attacker access level achieved — running as NT AUTHORITY\IUSR or SYSTEM on the SharePoint host — enables:

• Full read/write access to all SharePoint document libraries and lists — including HR files, board documents, financial data, legal materials, and engineering repositories
• Access to SharePoint service account credentials, which frequently carry elevated Active Directory privileges including domain admin paths
• Manipulation of SharePoint audit logs and activity records, enabling attackers to cover their tracks
• A high-trust foothold for laterally moving to database servers (SQL), file servers, and domain controllers connected to the SharePoint farm

09 Lessons for Security Teams

ToolShell is a case study in several compounding failure modes that security teams encounter repeatedly. Here are the lessons to carry forward:

1. Patch bypasses are expected, not exceptional: Microsoft patched the original ToolShell chain on July 8 — and it was bypassed within ten days. Treat every critical patch as "first round," monitor for bypass disclosures actively, and have a process for emergency re-patching. The attacker community invests in patch diffing as a core capability.
2. "Internal" infrastructure has a perimeter too: Organizations justified not treating SharePoint as a priority because it was "behind the firewall." The reality: any attacker who breaches your perimeter will immediately enumerate internal SharePoint. Internal does not mean safe.
3. EOL software is a liability with a due date: SharePoint 2010 and 2013 receiving no patch for a CVSS 9.8 zero-day is not a surprise — it is the documented outcome of running end-of-life software. If you have EOL SharePoint in your environment, the timeline for migrating off it is now measured in incident response events, not project cycles.
4. Patch compliance is not the same as remediation: Multiple post-incident investigations found that organizations patched the vulnerability but did not investigate whether the environment had already been compromised during the zero-day window. Patch + threat hunt is the complete remediation, not patch alone.
5. Machine keys are credentials: SharePoint machine keys are treated as configuration, not secrets. They are often in plaintext in config files, not rotated for years, and not covered by secrets management programs. After ToolShell, they must be treated as credentials that require the same rotation, access control, and monitoring as passwords.

10 References & Further Reading

• Microsoft MSRC — CVE-2025-53770 Official Advisory
• CISA Known Exploited Vulnerabilities Catalog
• Rapid7 — Zero-day Exploitation of Microsoft SharePoint (ETR)
• Microsoft Security Blog — Disrupting Active SharePoint Exploitation
• Censys Advisory — CVE-2025-53770 Exposure Analysis
• NVD — CVE-2025-53770 Detail
• Orca Security — ToolShell Exploit Chain Breakdown

Grey Shield Research Team · contact@greyshield.in · Responsible Disclosure Policy: /legal