ToolShell: From Pwn2Own Demo to the Worst SharePoint Zero-Day in History

In May 2025, a Vietnamese security researcher named Dinh Ho Anh Khoa walked onto the Pwn2Own Berlin stage, chained two SharePoint vulnerabilities together, and earned $100,000. Two months later, that same exploit chain was being used by Chinese nation-state actors to compromise over 400 organizations worldwide, steal cryptographic keys that survived patching, and deploy ransomware across government agencies, energy companies, and critical infrastructure. This is the full technical breakdown of how ToolShell works, why Microsoft's first patch failed, and what made this the most consequential SharePoint vulnerability chain ever discovered.

SharePoint is deeply embedded in enterprise infrastructure. It connects to Teams, OneDrive, Outlook, and Active Directory. Over a billion people interact with it daily. When you compromise a SharePoint server, you don't just get access to documents — you get a foothold into everything the organization runs through Microsoft's ecosystem.

That's what makes ToolShell different from a typical web application vulnerability. The exploit chain requires a single HTTP request, needs no authentication, and once successful, gives the attacker cryptographic material that maintains access even after the vulnerability is patched. It is, by any technical measure, an ideal initial access vector.

Timeline: From Pwn2Own to Mass Exploitation

The ToolShell story is a case study in how the gap between responsible disclosure and patch deployment creates a window that sophisticated adversaries are ready to exploit.

The entire arc from Pwn2Own demonstration to mass exploitation took approximately 60 days. The gap between the first confirmed in-the-wild attack (July 7) and Microsoft's emergency patch (July 19) was 12 days of active zero-day exploitation.

The Four CVEs

ToolShell involves four CVEs across two patch cycles. Understanding which is which matters for both detection and remediation, because the first two patches were incomplete.

CVE	Type	CVSS	Role in Chain	Patched
CVE-2025-49706	Spoofing (Auth Bypass)	6.5	Original authentication bypass via Referer header manipulation on ToolPane.aspx	July 8
CVE-2025-49704	Code Injection (RCE)	8.8	Insecure deserialization via XML content in web part parameters	July 8
CVE-2025-53770	RCE (Deserialization)	9.8	Bypass of the CVE-2025-49704 fix; same deserialization flaw via ExpandedWrapper object	July 19
CVE-2025-53771	Spoofing (Path Traversal)	6.3	Bypass of the CVE-2025-49706 fix; path traversal to circumvent patched auth check	July 19

Kaspersky's analysis made a critical observation: the exploit for CVE-2025-53770 is nearly identical to the exploit for CVE-2020-1147, a .NET deserialization vulnerability from five years earlier. The only difference is how the malicious ExpandedWrapper object is positioned in the payload. In their words, CVE-2025-53770 is essentially "an updated fix for CVE-2020-1147" — meaning the underlying class of vulnerability has persisted across half a decade of patches.

The Exploit Chain: Step by Step

The elegance of ToolShell — from an attacker's perspective — is its simplicity. The entire chain executes in a single HTTP POST request. No prior authentication. No user interaction. No file uploads required in the latest variant.

Step 1: Reconnaissance

Before exploitation, attackers fingerprint the target. Unit 42 observed pre-exploitation GET requests starting July 17, 2025, sent from exit nodes of the Safing Privacy Network (SPN) to conceal the attacker's origin. The requests targeted the vulnerable endpoint with a python-requests/2.32.3 User-Agent and no Referer header — a telltale signature of an automated scanning script.

GET /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx HTTP/1.1
Host: [target]
User-Agent: python-requests/2.32.3

Unit 42 observed that the sequential order of these GET requests matched the subsequent POST exploitation attempts exactly, indicating the attackers were working from a precompiled targeting list.

Step 2: Authentication Bypass (CVE-2025-49706 / CVE-2025-53771)

SharePoint's ToolPane.aspx endpoint handles web part configuration and management. Under normal conditions, accessing it requires authentication. The bypass exploits a logic flaw in how SharePoint validates the HTTP Referer header.

By setting the Referer to /_layouts/SignOut.aspx, the attacker tricks SharePoint into treating the request as originating from its own sign-out page. SharePoint's internal logic interprets this as a trusted internal request and processes it without requiring credentials.

POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx HTTP/1.1
Host: [target-sharepoint]
Referer: /_layouts/SignOut.aspx
Content-Type: application/x-www-form-urlencoded

MSOtlPn_Uri=[user-control-path]&MSOtlPn_DWP=[malicious-web-part-XML]

The POST request carries two critical parameters: MSOtlPn_Uri, which points to a user control or ASCX file to load, and MSOtlPn_DWP, which contains the malicious web part definition.

Microsoft's July 8 patch attempted to fix this by adding validation to the Referer header. Attackers discovered that a simple path traversal variation bypassed the check entirely, which Microsoft assigned as CVE-2025-53771.

Step 3: Insecure Deserialization (CVE-2025-49704 / CVE-2025-53770)

With authentication bypassed, the attacker's MSOtlPn_DWP parameter delivers a malicious web part containing a compressed deserialization payload. The web part uses a Scorecard:ExcelDataSet control — a legitimate SharePoint component — to carry a .NET deserialization gadget chain.

The payload leverages the TypeConfuseDelegate gadget generator (from the ysoserial.net toolkit) wrapped in an ExpandedWrapper object. When SharePoint's GetPartPreviewAndPropertiesFromMarkup method processes the web part XML, it deserializes the attacker-controlled data without adequate validation, triggering arbitrary code execution within the w3wp.exe IIS worker process.

"If we compare the exploit for CVE-2020-1147 and an exploit for CVE-2025-49704/CVE-2025-53770, we can see that they are almost identical. The only difference is that in the exploit for CVE-2025-49704/CVE-2025-53770, the dangerous ExpandedWrapper object is placed in the list." — Kaspersky Securelist

This is significant. The underlying deserialization vulnerability class in .NET's DataSet handling has been a recurring attack surface since 2020, and ToolShell represents its latest incarnation.

Step 4: Machine Key Extraction

Once the attacker has code execution, the immediate objective is not deploying malware — it's stealing cryptographic secrets. The initial web shells (like spinstall0.aspx) invoke internal .NET methods to read SharePoint's MachineKey configuration, extracting the ValidationKey and DecryptionKey.

These are the ASP.NET keys that SharePoint uses to sign and encrypt ViewState payloads, authentication tokens, and session data. With these keys, an attacker can forge any request that SharePoint will accept as legitimate.

Step 5: Persistent Access via Forged ViewState

This is where ToolShell becomes uniquely dangerous. With the stolen machine keys, the attacker generates signed __VIEWSTATE payloads using ysoserial.net. These payloads are cryptographically valid — SharePoint's ASP.NET runtime will deserialize them as trusted data.

# Generate a signed, malicious ViewState payload
$ ysoserial.exe -p ViewState \
    -g TypeConfuseDelegate \
    -c "powershell -EncodedCommand [base64-payload]" \
    --validationalg="SHA1" \
    --validationkey="[stolen-validation-key]" \
    --generator="[viewstate-generator-value]"

The attacker can now send these forged payloads to any SharePoint page. The server deserializes them, believing they were generated by itself, and executes arbitrary commands. This works even after the ToolShell patches are applied, because the vulnerability at this stage is not in SharePoint's code — it's in the stolen keys. The payload executes within the legitimate w3wp.exe process, making detection significantly harder.

This is why Microsoft's remediation guidance explicitly states that patching alone is insufficient. Organizations must also rotate their ASP.NET machine keys, restart IIS, and then rotate the keys again to fully invalidate any stolen cryptographic material.

The Machine Key Problem: Why Patching Isn't Enough

Most vulnerability response follows a straightforward model: identify, patch, verify. ToolShell breaks this model entirely.

Once an attacker has your ASP.NET ValidationKey and DecryptionKey, they hold a master key to your SharePoint environment. They can forge authentication tokens to impersonate any user, including Site Collection Administrators. They can create valid signed payloads that trigger deserialization. They can craft cookies that grant access to any content. All of this generates traffic that is cryptographically indistinguishable from legitimate server-generated requests.

The prescribed remediation sequence is critical and must be followed in order:

1. Apply all security patches for CVE-2025-53770 and CVE-2025-53771 (and CVE-2025-49704/49706 if not already applied)
2. Rotate ASP.NET machine keys using Microsoft's provided PowerShell tooling
3. Restart IIS using iisreset.exe (required even if AMSI is enabled)
4. Rotate keys again after restart to invalidate any keys cached in memory
5. Hunt for compromise indicators before assuming the environment is clean

"If you have SharePoint on-premises exposed to the internet, you should assume that you have been compromised. Patching alone is insufficient to fully evict the threat." — Palo Alto Networks Unit 42

The MAPP Leak: How Attackers Got Early Access

One of the most consequential aspects of the ToolShell story is the timing. Microsoft notified MAPP partners about the vulnerability in three waves: June 24, July 3, and July 7. The first confirmed exploitation attempt was detected on July 7 — the same day as the third notification.

Dustin Childs, head of threat awareness at Trend Micro (which runs Pwn2Own through its Zero Day Initiative), stated publicly that the most likely explanation is that a MAPP partner weaponized the vulnerability using privileged access to the confidential disclosure.

"Someone in the MAPP program used that information to create the exploits... the exploit attempts originated mostly from China, making it reasonable to speculate [the leak came from a company in that region]." — Dustin Childs, Trend Micro

Microsoft launched an investigation into a potential leak from within the MAPP program. The MAPP program exists to give security vendors advance notice of vulnerabilities so they can prepare protections for their customers. If a member of that program leaked vulnerability details to offensive actors, it represents a fundamental compromise of the coordinated disclosure ecosystem.

The implications extend beyond ToolShell. If nation-state actors have access to MAPP disclosures — even through a single compromised vendor — it means every future Patch Tuesday advisory comes with a pre-built exploitation window for adversaries.

Attribution: Three Chinese Groups, Two Ransomware Variants

Microsoft attributed ToolShell exploitation to three Chinese-linked threat groups operating concurrently. This is unusual — multiple state-affiliated groups exploiting the same zero-day simultaneously suggests either coordinated tasking or a shared supply chain for exploit access.

Linen Typhoon (APT27 / Budworm)

A long-established Chinese APT primarily focused on espionage operations. Linen Typhoon targets government, defense, and technology sectors. Their involvement in ToolShell aligns with their historical pattern of exploiting enterprise infrastructure for intelligence collection.

Violet Typhoon (APT31 / Sheathminer)

Another MSS-linked espionage group with a track record of targeting government and political entities. Violet Typhoon was previously attributed to the 2021 Microsoft Exchange ProxyLogon exploitation campaign, making ToolShell their second major Microsoft enterprise product exploitation in four years.

Storm-2603 / CL-CRI-1040 (Project AK47)

The most technically interesting actor. Unit 42 tracks this cluster as CL-CRI-1040 and identified their custom toolset as "Project AK47," which includes a backdoor, ransomware, and loaders. The group was formerly associated with a LockBit 3.0 affiliate and operates a double-extortion data leak site called "Warlock Client Leaked Data Show."

Storm-2603 deployed the Warlock ransomware after ToolShell exploitation, using Mimikatz for credential extraction, PsExec and WMI for lateral movement, and Group Policy Objects (GPOs) to distribute ransomware payloads across compromised networks.

A separate financially motivated campaign deployed 4L4MD4R ransomware, a variant of the open-source Mauri870 ransomware written in Go. The 4L4MD4R operator used encoded PowerShell commands to disable real-time monitoring, bypass certificate validation, and download the ransomware payload. The demanded ransom was 0.005 BTC — roughly $500 — suggesting a high-volume, low-value opportunistic approach distinct from the targeted espionage operations.

The convergence of espionage groups and ransomware operators on the same zero-day is noteworthy. It suggests either that Chinese offensive capabilities are becoming more commercially oriented, or that the exploit was distributed through shared channels that serve both state intelligence and criminal operations.

Impact and Scope

The numbers tell the story:

• 400+ organizations compromised globally, as reported by Bloomberg
• 148+ confirmed by ISMG with detailed forensic evidence
• 8,000+ publicly accessible SharePoint farms identified as vulnerable by Eye Security
• 424 servers still unpatched as of July 23, per the Shadowserver Foundation, concentrated in the United States, Iran, Germany, India, and China
• 5% of Recorded Future's scanned customer base with SharePoint servers remained susceptible after patches were available
• 20%+ of environments exposed according to Akamai's telemetry

Victims spanned government agencies (including the U.S. Departments of Energy and Homeland Security, and the NNSA), European and Middle Eastern government entities, telecom networks, energy companies, technology consulting firms, manufacturing organizations, and critical infrastructure providers. SentinelOne noted that early targets were selectively chosen for strategic value before mass exploitation began after public PoC disclosure.

NHS England's Cyber Security Operations Centre issued High-Severity Alert CC-4683 for active exploitation against UK healthcare SharePoint servers. The global footprint of affected organizations spans every major industry sector.

Detection and Hunting

Detecting ToolShell exploitation requires monitoring at multiple layers: network (IIS logs), endpoint (process chains), and file system (artifact hunting).

IIS Log Analysis

Search for POST requests to the ToolPane.aspx endpoint with a Referer header pointing to SignOut.aspx:

# Search IIS logs for ToolShell exploitation attempts
# Look for POST to ToolPane.aspx with suspicious Referer
Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC*\*.log" `
    -Pattern "ToolPane\.aspx.*DisplayMode=Edit" |
    Where-Object { $_ -match "POST" }

Look specifically for the python-requests User-Agent in GET requests to the same endpoint — this indicates pre-exploitation reconnaissance scanning.

Process Chain Monitoring

The telltale ToolShell process chain is:

w3wp.exe → cmd.exe → powershell.exe -EncodedCommand [base64]

Any PowerShell invocation spawned by the SharePoint IIS worker process should be treated as high-severity. Search Windows Event ID 4104 (script block logging) for encoded script execution correlated with w3wp.exe parent processes.

File System Hunting

Search for unexpected ASPX files in SharePoint's Layouts directory:

# Hunt for dropped web shells
Get-ChildItem -Recurse `
    "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\*\TEMPLATE\LAYOUTS\" `
    -Include "*.aspx" |
    Where-Object {
        $_.Name -match "spinstall|cmd\.aspx|webshell" -or
        $_.LastWriteTime -gt (Get-Date "2025-07-01")
    }

Known IOCs

CISA and multiple security vendors have published confirmed attacker infrastructure. Priority IPs to scan for in network logs, particularly between July 17–25, 2025:

# Known ToolShell C2 / exploitation IPs
107.191.58[.]76
104.238.159[.]149
96.9.125[.]147

# Known web shell hashes (SHA1)
f5b60a8ead96703080e73a1f79c3e70ff44df271  # spinstall0.aspx
fe3a3042890c1f11361368aeb2cc12647a6fdae1  # xxx.aspx
76746b48a78a3828b64924f4aedca2e4c49b6735  # App_Web_spinstall0.aspx compiled DLL

Key Takeaways

1. Patch, then rotate, then hunt. Applying the security update alone does not remove ToolShell access. You must rotate ASP.NET machine keys, restart IIS, rotate keys again, and then actively hunt for compromise indicators. This is non-negotiable for any organization that had on-premises SharePoint exposed to the internet during July 2025.
2. Assume breach if you were exposed. Unit 42, Microsoft, and SentinelOne all independently state this explicitly. If your SharePoint server was internet-facing and unpatched during the exploitation window, treat it as compromised until forensic evidence proves otherwise.
3. End-of-life means unprotectable. SharePoint Server 2010 and 2013 are confirmed vulnerable and will not receive patches. If you are running these versions, you have no mitigation path other than decommissioning or complete network isolation. Migration to SharePoint Online or a supported on-premises version is the only viable long-term option.
4. Network segmentation would have limited blast radius. ToolShell requires direct HTTP access to the SharePoint server. Organizations that restricted ToolPane.aspx access to internal networks or placed SharePoint behind a WAF with updated rules were protected from external exploitation. Akamai deployed WAF rules within two days of disclosure. Blocking POST requests to /_layouts/15/ToolPane.aspx is an effective interim control.
5. The MAPP program is a strategic target. If the timeline is accurate — exploitation beginning on the same day as the third MAPP notification — then coordinated disclosure programs themselves are part of the attack surface. Organizations that depend on early patches from MAPP-participating vendors should understand that the same information may reach adversaries through compromised members.
6. Deserialization is the vulnerability class that won't die. ToolShell is a direct descendant of CVE-2020-1147. .NET deserialization through DataSet processing has been a recurring attack surface for over five years. Until Microsoft fundamentally changes how SharePoint handles serialized data, variants will continue to emerge. Track deserialization-related advisories for all .NET applications in your environment, not just SharePoint.

ToolShell is a textbook example of how a single vulnerability chain — discovered responsibly at a hacking competition — can cascade into a global security event when the disclosure-to-exploitation gap is measured in days rather than months. The technical sophistication of the exploit is moderate. The operational impact was severe because it targeted infrastructure that is deeply embedded in enterprise operations and provided cryptographic persistence that outlasts the patch cycle.

For organizations still running on-premises SharePoint: the question is not whether you should migrate to SharePoint Online. It's whether you can afford to keep exposing infrastructure that has been an active zero-day target for three consecutive years.

Sources

• Kaspersky Securelist — Analysis of the ToolShell Vulnerabilities and Exploit Code (July 28, 2025)
• SentinelOne — SharePoint ToolShell: Zero-Day Exploited in the Wild (July 22, 2025)
• Palo Alto Networks Unit 42 — Active Exploitation of Microsoft SharePoint Vulnerabilities (Updated August 12, 2025)
• Palo Alto Networks Unit 42 — Project AK47: Uncovering a Link to the SharePoint Vulnerability Attacks (September 18, 2025)
• CISA — Microsoft Releases Guidance on Exploitation of SharePoint Vulnerabilities (July 20, 2025)
• Check Point Research — SharePoint Zero-Day CVE-2025-53770 (July 29, 2025)
• Recorded Future Insikt Group — ToolShell Exploit: Critical SharePoint Zero-Day Threatens Global Enterprises
• Akamai — Understand the SharePoint RCE: Exploitations, Detections, and Mitigations (October 27, 2025)
• Forescout — Threat Analysis: Microsoft SharePoint ToolShell Exploits (July 31, 2025)
• White Blue Ocean — ToolShell and SharePoint: A Hackathon Gone Wrong
• Qualys — ToolShell Zero-Day: Microsoft Rushes Emergency Patch (July 24, 2025)
• Resecurity — SharePoint Zero-Day Exploit (ToolShell) Network Infrastructure Mapping