SOC incident analysis. Letsdefend, SOC342 — CVE‑2025‑53770 SharePoint ToolShell Auth Bypass and RCE

Hello everyone, in this article I will show a step-by-step guide to solve a practical task for SOC with Letsdefend— SOC342 CVE‑2025‑53770 SharePoint ToolShell Auth Bypass and RCE.

First, you need to understand what data is in the alert itself.

It's very important to look at and understand the RULE NAME: CVE-2025–53770 SharePoint ToolShell Auth Bypass and RCE, as well as the Alert Trigger Reason: Suspicious unauthenticated POST request targeting ToolPane.aspx with large payload size and spoofed referrer (indicative of CVE-2025–53770 exploitation). Here, the payload size is shown by Content-Length, and it is indeed large. If you look at information about this CVE , you can find vulnerable versions, and we need to check whether our server is vulnerable.

The vulnerability information contains recommendations that can help identify attempts to exploit the vulnerability:

This data completely matches our alert, including the Source IP Address. And of course, the Device Action is Allowed, meaning the server accepted the request (but this doesn't necessarily mean the device itself is compromised, as the server could only accept the payload and process it securely). You can also check whether the IP address is bad. This can also be done on VirusTotal. 10 out of 92 vendors mark this IP address as bad, but given that it's mentioned in the CISA report on CVE-2025–53770, it can be considered malicious.

Now we need to find out if the server has actually been hacked. First, we can look at the network activity:

The attacker's IP address is visible. Now you can view the terminal history.

This command invokes powershell.exe without loading the PowerShell profile (-nop), without displaying the console window (-w hidden), and -e means that the subsequent text should be decoded and executed. Here's the decoded text:

This script displays all information about ASP.NET cryptographic keys. If the process is successful, it can, for example, create malicious ViewState by simply signing (or encrypting, if a decryptionKey is needed) and thereby execute code remotely.

If you look at the processes and find out who created the process with this command, you'll see:

w3wp.exe is an IIS web server process that executes ASP.NET, PHP, and other code. Given that it created the process, the CVE-2025–53770 vulnerability is 100% present on the server. Also, the Process User is listed as IIS APPPOOL\SharePoint — 80, which typically has access to cryptographic data, so the attacker has a high probability of obtaining it. The server can be considered compromised and should be isolated.

The server is now isolated.

Next, the attacker uses csc.exe (a Microsoft compiler), which converts C# text files into executable files (.exe) or libraries (.dll).

The next thing the attacker does is create a file that will be downloaded and executed (and when executed, it will download the payload.exe file) when the user navigates to the https://<TARGET_HOST>/_layouts/15/spinstall0.aspx tab. This is done by creating an ActiveX object with clsid::ADB880A6-D8FF-11CF-9377–00AA003B7A11, which is the class identifier for WScript.Shell. This is needed for the browser to execute or download the file, bypassing the security warning.

This is how this command is visible in processes:

Looking at the hash on VirusTotal, we can see that it's marked as malicious by 44 out of 61 vendors. The appearance of cmd.exe from the parent csc.exe is, with a high probability, malicious. Most likely, the file created using csc.exe and the one downloaded from the attacker's server are identical; this is simply a way to download the payload if one method fails. Alternatively, these files have the same name but represent different stages of the attack; unfortunately, this is impossible to determine without access to both files.

The last command is aimed at obtaining cryptographic data (like the first command)

You can now fill in the incident details.

IOCs: Network:

1. 107.191.58.76 — malicious IP (C2, payload hosting)
2. POST request to /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx with Referer: /_layouts/SignOut.aspx and large content size File hashes (SHA-256)
3. 10e01ce96889c7b4366cfa1e7d99759e4e2b6e5dfe378087d9e836b7278abfb6 — malicious machinekey.aspx
4. 92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514 — malicious spinstall0.aspx

File Paths: 5) C:\Windows\Temp\payload.cs, 6) C:\Windows\Temp\payload.exe, 7) C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\spinstall0.aspx

Process Chain: 8) The w3wp.exe process creates powershell.exe with the "-nop -w hidden -e" flags 9) powershell.exe -> csc.exe in the public directory (C:\Windows\Temp) 10) w3wp.exe (4560) -> powershell.exe(9876) -> csc.exe(9901) → cmd.exe(9910) → powershell.exe(9920)

Notes for SOC L2:

Required actions:

1. Block IP 107.191.58.76

2. Delete files: C:\Windows\Temp\payload.cs, C:\Windows\Temp\payload.exe, C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\spinstall0.aspx

3. Add rules to block the SHA-256 hashes: 10e01ce96889c7b4366cfa1e7d99759e4e2b6e5dfe378087d9e836b7278abfb6 (this is the hash code obtained from the base64 string) and 92bb4ddb98eeaf11fc15bb32e71d0a63256a0ed826a03ba293ce3a8bf057a514 (file from process 9910)

4. Upgrade the server to a secure version

5. Change the cryptographic keys