Detecting Malicious Network Activity with Wireshark

In one of our previous posts, we saw Netcat,  a tool dubbed as the Swiss knife of security for its many uses – for chats, file transfers, and remote shell handling among a few.

On this post, we’ll now see Wireshark, the tool dubbed as the Swiss knife for network analysis and how it can solve some of the various networks problems we see every day.

Brief History

Wireshark is a free and open-source software for packet capture and analysis. It was previously named Ethereal but was renamed to Wireshark in 2006 due to trademark issues. There is also a command line counterpart for Wireshark, Tshark, which is free and open source as well.

Installation

For this post, I installed Wireshark on both my Mac with Yosemite and Ubuntu Virtual VM. For the simulations, it would be mostly Mac that we will be using but don’t worry as the interfaces are almost similar. For installation on the other hand, there would be some differences as for Mac, we will be using the onsite installer while for Ubuntu, we will be installing from apt-get.

> Installing Wireshark on Mac OSX

Installing Wireshark in Mac is easy as you can just download the installer from their site. Found below is the homepage of Wireshark and you can just click the Download button and choose the installer suitable to your OS version.

Screen Shot 2015-12-19 at 12.46.30 AM.png

> Installing Wireshark on Ubuntu

On the other hand, for Ubuntu, we will be installing Wireshark and its dependency, libcap2-bin from apt-get:

sudo apt-get install wireshark libcap2-bin

To run Wireshark as non-root user, we add a new group named wireshark, add our user to it, and make it the group owner of the dumpcap directory:

sudo groupadd wireshark
sudo usermod -a -G wireshark $USER
sudo chgrp wireshark /usr/bin/dumpcap
sudo chmod 755 /usr/bin/dumpcap

Now, when you go and check the Wireshark GUI, no interfaces can be found. To make the interfaces visible, let’s issue the following command:

sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

 

Let’s Get Started: Capturing Packets

  1. Once you open Wireshark, you will be presented with a GUI where you can select which interface you want to listen to. Wireshark hints how much network traffic passes on each interface through each interface’s heartbeat line-like graph:Screen Shot 2015-12-18 at 11.25.00 PM.png
  2. When capture is already in progress, you can already see the moving packets realtime on your interface. At any time, you may start or stop your capture via the Capture menu. Note: Once you have stopped your capture, it is already considered a different capture from your next.

Screen Shot 2015-12-18 at 11.23.27 PM.png

Tip. On the Options option of Capture menu on our menu bar, make sure that you run Wireshark in its promiscuous mode so you can capture all the packets in your network. By default, network interfaces only keep the packets addressed to them and ignore everything else. With promiscuous mode on, you can capture all packets even if they are not directly addressed to you.

Screen Shot 2015-12-22 at 7.04.56 AM.png

Filters

For most of our use cases, we will be using filters. Filters are provided by Wireshark to help us isolate the packets we are truly interested in from all the packets that we’re captured (which are A LOT!). Isolating them would help us focus and follow the machine conversations with ease.

Wireshark has two types of filter, capture filters and display filters. Capture filters no longer keep and display the packets that don’t match the current filter (lost data already) while display filters on the other hand only take effect when you are currently on that filter. Unmatched packets will just be hidden but not disregarded and can be viewed again once the display filter is removed.

Here are some of the many possibilities on Wireshark filters:

Scenario 1:
We only want to see packets that were sent through a certain protocol.

How we can do it:
To filter packets by protocol, we could just type the name of the protocol we are interested in in the filter bar. Once you start typing, Wireshark also auto-suggests keywords that closely resembles what you are typing. So no much worries if you only remember a part of what you would want to find.

Say we want to only see packets sent through the DNS protocol: (Domain Name Systems lookup),we can do so by typing dns on the filter bar:

dns

Screen Shot 2015-12-18 at 11.40.16 PM.png

and there! We only saw DNS protocols. As you can see from the packet numbers, some number were skipped such as packets 1 and 2, since those packets were filtered out. But when we remove our filter, we can then again see all the packets (including 1 and 2).

Screen Shot 2015-12-18 at 11.41.55 PM

Scenario 2:
We want to only see packets coming from or to an IP address

How we can do it:
We can easily do the following to filter packets by IP address:

Step 1: To filter packets coming from an IP address, we can use the ip.src filter:

ip.src == 192.168.15.1

Screen Shot 2015-12-19 at 12.04.30 AM.png

Step 2. To filter packets that are going to a certain IP address, we can use the ip.dst filter:

ip.dst == 192.168.15.1

Screen Shot 2015-12-19 at 12.05.16 AM

Step 3: Wireshark allows logical operators(i.e. logical OR (||), logical AND (&&)) to be used in our filter bar! 🙂 So if we want to see packets coming from and to a certain IP (in our example, 192.168.15.1), we could combine the filters from Steps 1 and 2:

ip.src == 192.168.15.1 or ip.dst == 192.168.15.1

Or we could also use the provided shortcut by Wireshark for this  filter:

ip.addr == 192.168.15.1

Screen Shot 2015-12-19 at 12.06.07 AM.png

Notes on Filter Combinations:

You can combine any filtering condition with logical operators (i.e. OR (||) and AND (&&)) even if they are not the same filters to create more complex queries.

The following example shows how we can filter all ICMP (Internet Control Message Protocol) coming from 192.168.15.1:

ip.src == 192.168.15.1 && icmp

Screen Shot 2015-12-19 at 12.09.43 AM.png

Notes on Packet Types (SYN, SYN/ACK, RST, etc)

In the next following sections, we’ll be encountering more terminologies on packets and it is integral that we get an understanding of TCP flags. Flags are like switches that you can turn on and off on packets depending on what purpose do you intend the packet to have. Some of the available flags are the following:

  • SYN: short for SYNchronize. The SYN flag is used to initiate a connection.
  • ACK: short for ACKnowledge.  The ACK flag, on the other hand, acknowledges a previously sent invitation to connect (SYN packet)
  • RST: short for ReSeT. The RST flag is sent by an endpoint if it already wants to abort the connection.

In a packet, one or more flags can be turned on. For example, you may encounter SYN only packets as well as SYN/ACK packets.

Each flag has corresponding decimal numbers assigned to them:

  • SYN: 2
  • RST: 4
  • ACK: 16

So to calculate a SYN/ACK flag decimal value, we just add the value of SYN (2) to the value of ACK (16) and we get 18. We can use these decimal values later when we filter packets by the flags that are turned on.

For the other flags’ decimal values, you may refer here.

Use Cases

1. Detecting Torrent Downloads in your Network

If you ever experienced sudden slow internet for a period of time with no obvious reasons at all (sun is out, your network provider has no problems, etc), you may want to check who might be hogging your network capacity. There may be machines who are downloading  via torrent.

For the purposes of our demonstration, let’s download the free legal torrent of A Christmas Carol by Charles Dickens (since its almost Christmas :D) from Librivox: A Christmas Carol by Charles Dickens with seeders from archive.org. As soon as your download is finished, open up your favorite torrent application. I currently have Bit Torrent on my machine:

Screen Shot 2015-12-19 at 12.20.49 AM.png

Once our download starts, we can witness the live feed from Wireshark:

Screen Shot 2015-12-19 at 12.28.13 AM.png

As you can see from above, BitTorrent packets suddenly appeared in our feed. Filtering further to isolate bittorrent packets:

Screen Shot 2015-12-19 at 12.35.06 AM.png

With this, we can track that BitTorrent packets are present in our network which confirms that somebody might indeed be downloading in the network.

Apart from the BitTorrent packets, we can also see an influx of UDP protocol packets:

Screen Shot 2015-12-19 at 12.28.59 AM.png

And these are also caused by our Torrent download. Torrent has an extension DHT (distributed has tables) that makes use of UDP packets to transport data.

Based on observation, at least for this example with LibriVox, BitTorrent packets were only used during the initial period where our machine is still connecting to the servers (“handshake”) but once connection has been established, data is now transferred via UDP packets.

To also see how much traffic does the BitTorrent and UDP packets contribute, we can see the Protocol Hierarchy summary.

From the Statistics menu, choose the option Protocol Hierarchy:

Screen Shot 2015-12-19 at 12.39.05 AM

And then a screen would pop up summarizing the total number of packets captured so far as well as their size.

Screen Shot 2015-12-19 at 12.48.59 AM.png

In case upon inspection, you weren’t able to see BitTorrent nor UDP packets, but still suspect that the slowing down of internet is due to heavy downloads, you may see the total network traffic that has been sent from / to a machine in your network.

You can go to Statistics > Endpoints

Screen Shot 2015-12-22 at 10.37.36 AM.png

Or if you want a more detailed view and want to know to which exact ports and IP addresses were made from/to your network, you may go to Statistics > Conversations:

Screen Shot 2015-12-22 at 10.39.02 AM.png

On both Endpoints and Conversations, the columns are sortable. Just click on the column header of whichever column you’re interested to sort by.

2. Detecting Port Scans

Have you ever connected to a public WiFi, maybe in your favorite cofee shop or restaurant,  with paranoia that somebody might actually be listening to data you’re sending to the internet or maybe that somebody is looking for loopholes in your system in hopes of gaining access to it?

Attackers might do this with a tool called, NMAP, a network mapper that we saw in our previous NMAP post. In its most basic form, NMAP scans are done by sending SYN packets to ports of the target machine to which a SYN/ACK would be replied if the target’s machine port is open, otherwise an RST is replied.

For demo, we’ll try to port scan on our Ubuntu VM from our Mac (with IP Address: 172.20.10.2)

Screen Shot 2015-12-21 at 11.59.07 PM.png

And our Ubuntu VM has IP address: 172.20.10.3:Screen Shot 2015-12-21 at 11.57.36 PM.png

When we try to do a default NMAP port scan on our target machine, Ubuntu VM:

nmap 172.20.10.3

Screen Shot 2015-12-22 at 1.13.00 AM.png

We get the above results. 2 from the top 1000 ports are open.

Now before we go and filter the Nmap scans, let’s first figure out what’s happening in the wires when we did the scan. Inspecting our feed, we see that there were a lo t of SYN packets sent by our Mac to our Ubuntu Virtual VM.

Filter used:

 ip.src == 172.20.10.2

You may filter further by restricting the results to have 172.20.10.3 as their destinations:

ip.src == 172.20.10.2  && ip.dst == 172.20.10.3

Screen Shot 2015-12-22 at 1.05.56 AM.png

There’s a lot of SYN, and here, we can see from and to which ports were they sent. With the screenshot above, we can infer that the top 1000 ports include 80, 113, 59000, 21, 53, 111, 8888 and so on. As we learned earlier, here, our Mac is still doing the initial handshake step to the top 1000 ports.

Now, knowing that Nmap found port 21 to be open (i.e. 21 responded positively to the SYN packet sent), we can inspect how our Mac and port 21 (ftp) of our Ubuntu’s VM interacted. We can filter such packets by:

ip.addr == 172.20.10.3 && tcp.port == 21

Screen Shot 2015-12-22 at 12.01.53 AM.png

We see that after a SYN packet was sent by our Mac to our Ubuntu VM, a SYN/ACK was replied suggesting that port 21 is indeed open. After an ACK is sent (since we are in the default non-sudo port scan where TCP connect() establishes a full connection), our Mac then sends a RST/ACK to immediately close the connection as indicated in line 66.

On the other hand, closed ports respond with an RST/ACK packet indicating that they are closed. As we learned earlier, we can filter those packets with only the RST and ACK flags turned on by using the decimal values assigned to each flag. Since we want to get RST/ACK, we get a total value of 20 (RST(4) + ACK(16)).

tcp and tcp.flags == 20

We can see that this filter both includes packets from our Mac and packets from our Ubuntu VM like the one we saw earlier on port 21. We can enhance this further by just including the packets that came from our Ubuntu VM since it is whose ports we are interested in.

tcp and tcp.flags == 20 and ip.src == 172.20.10.2

Screen Shot 2015-12-22 at 4.09.06 PM.png

The results show a flood of RST/ACK packets from closed ports.

So there, these symptoms on your network, as you can get from Wireshark, can let you know if somebody is indeed scanning your ports. 🙂

What we saw in this blog post is just two of the many use cases for the many capabilities of using filters and other features of Wireshark.

Thanks for reading!

Sources:

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s