ICMPTunnel – Firewall evasion


Transparently tunnel your IP traffic through ICMP echo and reply packets.

‘icmptunnel’ works by encapsulating your IP traffic in ICMP echo packets and sending them to your own proxy server. The proxy server decapsulates the packet and forwards the IP traffic. The incoming IP packets which are destined for the client are again encapsulated in ICMP reply packets and sent back to the client. The IP traffic is sent in the ‘data’ field of ICMP packets.

RFC 792, which is IETF’s rules governing ICMP packets, allows for an arbitrary data length for any type 0 (echo reply) or 8 (echo message) ICMP packets.

So basically the client machine uses only the ICMP protocol to communicate with the proxy server. Applications running on the client machine are oblivious to this fact and work seamlessly.

Use Cases

  1. Bypassing Captive Portals: Many public Wi-Fi use Captive Portals to authenticate users, i.e. after connecting to the Wi-Fi the user is redirected to a webpage that requires a login. icmptunnel can be used to bypass such authentications in transport/application layers.
  2. Bypassing firewalls: Firewalls are set up in various networks to block certain type of traffic. icmptunnel can be used to bypass such firewall rules. Obfuscating the data payload can also be helpful to bypass some firewalls.
  3. Encrypted Communication Channel: Adding sufficient encryption to the data, icmptunnel can be used to establish an encrypted communication channel between two host machines.


  1. A POSIX-compliant host with root access that will be communicating with only ICMP protocol. This will be the client.
  2. A POSIX-compliant host with root access with full access to the internet. This will act as our proxy server.
  3. The proxy server should be accessible from the client host.

Note: Although icmptunnel has been successfully tested on Ubuntu 14.04 LTS, it should work on others as well.

Step-by-step instructions

  1. Install make on both machines.
  2. Clone this repository using this command:
    git clone https://github.com/DhavalKapil/icmptunnel
  3. Run make:
  4. On the server side run the tunnel with root privileges:
    [sudo] ./icmptunnel -s
  5. On the client side, find out your gateway and the corresponding interface:
    route -n
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 eth0

    Edit client.sh and replace <server> with the IP address of the proxy server. <gateway> with gateway address obtained above and similarly for <interface>.

  6. Check the DNS server at client side. Make sure it does not use any server not accessible by our proxy server. One suggestion is to use’s DNS server) which will be accessible to the proxy server. You would need to edit your DNS settings for this. You might need to manually delete the route for your local DNS server from your routing table.
  7. Run the tunnel on your client with root privileges:
    [sudo] ./icmptunnel -c <server>

The tunnel should run and your client machine should be able to access the internet. All traffic will be tunneled through ICMP.


icmptunnel works by creating a virtual tunnel interface(say tun0). All the user traffic on the client host is routed to tun0. icmptunnel listens on this interface for IP packets. These packets are encapsulated in an ICMP echo packet(i.e. the payload of the ICMP packet is nothing but the original IP packet). This newly generated ICMP packet is sent outside the client machine, to the proxy server, through the restricted internet connection.

The proxy server receives these ICMP packets and decapsulates the original IP packet. This is retransmitted onto the Internet after implementing IP masquerading. Hence, the target believes that its the proxy server making the request. The target then responds back to the proxy server with an IP packet. This is again captured by icmptunnel, encapsulated in an ICMP reply packet and send back to the client.

On the client side, the IP packet is retrieved from the payload of the ICMP reply packet and injected in tun0. The user applications read from this virtual interface and hence get the proper IP packet.

Overall Architecture

+--------------+                         +------------+
|              |       ICMP traffic      |            |       IP traffic
|    Client    |  ------------------->   |   Proxy    |   ------------------>
|              |  <-------------------   |   Server   |   <------------------
|              |    through restricted   |            |     proper internet
+--------------+         internet        +------------+

Client Architecture

+--------------+                                    +------------+
|              |  IP traffic  +------+  IP traffic  |            |   ICMP traffic
|     User     |  --------->  | tun0 |  --------->  | icmptunnel | --------------->
| Applications |  <---------  +------+  <---------  |  program   | <---------------
|              |        (Virtual Interface)         |            |    restricted 
+--------------+                                    +------------+     internet

Proxy Server Architecture

  ICMP traffic   |            |  IP traffic     +------+       NAT/Masquerading
---------------> | icmptunnel | ------------>   | tun0 |    ---------------------> 
<--------------- |  program   | <------------   +------+    <---------------------
   restricted    |            |           (Virtual Interface)   proper internet
    internet     +------------+


  • ICMP is implemented using raw C sockets.
  • The checksum is calculated using the algorithm given in RFC 1071.
  • Tun driver is used for creating a virtual interface and binding to user space programs.
  • The virtual interface is configured through ifconfig.
  • route is used to change the routing tables of the client so as to route all traffic to the virtual tunnel interface.
  • dd is used to temporarily change the setting of IP forwarding and replying back to ICMP requests on the side of the proxy server.
  • iptables is used to set up nat on the server side.


Network Setup

Proxy server is connected to eth0. This interface provides full internet connection.

Both the client and proxy server are connected to wlan0(a WiFi hotspot). This hotspot is configured not to provide any internet connection.

tun0 will be created in both the client and the proxy server.

The client will make an HTTP request to dhavalkapil.com.

Wireshark is used to capture network traffic at both ends on various interface.

Screenshots of network traffic

  1. tun0 on client sidetun0 client side

    The usual HTTP request is visible along with response.

  2. wlan0 on client sidewlan0 client side

    All traffic is ICMP. The HTTP/IP packet can be seen as part of the payload of the ICMP packet.

  3. wlan0 on proxy server sidewlan0 proxy server side

    The ICMP packets sent by the client can be seen.

  4. tun0 on proxy server sidetun0 proxy server side

    The HTTP/IP packets are decapsulated and sent through tun0.

  5. eth0 on proxy server sideeth0 proxy server side

    The HTTP/IP packets are forwarded to the internet. Notice how the source IP has been masqueraded because of nat.


Kali 2.0 Linux ISO of Doom

Setting up the OpenVPN Server

We will first set up our OpenVPN server on a Kali Linux box with an external IP address (a.b.c.d). Once that’s done, we’ll build The Kali Linux ISO of Doom on the same machine and make it available for download thorough HTTP

echo "1" > /proc/sys/net/ipv4/ip_forward
# Turn the server into the client's gateway
iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE
# Generate the OpenVPN server and client certs.
mkdir /etc/openvpn/easy-rsa
cp /usr/share/easy-rsa/** /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa/
sed -i 's/ --interact//' build-ca
sed -i 's/ --interact//' build-key-server
. ./vars
./build-key-server server
./build-key client


Continue reading Kali 2.0 Linux ISO of Doom


ZIB – The Open Tor Botnet

The Open Tor Botnet requires the installation and configuration of bitcoind:
apt-get install -y git-core build-essential libssl-dev libboost-all-dev libdb5.1-dev libdb5.1++-dev libgtk2.0-dev

git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin/src

make -f makefile.unix clean; make -f makefile.unix USE_UPNP= bitcoind

This bot-net is fully undetectable and bypasses all antivirus through running on top of Python27’s pyinstaller, which is used for many non-Trojan computer programs. The only hypothetical possibility of detection comes from the script, however, the script contains randomized-looking data through using a randomized AES key and initialization vector, meaning this is a non-issue.

ZIB.py is the main project file.

Continue reading ZIB – The Open Tor Botnet


ARDT – Akamai Reflective DDoS Tool

Akamai Reflective DDoS Tool

Attack the origin host behind the Akamai Edge hosts and bypass the DDoS protection offered by Akamai services.

ARDT - Akamai Reflective DDoS Tool
ARDT – Akamai Reflective DDoS Tool

How it works…

Based off the research done at NCC: (https://dl.packetstormsecurity.net/papers/attack/the_pentesters_guide_to_akamai.pdf)

Akamai boast around 100,000 edge nodes around the world which offer load balancing, web application firewall, caching etc, to ensure that a minimal amount of requests actually hit your origin web-server beign protected. However, the issue with caching is that you cannot cache something that is non-deterministic, I.E a search result. A search that has not been requested before is likely not in the cache, and will result in a Cache-Miss, and the Akamai edge node requesting the resource from the origin server itself.

What this tool does is, provided a list of Akamai edge nodes and a valid cache missing request, produces multiple requests that hit the origin server via the Akamai edge nodes. As you can imagine, if you had 50 IP addresses under your control, sending requests at around 20 per second, with 100,000 Akamai edge node list, and a request which resulting in 10KB hitting the origin, if my calculations are correct, thats around 976MB/ps hitting the origin server, which is a hell of a lot of traffic.

Finding Akamai Edge Nodes

To find Akamai Edge Nodes, the following script has been included:

# python ARDT_Akamai_EdgeNode_Finder.py

This can be edited quite easily to find more, it then saves the IPS automatically.


KeeFarce – Extracts Passwords From A Keepass 2.X Database From Memory

KeeFarce allows for the extraction of KeePass 2.x password database information from memory. The cleartext information, including usernames, passwords, notes and url’s are dumped into a CSV file in %AppData%

General Design

KeeFarce uses DLL injection to execute code within the context of a running KeePass process. C# code execution is achieved by first injecting an architecture-appropriate bootstrap DLL. This spawns an instance of the dot net runtime within the appropriate app domain, subsequently executing KeeFarceDLL.dll (the main C# payload).

The KeeFarceDLL uses CLRMD to find the necessary object in the KeePass processes heap, locates the pointers to some required sub-objects (using offsets), and uses reflection to call an export method.

Prebuilt Packages

An appropriate build of KeeFarce needs to be used depending on the KeePass target’s architecture (32 bit or 64 bit). Archives and their shasums can be found under the ‘prebuilt’ directory.

In order to execute on the target host, the following files need to be in the same folder:


Copy these files across to the target and execute KeeFarce.exe


Open up the KeeFarce.sln with Visual Studio (note: dev was done on Visual Studio 2015) and hit ‘build’. The results will be spat out into dist/$architecture. You’ll have to copy the KeeFarceDLL.dll files and Microsoft.Diagnostic.Runtime.dll files into the folder before executing, as these are architecture independent.

KeeFarce has been tested on:

KeePass 2.28, 2.29 and 2.30 – running on Windows 8.1 – both 32 and 64 bit.

This should also work on older Windows machines (win 7 with a recent service pack). If you’re targeting something other than the above, then testing in a lab environment before hand is recommended.

Sharp Needle by Chad Zawistowski was used for the DLL injection tesh.
Code by Alois Kraus was used to get the pointer to object C# voodoo working.


BSD License, see LICENSE file

This site uses cookies. Find out more about this site’s cookies.