ToolShell: SharePoint gets exploited at scale

A chain of SharePoint Server vulnerabilities — dubbed ToolShell — went from proof-of-concept to mass exploitation of internet-facing on-premises servers in under a week. Victims included government agencies in several countries.

The technical details are well documented elsewhere. The interesting part is the failure mode, because it is one your organization probably shares.

the shape of the failure#

The original vulnerabilities were disclosed and patched. Attackers then found a bypass of the patch — the fix addressed the specific proof-of-concept rather than the underlying class of issue — and the bypass was exploitable against systems that had applied the update.

That is the part worth internalizing. "We patched it" was true and insufficient. Organizations that had done everything right by conventional standards were still compromised.

The second failure: machine key theft. Once in, attackers extracted the ASP.NET machine keys, which let them forge valid __VIEWSTATE payloads. Those keys survive patching. An organization that applied the fix without rotating keys was still accessible with credentials the attacker already had.

This is the single most common post-incident mistake. You patch the hole, you declare it resolved, and the attacker walks back in through a credential they took on day one. Patching does not evict.

the on-prem problem#

Every mass-exploitation event of this shape over the last several years has hit on-premises enterprise software: file transfer appliances, VPN gateways, collaboration servers, email servers.

The pattern is consistent and the causes are structural:

• Internet-facing by design. These products exist to be reachable.
• Deeply integrated. They hold credentials for everything else.
• Patched slowly. Change control, testing windows, and the fact that they cannot go down.
• Poorly monitored. Nobody is watching the SharePoint server's outbound network connections.
• Legacy code. Large ASP.NET or Java applications with decades of accumulated surface area.

The cloud versions of these products were not affected, because they are patched centrally within hours by a team whose job is exactly that.

I do not love that conclusion, and I think it is correct: for this category of software, self-hosting is now a materially worse security posture for most organizations, unless you have a team that treats it like a full-time job.

the checklist#

If you run internet-facing enterprise software:

1. Inventory what is exposed. Most organizations discover something they forgot about. Run the scan today.
2. Rotate secrets after any suspected compromise. Machine keys, service account credentials, API tokens, certificates. Patching is not eviction.
3. Assume the patch is incomplete. Add detection, not just remediation. Watch for the behaviors — unexpected child processes, outbound connections, new files in web-accessible directories — not just the signature.
4. Segment. The collaboration server should not have a path to the domain controller. This is a decades-old recommendation and it is still the highest value control nobody implements.
5. Log egress. The compromise is usually discovered by noticing data leaving, and you cannot notice what you do not record.

the uncomfortable part#

Multiple victims were security-conscious organizations with real budgets and staff. This was not a story about negligence.

The honest reading is that defending complex internet-facing enterprise software against a well-resourced attacker is very hard, patching is necessary and not sufficient, and the strategic answer is reducing how much of that software you expose at all.