Join our Newsletter — 33% off our NHI Course
Home› NHI Breaches› ToolShell SharePoint Exploitation 2025: How Stolen ASP.NET Machine…
Breach analysis Incident: 18 Jul 2025

ToolShell SharePoint Exploitation 2025: How Stolen ASP.NET Machine Keys Kept Attackers Inside After Patching

← All NHI breaches
By Lalit Choda, NHI Mgmt Group Updated 26 September 2026 10 min read
On this page

In July 2025, attackers began mass exploitation of on-premises Microsoft SharePoint servers using a chain of flaws known as "ToolShell", tracked as CVE-2025-53770 and CVE-2025-53771. The first thing many of them did after getting in was not to steal documents. It was to read the server's ASP.NET machine keys, the ValidationKey and DecryptionKey that SharePoint uses to sign and protect its own data. With those keys an attacker can forge trusted requests and run code on the server again later, even after the vulnerability is patched. That makes ToolShell a clear case of a machine secret turning a one-off exploit into lasting access.

Key takeaways

  • Microsoft says it saw the earliest exploitation attempts on 7 July 2025. Eye Security detected mass exploitation on 18 July 2025, and its later scanning found at least 400 compromised servers.
  • Attackers uploaded a web shell, spinstall0.aspx, whose job was to read the server's MachineKey configuration and return the ValidationKey and DecryptionKey to them.
  • Stolen machine keys let an attacker sign malicious ViewState data that the server trusts, giving remote code execution that survives patching. Microsoft and CISA both told defenders to rotate machine keys and restart IIS, not just patch.
  • Microsoft attributed exploitation to two Chinese state actors, Linen Typhoon and Violet Typhoon, and to Storm-2603, which used it to deploy Warlock ransomware from 18 July.
  • Lesson: a server's cryptographic keys are non-human identities. If an attacker may have read them, they must be rotated, and every machine secret on the host should be treated as exposed.

At a glance

Organisation(s)Organisations running on-premises SharePoint Server 2016, 2019 and Subscription Edition, including US government bodies such as the Department of Energy's National Nuclear Security Administration
WhenEarliest attempts 7 July 2025; mass exploitation from 17 to 18 July 2025; emergency patches 20 to 21 July 2025
AttackerLinen Typhoon, Violet Typhoon and Storm-2603 according to Microsoft, with other actors expected to follow
Entry pointUnauthenticated requests to SharePoint's ToolPane.aspx page exploiting an authentication bypass and unsafe deserialisation
Identities abusedASP.NET machine keys (ValidationKey and DecryptionKey) used to sign and protect ViewState; the SharePoint server's own trust in data signed with those keys
ImpactAt least 400 servers compromised according to Eye Security; web shells, key theft and Warlock ransomware on some victims
CategoryNHI (cryptographic machine keys), vulnerability exploitation

What happened

The ToolShell name comes from an exploit chain that Code White GmbH demonstrated at Pwn2Own Berlin in May 2025, combining an authentication bypass (CVE-2025-49706) with a deserialisation flaw that allows remote code execution (CVE-2025-49704). Microsoft released fixes for those two flaws in July 2025. Attackers then found ways around those fixes, and the bypasses were assigned CVE-2025-53770 and CVE-2025-53771. SharePoint Online in Microsoft 365 was not affected; only on-premises servers were.

Eye Security, a Dutch security firm, identified active exploitation on 18 July 2025 at around 18:00 UTC. It described a POST request to /_layouts/15/ToolPane.aspx carrying a Referer of /_layouts/SignOut.aspx, which bypassed authentication. The attacker then dropped a file called spinstall0.aspx onto the server without any credentials. Microsoft describes this web shell as containing "commands to retrieve MachineKey data and return the results to the user through a GET request, enabling the theft of the key material by threat actors."

The keys matter because of how ASP.NET works. SharePoint uses its machine keys to sign and encrypt ViewState, data that the server sends to the browser and later accepts back. If an attacker has the ValidationKey, they can craft a malicious ViewState payload that the server treats as genuine. Eye Security showed that with public tooling such as ysoserial, a token signed with the stolen key could be added to any request and the command "is executed (RCE)". Because the key, not the bug, is what makes this work, patching the original flaw does not remove the attacker's access. Microsoft's advice was explicit: "It is critical that customers rotate SharePoint server ASP.NET machine keys and restart IIS on all SharePoint servers after applying the latest security updates above or enabling AMSI."

Microsoft published customer guidance on 19 July 2025 and emergency updates followed: on 20 July for SharePoint Server 2019 and Subscription Edition, and on 21 July for SharePoint Server 2016, according to BleepingComputer. CISA added CVE-2025-53770 to its Known Exploited Vulnerabilities catalogue on 20 July, and advised organisations to rotate machine keys, apply the update, rotate the keys again and restart IIS.

On 22 July Microsoft named three China-based actors exploiting the flaws: Linen Typhoon, which it says focuses on intellectual property theft, Violet Typhoon, which it links to espionage, and Storm-2603, which began deploying Warlock ransomware through the vulnerabilities on 18 July. The US Department of Energy confirmed it had been affected, saying through a spokesperson that on 18 July exploitation "began affecting the Department of Energy, including the NNSA" and that "a very small number of systems were impacted".

Timeline

DateEvent
May 2025Code White GmbH demonstrates the ToolShell chain at Pwn2Own Berlin.
July 2025Microsoft releases fixes for CVE-2025-49704 and CVE-2025-49706.
7 July 2025Earliest exploitation attempts observed by Microsoft.
17 July 2025First of four attack waves identified by Eye Security.
18 July 2025Eye Security detects mass exploitation. Storm-2603 begins deploying Warlock ransomware, according to Microsoft. The Department of Energy is affected.
19 July 2025Microsoft publishes customer guidance for CVE-2025-53770, including machine key rotation.
20 July 2025CISA adds CVE-2025-53770 to the KEV catalogue. Emergency updates for SharePoint 2019 and Subscription Edition.
21 July 2025Emergency updates for SharePoint Server 2016.
22 July 2025Microsoft attributes exploitation to Linen Typhoon, Violet Typhoon and Storm-2603. CISA adds CVE-2025-49704 and CVE-2025-49706 to KEV.
23 to 24 July 2025Reporting of at least 400 compromised servers and named US government victims.

How it happened: the identity attack path

  1. Unauthenticated entry. A crafted request to ToolPane.aspx with a spoofed SignOut.aspx referer bypassed SharePoint's authentication and reached vulnerable deserialisation code.
  2. Code execution in the web server. Microsoft observed encoded PowerShell being spawned by the IIS worker process, w3wp.exe, and a web shell written to disk.
  3. Theft of the server's machine identity. The spinstall0.aspx shell read the ASP.NET MachineKey configuration and returned the ValidationKey, the validation algorithm and the DecryptionKey to the attacker.
  4. Forged trust. With the keys, an attacker can sign ViewState payloads that SharePoint accepts as its own, giving remote code execution on demand.
  5. Persistence beyond the patch. Because the keys stay valid until rotated, patching alone leaves the door open. That is why Microsoft, CISA and Eye Security all stressed rotation and an IIS restart.
  6. Follow-on activity. Some actors used their access for espionage; Storm-2603 used it to deploy Warlock ransomware.

Impact

  • Scale: Eye Security scanned more than 23,000 SharePoint servers and found at least 400 compromised across four attack waves. BleepingComputer, citing Eye Security, reported at least 400 servers across 148 organisations, while The Register reported the count as more than 400 organisations. Early counts on 20 July were lower, at more than 85 servers and 54 organisations.
  • Government victims: the Department of Energy, including the National Nuclear Security Administration, confirmed impact. SecurityWeek listed reported victims including the Department of Homeland Security, the Department of Education and the National Institutes of Health; BleepingComputer reported the Florida Department of Revenue and the Rhode Island General Assembly.
  • Ransomware: Warlock ransomware was distributed on some compromised systems, according to CISA; Microsoft attributes its deployment to Storm-2603.
  • Lasting exposure: any server whose machine keys were read stays exposed until those keys are rotated.

What this means for NHI governance

Machine keys rarely appear in an identity inventory, yet they behave exactly like a non-human identity credential. They let a server prove to itself that data is genuine, and anyone who holds them can impersonate that trust. ToolShell shows attackers understand this: the web shell went for the keys first because keys give durable, quiet access that patching does not revoke.

This is not the first time ASP.NET machine keys have been abused. In February 2025 Microsoft warned about attackers using publicly disclosed machine keys for ViewState code injection, covered on our page How ASP.NET machine keys triggered remote code execution attacks. That case was keys copied from public code; ToolShell is keys stolen from live servers. The control failure is the same in both: static keys with no rotation schedule, no owner and no monitoring.

The broader point for incident response is that patching fixes the entry point, but it does not revoke credentials the attacker already took. Any breach of a server should trigger rotation of every secret that server held, including keys, service account passwords, connection strings and certificates.

Recommendations

  • Rotate machine keys after any suspected compromise. Follow Microsoft's guidance using Set-SPMachineKey or Update-SPMachineKey, then run iisreset.exe on every SharePoint server. Our guide to rotating non-human identities covers why rotation is often skipped and how to make it routine.
  • Treat cryptographic keys as NHIs. Inventory machine keys, signing keys and certificates alongside service accounts, with an owner and a rotation schedule, as set out in the NHI Lifecycle Management Guide.
  • Patch and enable AMSI. Apply the SharePoint updates and ensure the Antimalware Scan Interface is enabled with Microsoft Defender Antivirus, as Microsoft recommends.
  • Take unsupported and unpatched servers off the internet. CISA advised disconnecting public-facing SharePoint servers that could not be patched and end-of-life versions such as SharePoint Server 2013.
  • Hunt for key theft, not just web shells. Look for spinstall0.aspx and similar files, and for w3wp.exe spawning PowerShell. If found, assume the keys and other secrets on the host are exposed.
  • Rotate other secrets on compromised hosts. Service account passwords, database connection strings and certificates stored on the server should be rotated too. See The Secret Sprawl Challenge.

Frequently asked questions

What is ToolShell?

ToolShell is the name for an exploit chain against on-premises Microsoft SharePoint that allows unauthenticated remote code execution. The July 2025 attacks used CVE-2025-53770 and CVE-2025-53771, which bypassed earlier fixes for CVE-2025-49704 and CVE-2025-49706.

Why did attackers steal SharePoint machine keys?

The ValidationKey and DecryptionKey let an attacker sign ViewState data that the server trusts. That allows them to run code on the server again later, even after it has been patched, until the keys are rotated.

Is patching enough to fix a ToolShell compromise?

No. Microsoft and CISA both said administrators must also rotate the ASP.NET machine keys and restart IIS. A patched server with stolen keys can still be exploited.

ASP.NET machine keys RCE attacks · Gladinet hardcoded keys exploited for RCE · Salt Typhoon stolen credentials · Challenges of Rotating NHIs · Top 10 NHI Issues · NHI breaches

How NHI Mgmt Group can help

Securing Non-Human Identities (NHIs), including AI agents, is becoming increasingly crucial as attackers target cryptographic keys, service accounts, API keys, tokens and secrets. Our NHI Foundation Level Training Course gives teams the practical grounding to find, govern and protect these identities.

References

Explore further

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Written and reviewed by Lalit Choda, NHI Mgmt Group. Last updated 26 September 2026.
    Based on the public sources listed under References. Details may change as investigations continue.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org