WireShark for network forensics

It’s another day, and I am excited investigate another PCAP file on WireShark.

Identification is the second step of the incident response process. Even though I’m not yet employed as a professional, I still tackle it with seriousness and urgency, as though it happened to my client’s network. And even though the incident may have happened weeks, months, or even years ago, I still treat the incident as though it happened today.

I’m working through the PCAP challenges provided by Brad at Malware-Traffic-Analysis.net, which focuses on analyzing Windows-based malware-infected network traffic. I customized WireShark based on his suggestions, and find it extremely helpful in gathering relevant information.

The first thing I do is take note of the LAN segment range (which is usually provided), so I’m aware of the known-good endpoints/IP addresses in the client’s network. The more information I have to begin with, the better.

Next, I examine the IDS alerts for the possible initial infection, and take note of the two IP addresses in this communication. Since I’m already aware of the IP address range in the client’s network, I quickly determine the (potentially) infected host IP address, and switch over to WireShark for further investigation.

My attention now is on network traffic to and from this IP address. In WireShark, I click Statistics > Endpoints, which lists all of the endpoints by MAC address and IP addresses. I locate the IPv4 address, and right-click Apply as Filter > …Selected, so that I’m only shown network traffic to and from this particular address.

There is still a lot of packets to sift through, so I filter it further. Based on the alert, the client downloaded the potentially malicious file over TCP port 80 (HTTP), so I append the filter with http.request, to view the web traffic GET and POST requests from this IP address. This narrows it down substantially.

I find the packet that includes the GET request containing the file. I right-click the packet in the main window and go to Follow > TCP Stream… to view packet in more detail. There I find some useful information.

In this case, the “MZ…This program cannot run in DOS mode” indicates that the file is a Windows executable (the MZ is the first couple bytes of the file, also known as the file signature). So far, this is the potential initial infection. Threat actors may not necessarily show the executable in plain sight. In this case, the file is explicitly YAS20.exe. However, a lot of malware infections happen through phishing or malspam, through which malware executables are obfuscated by a benign file, such as a .png or .exe or .doc, that appears harmless to the target end-user.

This is considered an artifact and an indicator of compromise (IOC), and I include this in the incident report. I also need to gather as much information as possible about the file.

I close out the details window and click File > Export Objects > HTTP…, locate the file, and save it to my computer (I use a Kali Linux VM). I want to know the hash value of this file, so I use the sha256sum command in the terminal to look up its SHA256 hash.

I search query the hash on VirusTotal, to see if this file has been checked before. It in fact does contain malware binaries, so I document the hash in the incident report, along with the file location from the packet details in WireShark, including the file size.

I need to gather more information about the infected host, and include it in the incident report. I already have the IP address, but I also need the MAC address, host name, username, operating system details, and the day and time this infection happened. This helps form the scope of the incident.

After documenting this information in the report, I switch back to WireShark and look through the other GET requests. I find two more post-infection GET requests from the victim’s IP address. I investigate further, and find two .png files that are also malicious executables. I document their hashes, file paths, and file sizes, etc.

Based on the IDS alerts and my own research, I determine that this was a Trickbot infection. Now I know what it was, who it happened to, and how and when it happened.

I feel that writing everything down is extremely important, because it keeps everything organized and cohesive, and is vital for building a knowledge base. Mind you, this is one incident, with one network, and there can always be more details to include. It’s such an exciting and challenging kind of work. I wanted to keep this post reasonably brief, and is intended to document my thought process. I really enjoy the investigative process, and I know there is so much more to learn!