Warlock Ransomware and SharePoint ToolShell: Why Patching Alone Leaves You Exposed

Warlock ransomware operators are still exploiting on-premises Microsoft SharePoint servers through the ToolShell chain, with recent victims including a water utility, a telecommunications provider, a regional government body and a university — concentrated in Portuguese- and Spanish-speaking countries.

The patches for ToolShell shipped in July 2025. More than a year later it is still producing ransomware incidents, and the reason is specific and worth understanding: for this vulnerability, patching is not sufficient remediation. If you patched and did nothing else, an attacker who reached you first may still have access.

What ToolShell is

A chain of four SharePoint Server vulnerabilities: CVE-2025-49704, CVE-2025-49706, CVE-2025-53770 and CVE-2025-53771.

CVE-2025-53770 is the serious one — CVSS 9.8, remote code execution via insecure deserialisation of untrusted data, exploitable without authentication. It is a more severe variant of the original pair, which is why Microsoft issued a second round of patches with stronger safeguards on 19 and 22 July 2025.

This affects on-premises SharePoint Server only. SharePoint Online in Microsoft 365 is not in scope.

Why patching does not finish the job

This is the part that gets skipped, and it is the reason the campaign has such a long tail.

Attackers exploiting ToolShell extract the server's ASP.NET machine keys — the cryptographic keys SharePoint uses to sign and validate authentication tokens and view state. With those keys, an attacker can forge valid tokens and authenticate as any user, indefinitely, without needing the vulnerability again and without needing a password.

Patching closes the hole they came through. It does nothing about the keys they already copied. The access survives the update, survives a reboot, and survives a password reset.

Microsoft's guidance is explicit: rotate the SharePoint server ASP.NET machine keys and restart IIS on all SharePoint servers after applying the updates or enabling AMSI.

What to do, in order

1. Patch. Current security updates for your SharePoint Server version. If you are on a version no longer receiving updates, that is a migration decision, not a patching one.

2. Enable AMSI if it is not already on, and ensure Microsoft Defender Antivirus or an equivalent is running on the SharePoint servers.

3. Rotate the machine keys. This is the step that evicts the attacker.

Via PowerShell:

Set-SPMachineKey -WebApplication <SPWebApplicationPipeBind>
Update-SPMachineKey -WebApplication <SPWebApplicationPipeBind>

Then restart IIS on every SharePoint server in the farm:

iisreset.exe

Or through Central Administration: Monitoring → Review job definitions → Machine Key Rotation Job → Run Now, then restart IIS across the farm.

Order matters. Rotating keys before patching leaves the hole open to take fresh ones.

4. Hunt for what was already placed. Rotation removes the forged-token path; it does not remove a web shell. Look for:

• unexpected .aspx files in SharePoint layouts directories — spinstall0.aspx and variants were the signature in the original campaign, but assume the filename has changed
• unexpected IIS worker process child processes, particularly cmd.exe or powershell.exe spawned by w3wp.exe
• new local or farm administrator accounts
• scheduled tasks and services created around the time of suspected access
• outbound connections from SharePoint servers to unfamiliar addresses

5. Check for the driver abuse. Microsoft has reported Warlock attackers abusing a vulnerable signed driver to disable security tooling before deploying ransomware — the technique generally called bring-your-own-vulnerable-driver. Practically: confirm your EDR was actually running and reporting throughout the period in question. A gap in telemetry is a finding, not an absence of findings. Microsoft's vulnerable driver blocklist should be enabled.

6. Assume credential exposure. A compromised SharePoint server usually holds service account credentials and sits inside the domain. Rotate the farm service accounts, and treat any account that authenticated to the server during the window as suspect.

Suggestions beyond this incident

Get on-premises SharePoint off the internet. If external users need SharePoint content, publishing it directly is the expensive way. A reverse proxy with authentication in front, or migration of externally-shared content to SharePoint Online, removes the pre-authentication attack surface entirely. Nearly every ToolShell victim was internet-reachable.

Treat extractable secrets as a design problem. The lesson generalises past SharePoint: when a compromise yields keys or tokens, remediation has to include rotation. The same logic applies to Active Directory (krbtgt), SAML signing certificates, API keys and session-signing secrets. Build the rotation procedure before you need it, because doing it for the first time during an incident is how farms break.

Make the migration decision deliberately. On-premises SharePoint is a large internet-facing application stack that you are responsible for patching inside hours. That is a legitimate choice with a real cost. If you are keeping it, resource it: segmented, proxied, logged externally, patched on a short cycle. If you are not, the project has a clearer business case after the fourth emergency patch than before it.

Segment it. A SharePoint server does not need to reach the whole internal network. See network segmentation.

Have ransomware controls that work before you need them. Offline or immutable backups, tested restores, and EDR you can confirm was running. Our piece on ransomware readiness controls that work is the longer version.

The honest summary

ToolShell is over a year old, patched, and still causing ransomware incidents at utilities and public bodies. That is not a vendor failure — Microsoft shipped emergency patches within days and published clear guidance including the key rotation step.

It is a remediation-completeness failure. Organisations patched, closed the ticket, and left the keys the attacker had already taken. If your SharePoint servers were internet-facing in July 2025 and you have not rotated the machine keys since, do that this week, and hunt before you assume you are clear.

Sources

• Customer guidance for SharePoint vulnerability CVE-2025-53770 — Microsoft Security Response Center
• Warlock Ransomware Attackers Hit Water and Telecom Operators — Symantec / Security.com
• ToolShell: Critical SharePoint Zero-Day Exploited in the Wild — Symantec / Security.com
• ToolShell: Details of CVEs affecting SharePoint servers — Cisco Talos
• SharePoint ToolShell Exploitation, Campaign C0058 — MITRE ATT&CK