Vulnerability analysis part 4: Analyzing packets with Wireshark

Here is the given scenario: I’m a consultant for the security firm AllSafe. Our biggest client, E-Corp, suspects that an AllSafe employee did something to their network, and they need proof. All I have to work with is the packet capture file from our IDS.

A quick note about running Wireshark: To capture packets, Wireshark must be started as root. A quick search of the exploit database shows how many exploits there are for Wireshark. Obviously, I don’t want to be running Wireshark as root.

To capture packets, it’s safest use Wireshark’s CLI version, tshark.

# sudo tshark -i eth0 -w /tmp/packet_capture1.pcap

This allows me to promiscuously capture packets on the eth0 interface.

Now if I want to examine the capture (or any other .pcap file I download from the internet) from Kali, I need to modify permissions and view the file as a non-root user.

# chmod ugo+rx /tmp/packet_capture1.pcap

(ugo means users, groups, others, +rx means read and execute privileges). I’ll create a non-root user:

# adduser user1

After logging into our standard account with the supplied password, I’ll get to work.

$ wireshark /tmp/packet_capture1.pcap

I look for any host discovery scans. Nmap will do these scans differently depending on two things:

1) Is the user root?
2) Is it a local address (i.e. on the same subnet)

Nmap performs the following requests when scanning for hosts on a different network:

1) ICMP echo request
2) TCP SYN to port 443
3) TCP ACK to port 80
4) ICMP timestamp request

Filtering ICMP traffic reveals nothing.

Nmap performs ARP requests when scanning for hosts on the same subnet. I’ll look for ARP requests:

Bingo, I found host looking for hosts on our subnet. I’ll see if he was doing any port scans. I’m looking for TCP packets, specifically handshakes. I don’t know what kind of scan was performed, or which ports he scanned.

I’ll start by looking for traffic involving the suspicious machine to common ports. I expect the scan to be done first, so if I start seeing a lot of traffic on the port, I’ll just assume that he didn’t scan that port.

I look at ports for FTP, SSH, Telnet, and SMTP. They all start with:

This indicates that the suspicious host did an nmap stealth scan of the machine. I look at a few more ports, and it appears that he scanned ports 1-30. I didn’t see any of the SYN, SYN ACK, or RST packets for any ports above 30.

I want to see what websites he visited. I can do this by adding a filter on DNS traffic involving our suspicious machine.

It looks like he visited the website “”. This page has a lot of images and scripts which I can see if I take a closer look at his web traffic by adding a filter to see HTTP traffic.

Scrolling through the various loading of various widgets, images, and ads, I see a few interesting packets.

It looks like the suspicious .129 address tried visiting ~/bjones. I can follow the TCP stream of the subsequent HTTP GET packets and see what it contains.

Bob Jones must have had an Apache web server running. If I look a little after this, I see something else interesting:

The suspect downloaded a .rar password list. I wonder what he’ll use password list for…

Looking for any FTP traffic.

Here I see the password list being used to try to brute force the password for bjones. To find out if he was successful, let’s find out what response the server gives if the login is successful. According to, a server response of 230 indicates the user has successfully logged in.

If I go to where these packets occurred, I can see the correct FTP password being accepted by .131

User bjones had a password of password1234. Following the TCP stream can show us what mischief he was up to.

It looks like after navigating to the folder called Documents, the suspect downloaded the files andrea-nude.jpg, password-email.txt, password-email.txt, passwords.ods, and proposed-email.txt.

Using a little magic, I can rebuild these files and see what they contained.

Changing the filter to include packets with the FTP-DATA protocol. Now find the FTP-DATA packet after the response for the request for the .jpg. Save the raw dump to a location (I saved my in /tmp/rawdumps).

This data is meaningless in it’s current form. But using the Linux tools file and foremost, I can determine the type of file and then reconstruct the file by looking at headers, footers, and data.

$ file andrea-nude 
andrea-nude: JPEG image data, JFIF standard 1.01, resolution (DPI), density 300x300, segment length 16, baseline, precision 8, 332x332, frames 3
$ foremost andrea-nude 
Processing: andrea-nude
$ cd output/
$ ls
audit.txt jpg
$ eog jpg

I’ll do the same on the other files. Not all streams require us to decode them with file and foremost.

The email:

The OpenOffice spreadsheet:

Another email:

I also see the user SSHd to the victim machine. Obviously I won’t be able to see details of encrypted traffic.

This is all I was able to find from this file.