CVE-2019-0604: SharePoint RCE Forensics Analysis And Detection Methods

I decided to write this blog because I did not notice anyone publish any real detection methods or network/host forensics analysis yet until now. I will not talk about how the exploit works, but I will try to demonstrate quick PoC and analyze logs generated by that exploit and will provide some detection methods for the early stages of the attack.

If you want to read more about the exploit and how it works, I advise to read the below articles:

https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
https://x3fwy.bitcron.com/post/sharepoint-rce-explained

Quick PoC

In the above video you will see I’m doing the exploit and executing remote command and creating new process in the server side by sending a crafted HTTP POST request with particular path and payload parameter value.

Network Analysis And Detection

As shown in the PoC, The exploit done through sending a crafted HTTP POST request to the SharePoint web app.

The above picture shows the crafted HTTP POST packet capture, we will focus in the important POST headers and payload parameters for the detection:

1. URI:  /_layouts/15/Picker.aspx
2. URI query:
   • PickerDialogType=Microsoft.SharePoint.WebControls.ItemPickerDialog
   • PickerDialogType=Microsoft.SharePoint.Portal.WebControls.ItemPickerDialog
3. POST payload parameter: ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData

The POST parameter above value contains the encoded/serialized .Net XML payload that will be loaded and might executed in the SharePoint server side. The malicious payload should start with double underscores “__” to get the exploit work and to make the payload reaches the XML deserialization function in the SharePoint code which will cause remote command execution.

We can detect the exploit attempt with the below created Snort IDS rule:

alert tcp $EXTERNAL_NET any -> $SHAREPOINT_SERVERS [80,443] (msg:"SharePoint CVE-2019-0604 RCE Exploit Attempt"; flow:established,to_server; content:"POST"; http_method; content:"Picker.aspx?PickerDialogType=Microsoft.SharePoint"; http_uri; nocase; content:"ctl00|25|24PlaceHolderDialogBodySection|25|24ctl05|25|24hiddenSpanData|3d5f5f|";http_client_body; nocase; fast_pattern; reference:adraft.page/index.php/2019/09/14/cve-2019-0604-sharepoint-rce-forensics-analysis-and-detection-methods; sid:3000001; rev:1;)

This above rule is looking for any POST request with the URI, URI query mentioned earlier above, and a “ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData” parameter value starts with “__”.

Because i didn’t saw any legitimate POST request before with the URI and URI query mentioned earlier above, you can detect the exploit attempt also through monitoring IIS or WAF logs.

Host Forensics And Detection

As shown above picture and in the quick PoC, a new child process created from parent process w3wp.exe (IIS web service worker). The .Net XML generated malicious payload includes a .Net Process.Start Method which will loaded by SharePoint server and executed to start new process.

<ResourceDictionary
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:System="clr-namespace:System;assembly=mscorlib"
xmlns:Diag="clr-namespace:System.Diagnostics;assembly=system">
    <ObjectDataProvider x:Key="LaunchCalch" ObjectType="{x:Type Diag:Process}" MethodName="Start">
        <ObjectDataProvider.MethodParameters>
            <System:String>cmd.exe</System:String>
            <System:String>/c calc.exe</System:String>
        </ObjectDataProvider.MethodParameters>
    </ObjectDataProvider>
</ResourceDictionary>

Above an example of the XML payload code before encoding/serialization. You can read more about .Net Process.Start Method in Microsoft website:

https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.process.start?view=netframework-4.8

Above Sysmon log generated after doing the exploit, we can use this type of Sysmon log to look for any child process created under w3wp.exe.

Below is created Sigma rule for that:

title: CVE-2019-0604 RCE
status: experimental
description: Detects any child process created by IIS web service worker - CVE-2019-0604
references:
    - https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
tags:
    - attack.initial_access 
    - attack.t1190
    - attack.t1100
author: "Mansour Alsaeedi (@m_50)"
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        ParentImage: '*\System32\inetsrv\w3wp.exe'
    condition: selection

If the above Sigma rules gives you false positive, you can focus on PowerShell and CMD as a child process as the attacker most likely will use them to execute his code, and focus also on parent process command line that contains SharePoint application pool. Below is created Sigma rule for that:

title: CVE-2019-0604 RCE 2
status: experimental
description: Detects PS or CMD child process created by SharePoint IIS web service worker - CVE-2019-0604
references:
    - https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
tags:
    - attack.initial_access 
    - attack.t1190
    - attack.t1100
author: "Mansour Alsaeedi (@m_50)"
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 1
        ParentImage: '*\System32\inetsrv\w3wp.exe'
        ParentCommandLine: '*\system32\inetsrv\w3wp.exe -ap "SharePoint*'
        Image: 
            - '*\powershell.exe'
            - '*\cmd.exe'
    condition: selection

falsepositives:
    - not tested in production SharePoint Server, you should filter out the false postives.
level: high

Decoding The Payload

If you like to capture PCAPs and analyze the exploit encoded malicious payload as I do, unfortunately there is no script or easy and quick way to do that.

I do that through importing SharePoint DLL code (Microsoft.SharePoint.dll) into visual studio, to import the code you need .Net decompiler to look into DLL code. I use dotPeek which is free and easy to install decompiler.

You need only to import the below class code of the DLL which will be used to decode the serialized XML:

You can find that DLL after installing SharePoint server in the below path:

Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI

After importing the class in your visual studio project, you can invoke the decode method as below:

using  Microsoft.SharePoint.BusinessData.Infrastructure;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
             EntityInstanceIdEncoder.DecodeEntityInstanceId("encoded_payload");
        }
    }
}

But be careful, the encoded payload code will be executed in your machine. To avoid that and to look in the code I set a breakpoint in the line shown in the below picture:

You will find the decoded command in local variable g.

Prevention

Microsoft released a patch to solve the issue:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0604

Affected SharePoint versions:

• Microsoft SharePoint Foundation 2010 Service Pack 2
• Microsoft SharePoint Foundation 2013 Service Pack 1
• Microsoft SharePoint Server 2010 Service Pack 2
• Microsoft SharePoint Server 2013 Service Pack 1
• Microsoft SharePoint Enterprise Server 2016
• Microsoft SharePoint Server 2019

And the blog post ends here, this is my first post and I’m not that good in English, but i hope you enjoyed reading it 🙂 .

You can find a sample exploit PCAP and the Snort and Sigma rules in my below Github account:

https://github.com/m5050/CVE-2019-0604/