Understanding the RCE

On July 22, 2025, Immersive’s threat research team was trying to understand how the SharePoint zero-day vulnerability was uncovered, based on Eye Security’s initial article. 

There were many proofs of concept (PoCs) and initial articles on indicators of attack (IoAs) and their severity. But none covered the exploit itself or could help us understand how the exploit was weaponized in depth.

In this blog, I’ll share our research process and how we (eventually!) got to the bottom of this exploit.

The challenges of building a CTI lab

Our initial thought process for building this Cyber Threat Intelligence (CTI) lab was fairly straightforward. 

We’d understand the indicators of compromise (IoCs) and the PoCs that were shared in the article, try replicating it with the PoC, and obtain some logs. However, it was easier said than done.

What went wrong?

The PoCs just didn't work, and there was no way for us to understand why. This makes sense retrospectively – initial articles only provided surface-level information, rather than details on how the exploit was made. 

We ended up deploying different variants of SharePoint to see which were vulnerable. Alas, nothing worked (I’ll explain why this happened in more depth later on).

Looking at the logs to identify the problem didn’t work either, because who looks at logs, right? Some of the initial PoCs were taken down, and the ones remaining were missing a piece of the puzzle. It was also fairly noticeable that many of the PoCs added to GitHub weren’t true either, and some were ransomware binaries!

Dissecting the payload – mistakes and a learning curve

Based on the initial brief from the Eye Security article, we figured out that it was a deserialization problem.

After many days of unravelling and building multiple SharePoint servers with different versions, the “Hallelujah” moment finally arrived. A new remote code execution (RCE) module for this exploit was committed to Metasploit's GitHub repo. 

It wasn't the code that mattered much to us, but the comments in it that got us interested:

The highlighted comments helped us map out which deserialization gadget chain works against specific SharePoint Server versions. This was important, as the exploit itself abuses insecure deserialization in the ViewState on SharePoint pages like ToolPane.aspx. 

This is when it hit us: our initial exploit of the RCE using the TypeConfuseDelegate gadget with BinaryFormatter wasn't working because we weren’t targeting the versions that were vulnerable to that gadget chain. 

To put this to the test, we had the right version built (v16.0.10337.12109) and also decided to further analyze the payload itself from the Metasploit module – I know it's cutting corners, but I was very keen on how it all works together!

To achieve this, we downloaded the earliest exploit module commit on its GitHub, added it to our existing Metasploit framework, and intercepted the request using BurpSuite.

This gave us the PoC, which we could analyze:

Obviously, there was no need to reinvent the wheel since Metasploit already had a functional module, but where’s the fun in that?

Dissecting the payload – decoding

It’s already noticeable that the payload is URL-encoded. By decoding it, you’ll be able to see the body of the request. It has references to controltemplates/ACLEditor and an Excel DataSet, which is commonly used in .NET deserialization exploits, along with a Base64 encoded and compressed data table:

The next step was to extract and Base64 decode the compressed data table:

The decoded and decompressed information is the raw XML schema and DiffGram that the DataSetWrapper spits out. The part highlighted in the red box is the embedded first-stage gadget, Base64 encoded as an XSD string. 

Remember when I mentioned that our PoCs weren't working earlier? It’s because we didn't embed our Base64 encoded payload onto a raw XML schema and DiffGram.

If you take the Base64 encoded XSD string and decode it, you’d get the payload. The payload I had on Metasploit was:

And by decoding the string obtained from above, we can see it too:

Weaponizing our PoC to emulate the IoCs

With all the juicy information to hand, it was time to recreate this and see how threat actors in the wild did it. 

Bear in mind that the IoCs from the research article mentioned they weren’t obtaining any shells from the RCE, but stealthily leaking cryptographic secrets from SharePoint servers, which were chained to craft a fully valid and signed payload using ysoserial.

The PoC implemented based on the work from the Metasploit module wraps our initial “inner” ysoserial payload inside an XML and DataSet gadget that SharePoint expects, then serializes, compresses, and Base64 encodes it. 

The payload that was built closely resembles what’s seen in the wild, which was dropping malicious content to a file named spinstall0.aspx that leaks cryptographic secrets.

This Base64 payload was then embedded into an XML and DataSet gadget, using our PoC:

All that remained was to send the payload. Here’s what we noticed upon sending the request via Burp:

And while looking at the Process Explorer running on our SharePoint test environment:

Similar to the IoCs, you’ll note that w3wp.exe spawns cmd.exe, and a PowerShell process is then spawned from the cmd.exe child process. 

If it’s succeeded, you should be able to navigate to https://X.X.X.X/_layouts/15/spinstall0.aspx to view and read the SharePoint’s MachineKey config file, including the ValidationKey:

Finally, from our ELK logs:

As you’ll notice, the log shows that the exploit’s PowerShell payload used set-content to write an ASPX backdoor into SharePoint’s _layouts directory (spinstall0.aspx).

In summary

Looking back at this exploit, it’s interesting from an offensive perspective to see how advanced persistent threat actors are finding creative ways to compromise organization infrastructures.

In the meantime, I can only send prayers to the SOC analysts and Sysadmins fixing SharePoint, because let’s be honest – SharePoint is a cave nobody comes out alive from! 

For more information and finer details on how the exploit works, I'll leave this fantastic article here: 

Viettel Cyber Security: SharePoint ToolShell – One Request PreAuth RCE Chain