Many organizations do a great job of filtering inbound traffic but will often leave the outbound traffic unfiltered or at least have some sort of application aware filtering on the egress. ICMP is one of those protocols that is typically left unfiltered as it’s so often used for troubleshooting network connectivity.
Hping 3 is a command-line packet assembler/analyzer. It’s interface was inspired by the ping command, but hping can do so much more than just send ICMP echo requests. It also supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute mode, and has the ability to send files between a covered channel.
This means that while it’s designed to be used as a security tool it can also be used from a malicious standpoint.
First let’s look at what a normal ICMP packet looks like. We start by using TCPDUMP and then send a basic PING command to our loopback interface.
We can see in the data portion of a standard ICMP packet there is what appears to be some ASCII data (!"#$%^'()*+,-./01234567) in the Content field of the ICMP packet . This begs the question of what is this ASCII data. The RFC states that you should include some payload data aside from just the ICMP header, but it doesn’t specify WHAT that payload data should be. If it doesn’t specify what it must be then we can actually put anything we want in the Content field.
First we’ll create a file with just the contents of “This is a test message”
Then we can use HPING3 to send and IMCP pack using the contents of file1 as the payload.
We can see the contents of file1 in the payload of the ICMP packet using TCPDUMP
While this may seem harmless we can use this to exfiltrate data from a environment. (eg. credit card data).
If we create another file (file2) and paste some data in that file, in this case credit card data, we can then use Hping3 to send that data in our ICMP packet. (Please note that the credit card data in this example is NOT real credit card info. It was made up for the purposes of this example)
So far we’ve only been sending this data to our loopback interface. However if we send this packet out to a server on the internet you can see in the Wireshark image below that the packet (and data) was in fact received by the remote server. While the response back to us was truncated, the fact that we got a reply indicates that the data was received on the remote server.
This naturally should bring up the question of how do we prevent this from leaving our network? There are a couple of ways including DLP (Data Loss Prevention) looking for credit card data traversing the firewall but the simplest way is to just block outbound ICMP traffic if you don’t need it or at the very least restrict it to only systems with a confirmed business need.