Book Image

Instant Traffic Analysis with Tshark How-to

By : Borja Merino
Book Image

Instant Traffic Analysis with Tshark How-to

By: Borja Merino

Overview of this book

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

Analyzing 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.