Pingback: ICMP Tunneling Malware

Recently, Trustwave reported on a new malware family which they discovered during a breach investigation. The backdoor, dubbed Pingback, executes on Windows systems and communicates with its controller via ICMP messages. ICMP (Internet Control Message Protocol) is a protocol used for exchanging control messages between endpoints communicating via the Internet Protocol (IP). Echo Request and Echo Reply messages, type 8 and type 0 respectively, are collectively known as Ping messages and are often used to troubleshoot network connectivity issues. Since ICMP is commonly allowed through firewall devices, attackers often hide their communications in ping message payloads. This blog will introduce a method of detecting the Pingback malware attempting to do this very thing.

Detecting Pingback Communications

Corelight Labs team members examined communication artifacts produced by the Pingback malware and are publicly releasing a detection script. It is our hope that Zeek users can better protect themselves from this threat using the package located here. This script logs detections in the notice log and suppresses alerts based on Zeek’s default policy of one hour. The suppression is based on the IP address which caused the notice.

Since the payloads are originally produced by the backdoor as C structures, their lengths will not vary like a null-terminated string would. Defenders can use this constraint to their advantage by watching for ping messages of certain lengths. Also according to Trustwave, Pingback only uses three ICMP ping sequence numbers: 1234, 1235, 1236. The Trustwave report listed these numbers in little endian byte order (host byte order for Windows) while they are interpreted as big endian (network byte order – independant on operating system) values in Zeek and most other network applications. Wireshark’s UI reports both big and little endian values for convenience because some applications choose to interpret these sequence numbers as little endian integers. This is likely because the RFC for ICMP does not specify the byte order like it is specified for IP traffic. On page 13 of the ICMP RFC the sequence number is described and the byte order is missing:

The general consensus on the internet has been to treat the sequence number field as network byte order, like IP headers and others, when byte order is not specified. You will notice the other fields in the ICMP echo packet must be interpreted in network byte order for ping to work: type, code (when not zero), checksum, etc. However, a few applications choose not to interpret just the identifier and sequence numbers in network byte order. This is how Trustwave reported the Pingback sequence numbers in their report. The detection package Corelight released looks for the network byte order (big endian) sequence numbers 53764, 54020, and 54276. This is the reason there is a sequence number discrepancy between Corelight’s Zeek code and the Trustwave report. 

Therefore, Pingback detections in the Zeek script are built on message lengths, three sequence number values, and patterns in the payloads of the messages. As Zeek nicely parses all of these message fields from ICMP packets, the detection script’s logic is quite simple. First, we will put the payload lengths, commands, and message types (sequence numbers) into variables we will use later:

Next, the detection logic is simple as we look at ICMP echo requests and replies with the two events Zeek provides for us called “icmp_echo_request” and “icmp_echo_reply”:

You will see that in line 16 (and by extension 26) the logic checks the sequence number, then the payload length, and then finally the command in the payload. If Pingback is discovered, a Zeek notice is logged in lines 18 and 28.  Unfortunately, the PCAPs that were graciously provided to us to develop this script are not something we can redistribute, so instead of showing you an actual notice.log we will give you some Suricata rules. How is that for a bonus if you read this far? These additional Suricata rules have been added to the source code repository.

Summary

The Pingback malware family isn’t the first to employ ICMP tunneling as a method of surreptitious communications and likely won’t be the last. Corelight used three network-based artifacts discovered from Trustwave’s analysis to detect Pingback’s ICMP traffic. If you’d like to install this package in your Zeek environment you can do so by using zkg:

zkg install corelight/pingback

Corelight Labs Team - Keith Jones, Anthony Kasza and Ben Reardon