Malware of the Day – Pings!

What is Malware of the Day?

 

Lab Setup

“Malware”: Pings!

MITRE Tactics: TA0011 Command and Control, T1572 Protocol Tunneling

Traffic Type: Generic

Connection Type: ICMP

C2 Platform: icmpsh

Origin of Sample: https://github.com/hemp3l/icmpsh

Host Payload Delivery Method: Windows EXE

Target Host/Victim: 10.0.0.60 – Windows 10 x64

C2 Server: 157.230.93.100

Beacon Timing: 0.5s

Jitter: N/A

 

Brief

Our focus is on identifying anomalous network activity in order to detect and respond to threats. We are using AC-Hunter/RITA as our network threat and C2 detection platform to visualize the network traffic generated from running an ICMP (Internet Control Management Protocol) shell. ICMP is a network layer protocol used for diagnosing communication issues, testing, and error reporting. Like most protocols however, it can also be abused to carry data.

Today we are looking at how an adversary can use pings, a.k.a. ICMP echo requests, to establish a reverse shell. This is made possible through a technique called Protocol Tunneling (MITRE ATT&CK Tactic T1572). Protocol tunneling involves encapsulating arbitrary data within the payload of the tunneling protocol. The data can be anything, even packets of a different protocol. This can provide the ability to bypass firewalls or other security features by obfuscating the traffic, and/or its destination.

Using ICMP Echo requests (“pings”) for C2 is not a new idea. The technique has been around for decades but was seldom used and is therefore seldom looked for. Recently however, we have seen a re-emergence of ICMP tunneling with threats such as the Pingback Malware. Since ICMP is mainly used for error reporting, it is not usually monitored by network administrators or security teams. Pings are likely to be allowed inbound and outbound on most networks. This makes it an appealing attack vector for adversaries who want to remain unnoticed.

How does one abuse the ping protocol for nefarious activity? The answer lies in the structure of the packet itself.

ICMP packets are composed of a 28 byte header, and a payload. Of the header bytes, 20 are your typical IP header and 8 are the ICMP specific information. The graphic below depicts your typical ping packet.

ICMP tunneling works by injecting arbitrary data into the payload section of a ping packet which would normally be empty. An adversary could also edit the header data to give additional meanings to the fields.

Next, we’ll take a look at how we can detect ICMP tunneling on a network.

The program used for the basis of this analysis (icmpsh), gives us a fully functional reverse shell on the compromised system. Our setup consists of a Windows 10 client, sending ping requests out to our C2 server on the internet. Commands are sent back to the Windows machine within an echo reply. In theory these roles can also be reversed, but that is less effective in practice as it requires the host to not be behind a firewall. The OS on the client machine is an up-to-date version of Windows 10 Professional. Scanning the malicious executable (compiled locally) with Windows Defender did not raise any alarms.

The above screenshot shows the AC-Hunter long connections screen. We can see an internal system was connecting to a host on the internet for about 32 hours. ICMP is a stateless protocol, which means it has no sense of what a “connection” is, unlike how there is for something like the TCP protocol. We can still detect it though!

Because of our Zeek connection timeout settings, our reverse shell gets treated as a single long connection.

Looking at the second view in the long connections screen shows us that over 11 MB of data were transferred between the hosts. Since we know that typical ICMP traffic does not carry data, this is a strong indicator that something fishy is going on.

To prevent ping tunneling, network administrators should limit or block ICMP traffic whenever possible. Having a good intrusion detection system in place can help you quickly recognize when an ICMP attack is occurring and stop it before any real damage is done.

If we also have the packet captures (PCAP files), we can see the size of the individual packets. Here we have echo requests of various sizes going across the wire. Sorting the packets by length show there are various packet sizes going to this IP, the largest being 106 bytes. Moreover, we can see that the payload of the selected packet contains a chunk of directory information, which is definitely not a legitimate use of the protocol.

We encourage you to download and use the PCAP files included in the next section to analyze them independently using your preferred threat hunt platform to test your detection capabilities.

 

Capture Files

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

The following PCAP files are packet captures taken from the same lab environment over a 1-hour time frame and a 32-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.

Pings 1 Hour Capture
funkypings_1hr.pcap
Size: 122.13 MB
SHA256 Checksum: 30ACED4FC69797B8ED46918EF391BC45E8A2F5958AE91A9F5CD7736349E5BDC2

Pings 32 Hour Capture
funkypings_32hr.pcap
Size: 233.49 MB
SHA256 Checksum: 33C21B602748E17AC8F9978F3E877C5FA8A38DB137393C490C0F4C02707CBAEE

 

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.