Over the past week, attackers compromised multiple organizations worldwide using a vulnerability chain in SharePoint. Microsoft moved to release emergency patches, but here's the shocking part: these exploits aren't even new bugs. They're bypasses of fixes Microsoft shipped just two weeks ago.
The Story Behind the Chaos
It started at Pwn2Own Berlin in May, where a security researcher showed how to completely take over SharePoint using two vulnerabilities. Microsoft patched them in July. Problem solved, right?
Wrong.
Within days of these patches going live, attackers found new ways around them, and by July 18th, the exploits became widespread. Everyone wanted in.
Here's what we're dealing with:
The Original Flaws (July 2025 patch):
- CVE-2025-49706: Spoofs authentication by faking the Referer header
- CVE-2025-49704: Allows attackers to run code through unsafe deserialization
The New Bypasses (Emergency patches July 21):
- CVE-2025-53771: A new way to bypass authentication (circumvents the CVE-2025-49706 fix)
- CVE-2025-53770: A new path to code execution (circumvents the CVE-2025-49704 fix)
Security researchers are calling this the "ToolShell" attack chain. Microsoft initially thought they were seeing exploitation of the old bugs, but unfortunately, attackers had already found ways around the patches.
How the Attack Actually Works
The attack chain is elegant in its simplicity:
Step 1: Authentication Bypass The attacker sends a POST request to /_layouts/15/ToolPane.aspx?DisplayMode=Edit with a specially crafted Referer header set to /_layouts/SignOut.aspx. SharePoint's authentication logic has a flaw: it treats requests coming from certain internal pages (like the sign-out page) as pre-authenticated. This tricks SharePoint into granting access without any credentials.
Step 2: Exploiting .NET Deserialization Once past authentication, the attacker leverages SharePoint's control rendering mechanism. The ToolPane.aspx page accepts serialized .NET objects that define which controls to render. By crafting a malicious serialized object, attackers can trigger arbitrary code execution when SharePoint deserializes it.
Step 3: Payload Execution The deserialization vulnerability allows the attacker to execute PowerShell commands with the privileges of the SharePoint application pool. The attackers iterate through configuration files to extract sensitive configuration data.
Step 4: Key Extraction and Persistence The attacker's PowerShell script extracts the ASP.NET machine keys from web.config:
— validationKey: Used to sign ViewState data
— decryptionKey: Used to encrypt/decrypt ViewState data
With these keys, attackers can forge valid __VIEWSTATE tokens that SharePoint will accept as legitimate, even after patches are applied.
Step 5: Webshell Deployment
Finally, the attacker drops a webshell (named spinstall0.aspx in the common In-The-Wild attacks) found in the layouts directory: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\spinstall0.aspx
This webshell parses attacker commands, providing persistent remote access.
What Should You Do?
1. Take a proactive approach while patching
1.a. Implement a proactive mitigation while you apply patches
To minimize potential exposure during the upgrade process, configure your Web Application Firewall (WAF) to detect and block suspicious exploitation-related requests and common post-exploitation activities.
— Configure your Web Application Firewall to block POST requests to any URL ending with/_layouts/(15|16)/ToolPane.aspx (regex), has an HTTP Referer header containing /layouts/SignOut.aspx, and includes a form field named MSOTlPn_DWP whose first value contains ExcelDataSet or Scorecard (case-insensitive match).
— Additionally, block GET requests to URLs matching /_layouts/(15|16)/spinstall[0-9]?.aspx (regex) to prevent access to an existing web shell probed by reconnaissance or exploitation attempts.
This is an example of the rule logic for Cloudflare:
(http.request.uri.path matches "^/_layouts/(15|16)/ToolPane\.aspx"
and http.request.method == "POST"
and any(http.request.headers["referer"][*]
matches "^https?://[^/]+/_layouts/SignOut\.aspx$")
and http.request.body.form["MSOTlPn_DWP"][0]
matches "(?i)ExcelDataSet|Scorecard")
or
(http.request.uri.path matches "^/_layouts/(15|16)/spinstall[0-9]?\.aspx"
and http.request.method == "GET")Miggo automatically generated the above WAF rule logic using our Predictive Vulnerability Database and AI-powered security research process. This WAF rule logic is comprehensive, meaning that even if you were previously exploited, once you deploy Miggo’s WAF rule, it blocks access to the webshell and blocks an attacker who attempts to exploit again.
1.b. Enable AMSI
Consider turning on the Anti-Malware Scan Interface and deploying Microsoft Defender on all SharePoint servers. Configure AMSI in Full Mode for comprehensive protection.
2. Patch your system
Ensure your SharePoint instances are patched and up to date:
- SharePoint 2019: KB5002754
- SharePoint 2016: KB5002760
- SharePoint Subscription Edition: KB5002768
3. Assume compromised for internet-exposed instances
If you haven't patched since July 8th, consider your internet SharePoint server compromised.
3.a. Assume you're compromised and hunt for the Webshell
Look for the webshell file spinstall0.aspx, and monitor for requests to the webshell (as described in the WAF rule in the next section).
Microsoft's blog and Eye Security's research paper provide a full, detailed list of IOCs.
3.b Rotate the SharePoint machine keys
This is critical. Stop IIS, update your machine keys, and then restart. If you skip this, attackers may keep their golden ticket to this machine.
What this Means for Your Application Environment
Applications integrated with SharePoint are at risk. Act fast: validate all SharePoint data, use minimal-privilege service accounts, and consider temporarily disabling non-critical integrations until you've verified security.
But here's the uncomfortable truth: attackers are now studying patches and finding bypasses within days and sometimes hours. They target third-party applications like Microsoft SharePoint, Atlassian Confluence, or MOVEit, as well as third-party libraries such as Log4j or Next.js used in the applications you build. This isn't about zero-days anymore, it's about outsmarting remediation and mitigation processes.
At Miggo Security, we’re building a proactive application protection platform that combines observability, security, and AI. By continuously analyzing deep application behavior and context, we generate real-time, predictive threat intelligence that stops exploits before they land. Our platform doesn’t just detect attacks, it understands them in context, enabling defenses that adapt faster than attackers can pivot.
Don't wait. If you’ve been breached or need support, contact us here.
References
- Eye Security: SharePoint Under Siege
- Microsoft Security Blog: Disrupting active exploitation of on-premises SharePoint vulnerabilities
- CISA Alert: Microsoft SharePoint Vulnerabilities
- The Hacker News: CISA Orders Urgent Patching
- https://www.zerodayinitiative.com/blog/2025/5/16/pwn2own-berlin-2025-day-two-results
