Wednesday, August 28, 2019

Quick Network Analysis of Excel Document Utilizing WS-Discovery Protocol

 I thoroughly enjoy analyzing how malware slithers through endpoints using new/novel techniques to evade detection.  Searching through network traffic packets and putting together the "story" of the infection is just as if not more exciting.

I came across this sample some time ago, and did not immediately look at the network traffic in depth. Out of nowhere, I got the itch to analyze the traffic and found some techniques I was not familiar with.  The below will include a quick analysis of what I was able to pull from the network traffic captures.

This sample can be found at:


I first want to start by replaying the malicious PCAP in my SecurityOnion VM. This will allow me to get an idea of and possibly identify the malware responsible for the infection. At the very least, the alert will give us an idea of where to start our analysis (download, browser, etc.).

Figure 1

From the alerts in SGUIL, we are provided with quite a bit of information. For starters, we can confirm that the infection is due to a malicious Office document with embedded VBA. Additionally, we are provided with a source IP and port. It is best to remember that the source port hosting the malware may likely have been compromised and is simply the jump off point for the infection to talk to different servers.

Either way, we have a wealth of information to start our analysis.  While SGUIL is a great resource, I will use a number of other tools provided in the VM.

Opening our PCAP in Network Miner, we can get a bit more information on the infection as well as the file type.

Figure 2

We now know we are dealing with a malicious Excel document hosted at fakers[.]  Let's get an MD5 and SHA256 hash and keep moving.

Figure 3

With hashes for the suspect file, we can utilize VirusTotal to attempt and find out what type of malware we are dealing with.

Figure 5

From the VirusTotal output, it appears the Excel document acts as a dropper and reaches out to additional servers to download first, second, and so on stage malware.

With our PCAP already imported into SO, we have tools on top of tools to assist in our analysis. For the purposes of this post, I will be using Zeek (formerly known as Bro), Wireshark, and ELK.

Figure 6

Quite a bit of information to sift through in Kibana. Please note the date in the upper-right corner is the date from our PCAP as we imported it to preserve the timestamps.

In my humble inexperience opinion, it is best to start with DNS records for traffic analysis.  DNS records will allow us to view who are infected host is making requests to. This can easily be done in Kibana, but forgive me I will switch up between both tools.

Figure 7

In the interest of time and cluttering the page with screen shots, I decided to add the Bro_HTTP log output along with the DNS output. Not much that jumps out in terms of DNS, but that sure does change when we look at some of the URI's and HTTP Methods in the HTTP log.

Before we dive in too deep, let's take a look at the User-Agents used in the traffic.

Figure 8
Interesting user-agents to circle back to, but for now let's get back to the Zeek HTTP logs.  The first couple lines reveal traffic over port 5357, usually associated with Windows Network Discovery being enabled. While not unusual, the URI's and HTTP methods certainly are. We can see that our victim in this case, 192.168.240[.]39 has been talking to another address in our same network over POST requests with a suspicious URI.

Like reading a book, we can follow the GET request and accompanying traffic after the malicious Excel document is requested. The methods OPTIONS, and HEAD are very similar but PROPFIND required me to do some digging and further research.

Figure 9
The thing to keep in mind is that the above requests were made after the .xls document was downloaded to the compromised system.  While HEAD is usually not allowed on most web servers, seeing OPTIONS & HEAD may not immediately set off any bells. This traffic is internal to the network, but take a look at the UA's.

From what I was able to gather, it seems this traffic depicts an attempt to ascertain whether WebDAV is installed on the network. Additionally the second UA checks to ensure the document is on the server and not set as a temp resource.

Figure 10
Please notice that many of the requests do not include traditional headers as is seen in benign traffic. The PROPFIND attempts do not seem to be attempting to exploit CVE-2017-7269. In the PCAP, these requests are repeated multiple times, all with the sandbox returning a 405 status message.

This may be a small setback for our analysis as we cannot fully view how the malware responds to a 200 OK message.

Info Returned for POST Request

Moving back to our captured Zeek logs, let's take a better look at the connections logs.

Figure 12
From both screenshots, we can see a good number of IPv6 traffic was transmitted during the infection. Port 5357 was covered earlier, but another interesting port is 3702.

Figure 13

Port 3702 is utilized for WS-Discovery, or the Web Services Discovery protocol. What makes this traffic not only fascinating but scary is that when enabled, WS-Discovery allows a user (or attacker) to discover nearby devices utilizing the same protocol.

This now makes perfect sense to the SOAP & XML messages seen throughout the captured traffic. Discovered devices utilize SOAP to communicate with each other, would be a great tool for an attacker to exploit.

Figure 14


This was a great exercise to not only test my skills in analyzing traffic, but also learn about some not so commonly used protocols that may be enabled on systems across the world. While this was a quick dive into the malicious traffic, I hope much of it was beneficial to anyone who is still reading.

I purposely left out malicious domains

There are just a few questions left to answer for the above traffic:
  1. Was the malware host legitimate?  A: After researching the malware host through some of my favorite intelligence programs,[.]jp is indeed a legit site and was compromised by the attacker(s).
  2. What does the file do?   A: After getting a hash of the malicious document and running it in VirusTotal, we were able to identify the Excel document as a dropper that downloaded multiple different file types to the system in a variety of folder locations.
  3.  Did the file execute? A: According to the sandbox results, the document did execute however I believe it was only partially due to the 405 status messages. Either way, we can say definitively this incident would need to be elevated.  Additional malicious domains that were contacted can be found in the above sandbox report.
Thanks to Chris Sanders for the above three ways of analyzing an incident. I will look to include the above three ways of analyzing traffic in future cases. Please see his talk at: 

Related Info:

JPCert's Log Analysis Training

6 Aug 2020 About a week or so ago, JPCert released their Log Analysis training slides and corresponding CSV files for each hands-on exercise...