You are presented with some captured traffic from an internal network. Your job is to identify the various users and applications that were working in that network.
Identify the network's users
Identify protocols working within a network.
How to use Wireshark to identify network activities.
How to examine the headers and the payloads.
Identifying and spotting different activities on the network.
The provided PCAP file can be found at Desktop/Module7/Lab18/full_final.pcapng.
First, load this PCAP file into Wireshark.
Using the Wireshark protocol hierarchy option, we get a general overview of the protocols within the PCAP file.
Looking at the results, we can see that we have many well-known protocols such as DNS, DHCP, HTTP, and undefined protocol under the "Data" category.
We can use the HTTP filter to only display the HTTP traffic.
And view the packet details from the windows below:
The first HTTP packet came from 192.168.153.137 and was going to 212.58.244.68.
Usually, HTTP traffic is preceded by a DNS query to get the IP address of the site the user has requested.
We can use go back in the PCAP file and look for the requests which occurred before the HTTP request.
Alternatively, we can filter for the DNS traffic using the DNS filter, and choose the packet with the closest sequence number to the HTTP's first packet.
We can see that the first HTTP packet has the sequence number 20.
Now we need to examine the DNS traffic looking for the request that has occurred before this packet.
It seems that the closest DNS packet to precede the HTTP traffic packet number 20, is the DNS packet number 15 which originated from the client 192.168.153.137.
The client seems to ask about the www.bbc.com website and the server responded by sending the query with the appropriate response.
Since the question is asking about ports and sequence numbers, let's follow it on the TCP level.
The DNS packet sequence number is 15, and the first HTTP packet's number was 20. So we should expect to find the TCP handshake between 15 and 20.
The order of the events should be:
Sending the DNS query
Starting the TCP handshake
Sending the first HTTP request
Let's take a look at the first segment.
You can see the source port 49385 which our browser used to send the SYN segment. And the webserver is -typically- using port 80.
We can also examine the flags within that segment.
Looking at that the sequence number, we see that Wireshark is telling us that the first segment has the sequence number 0 even though we know that it is supposed to be a random number.
Wireshark marks the first packet in a traffic flow starting from 0 to make it easier for the analyst to follow the stream.
If we want to extract the actual sequence number, we need to go to the packet's hex dump in the window below.
If we translate the hex number below, we get the actual sequence number, which is 3070975449.
Now, according to how TCP works, the server should acknowledge that segment with an ACK and its own sequence number.
Here we can see the server sending a segment with SYN and ACK flags as shown.
The server's sequence number is 971266888.
And notice that the Server is sending the sequence number of the client's last received segment which is the b7 0b 5d da we saw earlier.
The final TCP segment sent by the client acknowledges the server's SYN segment.
The Sequence number is b7 0b 5d da, which is the previous sequence number (b7 0b 5d d9) +1. The segment also has the server's last sequence number in the acknowledgment field (39 e4 5b 49).
We can use the bootp filter to display the DHCP filter, as follows.
It seems that there are two DHCP cycles in the file. From the first look, we can see that a machine has requested an IP address, and another machine has released an IP address and re-requested an address.
Let's analyze the first DHCP discover packet.
We can see that the DHCP request is encapsulated within a UDP datagram.
The datagram originated from Port 68, and the server seems to be listening on Port 67.
We can see that this packet came from the device with the mac address specified in the figure.
As mentioned earlier, we know that the DHCP process is usually initiated when the client sends a "discover" packet to the network.
This discover packet contains the IP address which the client wants to obtain from the server alongside the client's host name and mac address in the "option" section.
The server replies with a DHCP offer packet containing the server's IP address and the client assigned IP address.
The offer also contains the lease time, which is the time the client can keep the IP address. After the lease time is over the client can request to keep that IP address for another period. The offer also contains the network subnet mask, DNS server, network's name, and its default gateway.
Just like before we can filter the ICMP traffic using the ICMP filter in Wireshark
Even without an in-depth examination of the packet, Wireshark description tells us that it's a PC pinging another PC.
By examining the content of the ICMP packet, we can extract the source and destination IP address (192.168.153.130 is pinging 192.168.153.137) as well as the time to live which equals 128.
Sometimes in a big file of packets, some custom connections may go unnoticed.
When working in network forensics, you'll often encounter applications that implement their own application-layer protocol.
That means Wireshark will only show them as typical TCP stream without being able to recognize what type of data is being encapsulated.
Recall that the data section we saw in the protocol hierarchy window, we opened at the beginning of this lab under the TCP section.
This suggests that non-standard application data was exchanged over the network.
We can investigate that mystery by looking at more statistics on the conversations within our file.
We can examine the TCP conversation and order them in respect to the destination port by clicking the TCP and Port B tabs respectively.
We can see that most of the connections we captured are going to either Port 80 or Port 443 which are normally used for HTTP and https connections.
However, at the end of the file, we notice a connection going to a non-standard port which is 5555
We can view the packets of that connection by filtering the packets that were going to or coming from port 5555.
The displayed packets show that after the TCP handshake there is a data exchange between the two communicating parties and then the connection is reset by the client who initiated.
In order to examine what sort of data was being exchanged between the communicating parties, we can use the follow TCP stream option to examine the data.
The stream shows what seems to be a custom chat application being used between the two machines.
