SharePoint Zero-day Persists Despite Microsoft Patches

Microsoft’s emergency fixes have not stemmed the “ToolShell” tide. The critical SharePoint zero‑day (CVE‑2025‑53770, CVSS 9.8) is still being weaponised to plant a tiny ASPX back‑door on unpatched servers, and incident‑response teams continue to log fresh intrusions daily. Redmond’s out‑of‑band updates published 19 July cover SharePoint Subscription Edition (KB 5002768) and SharePoint 2019 (KB 5002754), but SharePoint 2016 remains exposed, leaving thousands of on‑prem deployments reliant on a stop‑gap PowerShell script while attackers probe every internet‑facing portal they can find. 

SecurityWeek and Rapid7 say the campaign has already breached more than 75 organisations across finance, defence and higher‑education; telemetry shows ToolShell callers beaconing from IP ranges in Russia and Vietnam, with follow‑on payloads that dump LSASS, steal machine keys and pivot laterally.  In several cases the threat actor re‑entered even after administrators installed July’s cumulative updates, because the attackers had exfiltrated cryptographic material that let them mint new authentication cookies at will. Experts therefore stress that patching must be paired with machine‑key rotation and credential resets. 

The U.S. Cybersecurity and Infrastructure Security Agency has added CVE‑2025‑53770 to its Known Exploited Vulnerabilities (KEV) catalogue, giving federal agencies 48 hours to apply Microsoft’s mitigations or disconnect affected servers. CISA’s alert notes that ToolShell exploits a deserialisation flaw in SharePoint’s workflow engine, requires no authentication and grants SYSTEM‑level code‑execution on successful hit. 

Microsoft’s interim guidance for vulnerable SharePoint 2016 boxes boils down to four actions: (1) install all July security updates, (2) run the hardening script that blocks remote procedure calls to suspect endpoints, (3) enable AMSI‑based scanning in Defender for Endpoint, and (4) rotate machine keys and reboot IIS. Redmond says the 2016 patch is “in final validation” and should land “within days,” but has not committed to a firm date. 

Detection teams should hunt for newly created ToolShell.aspx, spinstall0.aspx or similarly named files in /_layouts/15 and review logs for the user‑agent string toolshell‑loader/1.3 or outbound traffic to 94.103.9[.]0/24 and 193.23.181[.]0/24. Rapid7 warns that the campaign is “deliberate and persistence‑oriented,” with operators revisiting servers to drop Cobalt Strike and Bughatch within hours of initial compromise.

Here’s the bottom line, if your SharePoint server still faces the open internet and does not have KB 5002768 or KB 5002754 (or their forthcoming 2016 equivalent) plus rotated machine keys, you remain a sitting duck. Administrators unable to patch immediately should remove public exposure, implement Microsoft’s mitigation script and comb logs for any sign ToolShell has landed—because attackers aren’t waiting for the final update, and neither should you.