ToolShell (July 2025): On-Prem SharePoint Zero-Days Exploited Worldwide

Retrospective: this article looks back at events from July 2025, written in 2026 with the benefit of hindsight.

On July 19, 2025, Microsoft's Security Response Center published guidance on active attacks against on-premises SharePoint Server. Over the following days the campaign — widely called ToolShell — became one of the year's most serious enterprise security events. Microsoft followed on July 22 with details of who was exploiting it and how to respond.

1. Earlier fixes bypassedJuly 2025: attackers exploit new variants of SharePoint vulnerabilities patched earlier that month.
2. Unauthenticated code executionCVE-2025-53770 lets attackers run code on internet-facing on-premises SharePoint servers.
3. Machine keys stolenAttackers extract ASP.NET machine keys to forge trusted requests and keep access.
4. Multiple actorsMicrosoft observes Linen Typhoon, Violet Typhoon and Storm-2603 — the latter deploying ransomware.
5. Patch plus rotateMicrosoft releases updates and stresses rotating machine keys; CISA publishes analysis and guidance.

The key vulnerability, CVE-2025-53770, was related to CVE-2025-49704, a remote code execution flaw patched earlier in July. A companion flaw, CVE-2025-53771, was a security bypass related to CVE-2025-49706. In other words, attackers found ways around fixes that organizations had only just applied.

SharePoint Online in Microsoft 365 was not affected. This was an on-premises problem.

What happened

According to Microsoft:

• Attackers exploited internet-facing on-premises SharePoint servers to gain unauthenticated remote code execution.
• They stole ASP.NET machine keys — cryptographic secrets SharePoint uses to validate requests. With those keys, attackers can forge trusted payloads and maintain access even after the server is patched, unless the keys are rotated.
• Microsoft observed two Chinese nation-state actors, Linen Typhoon and Violet Typhoon, exploiting the vulnerabilities, and another China-based actor, Storm-2603, using them to deploy ransomware.

Microsoft's guidance: upgrade to supported SharePoint versions, install the July 2025 security updates, enable AMSI integration with Microsoft Defender, deploy Defender for Endpoint, rotate machine keys and restart IIS. CISA added the vulnerability to its Known Exploited Vulnerabilities catalog and later published a malware analysis report.

Why it mattered

History repeated. Exchange Server suffered three major waves of exploitation in 2021–2022. ToolShell followed the same pattern for SharePoint Server: self-hosted Microsoft collaboration servers on the internet, zero-days, rapid mass exploitation.

Patching wasn't enough. Stolen machine keys meant organizations that patched but didn't rotate keys could remain compromised.

Incomplete fixes create urgency. When attackers bypass a recent patch, defenders get little warning.

Ransomware raised the stakes. Espionage actors and a ransomware group used the same entry point.

What to do now

If you still run SharePoint Server, choose one of two paths.

Path 1 — migrate to SharePoint Online.

1. Inventory sites, libraries, customizations, workflows and integrations.
2. Clean up obsolete content before moving it.
3. Plan replacements for farm solutions and classic workflows (SharePoint Framework, Power Automate or alternatives).
4. Migrate with Migration Manager or the SharePoint Migration Tool — and fix permissions during migration so you don't import oversharing that later affects Copilot.
5. Decommission servers after validation.

Path 2 — isolate and harden the servers you must keep.

1. Remove direct internet exposure. Publish internally only, or behind an identity-aware proxy such as Entra application proxy requiring Entra ID sign-in and MFA.
2. Run supported versions and install every security update promptly.
3. Enable AMSI integration and run Microsoft Defender Antivirus or Defender for Endpoint.
4. Rotate ASP.NET machine keys after relevant updates and any suspected compromise, then restart IIS.
5. Restrict outbound traffic from SharePoint servers.
6. Monitor for new ASPX files and unusual processes.

How to hunt for compromise

If your servers were internet-facing during the exploitation window:

• New ASPX files in SharePoint layouts directories (under the TEMPLATE\LAYOUTS path of the SharePoint web server extensions folder).
• IIS worker processes spawning shells — w3wp.exe launching cmd.exe or powershell.exe, particularly with encoded commands.
• Requests matching published indicators in IIS logs, using the patterns and indicators in Microsoft's and CISA's guidance.
• Outbound connections from SharePoint servers to unfamiliar hosts.
• Lateral movement from the server: new accounts, credential theft or remote execution against other hosts.

If you confirm compromise, consider rebuilding rather than cleaning, and rotate any credentials the server could reach.

Common mistakes

• Patching without rotating machine keys.
• Assuming "internal" SharePoint is safe when it's reachable through VPNs or reverse proxies without strong authentication.
• Running unsupported versions that receive no fixes.
• Delaying migration for years because "it still works."

The case for leaving on-premises collaboration servers

ToolShell wasn't an isolated event. On-premises Exchange Server suffered ProxyLogon and ProxyShell in 2021 and ProxyNotShell in 2022, each followed by mass exploitation. SharePoint Server joined that list in 2025. The pattern is consistent: complex, internet-facing collaboration servers attract zero-day research from well-resourced attackers, and every organization running them must react on the attackers' timeline.

There are still valid reasons to keep on-premises servers — regulatory requirements, specialized customizations, or disconnected networks. If those apply, document them, isolate the servers from the internet, and budget for emergency patching and monitoring. If they don't, migration to SharePoint Online removes a recurring source of emergencies and moves patching responsibility to Microsoft.

If you can't migrate this year

Set a deadline and interim controls. Keep the server off the internet, require Entra ID sign-in through a proxy, apply updates within days of release, rotate machine keys after relevant updates, run Defender with AMSI integration, and alert on new ASPX files and unusual IIS worker processes. Review the decision every quarter until the server is gone.

Questions for leadership

• Do we still run SharePoint Server, and is it reachable from the internet?
• Did we patch, rotate machine keys and hunt for compromise during ToolShell?
• What would it take to move remaining content to SharePoint Online?

Key takeaways

• ToolShell exploited on-premises SharePoint Server zero-days in July 2025; SharePoint Online wasn't affected.
• Stolen machine keys enabled persistence after patching — rotation was essential.
• Chinese state actors and a ransomware group exploited the same flaws.
• Migrate where possible; otherwise isolate, patch, rotate keys and monitor.
• Set a retirement date for any remaining on-premises SharePoint and review it quarterly.
• Hunt for compromise after patching; don't assume a patched server is clean.