Along with everyone else in the cybers, last weekend we watched a wave of realization hit Sharepoint admins around the world as they were confronted with a set a vulnerabilities allowing for unauthenticated remote code execution (CVE-2025-53770, CVE-2025-53771, …). It’s been a while since Sharepoint admins have known that feeling, the one that VPN Gateway admins are unfortunately forced to go through on a regular basis.
Which vulnerabilities should we detect?
As a reminder, at ONYPHE we aim to deploy detection capability before mass-exploitation of a vulnerability is observed, or as soon as possible afterwards if it’s a zero-day. We use the following criteria to determine if a vulnerability will be added to our vulnscan category:
- exploit reliability: the vulnerability can be exploited reliably outside the lab
- not CVSS (we never judge the severity of a vulnerability by its CVSS score, even though we may display it at times)
- unauthenticated: exploitation occurs before authentication or enables authentication bypass
- remote access: exploiting the vulnerability directly or indirectly allows for remote code execution (RCE)
- massively deployed: the number of potentially vulnerable systems exposed on the Internet is significant
- identifiable: potentially vulnerable systems can be identified before an exploitation attempt is made
- used by entreprises or governments: the technology is used by businesses and on public-sector networks (ie. typically not SOHO devices)
These are essentially the same selection criteria a cyber-criminal or other low-discretion threat-actor would use to determine whether to weaponise a vulnerability.
ToolShell, or CVE-2025-53770/53771
So when reading the excellent write-up by Eye Security we quickly realised that this suite of vulnerabilities would tick all our boxes and we’d need to have a detection capability in place as soon as possible.
Like many similar Internet-scanning vendors, we are able to identify Sharepoint Server systems thanks to the headers that Microsoft helpfully adds to HTTP responses. However, from previous investigations we know that Sharepoint version numbers are not updated systematically; that is, it’s possible to have a range of Sharepoint-related .NET components with different version numbers on the same system, and therefore it was not going to be possible to use a version-based detection for these CVEs.
We have one other detection avenue available to us which is a check-based detection. In other words, we can try and establish if a system is vulnerable or not by making one or more non-intrusive requests to the system. By non-intrusive we mean that we’re using existing functionality of the system, that is normally exposed to the Internet, and that our actions will not make life harder for the cyber-defenders working to protect organizations. Our priority is to defend the ecosystem, and where possible1 we notify impacted organizations, who are our customers or not.
The detection technique
Snippet of payload from hazcod
For ToolShell, we quickly added a detection for the known webshell URL as described by Eye Security and then we started to reach out to private contacts and look around for a Proof-of-Concept (POC) for the vulnerability. By Tuesday morning (22/08 CEST) exploit code was flying around the Internet and several people had examined these attack and posted code, but the cleanest and most helpful from our perspective was by hazcod (Niels Hofmans) https://github.com/hazcod/CVE-2025-53770/.
Niels’ neat Go code, non-intrusive payload, and helpful Readme demonstrate how security research can and should be done. We adapted his approach with our own technology stack.
- First things first, we need a list of all known Sharepoint servers. We don’t scan 0.0.0.0/0 for vulnerabilities, so we need to use our datascan dataset and extract all known IPs and virtual hosts running Sharepoint. We do this the same our customers can, with an OQL query : category:datascan app.http.component.product:”sharepoint server” !tag:honeypot
- As with the original POC, our code tries to exploit the vulnerability by injecting a harmless marker in to the SharePoint ToolBox widget. If the SharePoint server response contains the marker then the host is tagged as vulnerable. This marker stays in memory while the page is being rendered by the server but is not written to the Sharepoint server or the database
- Our first attempts at decoding the server response were unsuccessful as the marker is first compressed, then base64 encoded before being rendered by the server as an HTML Entity. We had to add some character substitutions at this point to reconstruct a valid base64 string before continuing with decompression and the checks for the presence of our marker
- As with all our vulnerability scans, we scan from the US and France, with servers that are identifiable as ONYPHE infrastructure, both with a reverse DNS entry and with a web server running on each scanner. Our IP ranges are published and we process legitimate opt-out requests with no questions asked (apart from, sure, what’s your IP range?)
Example response of a vulnerable system
Scan results
| Finding | Description | Count of unique IPs |
| Total | System tested for Sharepoint CVE-2025-53770 and CVE-2025-53771 | 11612 |
| Not Vulnerable | Tested with the harmless exploit POST request and marker not found in response | 11149 |
| Vulnerable | Tested with the harmless exploit POST request and marker found in response | 463 |
| Compromised | Tested the known webshell URL and backdoor presence confirmed | 141* |
* at the time of writing, only 71 machines were still responding with the backdoor. Many have been taken offline.
Querying vulnscan
ONYPHE Entreprise customers can use the following OQL queries on our vulnscan category to get access to the vulnerability data. ASM Edition customers will see any vulnerable systems across their Realms on the vulnerabilities tab.
- For vulnerable servers :
- For compromised servers :
As always, if your system is tagged vulnerable you should patch as soon as possible, and perform additional integrity checks such as the presence of new .aspx files. If your system is tagged compromised, we recommend disconnecting it from the network (while retaining electrical power – don’t turn it off) and contacting a competent cyber security incident response organization.
About ONYPHE:
ONYPHE is an attack surface management solution that monitors the exposure of vulnerable devices on the internet by analyzing IP addresses, accessible services, URLs, and indicators of active exploitation.
By collecting real-time data on over 370 million domains and nearly 500 million active IP addresses (IPv4 and IPv6 combined), ONYPHE helps identify affected systems, assess the risks posed by these assets, and track the evolution of exploited vulnerabilities.
To learn more, visit us at: https://www.onyphe.io/
- We won’t go through a bug-bounty process though, so make it easy for us to help you. We’re not interested in financial reward, and we don’t want to fill in forms justifying our findings. Provide us with an e-mail address and we’ll send you the details, with PGP if you prefer. Even better, implement securitytxt as we are also crawling them and have an inventory of such contacts. ↩︎
