Recently, I tackled a high-stakes alert on LetsDefend involving a critical zero-day vulnerability in on-premises SharePoint Server deployments: ToolShell (CVE-2025–53770).
This case was particularly interesting because it combined an authentication bypass with insecure deserialization to achieve Remote Code Execution (RCE). In this walkthrough, I'll break down my investigation steps, from the initial HTTP alert to the final host isolation.
1. The Alert: Critical SharePoint Zero-Day
The investigation started with a high-severity alert for SharePoint01 (172.16.20.17).
- Event: ToolShell Auth Bypass and RCE (CVE-2025–53770)
- Source IP: 107.191.58.76 (Vultr Hosting)



My first step was checking the reputation of the source IP. VirusTotal showed multiple security vendors flagging it as malicious, which immediately increased my suspicion.
2. Analyzing the HTTP Traffic
I dove into the Log Management tab to examine the raw HTTP request.
What stood out:
- The Endpoint: The request was a
POSTto/_layouts/15/ToolPane.aspx, a known target for this specific exploit. - Auth Bypass: The
Refererheader was set to/_layouts/SignOut.aspx. This is a classic "spoofing" tactic used to trick SharePoint into allowing unauthenticated requests. - The Payload: A
Content-Lengthof 7699 bytes for a simple page request is a massive red flag. This suggested a large serialized payload was being sent to the server.

3. Endpoint Investigation: Confirming RCE
To see if the exploit worked, I pivoted to the Endpoint Security tab for SharePoint01.
The Smoking Gun: In the process tree, I found the IIS worker process (w3wp.exe) spawning a PowerShell instance.
- Process Command Line:
powershell.exe -EncodedCommand PCVAIEltcG9yd...





Using CyberChef to decode the Base64, I discovered the script was designed to extract the server's Machine Keys (ValidationKey and DecryptionKey). By stealing these, an attacker can maintain persistent access and forge authentication cookies even if the initial vulnerability is patched.
4. Identifying the Web Shell
Looking closer at the file system logs, I found a new file created in the SharePoint layouts directory:
- Path:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\spinstall0.aspx

This confirmed that the attacker successfully dropped a Web Shell.
5. Mitigation & Containment
Because the attack was a True Positive and Successful, immediate action was required:
- Isolation: I isolated
SharePoint01from the network to stop any data exfiltration. - Tier 2 Escalation: I escalated the case for deep forensics and to ensure the stolen Machine Keys were rotated.
PLAYBOOK ANSWERS:





powershell.exe with -EncodedCommand spawned from the IIS service path.
107.191.58.76 Attacker IP IP Address
172.16.20.17 Victim IP IP Address
/_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx Malicious URL URL Address
/_layouts/SignOut.aspx Referer Header URL Address


Final Disposition
- Verdict: True Positive
- Case Disposition: Resolved — Escalated to Tier 2
This alert is a True Positive confirming the exploitation of CVE-2025–53770 (ToolShell) on the internal host SharePoint01 (172.16.20.17) by an external attacker (107.191.58.76).
Conclusion
This case was a perfect example of why SOC analysts can't rely on just one tool. It took a combination of network log analysis, threat intelligence, and endpoint forensics to see the full picture.
Special thanks to the LetsDefend team for providing such a realistic and challenging scenario!!!
