On July 18, mass exploitation of SharePoint servers started to appear in the news.
Soon, in less than 2 weeks, 400+ organizations were compromised. Still counting.
List includes top companies, government agencies and so on.
So, how was this possible?
It all comes down to one insecure SharePoint page!
Let’s break it down in today’s post!
💥 Why This Exploit Is So Dangerous
Two things make any vulnerability deadly:
Bypasses authentication
Executes arbitrary code
This SharePoint flaw does both.
And that’s exactly why attackers are moving fast.
⚔️ The Attack Flow
Let’s walk through the attack flow step-by-step in simple terms:
Attacker scans internet-facing on-premises SharePoint servers > Identifies a specific page called "ToolPane.aspx" in SharePoint (It is used by admins to edit web parts on a SharePoint page) > Only users with edit permissions should be able to access it.
Attacker sends a crafted HTTP POST request to /ToolPane.aspx page by setting the Referrer header to /_layouts/SignOut.aspx > Bypasses the authentication! > This is due to a validation flaw in authentication.
Now attacker finds another flaw in the same page: The page accepts POST data and uses it without any validation to run commands (deserialization flaw).
So, attacker now updates the POST request to add malicious payload in POST body and sends it to SharePoint server > SharePoint deserializes and executes attacker commands > This results in dropping a stealthy ASPX web shell into a directory (see below image, credits: securelist) > This grants persistent access to server!
The uploaded web shell is used to further extract sensitive cryptographic material from the server’s configuration > Using these keys, attacker forges and creates valid auth tokens that SharePoint will trust > Using them, attacker can login as any user! > Attackers can also access all SharePoint content and move laterally across the Windows Domain.
💡Key Insights & Lessons
Harsh reality of security world: If you closed a million doors but missed one door, you lose it all . Attackers only need one way in.
So, why did the auth bypass happen? SharePoint uses a series of flags to track authentication status. A logic bug in this process, set a wrong flag based on "Referrer" header comparison. It was specific to the code in this page. Its hard to catch these via automated scanners. This is where code reviews help.
The part that makes this vulnerability deadly: Patching is not enough. Why? Because even if you patch and remove the web shell, the stolen cryptographic keys allow attackers to generate valid auth cookies that they can use to re-enter the environment.
How the re-entry works? SharePoint uses JWT for internal service authentication. If an attacker extracts the "machineKey" (used for signing JWTs in ASP.NET), they can forge valid tokens and impersonate any user. This has huge impact.
More about de-serialization flaw: When an app saves complex data (like user profiles or settings), it often converts it into a simpler format (like a string of text or binary) — this process is called serialization. Later, when it needs to use that data again, it deserializes it — meaning it converts it back into usable objects in memory. A deserialization vulnerability happens when the app blindly trusts and deserializes data without checking if it’s safe. If an attacker sends malicious serialized data, the app may deserialize and unknowingly run attacker-controlled code — giving the attacker control over the system. This is what happened here.
If you're impacted, there's a lot to do: 1) Apart from patching, you also need to rotate SharePoint server ASP.NET machine keys 2) Restart IIS on all SharePoint servers 3) Rotate all credentials and system secrets that could have been exposed via the malicious ASPX.
Lateral movement threat: People often store sensitive enterprise data (sometimes including passwords) in SharePoint. Post breach, attackers could quickly scan SharePoint, identify new secrets and move laterally to those systems.
The mystery: This was originally presented at Pwn2Own in May. Microsoft was about to release patch on July 8. But exploitation started on July 7. Only July 8, the patches were out and were almost immediately bypassed! This is an interesting timeline and its as though attackers had prior insight into the fix.