Sunday, May 7, 2017
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.
In many organizations, while specific ports are blocked so as to disallow Internet access, ICMP is allowed for troubleshooting purposes. As in, can I ping securitynik.blogspot.com? If successful, then yes I have successful Internet connectivity.
This seemingly simple exercise and its use of the ICMP protocol could instead be used as an opportunity to exfiltrate data or to use ICMP as a covert channel.
In this example, we have “2” (I put the two in brackets because it is actually one host, but we are simulating two) hosts that we are responsible for. One with IP “127.0.0.1” (client) and the other with “10.0.2.15” (proxy). “127.0.0.1” operates as the pTunnel server and the proxy at “10.0.2.15”.
To ensure we can analyze the traffic so as to perform network forensics, let setup tcpdump to capture the traffic “tcpdump -vnn -I any icmp or tcp port 80 or tcp port 8000 -w pTunnel.pcap”.
With this filter, we will capture ICMP traffic between the client and the proxy and the HTTP traffic between the proxy and the destination we are going to.
Now that let’s setup the ptunnel proxy with “ptunnel -x securityNik -c lo -v 4 -f ptunnel.log”.
-x securityNik – This is the password to ensure only hosts using this password can leverage the tunnel
-c lo – The listening interface of the proxy
-v 4 – The verbosity level
-f ptunnel.log – The log file to write the messages to
Now that we have our proxy setup, let’s look at setting up the client by using “ptunnel -p 127.0.0.1 -lp 8000 -da nba.com -dp 80 -v 4 -f pTunnel-c.log -x securityNik”
-p 127.0.0.1 – Sets the proxy IP
-lp 8000 – The port which will be used by the application
-da nba.com – The designation host we would like to connect to
-dp80 – The destination port on the host we would like to connect to
-v 4 – The verbosity level
-f ptunnel-c.log – The log file to write the messages to
Now that all of this is in place, let’s open a browser and connect to “10.0.2.15:8000”. If all goes well, this should open up “nba.com”
Looks like all went well.
Covert channels are obviously a big concern for most organizations. However, detecting some of these activities can prove difficult without proper baselines or knowing what normal vs abnormal looks like.
If we look at the ptunnel proxy log, we see the following as part of the setup process …
… and here we see from the client perspective
In the next post, we will look at analyzing this from the network forensics (packet analysis) perspective.
Ping Tunnel Manpage
Firewall Evasion with ICMP (Ping Tunnel)