To perform the exercises covered in this chapter, you will require the following:

Every investigation requires a precise methodology. We will discuss the popular network forensics methodology used widely across the industry in the next section.

To assure accurate and meaningful results at the end of a network forensic exercise, you, as a forensic investigator, must follow a rigid path through a methodological framework. This path is shown in the following diagram:

Obtain, Strategize, Collect, Analyze, and Report (OSCAR) is one such framework that ensures appropriate and constant results. Let's look at each phase from a network forensics point of view:

Network evidence can be collected from a variety of sources and we will discuss these sources in the next section. The sources that we will be discussing are:

Tapping the wire and the air

One of the purest and most raw forms of information capture is to put taps on network and optical fiber cables to snoop on traffic.

 Many commercial vendors provide network taps and SPAN ports on their devices for snooping where they will forward all traffic seen on the particular port to the analyzer system. The technique is shown in the following diagram:

In the case of WLAN or Wi-Fi, the captures can be performed by putting an external wireless receptor into promiscuous mode and recording all the traffic for a particular wireless access point on a particular channel. This technique is shown in the following diagram:

 

Routing tables on routers

Routing tables in a router maps ports on the router to the networks that they connect. The following table is a routing table. These tables allow us to investigate the path that the network traffic takes while traveling through various devices:

Most of the routers have inbuilt packet filters and firewall capabilities as well. This means that they can be configured to log denied or certain types of traffic traveling to and from the network.

Dynamic Host Configuration Protocol logs

Dynamic Host Configuration Protocol (DHCP) servers generally log entries when a specific IP address is assigned to a particular MAC address, when a lease was renewed on the network, the timestamp it renewed, and so on, thus having significant value in network forensics. The following screenshot of the router's DHCP table presents a list of dynamically allocated hosts:

DNS servers logs

Name server query logs can help understand IP-to-hostname resolution at specific times. Consider a scenario where, as soon as a system got infected with malware on the network, it tried to connect back to a certain domain for command and control. Let's see an example as follows:

We can see in the preceding screenshot that a DNS request was resolved for malwaresamples.com website and the resolved IP address was returned.

Having access to the DNS query packets can reveal Indicators of Compromise for a particular malware on the network while quickly revealing the IP address of the system making the query, and can be dealt with ease.

Readers who are familiar with the basics of Wireshark can skip this section and proceed with the case studies; however, readers who are unfamiliar with the basics or who need to brush up on Wireshark essentials, can feel free to continue through this section. Let's look at some of the most basic features of Wireshark. Look at the following screenshot:

Wireshark

Once we execute Wireshark, we are presented with a screen similar to the preceding picture. On the left-hand side, we have a list of the available interfaces to capture packets from. In the middle, we have recent packet capture files and on the right- hand side, we have online help and user guides. To start a new packet-capture, you can select an interface, such as Ethernet, if you are connected over the wire, or Wi-Fi, if you are connected on a wireless network. Similarly, if you need to open a packet-capture file, you can press the Open button, browse to the capture file, and load it in the Wireshark tool. Let's capture packets from the wireless interface by selecting Wi-Fi and pressing the Start button, as shown in the following screenshot:

We can see from the preceding screenshot that we have various types of packets flowing on the network. Let's understand TCP conversations, endpoints, and basic Wireshark filters in the upcoming sections.

Identifying conversations and endpoints

You may want to view the list of IP endpoints that your system is communicating with. To achieve this, you can navigate to the Statistics tab and select Conversations, as shown in the following screenshot:

We can see that we have a variety of endpoints that are having conversations, the number of bytes transferred between the endpoints, and the duration of their data exchange. These options become extremely handy when you want to investigate malicious traffic and identify the key endpoints that are being contracted. Additionally, we can see that most of the conversations in the preceding screenshot involves 192.168.1.15 but we may not recognize the IP addresses its talking to.

 We can also make use of the Endpoints option from the Statistics tab, as shown in the following screenshot:

From the preceding screenshot, we can see all the endpoints, and sorting them using the number of packets will give us a clear understanding of the endpoints that are transmitting the highest number of packets, which is again quite handy when it comes to analyzing anomalous network behavior.

Identifying the IP endpoints

Domain names were invented to make it more easy to remember sites with common phrases. Having a list of IP addresses in the previous section would make no sense to us, but having a list that shows the resolution of the IPs into domain names can help us a lot. On clicking the Show address resolution/ Resolved Addresses option, we will be presented with the following:

Well, this now makes proper sense, as we have a list of IP addresses with their domain resolutions that can help us eliminate the false positives. We saw in the previous endpoint section that the second-highest number of packets in the endpoints originated from 162.125.34.6. Since we don't have an idea of what IP address this could be, we can easily refer to the address resolutions and figure out that this is dropbox-dns.com, which looks suspicious. Let's search for it on Google using the string client.dropbox-dns.com, and browsing the first result from the search, we have the following result:

We can see from the preceding search result (the official Dropbox website, https://www.dropbox.com/) that the domain is a legitimate Dropbox domain and the traffic originating to and from it is safe (assuming that Dropbox is permitted on the network or if allowed for a select group of users that the traffic is associated with those users only). This resolution not only helps us identify domains, but also speaks a lot about the software running on the target as well. We already identified Dropbox as running on the system. We also identified the following domains from the Resolved Addresses pane in Wireshark:

• A Gmail account being accessed
• A Qihoo 360 antivirus

• An HDFC bank account
• The Grammarly plugin
• The Firefox browser 

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, andudp.portmeans 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 port5353.

Note

In the latest version of Wireshark mdns is a valid protocol and display filter such as dns && !mdns works fine.

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.

Consider a scenario where an attacker has planted a keylogger on one of the systems in the network. Your job as an investigator is to find the following pieces of information:

Additionally, in this exercise, you need to assume that the packet capture (PCAP) file is not available and that you have to do the sniffing-out part as well. Let's say that you are connected to a mirror port on the network where you can see all the data traveling to and from the network.

We can begin our process as follows. We already know that we are connected via a mirror port. Let's sniff around on the interface of choice. If connected to the mirror port, choose the default interface and proceed with collecting packets, as shown in the following screenshot:

Most keyloggers work on the web (HTTP), FTP, and email for delivering the keystrokes back to the attacker. We will try all of these to check whether there's anything unusual with packets from these protocols.

Let's try HTTP first by setting the http filter, as shown in the following screenshot:

There is HTTP data, but everything seems fine.

Let's try a couple of protocols, SMTP and POP, to check for anything unusual with the email protocol, as shown in the following screenshot:

Everything seems fine here as well.

Let's try FTP as well, as shown in the following screenshot:

FTP

Well, we have plenty of activity on the FTP! We can see that the FTP packets contain the USER and PASS commands in the capture, which denotes a login activity to the server. Of course, this can be either the keylogger or a legitimate login from any user on the network. Additionally, we can see a STOR command that is used to store files on the FTP server. However, let's note down the credentials and filenames of the uploaded files for our reference and investigate further. Since, we know that the STOR command is used to store data on the server.

Let's view these data packets by changing filter to ftp-data, as shown in the following screenshot:

Changing filter to ftp-data

Let's see what we get when we follow the TCP stream of the packet, we can see that we have the following data being posted to the server:

We can see that the data being transmitted contains the word Ardamax, which is the name of a common piece of keylogger software that records keystrokes from the system it has infected and sends it back to the attacker. Let's save the packet capture in PCAP format by selecting File | Save As and choosing the .pcap format. We will be using the .pcap format only since the free version of NetworkMiner support only PCAP files and not the pcapng format.

Let's open the saved file using NetworkMiner as shown in the following screenshot:

Opening the saved file using network miner

We can see we have a number of hosts present in the network capture.

Let's navigate to the Credentials tab, as shown in the following screenshot:

We can see that we have the username and password captured in the PCAP file displayed under Credentials tab in NetworkMiner. We previously saw the STOR command, which is commonly used in uploading files to an FTP from the Wireshark dump.

Let's browse to the Files tab and see the files that we are interested in:

Files tab

We can see plenty of files. Let's open the files that we found using the STOR command in the browser, as shown in the following screenshot:

The attacker was not only keylogging, but was also fetching details such as the active window title along with the key logs. So, to sum this up, we have the following answers to the questions that we asked at the beginning of the exercise:

We have plenty of information regarding the hacker. At this point, we can provide the details we found in our analysis in the report, or we can go one step further and try to uncover the identity of the attacker. If you chose to do so, then let's get started in finding out how to uncover this information.

We already found their credentials in the server. Let's try logging into the FTP server and try to find something of interest, as shown in the following screenshot:

We can see that we are easily able to log into the server. Let's use an FTP client, such as Royal TSX in Mac (FileZilla for Windows), to view the files that reside on the server, as shown in the following screenshot:

Wow! So much information has been logged; however, we can see two directories named John and Jo. The directory Jo is empty but we may have something in the directory named John.

Let's view the contents of John, as shown in the following screenshot:

It looks as though the attacker is applying for jobs and keeps their updated resume on their server. The case-study analysis proves that the keylogger is a newbie. In answering the last question regarding the identity of the attacker, we have successfully conducted our first network forensic analysis exercise. The resume we found might have been stolen from someone else as well. However, this is just the tip of the iceberg. In the upcoming chapters, we will look at a variety of complex scenarios; this was an easy one.

In the next example, we will look at TCP packets and try figuring out what were the event causing such network traffic.

Let's analyze another capture file from https://github.com/nipunjaswal/networkforensics/blob/master/Ch1/Two%20to%20Many/twotomany.pcap, that we currently don't know any details about and try reconstructing the chain of events.

We will open the PCAP in Wireshark, as follows:

From the preceding screenshot, we can see that numerous SYN packets are being sent out to the 64.13.134.52 IP address. However, looking closely, we can see that most of the packets are being sent every so often from a single port, which is 36050 and 36051, to almost every port on 64.13.134.52. Yes, you guessed right: this looks like a port scan. Initially the SYN packet is sent out, and on receiving a SYN/ACK, the port is considered open.

We know that the originating IP address, 172.16.0.8, is an internal oneand the server being contracted is64.13.134.52. Can you figure out the following?:

Answering the first question requires a more in-depth understanding of a TCP-oriented communication and its establishment, TCP works on a three-way handshake, which means that on receiving a synchronize (SYN) packet from the source IP address, the destination IP address sends out a synchronize/ acknowledgment (SYN/ACK) packet that is followed by a final acknowledgment (ACK) packet from the source IP address to complete the three-way handshake. However, as we can see from the preceding screenshot, only a SYN/ACK is sent back from port 80, and there hasn't been an ACK packet sent out by the source IP address.

This phenomenon means that the ACK packet was never sent to the destination by the source, which means that only the first two steps of the three-way handshake were completed. This two step half open mechanism causes the destination to use up resources as the port will be help open for a period of time. Meanwhile, this is a popular technique leveraged by a scan type called SYN scan or half-open scan, or sometimes the stealth scan. Tools such as Nmap make use of such techniques to lower the number of network packets on the wire. Therefore, we can conclude that the type of scan we are dealing with is a SYN scan.

Applying the filer ip.src==64.13.134.5, we can see the responses sent by  64.13.134.52. It is evident that we have received the SYN/ACK from ports 53, 80, and 22, which are open ports. We can also see that there has been network loss, and the sender has sent the packets again. Additionally, we can see Reset Acknowledgment Packets (RST) that denote misconfigurations or the application running on the not willing to connect: the reasons for such behavior can differ.

Over the course of this chapter, we learned about the basics of network forensics. We used Wireshark to analyze a keylogger and packets from a port scan. We discovered various types of network evidence sources and also learned the basics methodology that we should follow when performing network forensics.

In the next chapter, we will look at the basics of protocols and other technical concepts and strategies that are used to acquire evidence, and we will perform hands-on exercises related to them.

To improve your confidence in your network forensics skills, try answering the following questions:

For further information on Wireshark, refer to https://www.packtpub.com/networking-and-servers/mastering-wireshark