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.
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.
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 namewww.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
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 …>
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 resolvedwww.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
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>
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: