Malware of the Day – C2 over ICMP (ICMP-GOSH)

What is Malware of the Day?

 

Lab Setup

Malware: Custom Go-based C2 (ICMP-GOSH)

MITRE Tactics: TA0011 Command and Control, T1071 Application Layer Protocol (custom ICMP-based), T1027 Obfuscated Files or Information (Encoded PowerShell), T1571 Non-Standard Port (UDP port 41337), TA0003 Persistence, TA0005 Defense Evasion, TA0002 Execution

Traffic Type: UDP, ICMP (Type 3)

Connection Type: Custom (UDP outbound, ICMP Type 3 inbound for C2)

C2 Platform: Custom Go-based C2 (ICMP-GOSH)

Origin of Sample: Active Countermeasures Threat Hunting Lab

Host Payload Delivery Method: Assumed post-RDP compromise installation

Target Host/Victim: 192.168.2.115 (Windows x64)

Adversary Host: 143.198.3.13 (Ubuntu Linux)

Beacon Timing: UDP outbound every 180 seconds (approx.)

 

 

Malware of the Day Mission

To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for Command and Control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.

 

Preface: The Threat Hunting Mindset

As threat hunters, we approach our work with the mindset of a detective, maintaining an open and unbiased perspective to ensure that all potential evidence is considered and interpreted objectively. Our investigation begins when we discover a piece of evidence that suggests something might be amiss. From this point, we employ a variety of supportive tools to either refute or strengthen our case.

The process of threat hunting involves layering evidence, gradually increasing the probability of a compromise as we gather different, independently verified pieces of information. Each new piece of evidence adds to the overall picture, allowing us to build a stronger case. Our ultimate goal is to construct a case that is sufficiently solid to inform the Incident Response team of a probable compromise.

Throughout the investigation, it is crucial to remember the golden rule of threat hunting: never cross the active-passive line. This means that we must use all the tools and techniques at our disposal in a manner that does not alert the intruder to the fact that they are being investigated. By maintaining a passive approach, we can gather the necessary evidence without compromising the investigation.

By adhering to this mindset and methodology, we can effectively investigate potential compromises, providing valuable insights and enabling our organization to respond to threats in an effective manner.

 

Background

In a previous article, we explored how the Network Time Protocol (NTP) can be leveraged as an unconventional C2 channel, highlighting that attackers often seek out such methods because organizations tend to focus their monitoring efforts on the “big three”: HTTP, HTTPS, and DNS. This exploration continues as we now turn our attention to another foundational internet protocol: the Internet Control Message Protocol (ICMP).

ICMP, first defined in RFC 792, operates at the Network Layer (Layer 3) of the OSI model and is primarily known as the “troubleshooting protocol.” It facilitates error reporting and diagnostic functions crucial for network operations.

 

Why ICMP Makes an Appealing Covert Channel

A common misconception is that ICMP’s utility is limited to “ping” (Echo Request/Reply messages). Rather, “ping” is a one specific use of ICMP messages, namely ICMP Types 8 and 0.

Instead, ICMP encompasses dozens of message types, each serving a distinct purpose.

The potential for ICMP to be used as a C2 channel is often overlooked precisely because it is such a foundational troubleshooting protocol, integral to the normal functioning of network communication. Many people view it as “background chatter”, not considering its potential to be intentionally leveraged to carry data for this exact reason.

ICMP Type 3 messages are particularly interesting. They are generated by a router or host when it cannot deliver a packet – for example, if the destination port is unreachable, the host is unknown, or fragmentation is needed but disallowed. Essentially, it’s a notification service that something went wrong with a packet sent from a local host. The Type 3 message typically includes the IP header and the first 8 bytes of the original datagram that caused the error, allowing the source host to identify the problematic communication.

Furthermore, while ICMP messages like Type 3 are not typically designed to carry arbitrary payloads in the same way application-layer protocols do, this is another good example of how malware can “bend the rules.”

Skilled malware authors capable of crafting raw packets can manipulate or append data to these error messages. Because many firewalls might permit these seemingly legitimate error messages without deep inspection, attackers can leverage this to establish a covert C2 channel.

 

Scenario and Setup

In today’s scenario, attackers successfully brute-forced a publicly exposed Remote Desktop Protocol (RDP) service that lacked Multi-Factor Authentication (MFA) on a corporate network. This RDP access provided them significant control, particularly useful for less technically savvy “affiliates.”

However, their immediate next step was to establish network persistence by installing a communication backdoor operating over a different, less conspicuous channel. This approach ensures redundancy; if the RDP intrusion is discovered and remediated, the backup channel remains.

The affiliate’s development partner had recently developed a new C2 tool, ICMP-GOSH. The C2 server component of this tool sends commands embedded within ICMP Type 3 (Destination Unreachable) error messages. Since these ICMP error messages are not based on a typical request-response pattern from the agent, the C2 server doesn’t need to wait for the agent to send a request before issuing a command.

However, because stateful firewalls might be triggered by unsolicited ICMP Type 3 messages (as they are normally a response to a locally originated packet that was dropped), the ICMP-GOSH agent on the compromised host is designed to periodically send outbound UDP packets to arbitrary high ports on the C2 server. The C2 server then responds with ICMP Type 3 (Port Unreachable) messages with embedded C2 commands.

This backdoor provided a reliable fallback channel for the attackers. Additionally, the ICMP-GOSH agent was configured to automatically run a series of enumeration scripts, passively providing a rich source of valuable information about the compromised system and network.

The company, Jane Doe Inc., was eventually alerted to the RDP intrusion when their security software reported multiple logins from an unexpected geolocation where no employees were known to be. The RDP connection was quickly investigated and terminated.

Jane Doe Inc. believed they had removed all traces of the intruder. However, shortly after the RDP remediation, their security software continued to generate alerts related to suspicious commands being executed on the system previously accessed via RDP. The company’s security team closely scrutinized all HTTP, HTTPS, and DNS traffic from the affected host, but this revealed nothing unusual.

Faced with the puzzling signs of continued compromise, the Jane Doe Inc. security team contacted us to assist with an in-depth investigation. Given the context – a remediated primary access vector followed by persistent suspicious activity – we decided to broaden our threat hunt beyond the usual suspects (HTTP, HTTPS, DNS).

We suspected that a hidden channel, perhaps leveraging a less monitored protocol, might be the root cause of the persistent attacker presence.

 

Network Traffic Analysis with RITA

Almost immediately upon analyzing the network logs in RITA, an unusual communication channel from the host 192.168.2.115 to the external IP 143.198.3.13 caught our attention – Image 1 below.

 

Several factors made this connection stand out. First, RITA classified this connection with ‘High’ severity and a beacon score of 100%. Further, the communication was directed to an external IP address (143.198.3.13) rather than a domain name, which can sometimes be an indicator of suspicious activity.

We can also see that approximately 17.72 MiB of data was transferred over 475 connections (Zeek sessions). While not excessively large, this volume for a relatively small number of connections suggests that more than just minimal header data was exchanged, hinting at potential data exfiltration or payload delivery.

Further, the destination port was 41337, which is not a standard well-known port. Attackers often use unconventional ports for C2 communication to evade simple port-based firewall rules or detection signatures (MITRE ATT&CK T1571: Non-Standard Port).

Finally, the connection is somewhat unusual in that the protocol that was used was UDP. While UDP is a standard transport layer protocol, seeing it used directly for persistent, beacon-like communication without a clear application-layer protocol on top (like DNS over UDP) is somewhat unusual. Though some legitimate services like gaming, streaming, or certain VPNs utilize raw UDP, its presence in a highly regular beaconing pattern to an unknown IP warrants further investigation.

These combined factors provided strong cause to investigate this communication channel further.

 

Network Traffic Analysis with AC-Hunter

Transitioning to AC-Hunter allowed for a more visual and detailed analysis of the beaconing behavior – Image 2 below.

 

First off, we see as was the case with RITA, AC-Hunter also reported a 100% beacon score for this connection. We can also see the hourly connection graph at the bottom of the interface displays consistent activity across all hours, reinforcing the automated, beacon-like nature of the communication.

Let’s look closer at the connection interval histogram – Image 3 below.

 

The histogram shows that the vast majority of connections (447 out of 475) occurred at an interval of exactly 180 seconds. A smaller number of connections had slightly longer intervals, extending up to 244 seconds (7 connections at this interval). This regularity, with minor variations, is characteristic of programmed C2 check-ins.

Next, we examined the connection size histogram – Image 4 below.

 

This histogram revealed a classic pattern often associated with C2 activity. The vast majority of connections (439 out of 475) involved very small data transfers, specifically 32 bytes. These likely represent the C2 agent’s “check-in” or “heartbeat” messages, asking the server if there are any tasks.

A handful of connections, however, were dramatically larger, with sizes ranging up to 1,200,407 bytes (approximately 1.14 MiB). These larger transfers are strong indicators of actual data exfiltration or the download of commands/payloads.

This combination of highly regular small check-ins and occasional large data transfers significantly deepened our suspicion that this was indeed a C2 channel. The immediate next step was to examine the raw packet data to understand the nature of these UDP packets and what, if anything, was being sent back from the external host.

 

Deep Packet Inspection using Wireshark

Opening the packet capture in Wireshark and filtering for traffic between 192.168.2.115 and 143.198.3.13 immediately revealed something incredibly peculiar – Image 5 below.

 

The outbound UDP packets from 192.168.2.115 to 143.198.3.13 on port 41337 were consistently being responded to by ICMP Type 3 (Destination Unreachable, specifically Code 3: Port Unreachable) messages from 143.198.3.13.

As discussed earlier, an ICMP Type 3 message signals that a packet could not be delivered. In this case, “Port Unreachable” means that the destination IP address was reachable, but there was no process listening on the specified UDP port (41337) on the server 143.198.3.13, or a firewall was blocking it and configured to send such a response.

This could, in a normal scenario, suggest that an application on 192.168.2.115 is trying to communicate with a service that is unavailable or misconfigured on 143.198.3.13, with some intermediate device or the server itself dropping the UDP packets and generating ICMP error responses.

However, what was unusual was the pattern: sometimes multiple outbound UDP packets would be sent from the agent before a single ICMP Type 3 response was received from the server. If each UDP packet was genuinely being dropped and triggering a standard ICMP error, one might expect a one-to-one correspondence.

The most striking anomaly, however, was the variation in the size of the inbound ICMP packets. ICMP error messages, which primarily consist of headers and a portion of the original offending packet, are generally expected to be of a fairly consistent and relatively small size.

While slight variations due to the original packet’s IP header can occur, the Wireshark capture showed ICMP Type 3 packets with a wide range of sizes between 87 and 487 bytes. This significant variation, especially towards the larger end, is highly atypical for standard ICMP error messages.

We decided to inspect the content of one of the larger ICMP packets (487 bytes) – Image 6 below.

 

The reason for the large packet size became immediately apparent: these ICMP Type 3 packets were indeed carrying payload data. What’s more, this data was unencrypted within the ICMP payload section – we could clearly see a command.

And this specific command is worrisome – it is used to execute a Base64 encoded PowerShell script in a hidden window, bypassing the system’s execution policy. It is a common technique used by attackers for stealthy execution of more complex scripts, which could perform actions such as downloading further malware, executing arbitrary commands, or establishing further persistence.

Inspecting a handful of other large ICMP packets revealed additional enumeration commands, confirming that this ICMP channel was indeed the source of the suspicious activity alerts reported by Jane Doe Inc.’s security software.

To ensure this was the only active C2 channel related to these alerts and to systematically collect all commands sent via this method, a more efficient approach than manually dissecting each packet in Wireshark was needed.

 

Go-Packet-Peeker: A Custom Tool for Payload Extraction

To expedite the process of extracting all commands from the ICMP payloads, we developed a custom Go tool named “Go-Packet-Peeker.” This tool is designed to parse PCAP files, filter traffic by host pair and protocol, analyze packet sizes, and extract and clean payloads from specific packet size ranges.

(Note: We have made this tool available for your use here. Full installation and usage instructions are available in the README, and a sample PCAP is included.)

First, the tool takes a PCAP/PCAPNG file as input via a command-line flag (-f) – Image 7 below.

 

This initial scan counts the total packets. It then lists all source and destination IPs, allowing the user to select a specific host pair for flow analysis. After selecting the source and destination IPs (143.198.3.13 and 192.168.2.115 in our case), the tool analyzes the flow and lists the protocols involved in their communication – Image 8 below.

 

Here, it correctly identifies 326 ICMPv4 (Type 03) packets from the server to the agent. Upon selecting the protocol (ICMPv4 Type 03 in our case), the tool generates a histogram of packet sizes (bytes) versus frequency (count) for that specific protocol and traffic direction – Image 9 below.

 

This histogram visually confirms that the vast majority of ICMP packets are small, likely representing ICMP error messages without significant embedded C2 data (perhaps simple “keep-alive” or acknowledgments from the C2 server). The larger packets are of primary interest for payload extraction.

Finally, the tool prompts for a minimum and maximum packet size range to analyze for payloads. For packets within the specified range (90 to 600 bytes in this analysis), it extracts the payload, interprets it as ASCII, cleans non-ASCII characters, and saves a list of unique payloads to a CSV file. In our case, the tool found 47 unique cleaned payloads – Image 10 below.

 

The resulting cleaned_unique_payloads.csv contained some Base64-only data (likely chunked portions of larger encoded scripts or binaries) and, more importantly, a set of clear-text enumeration commands. After manually filtering for these commands, we identified 23 distinct commands executed via this ICMP C2 channel – Image 11 below.

 

After cross-referencing these commands with the security alerts, Jane Doe Inc. confirmed that this ICMP backdoor channel was indeed the source. Once the system was properly remediated and this channel eliminated, the alerts ceased.

 

Backdoor Enumeration Command Review

It’s insightful to quickly review these extracted commands and understand their purpose from an attacker’s perspective. This helps us as threat hunters recognize the types of information attackers seek and how seemingly benign commands can be abused.

• arp -a: Displays the ARP cache, mapping IP to MAC addresses on the local network. Used by attackers to discover other live hosts and understand network topology.
• dir C:\Windows\System32 /s /b /a-d: Lists all files (excluding directories) in C:\Windows\System32 and subdirectories. Used to enumerate system files, find executables, libraries, or misconfigurations.
• echo %COMPUTERNAME%: Displays the hostname. Used for host identification.
• echo %PATH%: Displays the system’s PATH environment variable. Used to find writable directories for malware or identify executables.
• echo %USERNAME%: Displays the current username. Used to determine privilege level and identify compromised credentials.
• fsutil fsinfo drives: Lists all connected drives. Used to find storage containing sensitive data or for exfiltration.
• gpresult /R /SCOPE COMPUTER: Displays Group Policy Objects applied to the computer. Used to understand security configurations and restrictions.
• hostname: Displays the hostname (similar to echo %COMPUTERNAME%). Used for host identification.
• ipconfig /all: Displays detailed network configuration. Used to understand network setup, gateways, and DNS servers.
• net localgroup administrators: Lists members of the local ‘administrators’ group. Used to identify privileged accounts.
• net user: Lists all local user accounts. Used to enumerate potential target accounts.
• netsh advfirewall firewall show rule name=all dir=in verbose: Displays all inbound Windows Firewall rules. Used to understand firewall configuration and find allowed inbound paths.
• netstat -ano -p TCP: Displays active TCP connections, listening ports, and associated PIDs. Used to identify running services and established connections.
• powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -WindowStyle Hidden -EncodedCommand JABQAHIA…: Executes an encoded PowerShell script hidden, bypassing execution policy. Used for stealthy execution of malicious scripts (e.g., downloading malware, persistence).
• query user: Displays information about user sessions. Used to see logged-on users and activity patterns.
• qwinsta: Similar to query user, displays Remote Desktop session info. Used to identify active/disconnected sessions for potential hijacking.
• “reg query “”HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon”” /s”: Queries the Winlogon registry key. Used to find stored credentials or understand logon processes.
• schtasks /query /fo LIST /v: Lists all scheduled tasks. Used to find tasks to hijack for persistence or schedule malicious tasks.
• “systeminfo | findstr /B /C:””OS Name”” /C:””OS Version”” /C:””System Type”””: Displays OS name, version, and system type. Used for basic system fingerprinting to tailor exploits.
• tasklist /FO CSV: Lists running processes in CSV format. Used to identify running applications and security software.
• type C:\Windows\System32\drivers\etc\hosts: Displays the content of the hosts file. Used to check for custom DNS mappings or to modify it for redirection/blocking.
• wevtutil qe System /c:30 /rd:true /f:text: Queries the last 30 System event log entries. Used to check recent system events (reboots, errors) for operational awareness or to cover tracks.
• whoami: Displays username, group, and SID of the current user. Used to confirm session context and privilege levels.

 

 

Conclusion

This “Malware of the Day” investigation into ICMP-GOSH demonstrates how adversaries adapt by misusing fundamental network protocols, like ICMP, for covert Command and Control, particularly as a means of persistence after primary access vectors are shut down. By embedding C2 communications within ICMP Type 3 messages, attackers can establish stealthy backdoors that may bypass security measures focused on more common C2 protocols.

Several key takeaways emerge from this analysis. Firstly, attackers continue to exploit the trust and permissiveness of diagnostic protocols like ICMP. While ICMP itself is vital for network operations, its less scrutinized nature, compared to data-centric protocols, makes it an attractive conduit for hidden communications.

The technique observed here—using outbound UDP packets from an agent to solicit ICMP error responses carrying C2 commands—illustrates an attempt to lend plausibility to an otherwise anomalous traffic pattern. It is the behavioral analysis capabilities of tools like RITA and AC-Hunter that are crucial in cutting through this deception, by identifying the patterns inconsistent with normal network behavior.

Secondly, the detection of such unconventional C2 methods heavily relies on behavioral analysis rather than traditional signatures, which custom frameworks like ICMP-GOSH are designed to evade. Signatures are inherently brittle – all it takes is a new method of communication (as we observed here), or a simple deviation from a known one, to render them useless.

In this case, the initial pointers towards suspicious activity came from RITA, which flagged a high beacon score for UDP traffic to an unusual port and direct IP communication. AC-Hunter then provided further visual confirmation of the C2-like activity through its beacon analysis, clearly showing consistent check-ins alongside the characteristic pattern of small heartbeat packets mixed with significantly larger data transfers. These findings from RITA and AC-Hunter guided the investigation towards the right areas for deeper inspection.

Thirdly, while tools like RITA and AC-Hunter are essential for identifying suspicious network behavior at scale, deep packet inspection and sometimes custom tooling play a vital supporting role in confirming the threat and understanding its specifics. Once the anomalous ICMP traffic was pinpointed, examining packets with Wireshark revealed embedded commands, which was the definitive proof of malicious C2. Custom tools, such as Go-Packet-Peeker, can then accelerate the detailed analysis and payload extraction from such unconventional channels.

Finally, this scenario underscores the ongoing threat of persistence through covert channels. Attackers are adept at establishing secondary, stealthier C2 mechanisms to maintain access after an initial intrusion point is discovered and closed. Security teams must therefore be prepared to hunt for these more deeply embedded footholds. The ability of tools like RITA and AC-Hunter to identify subtle deviations and sustained low-and-slow communication patterns is key to uncovering these persistent threats, even when they operate outside expected protocols or after initial remediation efforts.

This investigation serves as a good reminder that the threat landscape is dynamic. As defenders we must continuously adapt and expand our monitoring and analytical capabilities beyond common protocols and known signatures. A layered approach, combining the broad network visibility and behavioral analytics of tools like RITA and AC-Hunter with targeted deep-dive techniques, is the key for effectively detecting and responding to sophisticated, covert C2 channels.

 

Capture Files

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

ICMP-GOSH 24 Hour Capture
icmp_gosh_24hr.pcapng
File Size:  109.7 MB
SHA-256 Hash: 3AC3B257AB65FF89F60FD09B77437AF8FA2D4EE46C37BF93AAF781853AAE040C

 

Zeek Logs

If you are an AC-Hunter or RITA user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter or RITA. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

Importing Zeek logs into AC-Hunter or RITA example:

ssh into your AC-Hunter or RITA server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/zeek_icmp_gosh/

Then run the following command:

For AC-Hunter v6.x and RITA v4.x and earlier:

rita import /tmp/zeek_icmp_gosh/*.log icmpgosh

For RITA v5.x+:

rita import --logs=/zeek_icmp_gosh/*.log --database=icmpgosh

You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “icmpgosh” you can select and view.

 

ICMP-GOSH 24 Hour Zeek Logs
zeek_icmp_gosh_24hr.zip
Size: 616.7 KB
SHA256 Checksum: 696BF34FCC7654C5EBD2DB05E98BBCF7BDBD9CB18F191FFEB8C61770626B6F27

 

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?

You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.

 

 

A huge thanks to Bill Stearns, Keith Chew and Chris Brenton for allowing me the opportunity to contribute to this awesome initiative, as well as their guidance, helpful feedback, and for being a couple of stand-up gents.

Live long and prosper!