Imagine you are a network forensics expert who has been tasked with analyzing the PCAP file. As soon as you open the file in Wireshark, you are presented with the following:

What we can see from the capture file is that it contains a ton of ICMP packets traveling to and from 192.168.153.129 and 192.168.153.130. We quickly added a new column by right-clicking the column header in Wireshark and choosing Column Preferences and adding a new column by clicking the + button and choosing its type as UTC for the UTC time, as shown in the following screenshot:

Next, we go to the Statistics tab and choose Capture File Properties:

The preceding option will populate the following window:

We can see a good amount of detail related to the capture file, such as the date and time of the first packet, last packet, duration, average packets per second, and the number of packets captured. When we populate the Endpoints tab, we can see the following:

We can quickly determine that the 192.168.153.129 and 192.168.153.130 IP addresses are communicating. We can confirm this by opening the Conversations tab:

We can see that both IPs are communicating. However, the strange thing is that the only traffic exchanged between these two is ICMP traffic. Using the filter as icmp.type == 8 displays that there are 510 ICMP echo requests sent from 192.168.153.129 to 192.168.153.130:

Let's see the number of replies by setting the icmp.type == 0 as follows:

We can see that the number of replies is almost equal to the number of requests—Strange! Someone would never send out that amount of ping requests intentionally—unless they are conducting a DOS attack. However, carrying out a ping of death or Ping DoS will require a significantly higher number of packets.

There is something wrong with this. Let's investigate the packets:

Everything seems fine until we reach packet number 149, to which no response was received from the target. The next packet, number 150, contains something of interest:

Packet 150 contains ipconfig in the data segment. Hmm.. this is awkward! Let's investigate further:

Packet number 179 has a system path in it. This is going south! The found traces denote that someone is accessing this system using an ICMP shell. The ICMP shell is a backdoor that makes use of data fields to send replies to a command sent by the attacker. Since all the requests originated from 192.168.153.129, we have our attacker. We can also see another strange thing: The ICMP packets are missing data fields, apart from the packets' ICMP backdoor packets. This gives us an edge to only focus on the packets having data, for this, we can type data as the filter:

We can see that we are only left with 17 packets out of 1,087, which can be easily traversed using Tshark. Tshark is the command-line wireless equivalent and is way better for people who love the command line. We will make use of PowerShell to run Tshark in Windows, as follows:

.	shark.exe  -Y data -r C:UsersApexDesktopWireicmp_camp.pcapng -T fields -e data  

The preceding command runs Tshark with the -Y switch as data, which denotes the filter, -r as the path of the capture file; the -T fields denotes the field types to print, and -e denotes which fields will be printed. Additionally, more details on these optional switches can be found using man tshark or tshark –help command in Windows. Now, let's run this command as shown in the following screenshot:

We can see that we have all the data from the 17 packets in hex. Let's copy this data into Notepad++:

Notepad++ contains pre-installed plugins to convert hex into ASCII. Let's browse to the Plugins tab and choose Converter | Hex -> ASCII:

As soon as we press the Hex -> ASCII option, we will have the following:

God! Someone was running commands on the system; they ran ipconfig followed by the whoami command.

In this exercise, we saw how innocent-looking ICMP packets were used to access a compromised system. However, throughout this exercise, we learned how to do a few things: We investigated ICMP packets, found some malicious activity, gathered and clubbed data from the various packets into a single file, and decoded them from hex into ASCII to reveal the intentions of the attacker and the activities that they performed on the target. We also identified that the backdoor was making use of the ICMP protocol to conduct command and control, and we looked at using Tshark for the very first time.