ToolShell made patching the easy part of a SharePoint emergency

The week

On Friday, July 18, 2025, researchers at Eye Security detected mass exploitation of on-premises Microsoft SharePoint Server through an attack chain nicknamed ToolShell.

SharePoint is the software many organizations use as their internal filing cabinet and intranet: the place where departments store documents, share policies and collaborate on files. “On-premises” means the organization runs it on its own servers, in its own building or data center, rather than renting Microsoft’s hosted version over the internet. An attack chain is a sequence of software flaws that attackers string together, each one opening the way to the next.

ToolShell allowed unauthenticated code execution: an attacker who had never logged in could make the server run programs of their choosing, which is close to the worst kind of flaw there is. Attackers used it to steal the ASP.NET machine keys that SharePoint uses to sign data. Those keys are, roughly, the server’s official seal: the secret it uses to prove that information passing between it and a user’s browser is genuine.

The response moved quickly. Microsoft assigned a new identifier, CVE-2025-53770, describing it as a variant of vulnerabilities it had patched on July 8. A CVE number is simply the standard catalog number the industry uses to track a specific software flaw. 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, meaning replace the stolen seal with a new one. CISA, the federal government’s lead civilian cyber defense agency, added CVE-2025-53770 to its Known Exploited Vulnerabilities catalog on July 20. That catalog is the government’s list of flaws confirmed to be under active attack, and federal agencies must fix what appears on it.

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, Microsoft’s hosted cloud version, was not affected. The problem was confined to organizations running the software themselves, a group that includes many government agencies.

Most emergency patch cycles end when the update is installed. A patch is a software fix issued by the maker; installing it closes the hole. Normally that is the finish line. ToolShell did not end there, 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, and did nothing about a copy of the key already in someone else’s pocket.

A hotel that finds a broken lock on a side entrance is in the same position. Fixing the lock stops new intruders, but if someone walked in and copied the master key card while the lock was broken, the hotel also has to reissue every key card and check every room for anyone still inside.

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.

What on-premises SharePoint is, and why it is such a target

Why a document-sharing system attracts state-linked attackers at all becomes clear from what accumulates in it. A SharePoint installation is often called a “farm”: a group of servers working together to host an organization’s sites and documents. Over years, a farm accumulates an extraordinary amount of material. Policies, contracts, budget drafts, personnel files, project plans, legal memos and internal correspondence can all end up there, because collecting them is what the system is for. For an attacker interested in espionage, it is a library with the most interesting books already gathered in one place.

SharePoint farms also tend to be deeply connected. They are linked to the organization’s identity system, the directory that holds everyone’s user accounts and decides who can access what. They may be connected to other departments, partner agencies or contractors. A foothold on the SharePoint server can become a route into those connected systems.

Finally, many on-premises farms face the internet so staff can reach them from home or partners can share files. That convenience means anyone on the internet can knock on the door. When a flaw like ToolShell appears, every exposed server can be found and attacked within hours, which is what “mass exploitation” means.

The contrast with the hosted version matters. In SharePoint Online, Microsoft runs the servers, applies the fixes and manages the keys. With on-premises SharePoint, each organization does those things itself, and its speed and skill determine how exposed it is.

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. The antimalware scanning integration lets security software inspect requests reaching SharePoint and block known malicious ones; it was an extra layer while fixes rolled out.

Agencies running SharePoint 2010 or 2013 had no patch to install. Those versions were already out of support, which means Microsoft no longer issues fixes for them, and CISA advised disconnecting public-facing end-of-life servers. An end-of-life product may still run, but nothing can be repaired when it breaks.

You cannot patch what you do not know you have

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. Configuration management is the discipline of keeping an accurate, current record of every system an organization runs and how each is set up. Those servers were found late, sometimes by external scans rather than internal records: some agencies learned about their own servers from outsiders looking in.

Suppose a state transportation department’s central IT team patches its two main SharePoint farms by Sunday evening and reports success. On Tuesday, an external scan flags a third SharePoint server on the agency’s network. It turns out to be a project site set up years earlier by a contractor for a highway program, still online and still holding project documents. Its original owner has left; nobody in central IT knew it existed. It has been exposed throughout the emergency.

A green dashboard is not the same as safety

The sequence also carried a warning about patch status itself. In the first days, Microsoft treated the attacks as a new variant and shipped new fixes, so nobody could say with confidence whether servers carrying the July 8 updates were safe. A dashboard showing every server at the current patch level offered little real assurance on July 19. Vulnerability teams need to track exploitation advisories and vendor guidance against each product, alongside 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. That distinction is worth insisting on in every briefing: “We patched everything we know about” and “We have confirmed every instance is covered” are very different statements.

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. Until the keys are rotated, a copied key still works.

Looking for what the intruder left behind

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.

Those terms are worth unpacking. A web shell is a small hidden program placed on a web server that gives an attacker a back door, letting them return and issue commands at will. Harvesting credentials means collecting usernames and passwords stored on or passing through the server. Directory services are the central systems that manage user accounts and permissions across an organization; reaching them is often the attacker’s real goal, because it can unlock everything else.

Eviction means hunting for those traces across the whole exploitation window. Microsoft later said attackers had attempted exploitation 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.

No logs, no proof

Hunting requires logs, and here many agencies came up short. Logs are the records a system keeps of who connected, when and what they did. Web server and SharePoint logs were often kept locally, for short periods, on the very server under suspicion. The evidence sat on the machine the attacker controlled, and was overwritten every few days.

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.

That last point deserves attention from the top. Accepting an unmeasured risk can be a legitimate choice. Accepting it silently, without anyone senior knowing it was a choice, is a governance failure. If an agency decides not to rebuild, the decision, the reasons and the person who made it should be written down.

Tell your neighbors

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. A directory trust is an arrangement that lets users from one organization’s system be recognized by another’s. 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, meaning users must prove who they are before they can even reach the server.
• Retire it and migrate the content.

The costs budgets tend to hide

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, the tangle of access rights that builds up as people are granted access to sites and never removed.

A written decision, reviewed annually, at least makes those costs visible before the next zero-day prices them. A zero-day is a flaw attackers exploit before the maker has a fix ready; it is named for the number of days defenders have had to prepare. 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.

Who owns each job inside an agency

One reason ToolShell responses varied so widely is that the three jobs naturally land with different people, and nobody is automatically in charge of connecting them.

Patching usually belongs to central IT operations: the server administrators who install updates and the team that keeps the inventory. Their finish line is clear and measurable, which is why most agencies got there within days.

Eviction belongs to the security team, often supported by an outside incident response firm. Their finish line is fuzzy. They are trying to prove a negative, that nobody is still inside, and the quality of their answer depends on evidence that someone else had to collect in advance. If operations never sent logs to a central store, security cannot conjure them after the fact.

The keep, wall-off or retire decision belongs to leadership: the chief information officer, the business owners of the content and, where money is involved, the budget office. It has no deadline imposed from outside, which is why it so often slips.

The most useful thing a senior official can do is make sure the handoffs happen. When operations reports “patched,” someone should ask security to show the intruder is gone. When security reports “we cannot be sure,” someone should ask leadership whether to rebuild, accept the risk or retire the server, and who decides. Each question moves the agency from one job to the next.

Consequences outside the technology team

The consequences of each job reach well past the technology team. A server that hosts personnel files or legal memos touches the general counsel, who may need to assess notification duties. Shared trust with other departments touches intergovernmental relationships. A forced rebuild touches every program that stores its work on the system. And a public report of compromise touches the agency’s reputation with residents, legislators and oversight bodies. Treating ToolShell as a purely technical event leaves those owners out of decisions that land on their desks anyway.

An agency ready for the next emergency

Pulling the three jobs together, an agency in good shape before the next emergency has a few recognizable features. It has a current inventory of every collaboration server, including those owned by program offices and contractors, with version and internet exposure recorded. Its emergency patch runbook, the step-by-step procedure for urgent fixes, includes rotating keys and secrets as an explicit step. Its web and application logs flow to a central store, off the server, kept long enough to investigate weeks after the fact. It knows which partners it shares trust with and how to reach them quickly. And every on-premises server has a recorded keep, wall-off or retire decision with a named owner.

The agencies that struggled did the opposite. They reported “fully patched” based on the servers already known, and treated the installed update as the end of the incident. They kept logs only on the server that might be compromised, decided not to rebuild without recording the decision, and waited for certainty before warning partners. Old servers stayed running because nobody owned the decision to turn them off.

The costs of these failures are concrete. A missed server can mean stolen documents and a long, expensive investigation. An unlogged intrusion can leave an agency unable to tell oversight bodies, partners or the public what was taken. A forced rebuild under pressure disrupts every department that depends on the system. Each is far more expensive than the inventory, logging and decisions that would have prevented it.

What the CIO should be able to show for every SharePoint server

1. Do we have a complete list of every SharePoint or similar collaboration server we run, including those set up by program offices, grants or contractors, and which of them are reachable from the internet?
2. When we say “fully patched,” do we mean every server we know about, or every server we have confirmed exists?
3. Does our emergency patch procedure include rotating keys and secrets, and was it done this time?
4. Where are our web and SharePoint logs kept, for how long, and are they stored off the server?
5. For each on-premises server, have we decided to keep it, wall it off or retire it, and who owns that decision?

With hindsight

Within days, Eye Security reported that scans had confirmed compromises across hundreds of servers and organizations worldwide. The Energy Department said it had been minimally affected, with the National Nuclear Security Administration among those hit. The NNSA is the agency responsible for the nation’s nuclear weapons stockpile, which gave the episode an unmistakable seriousness.

Later analysis refined the picture: Eye Security and CISA’s revised alert concluded the wave exploited the chain of flaws patched on July 8, and that the newer identifiers covered patch bypasses not known to have been exploited. The early confusion about whether July 8 patches were enough was real, and the honest answer only arrived weeks later. Microsoft reported on July 23 that Storm-2603 had used the flaw to deploy Warlock ransomware, widening the threat from espionage to disruption. Ransomware is malicious software that locks an organization’s files and demands payment to unlock them.

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.

An emergency is also an audit nobody scheduled. It shows, quickly and publicly, which systems an organization truly knows about, which it can investigate and which it has simply never decided about. The patch is the visible part of the response. The inventory, the logs and the decision about each server are the parts that determine how the next emergency goes.