This post is a write up of an exercise posted on Brad Duncan’s website, Malware Traffic Analysis, specifically the exercise titled ‘Sunnystation’. The linked page also includes the answers to this exercise, as well as other tutorials and guides on Brad’s site.

In this exercise we are provided a single packet capture file and tasked with identifying the hosts and user account names active on the network, along with identifying the type of malware that they’re infected with.

Introduction and tooling

Our primary analysis of the capture will be done in Wireshark, but we’ll use some other tools as well.

I’d highly recommend following Brad’s guide on setting up Wireshark for malware traffic analysis, as it seems to be the gold standard setup for this type of work in Wireshark. You can read his tutorial on the Unit42 website to get things configured and ready to go.

Technical analysis and deep dive

In this case I want to start with the exercise from the second question, and look at the hosts and user account names after identifying the malware that is in play.

So, let’s see if we can find some malware.

Hunting for malware samples

Normally I’d begin looking at a packet capture by first checking for any alerts generated by an IDS like Suricata, but as we can already assume that a malware download is present somewhere in the packet capture we can start there instead. A good place to start looking for this file is in the HTTP object list in Wireshark.

To view this, go to File > Export Objects > HTTP.

I generally go about filtering these results in one of two ways: either by sorting by content type and looking for applications (either using column sorting or the filter in the top right of this window), or by sorting by file size.

Sorting by the Size column brings a number of objects to the top of this list. Looking over each, the one that stands out most is the file with a MIME type of application/x-msdownload, which is associated with DLL and EXE files. While not uncommon, these sorts of files are certainly well represented in malware samples.

Also of note is the image/jpeg file, which wouldn’t normally raise any red flags, but in this case it was downloaded directly from 156.96.154.210. A quick search for this IP on VirusTotal tells us that it has been flagged as being malicious.

Let’s take a sample of both files by selecting each from the list and clicking Save.

Next, we’ll want to generate a hash for these files so that we can see if they’ve been flagged previously. This is easy to do using the command line in Linux. Simply navigate to the folder where the sample is saved and run the following command:

md5sum zbBYgukXYxzAF2hZc ; md5sum Ocklqc.jpg

If you’re using Windows you can use a similar command in PowerShell, get-filehash.

If, like me, you’re using Linux and you haven’t renamed the file this command should run successfully and return the following:

57595f82e73bed372c669e907d4db642 zbBYgukXYxzAF2hZc
f45c9b09bf1ddc724fd3148692d8c039 Ocklqc.jpg

The first set of characters on each line is the MD5 hash of the file, which we can copy and search on a platform like VirusTotal.

Analysing the x-msdownload file

Searching for the first hash (for the x-msdownload file) on VirusTotal generates a number of flags from both security vendors and sandboxes, so we can be fairly confident that we’ve found our piece of malware.

A quick glance over the “Detection” section tells us what malware it is that we’re dealing with here, and gives us part of the answer to the second question in this exercise: Emotet.

We can find the device that downloaded this particular file by clicking the object in the object list, which will highlight the entry where the download occurred. In this case, the device was operating on 172.16.0.149, has a MAC address of 00:1b:fc:7b:d1:c0 and downloaded the file on 2022-02-23 at 18:24:35 UTC.

Analysing the jpeg file

The second hash also generates a number of flags when searched on VirusTotal, but it isn’t clear what malware we’re dealing with based on the flags or information here, so we’ll need to dig into this deeper to be able to attribute it to anything.

A number of the flags identify it as a ‘reverse DLL’ and others mention obfuscation, which leads me to think this innocent image file may be a reversed DLL that something else will unpack or use.

I haven’t reversed the content of a file before, but a quick search on Google lead me to a nifty solution using xxd and tac in the Linux command line.

So, running the following:

< Ocklqc.jpg xxd -p -c1 | tac | xxd -p -r > Ocklqc

Gives us a reversed version of the original file, a DLL, which we can then hash in the same way we did for the others and search that. Doing this reveals a number of flags in VirusTotal that are much more useful for attributing and identifying the malware, but unfortunately I wasn’t able to attribute a name or strain to this sample. At any rate, we do know that it was downloaded by a device operating on 172.16.0.131, which has a MAC address of 2c:27:d7:d2:06:f5 and was downloaded on 2022-02-23 at 18:29:20 UTC.

Identifying hosts and users

There are a number of different ways to identify host names and users within a packet capture file in Wireshark. The few methods that I am aware of generally involve filtering the entries in Wireshark to find entries that include information like the host name or a username.

For this particular exercise, the question asks to identify all of the hosts and user accounts active in the network, which is broader than a more specific question (such as “what is the host name of the infected machine?”) and for me makes this a little more challenging.

As we’re looking for a broad set of data, I opted to use broader searching methods. The first was to simply filter for dhcp traffic and find host names in the DHCP Request entries by looking under the packet details section for Dynamic Host Configuration Protocol, expanding that and then expanding Option: (12) Host Name. Through this method, I was able to find a host name called DESKTOP-W5TFTQY.

While this is a good start, it doesn’t seem to be a complete picture of the network. I next opted to filter the traffic for Kerberos traffic specifically, by typing kerberos into the filter. This revealed a lot of traffic. Kerberos traffic is quite good in that it makes it easy to identify user and host names from that traffic.

To do this, select a request entry from the list and under the packet details section expand Kerberos, then as-req, req-body and finally, right-click CNameString and select Apply as Column.

If we then look at our Kerberos traffic again, we can see host names and usernames referenced in the column that we’ve just added. Through this method I was able to find the following active hosts and users in the network (I’ve also listed the IP address and MAC address that each is using):

Final answers and solutions

1. What hosts/usernames are active on this network?

The following hosts are active on the network, using the listed IP addresses, MAC addresses and usernames:


I was able to find these by filtering the capture for kerberos traffic.

2. What type of malware are they infected with?

I was able to identify two malware infections in the packet capture, and attribute one as Emotet, though I was unable to find the name for the second infection:


The user operating on 172.16.0.170 is infected with Emotet, but I was unable to find this during my analysis. In the answers for the exercise, Brad provided the following line as indicating traffic downloading an Emotet DLL:


Additionally, Brad identified the sample that I was unable to (on 172.1.0.131) as ‘Formbook’ (also known as ‘XLoader’).

Conclusion

While I wasn’t able to find all of the answers for this exercise, it does feel great to know that I am at a point where I can start finding some of the answers in exercises like this when working independently.

I’ll continue to practice and refine my skills, and maybe one day revisit this exercise to see if I can’t find that final infection on my own.