Analyse Network Traffic with Wireshark

Capture and dissect real DNS, TCP, and HTTP packets using Wireshark.

Introduction

30 Second Summary

Every time you open a website, send a message, or stream a video, hundreds of tiny data packets fly across the network in milliseconds. Most people never see them. Security professionals read them like a book.

In this project, you will capture real network traffic using Wireshark, dissect it packet by packet, and learn to identify exactly what is happening at each layer of the network stack.

What You'll Build

A hands-on network traffic analysis lab where you generate specific traffic (DNS lookups, TCP connections, HTTP requests), capture it live in Wireshark, and break down each protocol layer.

By the end of this project, you'll have:

A working Wireshark installation with live packet capture on your Windows machine and verified connectivity to a Kali Linux VM.
Captured and dissected real DNS, TCP, and HTTP/HTTPS traffic with full protocol-layer analysis.
Hands-on experience with display filters to isolate specific protocols and a saved .pcapng capture file for future reference.
Secret Mission: Use nmap from your Kali VM to perform a port scan and detect the scan pattern in Wireshark.

Are there any prerequisites?

You need a Windows PC with a Kali Linux VM running on VMware in NAT mode. Basic command line familiarity (running commands in a terminal) is helpful but not required.

Install Wireshark and Verify Your Environment

Before you can capture and analyse real network packets, you need the right tools installed and your lab environment connected.

In this step, you will install Wireshark on your Windows machine, identify the network interfaces available for capture, and confirm that your Windows host can talk to your Kali Linux VM.

In this step, get ready to:

Install Wireshark with Npcap on Windows.
Identify active network interfaces for packet capture.
Verify connectivity between your Windows host and Kali VM.

Download and install Wireshark on Windows

Wireshark is a packet capture and analysis tool that lets you see exactly what is travelling across your network, byte by byte. It needs a capture driver called Npcap to tap into live network traffic on Windows.

Let's check whether you already have Wireshark installed.

Press the Windows key to open your search bar.
Type Wireshark and look at the results.
If Wireshark appears, open it and click Help > About Wireshark to check the version number shown at the top of the dialog.

✔️ I see version 4.6.6 or higher

You already have the correct version of Wireshark installed.

Close the About dialog and proceed to the next substep.

ⓧ I see an older version

You need to upgrade to version 4.6.6 for this project.

Close Wireshark.
Press the Windows key and type Add or remove programs.
Press Enter to open the settings page.
Search for Wireshark in the app list.
Click Uninstall and follow the prompts to remove the old version.
Open your browser and navigate to https://www.wireshark.org/download.html.
Click the Windows x64 Installer link under Stable Release 4.6.6.
Run the downloaded installer and accept the default settings on each screen.
When the installer prompts you to install Npcap, accept it. Npcap is required for live packet capture.
Finish the installer.

Verify the upgrade by pressing the Windows key, typing Wireshark, and opening it. You should see network interfaces listed on the welcome screen.

ⓧ Wireshark doesn't appear in search results

Wireshark is not installed yet. Let's install it now.

Open your browser and navigate to https://www.wireshark.org/download.html.
Click the Windows x64 Installer link under Stable Release 4.6.6.
Run the downloaded installer and accept the default settings on each screen.
When the installer prompts you to install Npcap, accept it. Npcap is required for live packet capture.
Finish the installer.

Verify the installation by pressing the Windows key, typing Wireshark, and opening it. You should see a list of network interfaces on the welcome screen.

What is Npcap?

Npcap is a packet capture driver for Windows. It gives Wireshark low-level access to your network adapters so it can read raw packets as they arrive. Without Npcap, Wireshark cannot capture live traffic.

Wireshark shows no interfaces?

If Wireshark opens but the interface list is empty, Npcap may not have installed correctly. Close Wireshark, re-run the installer, and make sure you check the Npcap installation option.

If you still see no interfaces, try running Wireshark as Administrator (right-click the Wireshark shortcut and select Run as administrator).

Help me troubleshoot my Wireshark interface list being empty on Windows.

Identify your capture interfaces

Wireshark lists every network adapter on your machine. You need to identify two specific interfaces for this project.

In Wireshark's welcome screen, look at the listed network interfaces.
Find your active internet connection (labelled Ethernet or Wi-Fi). It will have a small activity sparkline graph showing live traffic.
Also locate the VMware Network Adapter VMnet8 interface. This is the NAT virtual network connecting your Windows host to your Kali VM.

Why two interfaces?

Your active Ethernet or Wi-Fi adapter carries all your internet traffic. You will capture DNS, HTTP, and HTTPS packets on this interface in later steps.

The VMnet8 adapter is the private network between your Windows host and the Kali VM. You will capture port scan traffic on this interface in the Secret Mission.

Verify Kali VM connectivity

For the Secret Mission later in this project, your Windows host needs to communicate with your Kali VM over the VMnet8 network. Let's confirm both machines can reach each other.

Switch to your Kali Linux VM in VMware.
Verify the network adapter is set to NAT: click VM > Settings > Network Adapter and confirm NAT is selected.

Now find your Kali VM's IP address.

Open a terminal in Kali and find your VM's IP address by running this command:

ip addr show

Look for the inet address on the eth0 interface. It will be in the 192.168.x.x range (for example, 192.168.136.128). Note this IP down.

Next, find your Windows host's VMnet8 IP address.

Switch back to your Windows machine and open Command Prompt by pressing the Windows key, typing cmd, and pressing Enter.
Find your VMnet8 adapter IP by running:

ipconfig

Scroll through the output and find the section labelled VMware Network Adapter VMnet8. Note the IPv4 Address (typically 192.168.x.1).

Now test connectivity in both directions.

From your Windows Command Prompt, ping your Kali VM's IP by running:

ping [[KALI_IP="your Kali VM IP address"]]

You should see replies coming back with response times. Press Ctrl+C to stop the ping.
Switch to your Kali VM terminal and ping the Windows VMnet8 IP by running:

ping [[WINDOWS_VMNET8_IP="your Windows VMnet8 IP address"]]

You should see replies. Press Ctrl+C to stop.

What does a successful ping look like?

A successful ping shows lines like "Reply from 192.168.x.x: bytes=32 time<1ms TTL=64" on Windows, or "64 bytes from 192.168.x.x: icmp_seq=1 ttl=128" on Kali. Any response with a time value means the two machines can communicate.

Ping not getting replies?

Make sure your Kali VM's network adapter is set to NAT (not Bridged or Host-Only) in the VM settings.

If pinging from Kali to Windows fails but the other direction works, Windows Firewall may be blocking incoming ICMP. You can temporarily allow it or disable the firewall for testing. You will do this in the Secret Mission later.

Help me troubleshoot ping connectivity between my Windows host and Kali VM on VMware NAT.

Your packet capture environment is ready. Next up, you will generate real DNS traffic and dissect it packet by packet in Wireshark.

Capture and Analyse DNS Traffic

Your environment is ready and your Windows host can talk to your Kali VM. Now it is time to capture real traffic and see what is happening under the hood.

Every time you visit a website, your machine first asks a DNS server to translate the domain name into an IP address. In this step, you will capture that process live in Wireshark and break down exactly what each layer of the network is doing.

In this step, get ready to:

Capture live DNS traffic by running a lookup command while Wireshark records packets.
Filter and dissect DNS packets layer by layer in the Packet Details pane.
Understand the OSI encapsulation model and the DNS query/response pattern.

Start a capture and generate DNS traffic

To see DNS in action, you need Wireshark recording while you trigger a DNS lookup. The lookup translates a domain name into an IP address, and Wireshark will capture every packet involved.

In Wireshark, double-click your active network interface (Ethernet or Wi-Fi) to start a live capture. You will see packets streaming in the Packet List pane immediately.

Which interface do I pick?

Pick the interface with the activity sparkline graph on Wireshark's welcome screen. This is your active internet connection. Do not pick the VMnet8 interface for this step.

Switch to your Command Prompt window and generate a DNS lookup by running this command:

nslookup example.com

Return to Wireshark and click the red square button (Stop) in the toolbar to stop the capture.

You should see a list of captured packets in the Packet List pane. There will be many packets because your machine generates background traffic constantly.

Not seeing any packets?

Make sure you double-clicked the correct interface. If you picked one with no sparkline graph, it may be inactive. Close the capture (Capture > Stop), return to the welcome screen, and double-click the interface showing activity.

Help me figure out why Wireshark is not capturing packets on my Windows machine.

Filter and dissect DNS packets

Your capture contains hundreds of packets from all kinds of traffic. Display filters let you narrow the view to only the protocol you care about.

In the display filter bar at the top of Wireshark, type dns and press Enter.
The Packet List now shows only DNS packets. Look for a packet with "Standard query" in the Info column followed by the domain name example.com. This is your DNS query.
Click on that query packet. The Packet Details pane (middle panel) displays the packet broken down by protocol layer.
Expand each layer by clicking the arrow next to it. Examine these four layers from top to bottom:

Ethernet II (Layer 2): shows the source and destination MAC addresses.
Internet Protocol (Layer 3): shows the source IP (your machine) and destination IP (your DNS server).
User Datagram Protocol (Layer 4): shows the source port (an ephemeral high number) and destination port 53.
Domain Name System (Layer 7): shows the query name (example.com) and the query type (A record).

What is the OSI model?

The OSI model is a framework that divides network communication into seven layers. Each layer wraps (encapsulates) data from the layer above. What you see in Wireshark's Packet Details pane is this encapsulation in action.

Layer 2 handles physical addressing (MAC). Layer 3 handles logical addressing (IP). Layer 4 handles transport (UDP or TCP). Layer 7 handles the application protocol (DNS in this case).

Now find the response packet. Look for "Standard query response" in the Info column with example.com in the same row.
Click on the response packet and expand the Domain Name System layer.
Expand the Answers section inside it. You will see the resolved IP address(es) that the DNS server returned for example.com.

You have now traced a complete DNS resolution from query to answer at the packet level.

Don't see any DNS packets after filtering?

Make sure you typed dns (all lowercase) in the filter bar and pressed Enter. The filter bar turns green when the syntax is valid. If it turns red, check for typos.

If the filter is valid but shows zero results, your nslookup command may have run before the capture started. Start a new capture, then run nslookup example.com again while the capture is active.

Help me troubleshoot why my Wireshark DNS filter shows no results.

Understand what you observed

You just witnessed a full DNS resolution at the packet level. Here is what happened in the background.

What just happened?

Your machine asked "What is the IP address for example.com?" and the DNS server replied with the answer. This query/response pattern is how every website visit begins. Your browser does this automatically before it can load any page.

DNS uses UDP port 53 by default for queries. UDP is faster than TCP because it skips the connection setup. For short lookups like DNS, speed matters more than guaranteed delivery.

Each layer you expanded in the Packet Details pane represents one layer of the OSI model wrapping the layer above. This is called encapsulation. The DNS query (Layer 7) is wrapped in UDP (Layer 4), which is wrapped in IP (Layer 3), which is wrapped in Ethernet (Layer 2).

Why does this matter for security?

DNS traffic is unencrypted by default. Anyone capturing packets on the same network can see exactly which domains a machine is resolving. This is why DNS monitoring is a core technique for SOC analysts detecting malicious activity.

You have captured and dissected your first protocol. Next, you will dig deeper into how computers establish reliable connections using the TCP three-way handshake.

Dissect the TCP Three-Way Handshake

In the last step, you saw how DNS resolves a domain name to an IP address. That lookup is the first thing that happens when your machine needs to reach a server. But what happens next?

Before any actual data can flow, your machine and the server need to agree on a connection. TCP handles this through a three-way handshake: a quick three-packet exchange that says "I want to connect", "OK, let's connect", and "Confirmed." In this step, you will capture a real TCP handshake and inspect each packet.

In this step, get ready to:

Capture a TCP connection to a web server using curl.
Identify the SYN, SYN-ACK, and ACK packets that form the three-way handshake.
Follow a TCP stream to see the full conversation between your machine and the server.

Capture a TCP connection

To see a TCP handshake, you need to capture the moment a connection is established. You will make an HTTP request to a web server and watch the packets flow in Wireshark.

In Wireshark, click the blue shark fin icon in the toolbar to start a new capture on your active network interface (Ethernet or Wi-Fi).

Switch to your Command Prompt and generate a TCP connection by running this command:

curl http://example.com

What does this command do?

curl makes an HTTP request to example.com on port 80. This forces your machine to establish a brand new TCP connection, which is exactly what you want to capture.

Return to Wireshark and click the red square button in the toolbar to stop the capture.

You should see a list of captured packets in the Packet List pane. There will be a mix of protocols visible.

Not seeing any packets?

Make sure you started the capture before running the curl command. If you stopped the capture too early, start a fresh one and run the command again.

Also confirm you are capturing on the correct interface. Your active connection (Ethernet or Wi-Fi) should show a small activity sparkline on the Wireshark welcome screen.

Help me troubleshoot why Wireshark isn't capturing packets when I run curl.

Find and analyse the handshake

Your capture contains many packets from different sources. Display filters let you narrow down to exactly the traffic you care about.

Click in the display filter bar at the top of the Wireshark window.
Type tcp.flags.syn == 1 and press Enter.

What does this filter show?

This filter isolates all packets that have the SYN flag set. SYN packets are connection initiators. Every TCP connection starts with one.

Look for a packet in the list whose Info column shows a destination port of 80. That is your HTTP connection attempt to example.com.

Now you will follow the full TCP conversation so you can see all three handshake packets together.

Right-click the SYN packet going to port 80.
Select Follow > TCP Stream.
A window will open showing the full HTTP conversation in readable text. Close this window.

Wireshark automatically applies a new filter that shows only the packets belonging to this specific TCP conversation. You should now see a much shorter, focused list of packets.

Look at the first three packets in the stream. These are the three-way handshake:

Packet 1 (SYN): Your machine sends a TCP packet with the SYN flag set to the server. This says "I want to connect."
Packet 2 (SYN-ACK): The server responds with both the SYN and ACK flags set. This says "I acknowledge your request and I also want to connect."
Packet 3 (ACK): Your machine sends an ACK back. This says "Connection established."

Click on each of the three handshake packets one at a time.
In the Packet Details pane (middle panel), expand the Transmission Control Protocol section to see the flags for each packet.

What should I see in the flags?

For the first packet, you will see the SYN flag set to 1. For the second packet, both SYN and ACK flags are set to 1. For the third packet, only the ACK flag is set to 1.

Wireshark also labels these in the Info column as [SYN], [SYN, ACK], and [ACK] so you can spot them at a glance.

Can't find a SYN packet going to port 80?

If your filtered list shows SYN packets to other ports (like 443), your system may have redirected to HTTPS. Try running curl http://example.com again with a new capture. Make sure you type http:// (not https://).

Help me find my TCP handshake packets to port 80 in Wireshark.

Understand ports and the connection

Now that you have identified the handshake, look at the port numbers in the conversation. These reveal how TCP keeps track of who is talking to whom.

Click on the first SYN packet and look at the Transmission Control Protocol section in the Packet Details pane.
Note the Source Port on your machine. This is an ephemeral port, a high number (like 51520) that your operating system assigns temporarily.
Note the Destination Port: 80. This is the well-known port for HTTP.
Click through several other packets in the stream. Notice that every packet uses the same source and destination port pair throughout the entire conversation.

Why do ports stay the same?

TCP uses the combination of source IP, source port, destination IP, and destination port to identify a unique connection. Keeping the same port pair throughout ensures all packets in the conversation are matched to the right connection.

Scroll past the three handshake packets. You should see the HTTP GET request your machine sent and the server's response containing the webpage content.

Why does the handshake matter?

This three-way handshake happens before ANY data can be exchanged over TCP. It is how TCP guarantees reliable, ordered delivery. Without it, neither side would know the other is ready to communicate.

This is one of the most commonly asked interview questions for security roles. Being able to explain SYN, SYN-ACK, ACK from memory is expected.

You have just captured and identified one of the most fundamental patterns in networking. Next up, you will compare what happens when traffic is encrypted versus unencrypted by looking at HTTP and HTTPS side by side.

Compare HTTP and HTTPS Traffic

In the last step, you watched TCP establish a reliable connection through the three-way handshake. Now you know how a connection starts. The next question is: what actually travels through that connection once it is open?

In this step, you will capture both HTTP and HTTPS traffic and compare them side by side. HTTP sends everything in readable plain text. HTTPS encrypts it so no one can eavesdrop. The difference is dramatic.

In this step, get ready to:

Capture and inspect unencrypted HTTP traffic in plain text.
Capture encrypted HTTPS traffic and identify the TLS handshake.
Understand why encryption matters for security.

Capture unencrypted HTTP traffic

Every time you visit a website over plain HTTP, the request and response travel across the network as readable text. Anyone capturing packets on the same network can read everything. Let's prove it.

In Wireshark, double-click your active network interface (Ethernet or Wi-Fi) to start a new capture.
Switch to your Command Prompt and generate HTTP traffic by running this command:

curl http://example.com

Return to Wireshark and click the red square button in the toolbar to stop the capture.
In the display filter bar at the top, type http and press Enter.
Click on the HTTP GET request packet in the Packet List pane (top panel).
In the Packet Details pane (middle panel), expand the Hypertext Transfer Protocol section.

You can read the full request in plain text: the method (GET), the host (example.com), the User-Agent header. Everything is completely visible.

Right-click the GET packet and select Follow > TCP Stream.

A window opens showing the full HTTP conversation in readable text: the request headers your machine sent and the full HTML response from the server.

What should I see?

The TCP Stream window shows colour-coded text. Red text is what your machine sent (the GET request with headers like Host: example.com and User-Agent).

Blue text is what the server sent back: HTTP status code, response headers, and the full HTML of the page. Every byte is readable.

Close the TCP Stream window by clicking Close.

Not seeing any HTTP packets?

Make sure you started the capture before running the curl command. If you ran curl first, Wireshark missed the traffic. Start a new capture and run the command again.

If you see packets but the http filter shows nothing, check for typos in the filter bar. The filter must be lowercase http with no spaces.

help me troubleshoot why I'm not seeing HTTP packets in Wireshark after running curl http://example.com

Capture encrypted HTTPS traffic

Now let's see what happens when the same kind of request goes over HTTPS instead. TLS encryption wraps the data so only the sender and receiver can read it.

In Wireshark, click the blue shark fin icon in the toolbar to start a new capture.
Switch to Command Prompt and generate HTTPS traffic by running this command:

curl https://www.google.com

Return to Wireshark and click the red square button to stop the capture.
In the display filter bar, type tls and press Enter.

You should now see TLS handshake packets listed. Look for packets with "Client Hello" and "Server Hello" in the Info column.

What are Client Hello and Server Hello?

These are the first two messages of the TLS handshake that establishes encryption. The Client Hello is your machine announcing the TLS versions and cipher suites it supports.

The Server Hello is the server responding with the TLS version and cipher suite it picked. After this exchange, both sides negotiate encryption keys and all further data is encrypted.

Now change the display filter to tcp.port == 443 and press Enter.
Right-click any packet in the filtered results and select Follow > TCP Stream.

Unlike the HTTP capture, the stream content is completely unreadable. You will see garbled characters and random-looking bytes. This is the encrypted data.

Close the TCP Stream window.

Seeing no TLS packets?

Confirm you started the capture before running curl. The tls filter only shows packets that Wireshark actually captured during the HTTPS connection.

If you see TCP packets but not TLS, your Wireshark version might still use the older ssl filter name. In Wireshark 4.6.6 the correct filter is tls (the ssl filter was renamed in version 3.0).

help me troubleshoot why TLS packets are not showing in my Wireshark capture

Understand the security implications

You have now seen the same action (requesting a web page) over two different protocols. The difference in what a network observer can see is striking.

HTTP vs HTTPS: what can an eavesdropper see?

HTTP (port 80): all data travels in plain text. Anyone capturing packets on the same network can read everything: URLs, form data, cookies, credentials.
HTTPS (port 443): after the TLS handshake, all data is encrypted. Even with packet capture, the content is unreadable without the encryption keys.

What about the Server Name Indication (SNI)?

The TLS Client Hello packet does reveal the Server Name Indication (SNI), which shows which domain you are connecting to. This is why DNS queries and SNI are visible to network monitors even for encrypted traffic.

You can see the SNI by clicking the Client Hello packet in your capture and expanding the TLS section in the Packet Details pane. Look for the Extension: server_name field.

This is why security professionals insist on HTTPS everywhere. It prevents eavesdropping and tampering on the wire.

You have now seen firsthand why encryption matters at the packet level. Next up, you will save a comprehensive capture file and learn powerful display filters to isolate exactly the traffic you need.

Save Your Capture and Apply Advanced Filters

You have captured and dissected DNS, TCP, HTTP, and HTTPS traffic individually. Now it is time to bring everything together into a single comprehensive capture.

In this step, you will generate multiple types of traffic in one session, save it as a reusable file, and learn the display filters that let you slice through captured data like a pro.

In this step, get ready to:

Create a comprehensive capture containing DNS, ICMP, HTTP, and HTTPS traffic.
Save your capture as a .pcapng file for future reference.
Apply display filters to isolate specific protocols and traffic patterns.

Create a comprehensive capture to save

Instead of capturing one protocol at a time, you will now generate a mix of traffic in a single session. This gives you a rich capture file to practice filtering on.

Switch back to Wireshark and start a new capture by clicking the blue shark fin icon on your active network interface (Ethernet or Wi-Fi).
Switch to your Command Prompt window and generate DNS traffic by running this command:

nslookup google.com

Generate ICMP traffic by running:

ping google.com

Generate HTTP traffic by running:

curl http://example.com

Generate HTTPS/TLS traffic by running:

curl https://www.google.com

Wait about 30 seconds for the capture to collect background traffic as well, then switch back to Wireshark and click the red square button to stop the capture.

Why capture all of this together?

A single capture containing multiple protocols mirrors what you would see on a real network. Learning to filter through mixed traffic is the core skill that makes Wireshark useful in practice.

Save your capture by clicking File in the menu bar.
Click Save As.
Choose a location you can find easily (like your Desktop).
Name the file my_first_capture.pcapng and click Save.

What is a .pcapng file?

The .pcapng format is Wireshark's default capture file format. It is flexible and extensible, supporting features like packet comments. You can reopen this file anytime to practise analysis or share it with colleagues.

You should see the file appear at the location you chose.

Save option greyed out?

Make sure the capture is stopped (red square clicked) before saving. You cannot save while a capture is still running.

If the menu shows no packets, your interface selection may not have been active. Start a new capture on the interface with the activity sparkline.

Help me save my Wireshark capture file.

Practice display filters

Display filters are what make Wireshark powerful in real-world analysis. They let you narrow down thousands of packets to just the ones relevant to your investigation.

Click on the display filter bar at the top of the Wireshark window (it says "Apply a display filter" when empty).
Type the following filter and press Enter to show only DNS traffic:

dns

You should see only DNS query and response packets in the packet list.

Clear the filter bar and type this filter to show only initial SYN packets (connection attempts):

tcp.flags.syn == 1 && tcp.flags.ack == 0

Clear the filter and try this one to show only HTTP requests:

http.request

Try this filter to show only TLS Client Hello messages:

tls.handshake.type == 1

Filter for all traffic to or from a specific IP address (use one of the resolved IPs from your DNS results, such as 93.184.215.14 for example.com):

ip.addr == 93.184.215.14

Filter for all HTTPS traffic by port:

tcp.port == 443

Combine filters using && (AND) and || (OR). Try this to see both DNS and HTTP packets together:

dns || http

What do these filter operators mean?

The == operator checks for equality. The && operator means both conditions must be true. The || operator means either condition can be true.

These are the building blocks for every Wireshark investigation. In a security role, you would combine IP addresses, ports, and protocol flags to hunt for suspicious activity.

Confirm that each filter changes the visible packets in the packet list. The packet count in the status bar at the bottom updates as you apply each filter.

Filter bar turning red?

A red filter bar means the syntax is invalid. Check for typos, especially in operators like == (two equals signs, not one) and && (two ampersands).

If a filter returns zero results, it might be correctly typed but no matching packets exist in this capture. Try a broader filter first (like tcp) to verify packets are present.

Help me fix my Wireshark display filter.

Use statistics for a traffic overview

Filters let you drill into specific packets. Statistics give you the big picture of what is happening across the entire capture.

Clear any active display filter first (click the X button on the filter bar so all packets are visible).
Click Statistics in the top menu bar.
Click Protocol Hierarchy.

A window opens showing a tree of every protocol detected in your capture, with packet counts and byte percentages for each.

What does Protocol Hierarchy show me?

This view displays all protocols in your capture organised by their network layer. You can see at a glance what percentage of traffic is TCP vs UDP, how much is DNS, how much is TLS, and so on.

In a real security investigation, Protocol Hierarchy is often the first thing you check. It immediately reveals unexpected protocols that should not be on the network.

Close the Protocol Hierarchy window.
Click Statistics again in the top menu bar.
Click Conversations.
Select the TCP tab at the top of the Conversations window.

This shows every TCP connection in your capture: which hosts communicated, on which ports, and how much data was transferred. Click the Bytes column header to sort by data volume.

How would a SOC analyst use this?

Sorting by bytes transferred quickly identifies the heaviest connections. In a security incident, this reveals data exfiltration (unusually large outbound transfers) or command-and-control traffic (many small connections to the same IP).

You now have a saved capture file and the filtering skills to slice through network traffic. Next up, the Secret Mission challenges you to detect a real port scan from your Kali VM.

Secret mission

Detect a Port Scan from Your Kali VM

A SOC analyst's daily reality involves spotting malicious activity hidden in network traffic. In this bonus challenge, you'll launch an nmap port scan from your Kali VM and then detect its signature in Wireshark. This is exactly how analysts identify reconnaissance attacks in the wild.

Clean Up Your Resources

This project runs entirely locally with no cloud resources or paid services. There are no ongoing costs to worry about.

Decide whether to keep Wireshark installed for future practice or remove everything from your machine.

Resources you used:

Wireshark 4.6.6 installation on Windows (free, no ongoing cost).
Npcap installation (installed alongside Wireshark for packet capture).
Saved my_first_capture.pcapng capture file on your local disk.

Keep everything running

No action needed. Choose this if you plan to keep practising with Wireshark or want to revisit your capture files later.

Wireshark stays installed and ready to use from the Start Menu.
Your my_first_capture.pcapng file remains on disk for future analysis.
There are no running background services or ongoing costs.

Pause - I'll come back to this later

Since Wireshark has no background services or running processes, there is nothing to pause. This is functionally the same as Keep.

Close Wireshark if you have it open.
Your installation and capture files stay on disk until you choose to remove them.

Delete - I don't want to use this again

Remove all project resources from your machine. This frees up disk space but means you will need to reinstall Wireshark if you want to use it again.

Uninstall Wireshark: open Settings on Windows, then select Apps.
Search for Wireshark in the app list, click it, and select Uninstall.
Search for Npcap in the app list and uninstall it. Npcap was installed alongside Wireshark for packet capture and is no longer needed.
Delete your capture file. Navigate to the folder where you saved my_first_capture.pcapng and delete it.

Nice Work!

You just built a hands-on network traffic analysis lab from scratch. You can now capture live packets, dissect them layer by layer, and interpret what is happening on your network at the protocol level.

You've learned how to:

Capture and dissect real DNS, TCP, and HTTP/HTTPS traffic at the packet level, mapping each layer to the OSI model.
Identify the TCP three-way handshake (SYN, SYN-ACK, ACK) and compare encrypted versus unencrypted traffic to understand why TLS matters.
Apply Wireshark display filters to isolate specific protocols and save capture files for future analysis.
Secret Mission: Detected a port scan from a Kali VM by recognising the SYN flood pattern in Wireshark, simulating real SOC analyst threat detection.

Ready to quiz yourself?