Not all network traffic is as it seems, learn how to identify malware, or a cyber attacker, may be discreetly exfiltrating your data via network tunneling.
Knowing how to identify and understand network tunneling traffic is key when attempting to prevent data loss. In this blog, we’ll examine covert network tunnels to provide a better understanding of how they operate, how we can identify them and how we may review their contents.
In this blog we’ll be looking at the following:
- What is tunneling, why is the identification of tunnels important to your business and what are some of the techniques used to tunnel data covertly;
- What sort of tools are used by both hackers and penetration testers to perform tunneling, and how to identify their usage;
Our next blog will examine malware which utilizes tunneling techniques to exfiltrate data.
What is network tunneling?
Network tunneling refers to the encapsulation of data within specific network protocols. While some forms of tunnels can have legitimate uses, we’ll be focusing on tunnels which are commonly used to covertly exfiltrate data from a network. In this context, the purpose of the tunnels is to allow the transmission of data in a context where ordinarily it would be blocked (e.g. due to firewall rules) or detected (e.g. by an IDS).
Why network tunnels matter?
The ability to control network access, and to understand the traffic that traverses a network is key to prevent data loss. Data transmitted over tunnels may represent valuable intellectual property, sensitive employee data or reconnaissance data which will provide an assailant with insights into your network. Additionally, even where the data being transmitted is not yours, it may represent command and control information being shared between malware on your network and a remote server. This may be a prelude to data loss through encryption (i.e. ransomware) or data theft.
Types of Network Tunnels
We’ll be looking at two types of covert tunnels today, DNS tunnels and ICMP tunnels.
DNS Tunnel
DNS tunneling involves the use of DNS packets as a means of encapsulate other forms of network data. DNS traffic is commonly seen within an organization’s network, so the normal obstacles to malicious data transmission (e.g. firewalls) may not find issue with such traffic.
DNS tunnels may be aimed directly at a non-standard DNS server. In this configuration, such tunnels may be more easily distinguished from legitimate traffic through the identification of an unusual target address. However, if an attacker is the authoritative source for name resolution within a particular domain on the internet, they can allow their DNS traffic to be routed as normal, safe in the knowledge that the traffic will ultimately be delivered to their remote name server.
ICMP Tunnel
ICMP tunneling involves encapsulating data within ICMP (Ping) packets and transmitting these packets to a remote computer. Ping traffic is often seen as being innocuous, so transmitting data in this manner can allow malware or a malicious actor to exfiltrate data from a network without raising an alarm.
Tools
DNS Tunneling
We’ll look at two well-known DNS tunneling applications, Dns2tcp and Iodine.
Dns2tcp
Dns2tcp is an application for tunneling TCP traffic through DNS traffic. Two main components make up Dns2tcp; the first is a daemon, Dns2tcpd, which is generally run on a remote server, while the second is a client application, Dns2tcpc, which can be run on a compromised computer and from which a connection will be initiated.
When generating traffic to examine within our lab environment, we used Dns2tcp to provide a tunnel to transmit SSH traffic. This approach is typical of how Dns2tcp might be used by an attacker, as the combination of a DNS tunnel and SSH allows an attacker to transmit encrypted data discreetly.
Analysis
Analyzing the traffic produced by Dns2tcp, we can discern some patterns which suggest that this traffic does not represent typical DNS activity.
To a human analyst this is probably quite apparent, as the domains being checked are unconvincing, e.g. 4XsAAAACCFNTSC0yLjAtT3BlblNTSF83LjVwMSBEZWJpYW4tMTANCg.dns2tcp.com
However, further analysis can reveal more about what is occurring, and can indicators which we can use for detection. For example, the random looking string we just looked at is in fact base64 encoded data which we can decode. When decoded, we see that the sequence 4XsAAAACCFNTSC0yLjAtT3BlblNTSF83LjVwMSBEZWJpYW4tMTANCg contains the encoded string SSH-2.0-OpenSSH_7.5p1 Debian-10\r, revealing that SSH encrypted data is being transmitted via DNS.
Other DNS messages can be decoded to show cipher suite negotiation. If we capture the initial creation of the tunnel we can also see DNS requests with subdomains of =auth and =connect, revealing the initial Dns2tcp negotiation between the client and server.
Identifying these early connection and authorization messages can allow an organization to detect that a tunnel exists, even if the contents of that tunnel are encrypted.
Iodine
Iodine is an IP-over-DNS tunneling application. As with Dns2tcp, Iodine comprises two main components; Iodined and Iodine. As before, Iodined is a daemon to be run on a server which is awaiting a connection, whilst Iodine is normally run on a compromised computer within a private network.
As before, the DNS tunnel once created was used to facilitate the creation of an SSH connection.
Traffic
When analyzing a tunnel created by Iodine, we can again delve into the traffic to identify indicators and obtain information about the way in which the tunnel has been configured.
Using Iodine with a standard configuration, initially we see a series of NULL packets which are exchanged between the client and server.
Looking at the data associated with these DNS queries and their responses, we can see the client/server negotiation and indications of the settings used when creating the tunnel.
Below are some examples of the data within the server responses:
Traffic like this, representing negotiations between the client and server, is typical of Iodine tunnel creation, and thus may provide key indicators for identifying Iodine-based DNS traffic.
ICMP Tunneling
To demonstrate ICMP tunneling, we’ll use the tool Hping3.
Hping3
Hping3 has several functions, not all of which relate to tunneling. Here we’ll look at its ability to transmit a file via an ICMP tunnel. For comparison sake, we’ll run Hping3 alongside a s tandard ping query from the same Linux machine, and will compare both these results to Windows ping traffic.
Analysis
Looking at the resulting traffic below, we can clearly demarcate the ordinary ICMP traffic (first four rows) from the tunnel traffic (last four rows) by frame size. This can be determined based on the “Length” column shown in the screenshot below, which displays the size of the ethernet frame in bytes. Though Hping3’s packet sizes are configurable, it is usually the case that ICMP tunnels will contain unusually large volumes of data in comparison to standard pings. Where the packets are kept smaller, there will be a corresponding need to transmit a large number of packets, providing another indication that something may be amiss.
Going deeper, if we look inside the Data section of a standard Linux ping, we can see a standardized character sequence, as demonstrated below:
If we look inside one of the tunnel packets however, we can see the contents of our test document, i.e. “This is a test document”:
On Windows the content of a standard ping is somewhat different, but is again distinguishable from ICMP tunnel traffic based on size and legibility:
Understanding how regular ICMP traffic looks within a given network can provide the basis on which to identify anomalous traffic which may be an indicator of a tunnel.
Using protocols like DNS and ICMP, which are as ubiquitous as they are innocuous, can provide the attacker a method to covertly operate within an organization’s network, siphoning away valuable data without detection. However, as with most threats, a covert tunnel can be recognized if an organization knows what to look for and has the appropriate tools, and skills, to perform the search.
Corvil understands the challenges inherent to detecting evasive threats of this nature. Our Security Analytics are trusted by our clients to automatically analyze network traffic in order to detect such threats and provide workflows to accelerate triage and response. Next week we’ll take a deeper look into Corvil’s ability to detect the use of covert tunnels or other data exfiltration techniques within your network.
Originally published at www.corvil.com.
