Basic filters

Network forensics requires you to pinpoint a variety of packets to establish a clear vision for the investigation. Let's explore how we can do this by going through the following steps:

Set up some basic display filters in Wireshark to only view packets of interest, as shown in the following screenshot:

We can see that simply typing in dns as the filter will display DNS packets only; however, we can see that MDNS protocol packets are also displayed.

Considering that we only require DNS packets and not MDNS protocol packets, we can set the filter as dns && !mdns, where ! denotes a NOT operation, as shown in the following screenshot:

We can see from this that we don't have an exact filter for MDNS. So, how do we filter the MDNS packets out? We can see that the MDNS protocol communicates over port 5353. Let's filter that out instead of using an !mdns filter, as shown in the following screenshot:

We can see that providing the filter dns and !(udp.port eq 5353) presents us with only the DNS packets. Here, eq means equal, the ! means NOT, and udp.port means the UDP port. This means that, in layman's terms, we are asking Wireshark to filter DNS packets while removing all the packets that communicate over UDP port 5353.

Similarly, for HTTP, we can type in http as the filter, as shown in the following screenshot:

However, we also have  OCSP and Simple Service Discovery Protocol (SSDP) protocol data alongside the data that is filtered from the stream. To filter out the OCSP and SSDP protocol data, we can type in http && !ocsp, and since SSDP poses a similar problem to MDNS, we can type !udp.port==1900. This means that the entire filter becomes http && !ocsp && !udp.port==1900, as shown in the following screenshot:

We can see from this that we have successfully filtered HTTP packets. But can we search through them and filter only HTTP POST packets? Yes, we can, using the expression http contains POST && !ocsp as shown in the following screenshot. 

We can see that providing the HTTP contains POST filter filters out all the non-HTTP POST requests. Let's analyze the request by right-clicking and selecting the option to follow the HTTP stream, as shown in the following screenshot:

We can see that this looks like a file that has been sent out somewhere, but since it has headers such as x-360-cloud-security-desc, it looks as though it's the cloud antivirus that is scanning a suspicious file found on the network. 

Let's take note of the IP address and match it with the address resolutions, as shown in the following screenshot:

Well, the address resolutions have failed us this time. Let's search the IP on https://who.is/, as shown in the following screenshot:

Yes, it belongs to the QiHU 360 antivirus.

We can also select HTTP packets based on the response codes, as shown in the following screenshot:

We can see that we have filtered the packets using http.response.code==200, where 200 denotes a status OK response. This is handy when investigating packet captures from compromised servers, as it gives us a clear picture of the files that have been accessed and shows us how the server responded to particular requests.

It also allows us to figure out whether the implemented protections are working well, because upon receiving a malicious request, in most cases, the protection firewall issues a 404 (NOT FOUND) or a 403 (Forbidden) response code instead of 200 (OK).

Let's now jump into some case studies and make use of the basics that we just learned.