ICMP Covert Channels: pTunnel – Network Forensics (Packet Analysis)

In the previous post, we looked at setting up pTunnel. Now let’s look to see how we might be able to detect this from the network as well as the host perspectives.

First up, we can leverage “netstat -nltp | grep 8000”.
Alternatively, we could have used “llsof -I | grep ptun”. This shows us all network communication for the “ptunnel” process.

From above, we see the ptunnel is running as root and has a PID of 5151. In this case I used “grep 8000” as I’m aware what port the client is listening on. However, if we didn't we would have to know what should be expected vs what should not on the end host. Now that we have this, now let’s look at our full packet capture to see if there is anything to help us understand what was going on over port 8000.

Before we do that, let’s take a look at our packet file to understand what is going on with it.

First up, let’s grab an overview of the protocol hierarchy by running “tshark -r pTunnel.pcap -n -z io,phs -q” at the command line.


From the image above, we see there are lots of TCP (HTTP) and ICMP traffic. Let’s first peak into to ICMP to see if this is all “regular” traffic. To achieve this let’s run “tshark -r pTunnel.pcap -n -Y 'icmp'”.

 

While this might look like nothing suspicious at first glance, the size of the requests and reply should be a cause of concern. By default, windows uses 32 bytes of data for ICMP echo request and that means I should expect 32 bytes of data in the response. On Linux (at least the SIFT workstation I am using right now) the default is 64 bytes of data. Looking at the packets above we see some packets as large as 1096 bytes. Additionally, there seems to be ICMP replies without any requests.

Let’s take a look into “one” of the echo request echo replies. Specifically lets look at the packet with ICMP sequence number 3 by doing “tshark -r pTunnel.pcap -n -Y 'icmp.seq == 3'”

This gave us a quick summary of what is involved.


Some standouts are the following:
1. 2 replies to 1 request
2.  Usual size of the requests
3. Reply with a size much larger than the request

Let’s dig into these packets, the one with size 1096 to see what is in this ICMP packet. to do this let’s add ‘-x” to the above tshark command such as “tshark -r pTunnel.pcap -n -Y 'icmp.seq == 3' -x”. This gives us:


Image edited for brevity

so we peaked into the ICMP packet to see what is being transmitted and clearly we see this is more than “regular” ICMP data.

For now there is no need to go much further with this post as we know the rest of the traffic is HTTP and we can analyze that further if we wish. However, for me at this time there is no need to as this was more about focusing on ICMP as a covert channel via ptunnel.

So a quick refresher of how this works.
1. Setup the proxy
2. Setup the client
3. Use you application to connect to the client
4. The client then communicates with the proxy via ICMP
5. The proxy then communicates with the destination via the port you specified to contact the destination on

Ok Folks that all I have for ptunnel.