How Hackers Use ICMP Tunneling to Own Your Network

Protocol Tunneling

One mainstay method for traffic obfuscation is Protocol Tunneling (MITRE T1572: Protocol Tunneling^[1]). When tunneling a protocol, instead of explicitly sending data packets in a protocol of choice (say TCP), adversaries will encapsulate the packets within another protocol. This behavior aids in concealing malicious traffic inside seemingly innocuous communication forms, aiding in detection evasion. Furthermore, it can be used to encrypt data and protect the attacker’s identity and interests.

Aside from creating a covert C&C and data exfiltration channel between two machines, protocol tunneling can also be used to bypass captive portals for paid Wi-Fi services. Many times, portal systems will block most TCP and UDP traffic to/from unregistered hosts – but will allow other protocols such as ICMP, DNS etc. Adversaries can exploit this by tunneling their traffic inside an allowed protocol’s packets.

Expanding on traditional protocol tunneling, hackers may use non-application-layer protocols, which are generally deemed less likely to be monitored for malicious intents, to obfuscate their traffic.

ICMP and Tunneling

ICMP

One common form of non-application-layer protocol tunneling is ICMP Tunneling.

The Internet Control Message Protocol (ICMP) is an OSI Network Layer protocol, used to discover and control routing problems across a network. When certain errors are detected by networking devices, they will produce ICMP packets to inform endpoints about what happened.

In example, when a routing loop occurs in a network, IP packets will circle endlessly across the loop, and eventually their TTL value will drop to zero. At this point, the last router to receive the packet will send an ICMP “Time Exceeded: TTL expired in transit” message to the packet’s source IP.

ICMP messages can also be used to control routing. For instance, if an endpoint sends a packet through an inefficient route, routers along the way may detect this behavior and send an ICMP “Redirect Message” packet – which will suggest a better route to be used next time.

Generally speaking, this protocol is not implemented on endpoint machines, aside for two very well-known tools:

• Ping – Networking utility used to test the reachability of a host over IP and measure the round-trip time. Ping uses ICMP “Echo” packets to operate – we’ll touch on these in detail later on.
• Traceroute – Networking diagnostics utility that displays the nodes and transit delays of a route between two machines in an IP network, utilizing ICMP. When “tracing a route”, traceroute will send multiple IP packets to the requested host. The packets are designed to make every router along the way send an ICMP “Time Exceeded” message to the source host, containing various information about the router.

ICMP Tunneling

Remember how ping uses ICMP Echo packets to test host reachability across a network? Basically, the pinging host will send an Echo packet with some data to the pinged host. Then, the pinged host will answer with an Echo Reply containing the same data. The data may be arbitrary and no strict guidelines are defined is ICMP’s RFC.

Attackers can exploit this design choice to obfuscate malicious network behavior. Instead of explicitly communicating with a machine in the protocol of choice, each packet will be injected into an Echo or Echo Reply packet. The communication stream will now seem to be a series of ping operations, rather than, for instance, a TCP connection.

Why It's a Problem

ICMP’s intended use is for discovering and controlling networking issues, so its de-facto ability to establish a data channel between two machines is often overlooked. Moreover, being that ICMP is an essential, well-established part of the Internet Protocol Suite and a non-Application-Layer protocol, enterprises are less likely to monitor it as closely as the usual data exfiltration suspects – HTTP, HTTPS, TCP, IMAP etc.

Moreover, mitigation is not trivial, being that in many cases ICMP functionalities cannot be completely disabled without impacting user experience significantly.

Common Tunneling Toolkits

There are several common toolkits to tunnel traffic through ICMP, and each of them provides slightly different features. Let’s examine them.

Icmpsh

Icmpsh is a simple toolkit for running reverse shells on Windows machines. It’s comprised of a client that is written in C and works on Windows machines only, and a POSIX-compatible server that’s available in C, Python and Perl.

Some of icmpsh’s notable features are:

• Used for C&C – unlike some other toolkits, icmpsh creates a reverse shell, which allows it to be used for C&C with targeted machines.
• Targets Windows Machines – the client is a Windows executable file and can only run on Windows machines for now.
• Low Privileges – the client doesn’t require administrative privileges to function properly.
• Easy to Use – both the client and the server applications are clean, portable and very easy to use, and require little to no tweaking.

Ptunnel

Unlike icmpsh, which is used for C&C, ptunnel is intended for TCP traffic obfuscation and tunneling. When executed, ptunnel’s client will tunnel TCP over ICMP to the designated ptunnel server. The server will act as a proxy, and will forward the TCP packets to and from their actual destination. This toolkit can run on POSIX-compliant OS’s only.

Some of ptunnel’s features are:

• Reliable Connections – ptunnel can detect lost packets and resend them as necessary.
• Multiple Connections – the server can be configured to handle multiple connections simultaneously.
• Supports Authentication – to prevent unknown hosts from using your proxy server.

Icmptunnel

Icmptunnel has a somewhat similar architecture to that of ptunnel, but unlike the latter it can tunnel any IP traffic. Additionally, it will tunnel all of the client’s IP packets – and not just a single session, port etc. This makes this tool very useful to bypass captive Wi-Fi portals, but somewhat less beneficial for coordinated cyber-attacks. Both the client and the server need to be POSIX-compliant.

Some of icmptunnel’s notable features are:

• Data Encryption – the ICMP payload is encrypted.
• Versatility – any IP traffic can be tunneled.

Demonstration

In this demonstration we will use icmpsh to tunnel a reverse shell session between our attacking Kali Linux machine and a victim Windows 10 machine.

We chose icmpsh because it doesn’t require administrative privileges to run on the victim’s machine, and is very portable.

Figure 2: Demonstration network’s diagram. Attacker at 192.168.68.113, victim at 192.168.68.115.

Step 1 – Disabling Kernel Echo Replies

Before running icmpsh, we will need to prevent the kernel from replying to ICMP echo requests. Most ICMP tunneling tools will implement mechanisms to synchronize the data stream between the two machines, and the kernel replies may cause unexpected results.

To disable kernel ping replies, we added the following line to the /etc/sysctl.conf file: net.ipv4.icmp_echo_ignore_all=1.

Figure 3: Editing sysctl.conf file to disable kernel Echo replies

Step 2 - Running Icmpsh Server and Client

First, we will run the icmpsh server on our Kali Linux machine. Thankfully this tool is very easy to use and only requires two arguments: the attacker and the victim’s IP addresses.

Figure 4: Running the icmpsh server on a Kali Linux machine.

Our machine is waiting for ping requests from our victim, 192.168.68.115.

Now we can run the client, which is an executable file that can be downloaded from the GitHub page linked above. Here are its arguments:

Figure 5: Available arguments for icmpsh’s Windows client executable

Our Kali machine is at 192.168.68.113, so this is the final command:

Figure 6: Running icmpsh client on Windows 10 machine.

On the attacking side, we are starting to receive SSH data:

Figure 7: Icmpsh server displaying client’s reverse shell output.

Step 3 – Executing Shell Commands

Now that everything is set up, we have a functioning reverse shell on our Kali server. For example, we can type systeminfo to gather information on our victim’s machine:

Figure 8: Running systeminfo through icmpsh’s reverse shell

When inspecting the network traffic between the two machines, we can see the extensive amount of ICMP packets:

Figure 9: Extensive ICMP traffic between the attacker and the victim, as captured on Wireshark once a reverse shell was initiated.

Additionally, as icmpsh doesn’t encrypt the data, we can see the shell’s text injected inside the datagrams:

Figure 10: Plaintext reverse shell output (marked in blue) obfuscated inside an ICMP packet.

Mitigation

Generally speaking, ICMP traffic cannot be blocked completely, so mitigation should focus on minimizing risks through network and endpoint detection measures.

Cynet’s network defense products implement smart heuristics and machine learning algorithms to detect and prevent ICMP tunneling. Some common tunneling patterns that may be detected are:

• Extensive ICMP Usage – Especially when tunneling large amounts of data, a significant amount of ICMP traffic may be detected going in or out of the network.
• Abnormal Packet Size – Closely related to the previous point, adversaries can opt to reduce the overall packet count by injecting larger datagrams into each request or reply. In general, legitimate Echo requests and replies will have a fixed standard size and so varying datagram sizes may indicate that the connection is used for tunneling.
• Periodical Ping Requests – As noted earlier, some tunneling tools will send empty ICMP requests periodically to punch holes through NATs and stateful firewalls. This pattern can be easily detected but is sometimes harder to distinguish from legitimate behaviors.
• Non-Arbitrary ICMP Payload – With deep packet inspection tools, ICMP packets’ data can be scanned and compared with common protocols’ structures and headers to detect tunneling directly. However, the data may be encrypted, and if done so elegantly – may be hard to distinguish from innocuous ICMP payloads.

Furthermore, in addition to conventional detection techniques, which rely on centralized traffic analysis through firewalls, IPS systems etc.^[2], Cynet’s products can detect and prevent tunneling attempts directly on endpoints, without the need for designated network devices.

Further Reading

Footnotes:

1. https://attack.mitre.org/beta/techniques/T1572/
2. https://arxiv.org/ftp/arxiv/papers/1408/1408.1136.pdf

Protocol Tunneling

1. DNS Tunneling – https://www.cynet.com/attack-techniques-hands-on/how-hackers-use-dns-tunneling-to-own-your-network/
2. https://www.kaspersky.com/resource-center/definitions/tunneling-protocol

ICMP

1. ICMP RFC – https://tools.ietf.org/html/rfc792
2. http://www.enterprisenetworkingplanet.com/netsp/article.php/3584166/Networking-101-Understanding-and-Using-ICMP.htm
3. https://en.wikipedia.org/wiki/Traceroute#Implementations
4. https://en.wikipedia.org/wiki/Ping_(networking_utility)

ICMP Tunneling Tools

1. ptunnel – https://www.mit.edu/afs.new/sipb/user/golem/tmp/ptunnel-0.61.orig/web/
2. ptunnel-ng – https://github.com/lnslbrty/ptunnel-ng
3. icmptunnel – https://github.com/DhavalKapil/icmptunnel

Mitigation

1. https://link.springer.com/chapter/10.1007/3-540-45067-X_20