6 min read

(For more resources related to this topic, see here.)

Getting ready

It’s not new to use tunneling techniques to attempt to circumvent firewalls or other countermeasures that do not make use of deep packet inspection. Tools such as iodine, Hping3, Netcross, and so on, can be used to encapsulate certain type of traffic within the payload of another protocol and thus get its contents hidden. The use of these tools can be tedious for network administrators who try to control the information entering and leaving their network. Tshark can be an effective tool to detect this type of traffic if it’s done wisely.

How to do it…

  1. So suppose we are performing a periodic analysis of our network. We decide to start looking at the protocols used to make connections with the outside. Note that with the condition ip.addr! = we will ensure that Tshark displays packets involving communication between our LAN and any other network (in this case the outside because we do not have more subnets). This way, we are also filtering connections between hosts on our LAN.

    bmerino@Mordor:/$ tshark -r icmp.pcap -o column.
    format:'"Protocol","%p"' -R "ip.addr !=" | sort -u

  2. According to our policies (only allowed HTTP/HTTPS, DNS, and ICMP), we can see that all protocols seem normal. Since ICMP can result from a variety of network issues we decided to run the following:

  3. We know now that a user of our network is communicating with an external host via ICMP. What is striking about this communication is the size of those packets. To see exactly what kind of ICMP packets they are sending, we run:

    bmerino@Mordor:/$ tshark -r icmp.pcap -T fields -e icmp.code -e
    icmp.type -R 'frame.number==41628'
    0 8

  4. The user is sending ICMP echo request (type = 8/code = 0) of a size well above a standard ping. To know for sure the reason for that size we do a dump of one packet to see its payload:

  5. With the dump, we verified that the user was leaking information to the outside via ICMP packets. In the example the user is sending the RSA private key of a certain user/service. We realized that all payloads started with “BOF” to indicate the beginning of the file content. Likewise the “EOF” string was being used to indicate the end. With this data we could find out that the user was using the ICMP Exfiltration module from Metasploit to get all kinds of files from the internal host.

  6. We could take advantage of the BOF string to list all files sent by that user (the external IP has been omitted).

    bmerino@Mordor:/$ tshark -r icmp.pcap -R "icmp contains BOF &&
    ip.src =="

    This would generate the following output:

    41591 764.064922000 -> *.*.*.*ICMP 938 Echo (ping)
    request id=0x1b3d, seq=1/256, ttl=64
    41593 765.065198000 -> *.*.*.*ICMP 938 Echo (ping)
    request id=0x1b3d, seq=3/768, ttl=64

  7. Although most files were plaintext, one of them looked as follows:

    bmerino@Mordor:/$ tshark -r icmp.pcap -R "frame.number==268" -V |
    grep ^0 | cut -d" " -f21 | tr -d 'nBOF'

  8. This seems to indicate that he was sending a file encoded in base 64, possibly to deal with nonprintable characters. Leveraging the output and using a little bash we get the following:

    bmerino@Mordor:/$ tshark -r icmp.pcap -R "frame.number==268" -V |
    grep ^0 | cut -d" " -f21 | tr -d 'n' | sed 's/^...//' | base64 -d
    MZ ? ? ? ? @ ? ? ? ? ! ? L ? !This program cannot be run in DOS mode.
    $PEL ? 4 ?
    ? bL ? @ 0

  9. Effectively the output indicated part of the PE header of an executable file. Now we can dump it to a file and analyze it with our favorite debugger.

There’s more…

Let’s see another case. The internal server ( of a certain organization has been compromised several times. The fact that the server is not accessible from the outside led us to think that an internal user had also been compromised, and the attacker was doing “pivoting” from that machine to the server. Another option was that an infected USB had been the root of the problem. However, after checking that the firewall did not filter the traffic DMZ —> Internal Network, we could confirm that this was the origin of the intrusion. The web server ( in the DMZ was compromised, and from here the attacker could access the internal LAN using the Administrator account. To do this the attacker used Mimikatz to get the credentials of that machine and then ran Psexec against the internal server with the Administrator account.

We realized this when we checked the traffic from DMZ to the Internal LAN as follows (note the use of the flag SYN = 1 and ACK = 0 to show only connections initiated from the DMZ):

bmerino@Mordor:~$ tshark -r pivo.pcap -T fields -e ip.src -R "ip.src == && ip.dst== && tcp.flags.syn==1 && tcp.
flags.ack==0" | sort -u

According to this information the machine (the web server) started some kind of connection with the internal server.

The following output shows an excerpt of the type of traffic generated between both machines:

bmerino@Mordor:~$ tshark -r pivo.pcap -o column.format:'"Info","%i","Pro
tocol","%p"' -R "ip.src == && ip.dst==" | head

This would generate the following output:

Tree Connect AndX Request, Path:$ SMB
Redirect (Redirect for host) ICMP
[TCP Retransmission] Tree Connect AndX Request, Path:
Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: PSEXESVC.

As shown in the output, the web server initiated a NETBIOS connection with the internal server (something totally suspicious). From there, he ran Psexec to authenticate to the server machine. You can also see the plaintext password and the user used to login the server (surely he uses Psexec with -u option, which sends the password in clear text):

bmerino@Mordor:~$ tshark -r pivo.pcap -x "ip.src == &&
ip.dst==" | grep "A.D.M.l" -m 1 -A 1 | awk -F " " '{print

This would generate the following output:


Note that there will be more complex cases that will require much deeper research. Take a look, for example, at this article at http://www.securityartwork.es/2012/11/27/ covert-channels-2/?lang=en, which explains some covert-channel techniques with a few TCP and IP fields. In such cases, the joint use of debuggers, traffic analysis tools, and event correlation will be our best ally.


This article explains how to obtain evidence from suspicious network traffic. We will look at tunneling techniques to attempt to circumvent security mechanisms (ICMP exfiltration, UDP tunnels, and so on) in addition to other post-exploitation attacks

Resources for Article :

Further resources on this subject:

Subscribe to the weekly Packt Hub newsletter

* indicates required


Please enter your comment!
Please enter your name here