Detecting ICMP Covert Channels through payload analysis
We’re kicking off the New Year 2019 with a couple of Trisul scripts to detect Covert Channels that use PING. This script was inspired by the blog post [How To: C2 over ICMP]
Many firewalls statefully allow outbound ICMP ECHO (aka PING) requests and pass along the corresponding responses. Blocking PING altogether is rare because of its extensive use by IT teams for troubleshooting. Signature based detection such as those found in the default Snort icmp.rules are not be very effective in the absence of a particular pattern in each packet.
Here we introduce the new Ping Tunnel Detector scripts we released on Github which use stateful payload analysis to spot this bad news.
Exfil vs C&C Tunnels
The classic way to do ICMP tunnels is to run pTunnel . Using pTunnel you get a low bandwidth TCP Tunnel of around 50Kbps over ECHO and ECHO-REPLY. This is great for Command and Control (C&C) which usually require two way comms.
The typical C&C
- First a legit PING is exchanged to punch a hole in the firewall
- Then you pretty much have a bi-directional stream to keep the firewall hole live
The typical Exfil – Tunnels used to steal data
- The end point just chops the information into small chunks say 512 bytes and shoots ICMP ECHO to the receiver. This can be unidirectional , there may be packet losses but a large amount of information can be stolen like this. Since Outbound ICMP ECHO are typically allowed. This doesnt trip anything.
There are Snort and Suricata rules to detect large size ICMP ECHO packets. The attackers has to keep the packet sizes low to evade those IDS.
Payload analysis to spot ICMP tunnels
Trisul is an open platform with a powerful embedded LuaJIT scripting engine and an API. We have released two scripts on Github trisulnsm/trisul-scripts to tightly detect almost any ECHO tunnel. The two techniques are shown below.
The ICMP ECHO protocol demands that the payload in the ECHO packet must match that in the ECHO-REPLY packet. So here we check EVERY echo-request payload with the corresponding reply. This makes it impossible to have a functional 2-way C&C if one side is just echoing the other.
All PING clients we have seen dont send completely random data in the ECHO payload. Each successive ECHO packet only varies in the first 8 or 16 bytes or so. Many clients include a 8 byte timestamp in the payload the rest of the payload is just the same between packets. We make use of this insight here. The hamming distance is just a fancy term for a number that tells you how similar two strings of equal length are.
This script monitors the hamming distance between successive echo/reply payloads. Any C&C or Exfil will flunk this check because successive payloads are going to vary quite a bit. On our GitHub page we documented our calculation for Linux/Windows/MAC/Cisco PING clients the payloads are very similar with a hamming distance of < 10. Tunnels with actual user data are > 90 !
If this kind of analysis excites you, get on to Trisul Scripting by downloading Trisul and checking out the LUA Getting Started Tutorials.