Detect Suspicious/Malicious ICMP Echo Traffic

Using Behavioral and Protocol Semantic Analysis

Introduction

With release version 2.0, we have added a new advanced detection module to PacketSmith, with the sole objective of scanning for suspicious/malicious network traffic, at different protocol layers.

ICMPv4/v6 Suspicious/Malicious Echo Traffic

The ICMPv4 Echo request/reply types have been widely used in-the-wild for tunneling and as a C&C communication channel to evade network detection. Multiple public open-source projects demonstrate such technique, from PingRat, icmpsh, to Ptunnel-NG and “ICMP Backdoor”, among others. Moreover, multiple documented malware families have used it as well, for data exfiltration, C&C channel, or as an activation packet. These include malware families such as, RomCom, Bpfdoor, CCHack, Pingback, CobaltStrike, PingPull, Winnti, MystRodX, Anchor and PlugX among others.

Traditional Detection Method

Writing traditional Intrusion Detection/Prevention System (IDS/IPS) signatures can detect malicious ICMP Echo traffic if you have prior knowledge of its characteristics. This involves creating rules based on hardcoded protocol fields or specific patterns in the data payload.

However, this approach has significant limitations. It’s often ineffective when:

Protocol fields are not abnormal. Malicious traffic can mimic legitimate traffic, leaving no obvious flags to match.

The payload is encrypted or lacks unique patterns. Without a clear signature, traditional matching becomes impossible.

Malware evolves. IDS/IPS signatures are easily outdated as malware and tools update their protocol specifications to evade detection.

PacketSmith Detection Module

To address these challenges and move beyond static signatures, version 2.0 introduces a new detection module for ICMP Echo traffic. This module identifies malicious and suspicious activity using behavioral and protocol-semantic analysis, making it independent of specific signatures. This advanced detection capability is built upon our foundational work in constructing ICMP Echo streams (for more information about iStreams, please refer to the article “Introducing ICMP Echo Streams (iStreams)“). We are unaware of any theoretical or in-the-wild abuse of the ICMPv6 protocol, nonetheless, the detection outlined in this section works against both version v4 and v6.

With respect to normal ICMP Echo traffic on different OSes and legitimate ping tools, malicious implants and tools tend to exhibit certain unique behaviour and anomalies in the construction of the ICMP Echo packet. By baselining normal traffic, we ended up with 8 unique detection rules, that track the flow of ICMP Echo traffic. Those rules are defined as follow:

ID	Rule	Verdict
1	Echo requests with more than one reply	Malicious/Not Found
2	ICMP sequence number not incrementing by 1	Malicious/Not Found
3	Echo request/reply packets data mismatch	Malicious/Not Found
4	Time series analysis (> 2 packets per second)	Suspicious/Not Found
5	Number of echo requests less than 3	Suspicious/Not Found
6	Echo requests with no replies	Suspicious/Not Found
7	iStream starts with a reply packet	Malicious/Not Found
8	Payload size is greater than 64 bytes	Suspicious/Not Found

Internally, PacketSmith builds a relationship type mapper between every Echo request and reply with respect to their unique sequence number, for every iStream.

This feature is available through the “Detection” section in the command line via the option “—Detection -icmp“.

Implementation details for the rules are as follow:

ID=1; This happens when the ICMP sequence number is the same for different request/reply pairs. This is a violation of common implementations of the specification (RFC 792) which states “… and the sequence number might be incremented on each echo request sent.“.
- This requires the implementation of an ICMP Echo request/reply mapper.
- We flag this activity as malicious because it’s highly improbable with legitimate tools.

ID=2; This follows from rule ID=1, whereby if the sequence number does not increment by 1 between every pair of echo request and reply packets, we flag this occurrence as malicious.
- The sequence number of every pair of echo packets has to be the same, and increments by 1 for the next echo pair.

ID=3; As per RFC 792, “The data received in the echo message must be returned in the echo reply message.“.
- Therefore, in case there’s a data mismatch in a given echo request/reply pair, we flag this occurrence as malicious.

ID=4; We analyze all ICMP Echo streams (iStreams) over time. Any stream that sends more than two packets in a one-second period is flagged as suspicious.
- This threshold of three packets was determined by a baseline analysis of legitimate and malicious ICMP traffic, which showed that legitimate tools rarely, if ever, behave this way.

ID=5; We analyze all ICMP Echo streams (iStreams) such that if the number of echo requests is less than 3 per stream, we flag this occurrence as suspicious.
- Typically, when you ping an endpoint, it sends at least four echo requests, regardless of whether the endpoint is active or not.
- This depends on the tool’s default settings and can be easily changed with a custom option.

ID=6; We analyze all ICMP Echo streams (iStreams) and flag any stream as suspicious if it doesn’t contain an echo reply packet.
- This rule should be treated as a signal for further investigation.

ID=7; We analyze all ICMP Echo streams (iStreams) and flag a stream as malicious if it begins with a reply packet instead of a request packet.
- This behavior is typical of reverse mapping attacks.

ID=8; We analyze all ICMP Echo streams (iStreams) and flag any stream as suspicious if the payload’s size is greater than 64 bytes.
- On Windows, the default payload size for the ping utility is 32 bytes, while on various Linux distributions, it is 64 bytes.
- This rule should be treated as a signal for further investigation.

When a match cannot be found for any of the rules, the result is reported as “Not Found“.

Demonstration (use-cases)

To demonstrate such detection against a real world example, let’s take PingRAT as an example. It is described as a tool that “secretly passes C2 traffic through firewalls using ICMP payloads“. For reference, the pcap is attached here pingrat_icmpv4_traffic.

PingRAT ICMPv4 traffic is shown in Fig. 1. It consists of a single iStream. If we run PacketSmith icmp detection module against this pcap, using this option “—Detection -icmp“ we’ll get the following output:

Detect Suspicious/Malicious ICMPv4/v6 Traffic
---------------------------------------------

type                                            verdict
----                                            -------
echo requests with more than one reply          malicious
icmp sequence number not incrementing by 1      malicious
echo request/reply packets data mismatch        malicious
time series analysis (> 2 pkts per second)      suspicious
number of echo requests less than 3             not found
echo requests with no replies                   not found
istream starts with a reply packet              not found
payload size is greater than 64 bytes           suspicious

Five of the rules have fired against the pcap, with a total of 3 marked as malicious and 2 as suspicious. It is clearly a malicious traffic.

The details for each of the matching rules are also printed out to the console as follow:

------------------ Details ------------------

 *** [ Echo Requests With More Than One Reply ] ***

 |- ICMPv4 -|

  req_frame     req_iseq_num    reply_frames
  ---------     ------------    ------------
  1             0               2,5,8,11
  4             0               5,8,11
  7             0               8,11

 *** [ ICMP Sequence Number Not Incrementing By 1 ] ***

 |- ICMPv4 iStreams (keys) -|

  src_ip                        dst_ip                          icmp_id
  ------                        ------                          -------
  192.168.2.14                  192.168.2.16                    13170

 *** [ Echo Request/Reply Packets Data Mismatch ] ***

 |- ICMPv4 Flows -|

  request       reply
  -------       -----
  1             5
  1             11
  4             8
  4             11
  7             11

 *** [ Time Series Analysis (> 2 pkts per second) ] ***

 |- ICMPv4 iStreams (keys) -|

  src_ip                        dst_ip                          icmp_id
  ------                        ------                          -------
  192.168.2.14                  192.168.2.16                    13170

   2025-07-29 13:08:28 -> number of frames: 3
   2025-07-29 13:08:54 -> number of frames: 3
   2025-07-29 13:09:10 -> number of frames: 3
   2025-07-29 13:09:18 -> number of frames: 3

 *** [ Number Of Echo Requests Per iStream (< 3) ] ***

 *** [ Echo Requests With No Replies By iStream ] ***

 *** [ iStream Starts With an Reply Packet ] ***

 *** [ Payload Size > 64 Bytes ] ***

 |- ICMPv4 iStreams (keys) -|

  src_ip                        dst_ip                          icmp_id   frames
  ------                        ------                          -------   ------
  192.168.2.14                  192.168.2.16                    13170     12

Rule ID 1 lists all ICMP echo request frames, along with the corresponding frame IDs for their associated reply packets. This works in descending order. To clarify, the first ICMP echo request frame in the pcap has 4 reply packets associated with it.

For rule ID 2, an astute reader would have already inferred it from the results of rule ID 1. It shows the iStream key associated with this behaviour.

For rule ID 3, it shows all related request/reply frames that don’t have a matching payload.

Rule ID 4 displays the matching iStream key, with a list of all time series buckets, and the number of frames within each bucket.

Rule ID 8 provides the flow information for any frame with a payload size greater than 64 bytes, such as the example shown for frame number 12.

This table shows which rules were a match for each of the different malware families.

ID	Rule	Malware
1	Echo requests with more than one reply	Pingback; PingRAT
2	ICMP sequence number not incrementing by 1	Pingback; PingRAT
3	Echo request/reply packets data mismatch	Pingback; PingRAT
4	Time series analysis (> 2 packets per second)	PingRAT; PTunnel-NG; ROMCOM.YACFT
5	Number of echo requests less than 3	PingPull; Pingback; ICMP Backdoor; BPFDoor.A; CCHACK.A; ROMCOM.YEDD1; ROMCOM.YACFT; PingPull
6	Echo requests with no replies	CCHACK.A
7	iStream starts with a reply packet
8	Payload size is greater than 64 bytes	PingPull; Pingback; PingRAT; ROMCOM.YEDD1; ROMCOM.YACFT; PingPull

Conclusion

This article explains the technical details behind the ICMP detection module implemented in PacketSmith v2.0. It showcases how to detect malicious or suspicious ICMP echo traffic using behavioral and protocol semantic analysis based on a predefined set of rules, against multiple malware families and open-source frameworks that abuse the ICMP echo protocol for nefarious purposes.

Author: Mohamad Mokbel (Netomize)

First release: September 08, 2025