ToolShell Aftermath: What Defenders Should Do After Patching CVE-2025-53770

by Nextron Threat Research TeamJul 25, 2025

The recently exploited SharePoint vulnerability chain known as ToolShell (CVE-2025-53770) has shown once again that patching alone isn’t enough. Attackers gained unauthenticated remote access to vulnerable on-premises SharePoint servers, planted web shells, and exfiltrated cryptographic keys to enable further exploitation.

Now that patches are rolling out, defenders must assume compromise and verify the integrity of their systems. Here’s what you need to know and do.

At Nextron, we focus on the second part of any response to a threat like this: detection engineering. While others analyze the threat itself, we ensure that defenders have the best rules, indicators, and tooling to find traces of it on their systems. What sets our approach apart is that we don’t just write rules – we create structured detection intelligence that includes rich metadata, threat actor links, malware family tags, and technique mappings.

We maintain and apply this detection intelligence across two scanning engines:

How Our Scanners Apply Detection Intelligence

We use two complementary tools to deploy our rulesets effectively:

THOR: Our on-demand scanner that runs on endpoints or as a network service. It supports:
- YARA rules for detection across files, registry, process memory, and more
- Sigma rules for event log and process analysis
- IOC matching across file names, hashes, and strings
THOR doesn’t just scan files – it also applies process-related rules to the live process tree and registry-related rules to the current registry state. That means we cover artifacts others might miss.
Aurora: Our lightweight real-time endpoint agent. It applies:
- Sigma rules to Windows ETW (Event Tracing for Windows) streams
- IOC matching on live event data
Aurora doesn’t depend on audit policies or log availability. It sees what happens on the endpoint in real-time, applies detection logic locally, and only sends compact, meaningful alerts to central systems – perfect for environments that care about bandwidth or data privacy.

Together, these tools allow us to cover a wide spectrum of evidence – from dropped files and web shells to command line patterns and registry changes – with tailored detection rules. Our goal is to give defenders the best possible insight into post-compromise activity.

What Happened

ToolShell combines multiple bugs into a working unauthenticated remote code execution (RCE) chain affecting on-premises SharePoint. The attackers exploited the endpoint:

/_layouts/15/ToolPane.aspx

using a crafted POST request and an unusual Referer header:

/_layouts/SignOut.aspx

This allowed them to drop malicious ASPX files to disk and later interact with them via HTTP requests, no login required.

Stable Detection Patterns

Based on the nature of the vulnerability and the exploitation method, we distinguish between stable, technique-level indicators and campaign-specific artifacts:

Stable indicators (expected to remain relevant across future exploitation variants):

POST requests to /_layouts/15/ToolPane.aspx
Referer header set to /_layouts/SignOut.aspx
Creation of .aspx files in SharePoint’s LAYOUTS directory
PowerShell processes spawned from w3wp.exe (SharePoint worker)

Campaign-specific indicators (seen in this wave, may not generalize):

GET requests to suspected web shells such as /_layouts/15/spinstall0.aspx (number may change)
GET requests to suspected web shells such as /_layouts/15/ghostfile000.aspx (numbers are different per attack)

Note: Since these filenames often include varying numbers or version suffixes, our detection rules and IOCs use regular expressions to match the broader pattern. This ensures we detect all known variants, even if filenames differ slightly between attacks.

Indicators of the Initial Exploitation Campaign

IOCs from the first exploitation waves include:

Web shell filename: spinstall0.aspx (the number at the end can be different or left out entirely)
Web shell filenames: ghostfile399.aspx (the number at the end differs for each attack)
Dropper behavior: PowerShell writing decoded base64 payloads to disk
File paths:
- C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\spinstall0.aspx
- C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\ghostfile399.aspx
- C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\debug_dev.js
- C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\1.css
- C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\ghostfile399.aspx`
- Similar variants under 16\TEMPLATE\LAYOUTS\
IPs linked to early activity (see Eye Security report)
Base64 strings containing layout paths or webshell filenames like spinstall0.aspx and ghostfile399.aspx

Note: The filename used (spinstall0.aspx) is not required by the exploit chain. It’s simply what the attacker used in this campaign. There are different variants using other version numbers or no number at all. Future attacks might use entirely different names.

Why Patching Isn’t Enough

This was an unauthenticated RCE. If your SharePoint server was exposed to the internet, you have to assume compromise. Web shells could still be present, credentials may have been harvested, and cryptographic keys (MachineKeys) may have been stolen.

Even if your EDR didn’t raise any alerts, log coverage or policy gaps may have allowed the attack to go unnoticed. That’s why we see post-patch compromise assessment as a mandatory component of incident response. It serves to verify system integrity, detect potential persistence mechanisms, and identify evidence of credential or key material compromise. Without this validation step, organizations risk leaving undetected backdoors in place.

Our Recommendation: Run a THOR Scan

After patching, we strongly recommend scanning affected systems with:

All include updated YARA rules to detect:

The web shell payloads (cleartext and compiled)
Dropper artifacts (base64 PowerShell, encoded commands)
IIS log patterns
Encoded or obfuscated exploitation logic

In fact, the web shell used in this campaign was already detectable by a generic rule from 2021 (WEBSHELL_ASP_Runtime_Compile) before the first advisory was published.

If you have an exisiting scanning solution, capable of ingesting YARA or Sigma rules, you can also use our extensive collection of public YARA rules and Sigma rules covering CVE-2025-53770 attack indicators and artefacts. Check the overview below for the most relevant rules.

Relevant YARA Rules

Rulename	Description
WEBSHELL_ASP_Runtime_Compile	Detects ASP.NET web shells using runtime compilation
WEBSHELL_ASPX_Sharepoint_Drop_CVE_2025_53770_Jul25	Detects ASPX web shell dropped during the exploitation of SharePoint RCE vulnerability CVE-2025-53770
WEBSHELL_ASPX_Compiled_Sharepoint_Drop_CVE_2025_53770_Jul25_2	Detects compiled ASPX web shell dropped during the exploitation of SharePoint RCE vulnerability CVE-2025-53770
APT_EXPL_Sharepoint_CVE_2025_53770_ForensicArtefact_Jul25_1	Detects URIs accessed during the exploitation of SharePoint RCE vulnerability CVE-2025-53770
APT_EXPL_Sharepoint_CVE_2025_53770_ForensicArtefact_Jul25_2	Detects URIs accessed during the exploitation of SharePoint RCE vulnerability CVE-2025-53770

Relevant Sigma Rules

ID	Description
ba479447-721f-42a9-9af2-6dcd517bbdb3	Detects the creation of file such as spinstall0.aspx which may indicate successful exploitation of CVE-2025-53770.
7477881c-ec3b-49d6-aced-7255944e5c59	Detects potential exploitation of CVE-2025-53770 by identifying indicators such as suspicious command lines discovered in Post-Exploitation activities.
48d053db-6a56-4866-b60d-0975647050ed	Detects access to vulnerable SharePoint components potentially being exploited in CVE-2025-53770 through IIS web server logs.