ICMP packets decoding using Wireshark and Tshark

November 4, 2023 0 Comments

In this lab, I am going to go through an analysis of ICMP packets using Wireshark.

Here is the pcap file that I will go through:

One of the first things that catches my eye is the length of the packets. The ICMP echo request packets are bigger than the ICMP echo replies (56 bytes for the request versus 42 bytes for the reply). This is very odd as regardless of the OS used by the sending and receiving systems, whatever you receive in an echo request packet you’re required to reflect it back in your echo reply. If I send a Ping packet from a window system to a Linux system, the Linux system has to put what windows wanted to use for a payload in its echo reply and not what it normally uses for a payload So these sizes should be the same, and as we can see the echo request is showing up a little bit bigger than what we’re getting for an echo reply.

If i scroll down the file, this pattern gets even weirder:

So the reply packet length which was until now always equal to 42 bytes is now changed to 46 bytes. Right after this packet, I notice that when the reply got a little bigger the request got way bigger (106 bytes). Then the reply went back to 42 again. If I scroll down a little more this seems to continue for a while with request packets 106 bytes in length and reply packets 42 bytes in length.

The second thing that is grabbing my attention is that the IP ID is fixed at 1 while the sequence number is going up by one each time. This is the kind of pattern I expect to see on a Windows system but Windows systems have a starting TTL of 128 while the TTL displayed by the source system is equal to 246. Therefore I cannot really tell if the source system is a Windows system or not.

Network gear like Cisco devices usually have a starting TTL of 255 and Linux and Macintosh systems have a starting TTL of 64.

At this point in the analysis, my best guess is that the source system probably has a starting TTL of 255 and it is sitting 9 hops away from me (255 – 246 = 9 hops). I know it’s doing windowy things up with IP IDs and Sequence number increments but not using a windows TTL. Because of this my normal passive fingerprinting goes out the window a little bit at this point. One possible scenario is that somebody is crafting these packets and in this case the starting TTL could well be 246 and my assumption of this system sitting 9 hops could completely wrong. The TTL could be anything and the system could be 8 hops away, 7 hops away or it might even be on the local network.

Now I am going to look at the payloads. This is an echo requests payload:

and the echo replies:

We can see in the lower panels that the payloads do not match which is again very odd.

If I keep on scrolling down these payloads, I even start to find words in the payloads

This looks like someone ran the task list command on a window system. This does not look like somebody is pinging something. This is somebody generating traffic to make it look like they are pinging something but they are using that to go through and exfiltrate data. ICMP was not designed to transmit any data but that does not mean you can not do that.

Wireshark does not allow me to follow this ICMP string but I can use Tshark to do this:

My command is Tshark -n so that I don’t resolve any host names -r to read the pcap file -T fields to specify the fields that are going be presented, -Y data.data to present the data field as just a raw hex output -e “data.data” this the field I want to print (the data field). Head is used to print the first 10 lines.

Now, I need to convert this payload to make it readable and usable. I can use CyberChef to convert this payload :

I can also convert it in wireshark using this command:

It looks like a directory listing and based on the directory structure it looks like a windows system.

I also see “dir” repeated twice at the beginning. Why ?

This is a terminal thing as in using a terminal. Back in the days, Telnet didn’t require any real real processing on our side. You could use what was referred to as a dumb terminal. It was not much more than just a display and everything would work because everything was getting processed on the server. Telnet was character based and when you would type let’s say the letter D, it would reflect back the letter D. If you were sniffing the packets, you’d see the letter D go from the client to the server, and then you’d see it go from the server to the client so that it could get presented on the screen, because the terminal wasn’t even reading what you’re typing on the keyboard. It didn’t even do that. The server was actually responsible for doing that.

So to have somebody type a command and then have it reflected back to them, that is a terminal thing. It looks like someone is using echo request and echo reply packets to have terminal access to some system which I assume is a window system.

If I scroll down, I can also a command prompt where somebody ran the tasklist command:

I can see all the tasks running on this system.

This leads me to the conclusion that this is a Command and Control channel. Somebody set up a C2 channel using ICMP.

Leave a Reply

Your email address will not be published. Required fields are marked *