ToolShell made patching the easy part of a SharePoint emergency
Attackers exploiting the July 2025 SharePoint zero-day stole the keys that let them return after the patch. For agencies running collaboration servers on premises, the response split into three jobs with different owners: patch, evict, and decide whether the server should exist.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On July 18, 2025, researchers at Eye Security reported mass exploitation of on-premises Microsoft SharePoint Server. Microsoft confirmed the flaw, tracked as CVE-2025-53770 and nicknamed ToolShell, as a variant of vulnerabilities it had patched on July 8. It allowed unauthenticated code execution, and attackers used it to steal the ASP.NET machine keys that SharePoint uses to sign data. Microsoft issued emergency updates for SharePoint Subscription Edition and 2019 on July 20 and for 2016 on July 21, and told customers to rotate machine keys after patching. CISA added the flaw to its Known Exploited Vulnerabilities catalog on July 20. On July 22, Microsoft attributed exploitation to two Chinese state-linked groups, Linen Typhoon and Violet Typhoon, and a China-based actor it tracks as Storm-2603. SharePoint Online was not affected.
Most emergency patch cycles end when the update is installed. ToolShell did not, because of what attackers took. SharePoint uses machine keys to sign and validate data that passes between the server and the browser. An attacker holding those keys can craft requests the server accepts as genuine, and can use them to run code again after the original flaw is closed. Patching shut the door. It did nothing about a copy of the key already in someone else’s pocket.
For agencies that still run SharePoint or similar collaboration servers on premises, the response therefore split into three jobs: patching the vulnerability, evicting anyone who got in first, and deciding whether the server should stay on premises at all. Each has a different owner and a different finish line. Most agencies finished the first within days. The second and third are where the outcomes diverged.
Patch: speed depends on inventory
The first job was to install Microsoft’s emergency updates, enable its antimalware scanning integration in SharePoint, or take servers offline until both were done. Agencies running SharePoint 2010 or 2013 had no patch to install. Those versions were already out of support, and CISA advised disconnecting public-facing end-of-life servers.
Speed here depended almost entirely on inventory. A central IT team that knew every SharePoint farm, its version and its exposure could patch in hours. Many agencies did not have that list. Farms stood up years earlier by a program office, a grant-funded project or a contractor often sat outside configuration management, with an owner who had moved on. Those servers were found late, sometimes by external scans rather than internal records.
The sequence also carried a warning about patch status itself. Servers that had installed the July 8 updates were still exposed, because ToolShell bypassed those fixes. A dashboard showing every server at the current patch level would have looked green on July 18. Vulnerability teams need to track exploitation advisories and vendor guidance against each product, not only patch compliance percentages.
The useful metric is time from advisory to confirmed coverage of every instance, not time to patch the servers already known. Agencies that measure only the second will keep reporting success while the unknown server stays exposed.
Evict: the step that needs evidence
The second job was harder. Microsoft’s guidance was to rotate machine keys after patching and restart the web service, so stolen keys would stop working. That step is simple once someone knows to do it. It is also easy to miss when a team treats the installed update as the finish line.
Key rotation addresses only the stolen keys. An attacker who had code execution before the patch could have planted web shells, created accounts, harvested credentials or moved toward directory services. Eviction means hunting for those traces across the whole exploitation window. Check Point Research reported exploitation attempts as early as July 7, well before the public alarm. It also means treating the SharePoint server as a possible foothold into everything it trusted.
Hunting requires logs, and here many agencies came up short. Web server and SharePoint logs were often kept locally, for short periods, on the very server under suspicion. Without centrally retained logs, an agency cannot show that nothing happened. It must either assume compromise and rebuild, or accept a risk it cannot measure. Rebuilding a farm that hosts years of departmental content is slow and disruptive, which pushes agencies toward the second option, often without anyone recording that a decision was made.
Eviction also has a communication duty. Agencies that share directory trusts, document repositories or network links with other departments, counties or contractors should tell those partners early when a server may have been compromised. Waiting for forensic certainty gives an intruder time to use the trust relationship.
Decide: keep, wall off, or retire
The third job appears in no emergency directive, but it determines how often the first two recur. On-premises collaboration servers are attractive targets. They face the internet, hold sensitive documents, connect to identity systems and are often patched more slowly than cloud services. In the hosted version of the same product, the provider patches the service and rotates its own keys.
Some agencies have sound reasons to stay on premises: legal or classification constraints, integration with systems that cannot move, or data that must stay under direct control. Many deployments persist from inertia. Each server deserves an explicit decision among three options. Keep it, with a named owner and a funded patch and logging regime. Wall it off, removing direct internet exposure and placing it behind an authenticated access layer. Or retire it and migrate the content.
Each option has costs that budgets tend to hide. Keeping a farm means paying for skilled administrators and log retention. Walling it off can break external collaboration that partners rely on. Retiring it means a migration that may surface years of permission sprawl. A written decision, reviewed annually, at least makes those costs visible before the next zero-day prices them. For servers kept or walled off, the decision should also name the evidence that would trigger retirement, such as a missed patch deadline or an end-of-support date.
With hindsight
Within days, Eye Security reported that scans had confirmed compromises across hundreds of servers and organizations worldwide. The Energy Department acknowledged that a very limited number of National Nuclear Security Administration systems were affected. Microsoft reported on July 23 that Storm-2603 had used the flaw to deploy Warlock ransomware, widening the threat from espionage to disruption.
The architecture question did not stay optional for long. Microsoft’s published lifecycle dates set the end of extended support for SharePoint Server 2016 and 2019 at July 14, 2026. By this point in 2026, agencies still running those versions face the position 2010 and 2013 users faced during ToolShell: no patch for the next flaw. Agencies that used the 2025 emergency to inventory their farms, centralize logs and make a keep, wall-off or retire decision had a plan when that date arrived. Those that patched and moved on met the deadline with the same unknown servers.