This post details my approach to analysing a packet capture from Brad Duncan’s Malware Traffic Analysis website. By tackling the ‘Sunnystation’ exercise, I aimed to deepen my understanding of malware detection techniques and sharpen my network analysis skills. If you’re exploring malware traffic analysis, this write-up offers insights and practical tips to get started.

Introduction and Tooling

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

I recommend following Brad’s guide on setting up Wireshark for malware traffic analysis, which is a solid standard for this type of work. You can read his tutorial on the Unit42 website to get things configured and ready to go.

Technical Analysis

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.

Identifying Malware in Traffic

Typically, I’d start by checking for IDS alerts like those from Suricata. However, given that a malware download is already assumed, we’ll focus on that directly. An effective starting point for locating the 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.

Hashing and Verifying Files

Next, let’s generate a hash for these files and see if they’ve been flagged before. 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  zbBYgukXYxzAF2hZ
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 triggered multiple flags on VirusTotal, but the results didn’t clearly indicate the type of malware. To attribute it accurately, I needed to dig deeper.

Interestingly, several flags described the file as a “reversed DLL” with mentions of obfuscation. This suggested the image was a disguised, reversed DLL file, potentially unpacked or executed by another component.

Since I hadn’t reversed a file before, I turned to Google and found this solution using xxd and tac on the Linux command line. Running the following command:

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

produced a reversed version of the file—a DLL. After hashing and searching the reversed file, VirusTotal returned significantly more actionable results, though I couldn’t pinpoint a specific name or strain for the malware.

What I did identify was useful metadata: the file was downloaded by a device with the IP address 172.16.0.131 and MAC address 2c:27:d7:d2:06:f5 on 2022-02-23 at 18:29:20 UTC. While attribution remains incomplete, these details form a clearer picture of how the malware fits into the network activity.

Identifying Hosts and Users

With the malware identified, the next step is to explore the network traffic for host and user information.

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. Here are the active IP addresses, MAC addresses and host name and usernames identified on the network through the analysis of Kerberos traffic:

Final Answers and Solutions

The following sections summarise the key technical findings of the analysis. This includes identifying active hosts and usernames observed during the investigation, as well as the malware infections discovered. These findings represent the culmination of the analysis process, tying together the evidence gathered and the insights gained.

Active Hosts/Usernames


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

Malware Identified

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 was also 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 and Reflection

This exercise was an invaluable learning experience that sharpened my technical skills in malware traffic analysis, as well as my ability to work with tools like Wireshark and VirusTotal. While I successfully identified and attributed one malware infection (Emotet), the second infection presented a challenge that I wasn’t able to fully solve within the scope of the exercise. However, I see this as an opportunity for growth.

Key Takeaways

Areas for Growth

While I was able to identify key hosts, user names, and malware infections, there were aspects of the exercise I couldn’t fully resolve. For example, I was unable to identify the specific strain of malware in the second case. This is something I intend to revisit with a more refined approach, improving my ability to correlate network traffic with known malware signatures and hash values. I look forward to challenging myself with more complex cases and fine-tuning my investigative techniques.

This exercise has deepened my understanding of malware detection techniques, and I’m excited to continue expanding my knowledge in this area. The ability to think critically, troubleshoot issues, and adapt to new challenges are crucial skills that I’ll carry with me in my journey toward becoming a well-rounded security analyst.