On July 19–20, 2025, various security companies and national CERTs published alerts about active exploitation of on-premise SharePoint servers. According to the reports, observed attacks did not require authentication, allowed attackers to gain full control over the infected servers, and were performed using an exploit chain of two vulnerabilities: CVE-2025-49704 and CVE-2025-49706, publicly named “ToolShell”. Additionally, on the same dates, Microsoft released out-of-band security patches for the vulnerabilities CVE-2025-53770 and CVE-2025-53771, aimed at addressing the security bypasses of previously issued fixes for CVE-2025-49704 and CVE-2025-49706. The release of the new, “proper” updates has caused confusion about exactly which vulnerabilities attackers are exploiting and whether they are using zero-day exploits.

Kaspersky products proactively detected and blocked malicious activity linked to these attacks, which allowed us to gather statistics about the timeframe and spread of this campaign. Our statistics show that widespread exploitation started on July 18, 2025, and attackers targeted servers across the world in Egypt, Jordan, Russia, Vietnam, and Zambia. Entities across multiple sectors were affected: government, finance, manufacturing, forestry, and agriculture.

While analyzing all artifacts related to these attacks, which were detected by our products and public information provided by external researchers, we found a dump of a POST request that was claimed to contain the malicious payload used in these attacks. After performing our own analysis, we were able to confirm that this dump indeed contained the malicious payload detected by our technologies, and that sending this single request to an affected SharePoint installation was enough to execute the malicious payload there.

Our analysis of the exploit showed that it did rely on vulnerabilities fixed under CVE-2025-49704 and CVE-2025-49706, but by changing just one byte in the request, we were able to bypass those fixes.

In this post, we provide detailed information about CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771, and one related vulnerability. Since the exploit code is already published online, is very easy to use, and poses a significant risk, we encourage all organizations to install the necessary updates.

The exploit

Our research started with an analysis of a POST request dump associated with this wave of attacks on SharePoint servers.

Snippet of the exploit POST request

We can see that this POST request targets the “/_layouts/15/ToolPane.aspx” endpoint and embeds two parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. Looking at the code of ToolPane.aspx, we can see that this file itself does not contain much functionality and most of its code is located in the ToolPane class of the Microsoft.SharePoint.WebPartPages namespace in Microsoft.SharePoint.dll. Looking at this class reveals the code that works with the two parameters present in the exploit. However, accessing this endpoint under normal conditions is not possible without bypassing authentication on the attacked SharePoint server. This is where the first Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49706 comes into play.

CVE-2025-49706

This vulnerability is present in the method PostAuthenticateRequestHandler, in Microsoft.SharePoint.dll. SharePoint requires Internet Information Services (IIS) to be configured in integrated mode. In this mode, the IIS and ASP.NET authentication stages are unified. As a result, the outcome of IIS authentication is not determined until the PostAuthenticateRequest stage, at which point both the ASP.NET and IIS authentication methods have been completed. Therefore, the PostAuthenticateRequestHandler method utilizes a series of flags to track potential authentication violations. A logic bug in this method enables an authentication bypass if the “Referrer” header of the HTTP request is equal to “/_layouts/SignOut.aspx”, “/_layouts/14/SignOut.aspx”, or “/_layouts/15/SignOut.aspx” using case insensitive comparison.

Vulnerable code in PostAuthenticateRequestHandler method (Microsoft.SharePoint.dll version 16.0.10417.20018)

The code displayed in the image above handles the sign-out request and is also triggered when the sign-out page is specified as the referrer. When flag6 is set to false and flag7 is set to true, both conditional branches that could potentially throw an “Unauthorized Access” exception are bypassed.

Unauthorized access checks bypassed by the exploit

On July 8, 2025, Microsoft released an update that addressed this vulnerability by introducing additional checks to detect the usage of the “ToolPane.aspx” endpoint with the sign-out page specified as the referrer.

CVE-2025-49706 fix (Microsoft.SharePoint.dll version 16.0.10417.20027)

The added check uses case insensitive comparison to verify if the requested path ends with “ToolPane.aspx”. Is it possible to bypass this check, say, by using a different endpoint? Our testing has shown that this check can be easily bypassed.

CVE-2025-53771

We were able to successfully bypass the patch for vulnerability CVE-2025-49706 by adding just one byte to the exploit POST request. All that was required to bypass this patch was to add a “/” (slash) to the end of the requested “ToolPane.aspx” path.

Bypass for CVE-2025-49706 fix

On July 20, 2025, Microsoft released an update that fixed this bypass as CVE-2025-53771. This fix replaces the “ToolPane.aspx” check to instead check whether the requested path is in the list of paths allowed for use with the sign-out page specified as the referrer.

CVE-2025-53771 fix (Microsoft.SharePoint.dll version 16.0.10417.20037)

This allowlist includes the following paths: “/_layouts/15/SignOut.aspx”, “/_layouts/15/1033/initstrings.js”, “/_layouts/15/init.js”, “/_layouts/15/theming.js”, “/ScriptResource.axd”, “/_layouts/15/blank.js”, “/ScriptResource.axd”, “/WebResource.axd”, “/_layouts/15/1033/styles/corev15.css”, “/_layouts/15/1033/styles/error.css”, “/_layouts/15/images/favicon.ico”, “/_layouts/15/1033/strings.js”, “/_layouts/15/core.js”, and it can contain additional paths added by the administrator.

While testing the CVE-2025-49706 bypass with the July 8, 2025 updates installed on our SharePoint debugging stand, we noticed some strange behavior. Not only did the bypass of CVE-2025-49706 work, but the entire exploit chain did! But wait! Didn’t the attackers use an additional Microsoft SharePoint Remote Code Execution Vulnerability CVE-2025-49704, which was supposed to be fixed in the same update? To understand why the entire exploit chain worked in our case, let’s take a look at the vulnerability CVE-2025-49704 and how it was fixed.

CVE-2025-49704

CVE-2025-49704 is an untrusted data deserialization vulnerability that exists due to improper validation of XML content. Looking at the exploit POST request, we can see that it contains two URL encoded parameters: “MSOtlPn_Uri” and “MSOtlPn_DWP”. We can see how they are handled by examining the code of the method GetPartPreviewAndPropertiesFromMarkup in Microsoft.SharePoint.dll. A quick analysis reveals that “MSOtlPn_Uri”  is a page URL that might be pointing to an any file in the CONTROLTEMPLATES folder and the parameter “MSOtlPn_DWP” contains something known as WebPart markup. This markup contains special directives that can be used to execute safe controls on a server and has a format very similar to XML.

WebPart markup used by the attackers

While this “XML” included in the “MSOtlPn_DWP” parameter does not itself contain a vulnerability, it allows attackers to instantiate the ExcelDataSet control from Microsoft.PerformancePoint.Scorecards.Client.dll with CompressedDataTable property set to malicious payload and trigger its processing using DataTable property getter.

Code of the method that handles the contents of ExcelDataSet’s CompressedDataTable property in the DataTable property getter

Looking at the code of the ExcelDataSet’s DataTable property getter in Microsoft.PerformancePoint.Scorecards.Client.dll, we find the method GetObjectFromCompressedBase64String, responsible for deserialization of CompressedDataTable property contents. The data provided as Base64 string is decoded, unzipped, and passed to the BinarySerialization.Deserialize method from Microsoft.SharePoint.dll.

DataSet with XML content exploiting CVE-2025-49704 (deserialized)

Attackers use this method to provide a malicious DataSet whose deserialized content is shown in the image above. It contains an XML with an element of dangerous type "System.Collections.Generic.List`1[[System.Data.Services.Internal.ExpandedWrapper`2[...], System.Data.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]", which allows attackers to execute arbitrary methods with the help of the well-known ExpandedWrapper technique aimed at exploitation of unsafe XML deserialization in applications based on the .NET framework. In fact, this shouldn’t be possible, since BinarySerialization.Deserialize in Microsoft.SharePoint.dll uses a special XmlValidator designed to protect against this technique by checking the types of all elements present in the provided XML and ensuring that they are on the list of allowed types. However, the exploit bypasses this check by placing the ExpandedWrapper object into the list.

Now, to find out why the exploit worked on our SharePoint debugging stand with the July 8, 2025 updates installed, let’s take a look at how this vulnerability was fixed. In this patch, Microsoft did not really fix the vulnerability but only mitigated it by adding the new AddExcelDataSetToSafeControls class to the Microsoft.SharePoint.Upgrade namespace. This class contains new code that modifies the web.config file and marks the Microsoft.PerformancePoint.Scorecards.ExcelDataSet control as unsafe. Because SharePoint does not execute this code on its own after installing updates, the only way to achieve the security effect was to manually run a configuration upgrade using the SharePoint Products Configuration Wizard tool. Notably, the security guidance for CVE-2025-49704 does not mention the need for this step, which means at least some SharePoint administrators may skip it. Meanwhile, anyone who installed this update but did not manually perform a configuration upgrade remained vulnerable.

CVE-2025-53770

On July 20, 2025, Microsoft released an update with a proper fix for the CVE-2025-49704 vulnerability. This patch introduces an updated XmlValidator that now properly validates element types in XML, preventing exploitation of this vulnerability without requiring a configuration upgrade and, more importantly, addressing the root cause and preventing exploitation of the same vulnerability through controls other than Microsoft.PerformancePoint.Scorecards.ExcelDataSet.

Code of new type verifier in updated XmlValidator

CVE-2020-1147

Readers familiar with previous SharePoint exploits might feel that the vulnerability CVE-2025-49704/CVE-2025-53770 and the exploit used by the attackers looks very familiar and very similar to the older .NET Framework, SharePoint Server, and Visual Studio Remote Code Execution Vulnerability CVE-2020-1147. In fact, if we compare the exploit for CVE-2020-1147 and an exploit for CVE-2025-49704/CVE-2025-53770, we can see that they are almost identical. The only difference is that in the exploit for CVE-2025-49704/CVE-2025-53770, the dangerous ExpandedWrapper object is placed in the list. This makes CVE-2025-53770 an updated fix for CVE-2020-1147.

DataSet with XML content exploiting CVE-2020-1147

Conclusions

Despite the fact that patches for the ToolShell vulnerabilities are now available for deployment, we assess that this chain of exploits will continue being used by attackers for a long time. We have been observing the same situation with other notorious vulnerabilities, such as ProxyLogon, PrintNightmare, or EternalBlue. While they have been known for years, many threat actors still continue leveraging them in their attacks to compromise unpatched systems. We expect the ToolShell vulnerabilities to follow the same fate, as they can be exploited with extremely low effort and allow full control over the vulnerable server.

To stay better protected against threats like ToolShell, we as a community should learn lessons from previous events in the industry related to critical vulnerabilities. Specifically, the speed of applying security patches nowadays is the most important factor when it comes to fighting such vulnerabilities. Since public exploits for these dangerous vulnerabilities appear very soon after vulnerability announcements, it is paramount to install patches as soon as possible, as a gap of even a few hours can make a critical difference.

At the same time, it is important to protect enterprise networks against zero-day exploits, which can be leveraged when there is no available public patch for vulnerabilities. In this regard, it is critical to equip machines with reliable cybersecurity solutions that have proven effective in combatting ToolShell attacks before they were publicly disclosed.

Kaspersky Next with its Behaviour detection component proactively protects against  exploitation of these vulnerabilities. Additionally, it is able to detect exploitation and the subsequent malicious activity.

Kaspersky products detect the exploits and malware used in these attacks with the following verdicts:

• UDS:DangerousObject.Multi.Generic
• PDM:Exploit.Win32.Generic
• PDM:Trojan.Win32.Generic
• HEUR:Trojan.MSIL.Agent.gen
• ASP.Agent.*
• PowerShell.Agent.*

A new, critical zero-day vulnerability dubbed “ToolShell” (CVE-2025-53770) poses a significant threat to on-premises SharePoint Server deployments. This vulnerability enables unauthenticated remote code execution (RCE), posing a significant risk to organizations worldwide. SentinelOne has detected exploitation in the wild, elevating the active threat posed by this new attack and the importance of organizations taking mitigative action as soon as possible.

In this blog, we outline ways to defend against ToolShell and how SentinelOne keeps you ahead of the curve for this critical vulnerability. For a comprehensive technical breakdown of this threat, we published a detailed analysis on the SentinelOne blog.

What is ToolShell?

ToolShell is a critical zero-day remote code execution vulnerability impacting on-premises SharePoint Servers. Its severity stems from several key characteristics:

• Zero-Day Status: It was previously unknown and unpatched, leaving organizations exposed before official fixes were available.
• High CVSS Score (9.8): This indicates near-maximum severity, signifying a critical vulnerability with a high impact.
• No Authentication Required: Attackers can exploit ToolShell without needing valid credentials, making it incredibly easy to compromise vulnerable systems.
• Remote Code Execution (RCE): Successful exploitation grants attackers the ability to execute arbitrary code on the compromised SharePoint Server, potentially leading to full system control, data exfiltration, or further lateral movement across the network.
• In-the-Wild Exploitation: Threat actors are already actively leveraging this vulnerability, highlighting the immediate and tangible danger it poses.

SentinelOne’s Defense Against ToolShell

At SentinelOne, our commitment to proactive security means we are constantly working to identify and neutralize emerging threats, such as ToolShell, often before they become widespread news. SentinelOne was aware and working to defend our customers from ToolShell two days prior to the public announcement of the vulnerability.  This integrated approach ensures that SentinelOne customers are protected from the outset:

• SentinelOne’s Identification and Breakdown of the Vulnerability: Our world-class threat research team, SentinelLABS, along with our MDR team, swiftly identified and performed an in-depth technical analysis of the ToolShell vulnerability. This early insight is critical for developing effective countermeasures.
• Out-of-the-Box Detection Logic for SentinelOne Customers: Based on the detailed analysis from SentinelLABS, our engineering teams rapidly developed and implemented robust, out-of-the-box detection logic directly into the SentinelOne platform. This means that SentinelOne customers automatically received protection against ToolShell.
• Seamless IOC Integration: The IOCs identified by SentinelLABS are automatically integrated into the SentinelOne platform, enhancing its ability to detect and prevent ToolShell-related activity across all monitored endpoints.
• Hunting Queries for Singularity Platform Users: For security teams leveraging the SentinelOne Singularity Platform, we have made specific hunting queries available below, as well as in our technical breakdown of this vulnerability. These queries empower security analysts to proactively search for any signs of ToolShell activity within their environments, ensuring comprehensive visibility and enabling rapid response.
• Proactive Detection Through Singularity Vulnerability Management: SentinelOne customers who use Singularity Vulnerability Management can also detect instances of ToolShell within their environment, enabling teams to identify and mitigate the vulnerability before it is exploited during an active attack.

How to Defend Against ToolShell

Given the critical nature of ToolShell, we strongly recommend that organizations implement a multi-layered defense strategy. Proactive measures are crucial to mitigate the risk of compromise:

Immediate Mitigation & Patching:

• Isolate SharePoint instances from public availability: Whenever possible, restrict access to on-premises SharePoint Servers from the public internet. This significantly reduces your attack surface.
• Enable Antimalware Scan Interface (AMSI) in Full Mode: The Antimalware Scan Interface (AMSI) is an interface standard that enables SharePoint to integrate with your endpoint protection solution’s scanning capabilities. While AMSI was enabled by default in the September 2023 SharePoint update, organizations that do not have this capability configured should enable the integration as soon as possible.
• Apply available patches immediately: Microsoft has released security updates to address ToolShell for SharePoint Subscription and 2019 versions. Organizations should prioritize and deploy these patches as soon as possible.

Enhanced Detection and Monitoring:

• Integrate Indicators of Compromise (IOCs): SentinelLABS has provided specific IOCs related to the ToolShell exploitation, as detailed below and in SentinelOne’s technical breakdown. These should be promptly added to your EDR/XDR and SIEM toolsets for detecting potential exploitation in your environment. SentinelOne customers are encouraged to enable the platform detection rules for ToolShell that have already been added to your Platform Detection Library.
• Monitor for Suspicious SharePoint Behavior: Deploy custom detection rules to monitor key SharePoint directories, specifically the `LAYOUTS` directory, to detect the presence of exploitation and the subsequent web shell. For SentinelOne users, relevant rules are provided in the Platform Detection Library.
• Retroactive Threat Hunting: If you are currently running on-premises SharePoint Server, retroactive threat hunting for ToolShell exploitation is highly recommended.

Conclusion

ToolShell represents a significant vulnerability that leaves many organizations running on-premises SharePoint Server at considerable risk. The potential for unauthenticated remote code execution, coupled with observed in-the-wild exploitation, underscores the urgent need for organizations to take decisive action to maintain their security posture. This includes diligently applying patches, implementing robust monitoring, and leveraging advanced threat detection capabilities to mitigate the risk.

For SentinelOne customers, you can rest assured that you are protected. Our dedicated threat research and MDR teams work tirelessly to stay one step ahead of adversaries, ensuring that our platform provides immediate and effective defense against emerging threats, such as ToolShell. Our proactive identification, rapid deployment of detection logic, and continuous sharing of intelligence empower our customers to maintain a resilient security posture.

Contact SentinelOne today to learn how our AI-powered security platform can provide the comprehensive protection and peace of mind your organization deserves. Don’t wait for the next zero-day; secure your future today.

Indicators of Compromise

SHA-1

f5b60a8ead96703080e73a1f79c3e70ff44df271 – spinstall0.aspx webshell
fe3a3042890c1f11361368aeb2cc12647a6fdae1 – xxx.aspx webshell
76746b48a78a3828b64924f4aedca2e4c49b6735 – App_Web_spinstall0.aspx.9c9699a8.avz5nq6f.dll, a compiled version of spinstall0.aspx

IP Addresses

96.9.125[.]147 – attacker IP from “no shell” cluster
107.191.58[.]76 – attacker IP used in 1st wave of spinstall0.aspx cluster
104.238.159[.]149 – attacker IP used in 2nd wave of spinstall0.aspx cluster

New SentinelOne Platform Detection Rules

• Web Shell Creation in LAYOUTS Directory
• Web Shell File Detected in LAYOUTS Directory
• Suspicious Process Spawned by SharePoint IIS Worker Process

SentinelOne Platform Hunting Queries

//Suspicious SharePoint Activity

dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.parent.name contains "svchost.exe" and src.process.name contains "w3wp.exe" and tgt.process.name contains "cmd.exe" and src.process.cmdline contains "SharePoint"

//spinstall0.aspx execution traces

dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.name contains "csc.exe" and tgt.file.path contains "App_Web_spinstall0.aspx"

Disclaimer

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

On July 19th, Microsoft confirmed that a 0-day vulnerability impacting on-premises Microsoft SharePoint Servers, dubbed “ToolShell” (by researcher Khoa Dinh @_l0gg), was being actively exploited in the wild. This flaw has since been assigned the identifier CVE‑2025‑53770, along with an accompanying bypass tracked as CVE‑2025‑53771. These two new CVEs are being used alongside the previously patched CVEs (49704/49706) which were patched on July 8th, with PoC code surfacing by July 14th.

The advisory also confirmed emergency patches for on-prem SharePoint Subscription Edition and SharePoint Server  2019, with updates scheduled for version 2016 as well. We strongly recommend immediate patching, and following Microsoft’s recommendations of enabling AMSI detection, rotating ASP.NET machine keys, and isolating public-facing SharePoint servers until defenses are in place.

SentinelOne first observed ToolShell exploitation on July 17th, ahead of official Microsoft advisories. Since then, we’ve identified three distinct attack clusters, each with unique tradecraft and objectives. In this blog, we unpack the timeline, explore these clusters, and equip defenders with best-practice mitigation strategies. At this time, we provide no attribution beyond this early clustering as research is ongoing.

Observed Targets

We have observed initial ToolShell exploitation against high value organizations, with victims primarily in technology consulting, manufacturing, critical infrastructure, and professional services tied to sensitive architecture and engineering organizations. The early targets suggest that the activity was initially carefully selective, aimed at organizations with strategic value or elevated access.

The attacks that we describe in this report were targeted in nature and occurred before public disclosure of the vulnerability spurred mass exploitation efforts from a wider set of actors. We expect broader exploitation attempts to accelerate, driven by both state-linked and financially motivated actors seeking to capitalize on unpatched systems.

SentinelOne has observed multiple state-aligned threat actors, unrelated to the first wave of exploitation, beginning to engage in reconnaissance and early-stage exploitation activities. Additionally, we’ve also identified actors possibly standing up decoy honeypot environments to collect and test exploit implementations , as well as sharing tooling and tradecraft across known sharing platforms. As awareness spreads within these communities, we expect further weaponization and sustained targeting of vulnerable SharePoint infrastructure.

Technical Overview

Both previously patched CVEs (49704/49706) were first disclosed at Pwn2Own Berlin. It was later discovered that these two flaws could be paired together to produce the full RCE ‘ToolShell’ attack chain. The name ‘ToolShell’ refers to the initial abuse of SharePoint’s /ToolPane.aspx (CVE-2025-49704), a system page used for website configuration and management.

This vulnerability chain enables unauthenticated remote code execution by sending a crafted POST request to the URI /layouts/15/ToolPane.aspx?DisplayMode=Edit, exploiting a logic flaw in the Referer header validation. This bypass allows attackers to access SharePoint’s ToolPane functionality without authentication, ultimately leading to code execution via uploaded or in-memory web components.

xxx.aspx

On July 18th, 2025 at 09:58 GMT, SentinelOne observed a single exploitation attempt where the attacker dropped a custom password-protected ASPX webshell named xxx.aspx. This activity appears to be hands-on and exploratory in nature, likely performed by a human operator rather than an automated script.

The webshell was written to the following path:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\xxx.aspx

This webshell provides a basic HTML interface allowing three primary functions:

1. Authentication via an embedded form that sets a cookie.
2. Command Execution by submitting commands through the GTaRkhJ9wz parameter, which are run via cmd.exe and returned to the client.
3. File Upload via a multipart form using fields 0z3H8H8atO (file) and 7KAjlfecWF (destination path).

The shell leverages basic obfuscation and validation mechanisms, including cookie-based authentication and a hardcoded SHA512 hash to restrict access. The password check logic suggests the actor anticipated repeated or remote usage of the shell.

After the webshell was dropped, the attacker issued the following commands:

cmd.exe /c whoami > c:\progra~1\common~1\micros~1\webser~1\16\template\layouts\info.js

The first attempt to redirect the whoami output failed due to a typo (\templa), indicating the activity was likely manual and exploratory. The corrected second command successfully writes the output of whoami into a web-accessible .js file, a common tactic for validating command execution and potentially retrieving output through a browser.

While this activity was limited to a single observed instance, the customized tooling and interactive behavior suggest a deliberate post-exploitation attempt by a threat actor testing or preparing for broader operations.

spinstall0.aspx

SentinelOne observed two distinct waves of activity involving a consistent final payload, spinstall0.aspx, dropped across SharePoint environments from different attacker infrastructure on July 18 and 19, 2025. While the initial dropper scripts varied slightly between waves, both resulted in deployment of the same webshell, designed to extract and expose sensitive cryptographic material from the host.

First Wave – July 18, 2025 (14:54–18:44 GMT)

Source IP: 107.191.58[.]76

This initial wave involved PowerShell-based payload delivery. A base64-encoded blob was decoded and written to the SharePoint LAYOUTS directory:

$base64String = [REDACTED]
$destinationFile = "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx"
$decodedBytes = [System.Convert]::FromBase64String($base64String)
$decodedContent = [System.Text.Encoding]::UTF8.GetString($decodedBytes)
$decodedContent | Set-Content -Path $destinationFile -ErrorAction Stop

The resulting file, spinstall0.aspx, is not a traditional command webshell but rather a reconnaissance and persistence utility:

<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>

This code extracts and prints the host’s MachineKey values, including the ValidationKey, DecryptionKey, and cryptographic mode settings—information critical for attackers seeking to maintain persistent access across load-balanced SharePoint environments or to forge authentication tokens.

Second Wave – July 19, 2025 (03:06–07:59 GMT)

Source IP: 104.238.159[.]149

Roughly 12 hours later, a second wave used nearly identical logic to deliver the same spinstall0.aspx payload. The key difference was in the PowerShell staging script:

$b = [REDACTED]
$c = "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\15\TEMPLATE\LAYOUTS\spinstall0.aspx"
$d = [System.Convert]::FromBase64String($b)
$e = [System.Text.Encoding]::UTF8.GetString($d)
$e | Set-Content -Path $c -ErrorAction Stop
Start-Sleep -s 3

While the encoded payload was marginally different in form, it decoded to the same spinstall0.aspx shell. The change in target directory, from 16\TEMPLATE to 15\TEMPLATE, may reflect testing across different SharePoint versions or environments.

Unlike more interactive webshells observed in this campaign, spinstall0.aspx does not support command execution or file upload. Instead, its singular purpose appears to be information gathering, specifically targeting cryptographic secrets that could be reused to forge authentication or session tokens across SharePoint instances.

Given the uniqueness and strategic value of the MachineKey data harvested by this shell, we assess this cluster to be part of a broader effort to establish durable access into high-value SharePoint deployments.

“no shell”

This activity cluster, tracked as “no shell”, represents a more advanced and stealthy approach compared to others in this campaign. SentinelOne observed this cluster operating between July 17, 2025 10:35:04 GMT and July 18, 2025 03:51:29 GMT, making it our earliest known exploitation of CVE-2025-53770 in the wild.

Unlike the other clusters, no persistent webshells were written to disk. Instead, telemetry and behavioral indicators suggest the attackers relied on in-memory .NET module execution, avoiding traditional file-based artifacts entirely. This approach significantly complicates detection and forensic recovery, underscoring the threat posed by fileless post-exploitation techniques.

All observed activity in this cluster originated from a single IP address: 96.9.125[.]147. Despite the lack of file system artifacts, compromised hosts exhibited patterns consistent with SharePoint exploitation, followed by encoded payload delivery and dynamic assembly loading via PowerShell or native .NET reflection.

Given the timing, just days after public proof-of-concept chatter began, and the sophistication of the fileless execution chain, we assess this cluster to be either a skilled red team emulation exercise or the work of a capable threat actor with a focus on evasive access and credential harvesting.

Defenders should be especially vigilant for memory-resident activity following SharePoint exploitation attempts and should employ EDR solutions capable of detecting anomalous .NET execution patterns and assembly loading.

Conclusion

Modern threat actors are maximizing gains from patch diffing, n-day adoption, and iterative development of  exploits through fast adoption. SharePoint servers are attractive to threat actors for the high likelihood that they store sensitive organizational data. Beyond their value as a knowledge store, vulnerable SharePoint servers can be used to stage and deliver additional attack components to the victim organization for internal watering hole attacks. The ease of exploitation and potential value of the data hosted on these servers make ‘ToolShell’ a potent and dangerous attack chain.

As of this writing, SharePoint Online for Microsoft 0365 is not impacted. Our research teams have provided out-of-the-box Platform Detection rules and Hunting Queries to assist in discovering and isolating related behavior.  We recommend that vulnerable organizations apply the available security updates released by Microsoft (released July 21, 2025) to mitigate the related vulnerabilities as soon as possible. SentinelOne is actively monitoring its customer base for impact and is notifying those affected as they are identified.

Indicators of Compromise

SHA-1

f5b60a8ead96703080e73a1f79c3e70ff44df271 - spinstall0.aspx webshell
fe3a3042890c1f11361368aeb2cc12647a6fdae1 - xxx.aspx webshell
76746b48a78a3828b64924f4aedca2e4c49b6735 - App_Web_spinstall0.aspx.9c9699a8.avz5nq6f.dll, a compiled version of spinstall0.aspx

IP Addresses

96.9.125[.]147 - attacker IP from “no shell” cluster
107.191.58[.]76 - attacker IP used in 1st wave of spinstall0.aspx cluster
104.238.159[.]149 - attacker IP used in 2nd wave of spinstall0.aspx cluster

New SentinelOne Platform Detection Rules

• Web Shell Creation in LAYOUTS Directory
• Web Shell File Detected in LAYOUTS Directory
• Suspicious Process Spawned by SharePoint IIS Worker Process

SentinelOne Platform Hunting Queries

//Suspicious SharePoint Activity

dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.parent.name contains "svchost.exe" and src.process.name contains "w3wp.exe" and tgt.process.name contains "cmd.exe" and src.process.cmdline contains "SharePoint"

//spinstall0.aspx execution traces

dataSource.name = 'SentinelOne' and endpoint.os = "windows" and event.type = "Process Creation" and src.process.name contains "csc.exe" and tgt.file.path contains "App_Web_spinstall0.aspx"

Disclaimer

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

The post Detectify Security Updates for November 16 appeared first on Detectify Blog.

The post Crowdsource Success Story: From an Out-of-Scope Open Redirect to CVE-2020-1323 appeared first on Detectify Blog.