Book Image

Instant Traffic Analysis with Tshark How-to

By : Borja Merino
Book Image

Instant Traffic Analysis with Tshark How-to

By: Borja Merino

Overview of this book

Malware, DoS attacks, SQLi, and data exfiltration are some of the problems that many security officers have to face every day. Having advanced knowledge in communications and protocol analysis is therefore essential to investigate and detect any of these attacks. Tshark is the ideal tool for professionals who wish to meet these needs, or students who want to delve into the world of networking.Instant Traffic Analysis with Tshark How-to is a practical, hands-on guide for network administrators and security officers who want to take advantage of the filtering features provided by Tshark, the command-line version of Wireshark. With this guide you will learn how to get the most out of Tshark from environments lacking GUI, ideal for example in Unix/Linux servers, offering you much flexibility to identify and display network traffic.The book begins by explaining the basic theoretical concepts of Tshark and the process of data collection. Subsequently, you will see several alternatives to capture traffic based on network infrastructure and the goals of the network administrator. The rest of the book will focus on explaining the most interesting parameters of the tool from a totally practical standpoint.You will also learn how to decode protocols and how to get evidence of suspicious network traffic. You will become familiar with the many practical filters of Tshark that identify malware-infected computers and lots of network attacks such as DoS attacks, DHCP/ARP spoof, and DNS flooding. Finally, you will see some tricks to automate certain tasks with Tshark and python scripts.You will learn everything you need to get the most out of Tshark and overcome a wide range of network problems. In addition you will learn a variety of concepts related to networking and network attacks currently exploited.
Table of Contents (7 chapters)

Analyzing malware traffic (Must know)


In this recipe we will see how Tshark can be an excellent support tool for malware traffic analysis. Likewise we will see some useful filters that help us identify possible infected computers on our network.

Getting ready

Performing simple checks on our network periodically can help us to detect malware. For example, if your network hosts use an internal DNS to resolve names, something as simple as checking that all requests are coming from that server can help us identify infected hosts. The reason is that malware might bypass the host DNS settings. For example, using the DNS_QUERY_NO_HOSTS_FILE flag in the DnsQuery API, the malware will not query the hosts file. Even better, the malware can open a UDP socket and construct UDP packets to send them directly to a particular resolver. The response is then parsed by the malware itself and this way it would not even need to change the DNS setting of that host. Festi Botnet, for example, uses this technique to choose 8.8.8.8 (Google) as a resolver.

How to do it...

  1. In the next example, we are looking for DNS output requests made from any hosts whose IP is different from the Internal DNS server (192.168.1.100). Captured packets are stored in a pcap file on a remote server (note the argument -w - to write raw packet data to the standard output). Thanks to this, we could find out that the host 192.168.1.42 requested the domain name www.malwaredomain.net (not a real domain) without using its local DNS:

    bmerino@Mordor:~$ tshark -i eth0 -f "udp dst port 53 and not src host 192.168.1.100" -w - | ssh [email protected] "cat > SuspiciousDNS.pcap"
    Capturing on eth0
    2 
    bmerino@Mordor:~$ ssh 
    [email protected]
     "tshark -r SuspiciousDNS.pcap" 
      1 0.000000000 192.168.1.42 -> 8.8.8.8      DNS 81 Standard query 0x1b58  A 
    www.malwaredomain.net
    
  2. Searching for nonexistent domains in DNS responses can also help us to locate infected hosts. In this case it is likely that the control server has been shut down and some hosts are trying to connect to them from time to time. Let's see an example. First, we use a capture filter to save all DNS responses received for a couple of hours.

    bmerino@Mordor:~$ tshark -i eth0 -f "udp src port 53" -a duration:7200 -P -w /tmp/dns.pcap
    

    This would generate the following output:

    Capturing on eth0  
    80.58.61.250 -> 192.168.1.131 DNS 157 Standard query response 0xd983 No such name
    <... rest of output omitted …>
    
  3. Then we will take the pcap file to show only the responses with a reply code of 3 which indicates that the domain does not exist. As we can see in the following example, the IP 192.168.1.131 tried to resolve the domain www.botcontrold omain.net (not a real domain) 16 times and 192.168.1.42 tried to resolved www.maliciousdomain.org (not a real domain) 11 times:

    bmerino@Mordor:~$ tshark -r /tmp/dns.pcap -T fields -e  
    dns.qry.name
     -e ip.dst -R "dns.flags.rcode==3" | sort |uniq -c
    

    This would generate the following output:

         16 www.botcontroldomain.net  192.168.1.131
         11 www.maliciousdomain.org   192.168.1.42
    

How it works...

In this recipe we have used another option of Tshark, -P. This parameter allow us to decode and display packets even while we are writing raw packet data using the –w option, useful if we want to store packets and watch them at the same time. We have also used the –T pdml option to set the output format. Packet Details Markup Language (PDML) is an XML-based format equivalent to the packet details printed with the –V flag. Tshark has another option to specify the format in which to write the file by using the –F option; in this case, however, you can't specify it for a live capture:

bmerino@Mordor:~$ tshark -r malware.pcap -F pcapng –w malwareA.pcap

To list the available file formats use the -F flag without a value:

bmerino@Mordor:~$ tshark -F

This would generate the following output:

tshark: The available capture file types for the "-F" flag are:
    5views - InfoVista 5View capture
    btsnoop - Symbian OS btsnoop
<rest of output omitted>

There's more...

Consider the examples seen in the Implementing useful filters (Should know) recipe to compare all domains accessed by users with a blacklist and to use a DNS PASSIVE service to get more information about suspicious IPs. In addition to these filters, there are many aspects we have to consider when looking for malware traffic. Thus, if the malware uses TLS to communicate with the C&C to evade firewalls and IDS, we can still see details such as: invalid certificates, TLS handshake failures, strange domain names, and so on (be aware that the initial part of an SSL session is not encrypted). We can even take into account information such as the size or timing of packets when we are monitoring encrypted packets (for example, very short-lived sessions of a single request followed by a reply could indicate malware activity). Also make sure that the traffic traveling through port 443 is TLS/SSL as many malware use this port to send HTTP traffic or a custom encrypted protocol (as in Aurora Operation). Take a look at the paper Detection of Web Based Command & Control Channels of Martin Warmer to see many of these patterns. (http://eprints.eemcs.utwente.nl/20941/01/MSc_M_Warmer.pdf). In the following example we can see how the certificate sent by certain host presents a suspicious CN:

bmerino@Mordor:~$ tshark -r 443.pcap -R "ssl.handshake.certificates" -T pdml  > certificates
bmerino@Mordor:~$ cat certificates | grep -i commonname -m 1 
<field name="ssl.handshake.certificate" showname="Certificate (id-at-commonName=
ERdifadjklwkrsaf.EdkjaldfkWEfd.WEdf.net
,id- 

Tshark can serve as a complement to our debugger to analyze the traffic generated by malware. The figure that follows is a code excerpt from a certain Trojan. In it we can see the assignment of certain static data to a buffer. This buffer is then sent as a POST request to a malicious domain through the API HttpSendRequest. To confirm the sending of such data, we run the sample in a Cuckoo VM several times while we leave Tshark listening.

After checking the sending of such data through the POST requests, we can use them to create a signature for SNORT and block this way any future connection from any other hosts of our network. This rule, along with the malicious domains used by the Trojan, will help us to detect not only that Trojan itself but a possible variant thereof in a preventive way. Check out the signature created based on the positions of the static data in the POST request: