By: Karrie Westmoreland
When Microsoft tells you to unplug your own servers, do not stop, do not pass Go and do not collect $200. Kindly proceed directly to your server room.
That was the reality with the SharePoint zero-day CVE-2025-53770, nicknamed “ToolShell.” Before a patch even existed, threat actors were already moving in like uninvited roommates. If you ran SharePoint exposed to the Internet, you were not hosting documents. You were hosting web shells.
After twenty years in this field, I can tell you: zero-days never arrive on a quiet Wednesday. They show up on a Friday afternoon when your SOC is running skeleton crew, the vendor has no fix, and executives want to know, “What’s the business risk?” The honest answer is usually “everything.”
ToolShell was textbook zero-day chaos. Remote code execution gave adversaries control. Persistence through web shells kept them there. Privilege escalation turned it from a crack in the wall into a full-blown breach.
For organizations that treat SharePoint as digital oxygen, this was suffocation waiting to happen.
Here is how the bad guys cashed in:
Nothing innovative. Just brutally effective.
Zero-days do not show up gift-wrapped in your SIEM, but they leave tracks.
I have seen defenders catch them by spotting PowerShell activity from SharePoint worker processes, something that should never happen in a healthy setup. Outbound traffic from a server that usually minds its own business is another red flag. And if ASPX files suddenly appear in your web directories, congratulations: you are now running a hostile remote access service.
Organizations with AMSI integration in Microsoft Defender had a fighting chance, since AMSI could intercept malicious scripts in real time. Without it, defenders were left hoping vigilance and log analysis would pick up the slack.
Hope, as we will get to, is not a strategy.
When a fix does not exist, defenders improvise. Microsoft’s guidance was blunt: if you cannot enable AMSI, disconnect the servers.
Translation: if your house is on fire, stop leaving the front door wide open.
Others layered defenses as best they could. Segmenting SharePoint servers away from the rest of the network. Monitoring file integrity like it owed them rent. Using AMSI wherever possible to choke off malicious scripts.
The goal was not elegance. It was survival until reinforcements arrived.
If ToolShell taught us anything, it is that “patch and pray” is not a plan.
Here is what your no-patch playbook should include:
If you are drafting this playbook mid-incident, you are already behind.
I have seen this movie before. Different CVE, same plot. Vendors scramble. Threat actors sprint. Defenders improvise.
The strongest organizations are not the ones with the fastest patch cycles. They are the ones that can survive the “no patch” window without burning the place down.
Zero-days are not just a SOC problem. They are board-level events. When a vendor says “disconnect critical systems,” that is a business continuity issue, not just an IT ticket. Executives need to support security teams when they make hard calls, even if it disrupts operations.
The real lesson: have a no-patch playbook ready before the crisis. It is cheaper to plan downtime on your own terms than to suffer downtime on an adversary’s terms.
Zero-days remind us that patching is a tactic, not a strategy. Resilience comes from defense in depth, strong detection, and a playbook built on clear skies, not cloudy days.
Because once the patch arrives, the race does not end. Threat actors pivot to the laggards. If you are still dragging your feet, you have effectively put out a welcome mat.
Does your organization have a no-patch playbook, or are you still betting on hope and luck? Just remember: hope is not a control, and luck does not show up on your risk dashboard.
Primary Image Concept: A cracked SharePoint logo reimagined as a shield, with defenders bracing it using makeshift planks and barriers — a visual metaphor for holding the line until reinforcements arrive.