Using WireShark to Capture Packets
BACKGROUND
WireShark is an open source network scanner and monitor. It’s an industry favorite for analyzing packets and is used to troubleshoot networks, help design software, and aid in education. In fact, there is a conference every year for WireShark enthusiasts (including many high-level security contractors) called SharkFestTM.
WireShark is freely available on MacOS, Windows, and Linux. It can scan network traffic. This is very helpful - imagine examining packets from background applications - you can see if anything nefarious is happening. WireShark can also be run on some routers and servers.
DESCRIPTION
This lab is an entry-level look into some of the basic functions of WireShark; we will revisit WireShark in a future chapter. This lab will reference two different websites (innovativedave.com and daveghidiu.com)--all of the content on the website(s) is maintained by me and contains no malicious payloads.
REQUIREMENTS
This exercise assumes you have access to a computer that has WireShark on it. It should be part of the Kali Linux distribution, though you can use any computer you wish for this lab (WireShark is freely available for MacOS and Windows as well). Since WireShark will examine all traffic through your NIC, you should close all other applications and all tabs in your web browser before capturing packets otherwise there will be an awful lot of information to wade through.
PART I: Understand the layout of WireShark
- Upon booting up WireShark, you will notice all the different interfaces that WireShark can see. In my case, I can see that there is activity in the Wi-Fi: e0 and Loopback: lo0 interfaces (note the small thumbnails showing traffic on each one).

We will be looking at the WiFi adapter (in this case, Wi-Fi: e0). WireShark will examine all packets that enter and leave your NIC. Many websites will load content from dozens of different places in the background so packet captures can be quite voluminous.
- The second thing we’ll need to look at are the main functions in the menu bar.There are a number of symbols in the menu bar; we’ll only be playing with a few of them:

This will start a packet capture. Note that if you have already captured some packets, clicking on this will overwrite existing data.
This will stop a packet capture.
This will start a packet capture. Note that if you have already captured some packets, clicking on this will overwrite existing data.
This will start a packet capture. Note that if you have already captured some packets, clicking on this will overwrite existing data.
- It’s also worth noting that the default mode for WireShark is promiscuous mode. This means that WireShark will examine any packet it encounters regardless of if that packet is destined for your computer. You can turn it off in the “Preferences” section, though you don’t need to because we’ll be using filters to examine traffic.
PART II: Understand the TCP Handshake
- We’ll also need to know the fundamentals of a TCP handshake.
- There are three steps. The initiating computer will send a synchronization request to the receiving computer:

- Next, the receiving computer will respond with an acknowledgement and synchronization of its own:

- Lastly the sending computer will send an acknowledgement:

- Now both computers are ready to exchange information.
- When you are examining packets that use TCP, you may encounter the SYN-ACK. Keep your eyes peeled!
PART III: Capture some packets over HTTP
- Close all your applications (except for a web browser and WireShark). It’s a good idea to close all but one tab in your browser. This lab will be looking at all the packets zooming around, so the less traffic we have to wade through, the better. Capture packets with WireShark by pressing the shark fin icon to start. After a few seconds, press the red square to stop. Most of the activity should be between computers on the network (for many home routers, the IP addresses are between 192.168.0.1 and 192.168.255.254 range). You might even see some ARPing (“Who has 192.168.0.11? Tell 192.168.0.1”) as your computer tries to settle into the network.
EVIDENCE #1 |

INSERT THE IMAGE OF THE INITIAL PACKET CAPTURE. |
- Start another packet capture (no need to save the current one). Once started, let’s look at the communication needed to serve a website. Go to your browser and go to:
http://www.innovativedave.com/security
As soon as the page loads head back over to WireShark, wait a second or two, and stop the capture.
- Again, there will most likely be a lot of packets that have been captured. Most of them are the noise from your computer communicating with other computers on the network, though some of them should be HTTP requests. Most of the network traffic should have source and destination IP addresses that are similar (usually starting with 192.168) and will usually use the TCP or ARP protocol. We’re not interested in those; we want to see only the HTTP requests.
Click in the filter bar (under the shark fin and the stop button), and in the spot where it says “Apply a display filter…”, type in “http”. This will filter out any packet that is not using the HTTP protocol.

If everything goes right you probably only have a few different packets to look at (because most traffic with your computer isn’t HTTP).
EVIDENCE #2 |

INSERT THE IMAGE OF THE INITIAL PACKET CAPTURE. LOOK CAREFULLY AT THE CAPTURE. INDICATE ANY RED FLAGS. |
PART III: Capture some packets over HTTPS
- Again, close all your tabs in your browser, save for one. Go over to WireShark and start a capture. Head back to your browser and go to:
https://www.daveghidiu.com/security
As soon as the page loads, head back over to WireShark, wait a second or two, and stop the capture.
- We want to filter for HTTPS instead of HTTP. We do this by applying the “SSL” filter.
- It might be the case that when you filter for SSL there is still a lot of other noise. That’s probably because more communications are whizzing through your computer than just the website information. Some of this noise might be services that your computer uses without you even knowing it. But the problem is that it’s kind of hard to sift through all this data if we don’t even know the IP address we are looking for.
- Let’s head over to a terminal and find the IP for daveghidiu.com. This will make our packet examination a little bit easier:
ping daveghidiu.com -c 1

- Sweet! Looks like the IP address of daveghidiu.com is 192.232.223.120. Now we can filter the output by IP address; this will laser-focus our analysis. Let’s filter the capture data in WireShark. Using the ip.addr search string, we can look for any traffic where the IP address was the source or the destination:
ip.addr == 192.232.223.120
- This is interesting because we can see a number of different protocols that were used to communicate with the server. It looks like a lot of TCP (in fact, we can see that TCP three-way handshake we talked about before). There is also one entry that is HTTP. That’s a little alarming because the server is HTTPS! If you click on the entry, you’ll see the related data in the pane below.
Upon further investigation, it looks like that data is a 302 redirect; most likely the HTTPS redirect. So we can conclude that an HTTP packet makes sense.

- Let’s focus our interrogation. Let’s change the filter to show not only the IP address, but any traffic that was HTTPS (because that’s what we are really after):
ip.addr == 192.232.223.120 && ssl
EVIDENCE #3 |

INSERT IMAGE OF THE DATA FILTERED BY IP ADDRESS AND HTTPS. |
Notice that we can’t make sense of the content in the packets; that’s because they are encrypted! We’re using HTTPS after all!
CONCLUSION
WireShark is great for monitoring data that is coming into and out of the NIC on your computer. This is great for troubleshooting as you’ll be able to granularly check data (great for finding latency issues, malware issues, etc.)
For further exposure to WireShark, check out the following: