ngrok-free[.]app

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. 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. 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. 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. 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. 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. 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. 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. 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. 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.List1[[System.Data.Services.Internal.ExpandedWrapper2[...], 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. 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. 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.*

The recently disclosed critical Microsoft SharePoint vulnerability has been under exploitation as early as July 7, 2025, according to findings from Check Point Research. The cybersecurity company said it observed first exploitation attempts targeting an unnamed major Western government, with the activity intensifying on July 18 and 19, spanning government, telecommunications, and software sectors in North America and Western Europe. Check Point also said the exploitation efforts originated from three different IP addresses – 104.238.159[.]149, 107.191.58[.]76, and 96.9.125[.]147 – one of which was previously tied to the weaponization of security flaws in Ivanti Endpoint Manager Mobile (EPMM) appliances (CVE-2025-4427 and CVE-2025-4428). "We're witnessing an urgent and active threat: a critical zero-day in SharePoint on-prem is being exploited in the wild, putting thousands of global organizations at risk," Lotem Finkelstein, Director of Threat Intelligence at Check Point Research, told The Hacker News. "Our team has confirmed dozens of compromise attempts across government, telecom, and tech sectors since July 7. We strongly urge enterprises to update their security systems immediately – this campaign is both sophisticated and fast-moving." The attack chains have been observed leveraging CVE-2025-53770, a newly patched remote code execution flaw in SharePoint Server, and chaining it with CVE-2025-49706, a spoofing vulnerability that was patched by Microsoft as part of its July 2025 Patch Tuesday update, to gain initial access and escalate privileges. It's worth mentioning at this stage that there are two sets of vulnerabilities in SharePoint that have come to light this month - CVE-2025-49704 (CVSS score: 8.8) - Microsoft SharePoint Remote Code Execution Vulnerability (Fixed on July 8, 2025) CVE-2025-49706 (CVSS score: 6.5) - Microsoft SharePoint Server Spoofing Vulnerability (Fixed on July 8, 2025) CVE-2025-53770 (CVSS score: 9.8) - Microsoft SharePoint Server Remote Code Execution Vulnerability CVE-2025-53771 (CVSS score: 6.5) - Microsoft SharePoint Server Spoofing Vulnerability CVE-2025-49704 and CVE-2025-49706, collectively referred to as ToolShell, is an exploitation chain that can lead to remote code execution on SharePoint Server instances. They were originally disclosed by Viettel Cyber Security during the Pwn2Own 2025 hacking competition earlier this May. CVE-2025-53770 and CVE-2025-53771, which became public knowledge over the weekend, have been described as variants of CVE-2025-49704 and CVE-2025-49706, respectively, indicating that they are bypasses for the original fixes put in place by Microsoft earlier this month. This is evidenced by the fact that Microsoft acknowledged active attacks exploiting "vulnerabilities partially addressed by the July Security Update." The company also noted in its advisories that the updates for CVE-2025-53770 and CVE-2025-53771 include "more robust protections" than the updates for CVE-2025-49704 and CVE-2025-49706. However, it bears noting that CVE-2025-53771 has not been flagged by Redmond as actively exploited in the wild. "CVE-2025-53770 exploits a weakness in how Microsoft SharePoint Server handles the deserialization of untrusted data," Martin Zugec, technical solutions director at Bitdefender, said. "Attackers are leveraging this flaw to gain unauthenticated remote code execution." This, in turn, is achieved by deploying malicious ASP.NET web shells that programmatically extract sensitive cryptographic keys. These stolen keys are subsequently leveraged to craft and sign malicious __VIEWSTATE payloads, thereby establishing persistent access and enabling the execution of arbitrary commands on SharePoint Server. According to Bitdefender telemetry, in-the-wild exploitation has been detected in the United States, Canada, Austria, Jordan, Mexico, Germany, South Africa, Switzerland, and the Netherlands, suggesting widespread abuse of the flaw. Palo Alto Networks Unit 42, in its own analysis of the campaign, said it observed commands being run to execute a Base64-encoded PowerShell command, which creates a file at the location "C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx" and then parses its content. "The spinstall0.aspx file is a web shell that can execute various functions to retrieve ValidationKeys, DecryptionKeys, and the CompatabilityMode of the server, which are needed to forge ViewState Encryption keys," Unit 42 said in a threat brief. In an advisory issued Monday, SentinelOne said it first detected exploitation on July 17, with the cybersecurity company identifying three "distinct attack clusters," including state-aligned threat actors, engaging in reconnaissance and early-stage exploitation activities. Targets of the campaigns include 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," researchers Simon Kenin, Jim Walter, and Tom Hegel said. Analysis of the attack activity has revealed the use of a password-protected ASPX web shell ("xxx.aspx") on July 18, 2025, at 9:58 a.m. GMT. The web shell supports three functions: Authentication via an embedded form, command execution via cmd.exe, and file upload. Subsequent exploitation efforts have been found to employ the "spinstall0.aspx" web shell to extract and expose sensitive cryptographic material from the host. Spinstall0.aspx is "not a traditional command web shell but rather a reconnaissance and persistence utility," the researchers explained. "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." Unlike other web shells that are typically dropped on internet-exposed servers to facilitate remote access, spinstall0.aspx appears to be designed with the sole intention of gathering cryptographic secrets that could then be used to forge authentication or session tokens across SharePoint instances. These attacks, per CrowdStrike, commence with a specially crafted HTTP POST request to an accessible SharePoint server via the "/_layouts/15/ToolPane.aspx" endpoint that attempts to write spinstall0.aspx via PowerShell. The company said it blocked hundreds of exploitation attempts across more than 160 customer environments. SentinelOne also discovered a cluster dubbed "no shell" that took a "more advanced and stealthy approach" to other threat actors by opting for in-memory .NET module execution without dropping any payloads on disk. The activity originated from the IP address 96.9.125[.]147. "This approach significantly complicates detection and forensic recovery, underscoring the threat posed by fileless post-exploitation techniques," the company said, positing that it's either a "skilled red team emulation exercise or the work of a capable threat actor with a focus on evasive access and credential harvesting." It's currently not known who is behind the attack activity, although Google-owned Mandiant has attributed the early-exploitation to a China-aligned hacking group. Data from Censys shows that there are 9,762 on-premises SharePoint servers online, although it's currently not known if all of them are susceptible to the flaws. Given that SharePoint servers are a lucrative target for threat actors due to the nature of sensitive organizational data stored in them, it's essential that users move quickly to apply the fixes, rotate the keys, and restart the instances. "We assess that at least one of the actors responsible for the early exploitation is a China-nexus threat actor," Charles Carmakal, CTO, Mandiant Consulting at Google Cloud, said in a post on LinkedIn. "We're aware of victims in several sectors and global geographies. The activity primarily involved the theft of machine key material which could be used to access victim environments after the patch has been applied." (The story was updated after publication on July 23, 2025, to reflect the change in CVSS scores.)