Kali Linux Ethical Hacking, Part 6: Reading Your Own Lab Traffic With Wireshark

Series: Kali Linux Ethical Hacking, Part 6. Previous: Part 5, keeping Kali healthy and updated. Earlier: Part 4, thinking like a defender.

You capture lab traffic safely by running tshark only on your Kali host only interface, with a capture filter for your own lab host and a ring buffer that caps disk use. You then generate traffic yourself, read it with display filters and statistics, check a fix from Part 4, and delete the capture files when you’re done.

First, the legal bit

Disclaimer: This post is for education and authorized security testing only. Capturing traffic on a network you don’t own or aren’t authorized to monitor may be illegal, as is accessing any computer, network or account without permission, including under India’s Information Technology Act, 2000 and similar laws in other countries. Only capture on networks you own, or where you have clear written permission from the owner before you start.

Everything here runs on your own Kali VM and your own lab host, lab-web-01, on the host only network from Part 1. Don’t capture on home Wi Fi, office networks or anyone else’s traffic.

Why should you learn to read packets in your own lab?

Nmap tells you what a host claims to offer. A packet capture shows what actually crossed the wire: every connection attempt, every reply, every reset. When you can read that, you can check your own scans, confirm fixes and spot noise.

My day job sits close to network detection and response, and from that side packets are the ground truth. Logs can be incomplete. A capture of your own lab, read calmly, settles most arguments about what really happened.

Which Wireshark and tshark versions are current?

Checked on 25 October 2026:

• Upstream: the Wireshark download page lists 4.6.9 as the stable release, with 4.4.19 as old stable and 5.0.0rc1 as a development release. The 4.6.9 release notes list security fixes, including wnpa-sec-2026-92, a ZigBee ZCL dissector crash.
• Kali: the Kali package tracker shows tshark and wireshark at 4.6.6-1 in kali-rolling, imported on 28 May 2026, with 4.6.9-1 already in kali-dev.

Dissector crash fixes are a good reason to keep Wireshark updated, since you are feeding it untrusted packets. The update routine in Part 5 covers that.

What do you need before you start?

• Your Kali VM with two adapters: NAT for updates, host only for the lab.
• lab-web-01 on the host only network running OWASP Juice Shop on port 3000, as in Part 1 and Part 3. The examples use 192.168.56.101 for lab-web-01. Replace it with your own address.
• A notes folder:

CAP=~/lab-notes/$(date +%F)/capture
mkdir -p "$CAP" && chmod 700 "$CAP"
cd "$CAP"

The chmod 700 keeps the folder readable only by you, because captures can hold sensitive data.

How do you set up capture safely on Kali?

Step 1: Install or check tshark

sudo apt update
sudo apt install -y tshark
tshark --version | head -1

Expected output (sample): TShark (Wireshark) 4.6.6 ... or newer. During install, Debian based systems ask whether non root users should be able to capture. Answer Yes.

Step 2: Let your user capture without root

Capturing is done by a small helper called dumpcap. Add yourself to the wireshark group so you don’t run the whole analyser as root:

sudo dpkg-reconfigure wireshark-common
sudo usermod -aG wireshark "$USER"

Choose Yes in the dialog, then log out and back in, and check:

groups | tr ' ' '\n' | grep wireshark

Expected output:

wireshark

Step 3: List interfaces and pick the host only one

tshark -D
ip -br addr

Expected output (sample):

1. eth0
2. eth1
3. any
4. lo (Loopback)

Match the names against ip -br addr. The interface with your 192.168.56.x address (often eth1) is the host only one. Never pick eth0, which leads to the outside world, or any.

Step 4: Start a filtered capture with a ring buffer

tshark -i eth1 -f "host 192.168.56.101" -b filesize:10240 -b files:5 -a duration:300 -w "$CAP/lab.pcapng"

What each part does:

• -i eth1 captures only on the host only interface.
• -f "host 192.168.56.101" is a capture filter: only packets to or from lab-web-01 are saved.
• -b filesize:10240 -b files:5 is a ring buffer: files of about 10 MB each, keeping only the newest five.
• -a duration:300 stops automatically after five minutes.

Expected output (sample): Capturing on 'eth1', then a packet counter that rises as traffic flows. Leave it running and open a second terminal.

How do you generate traffic you can read?

Step 5: Make some HTTP requests to Juice Shop

In the second terminal, go to the same notes folder first, then send the requests:

CAP=~/lab-notes/$(date +%F)/capture
cd "$CAP"
for i in 1 2 3; do curl -s -o /dev/null -w "%{http_code}\n" http://192.168.56.101:3000/; sleep 2; done

Expected output:

200
200
200

Step 6: Run the Part 2 smoke test

sudo nmap -sV --top-ports 20 192.168.56.101 -oA "$CAP/smoke"

Expected output: the familiar port table from Part 2. Now you’ll see what that scan looks like from the wire. Wait for the capture to stop, or press Ctrl+C in the first terminal.

How do you read the capture with display filters?

Step 7: Merge the ring buffer files

ls -l "$CAP"/lab_*.pcapng
mergecap -w "$CAP/lab-merged.pcapng" "$CAP"/lab_*.pcapng

Expected output (sample): one or more files named like lab_00001_20261025221500.pcapng, then a single merged file.

Step 8: Look at the HTTP requests

tshark -r lab-merged.pcapng -Y "http.request" -T fields -e frame.time_relative -e ip.src -e http.request.method -e http.request.uri

Expected output (sample):

0.512   192.168.56.102  GET  /
2.531   192.168.56.102  GET  /
4.549   192.168.56.102  GET  /

Those are your three curl requests. Some of Nmap’s -sV probes may show up too.

Step 9: Filter by port, then by SYN packets

tshark -r lab-merged.pcapng -Y "tcp.port==3000" | head -5
tshark -r lab-merged.pcapng -Y "tcp.flags.syn==1 && tcp.flags.ack==0" -T fields -e tcp.dstport | sort -n | uniq -c | head

Expected output (sample): the first command shows the start of the port 3000 conversations. The second counts connection attempts by destination port, and the first lines look like this:

      4 21
      4 22
      9 3000

Each line is one port the scan probed. This is what a defender sees when someone scans a host: a burst of SYNs across many ports from one address.

How do you use tshark statistics?

Step 10: Conversations and protocol hierarchy

tshark -r lab-merged.pcapng -q -z conv,tcp | head -15
tshark -r lab-merged.pcapng -q -z io,phs

Expected output (sample): a table of TCP conversations between 192.168.56.102 and 192.168.56.101, with frame and byte counts, then a protocol tree such as:

eth  frames:1450
  ip  frames:1450
    tcp  frames:1430
      http  frames:24

The conversation table shows who talked to whom and how much. The protocol hierarchy shows what the traffic was made of.

Step 11: Follow one stream and export HTTP objects

tshark -r lab-merged.pcapng -q -z follow,tcp,ascii,0 | head -30
mkdir -p "$CAP/objects"
tshark -r lab-merged.pcapng -q --export-objects http,"$CAP/objects"
ls "$CAP/objects" | head

Expected output (sample): the first command prints the first TCP stream as text, starting with a GET / request and the Juice Shop response headers. The export puts the files served over HTTP, such as the home page, into objects. Only do this with your own lab traffic.

How do you check a Part 4 fix in the packets?

In Part 4 you made a fix list. If one fix was to stop port 3000 answering on the lab network, for example by binding Juice Shop to 127.0.0.1 on lab-web-01, you can prove it with packets.

Step 12: Capture again after the fix

Terminal 1:

tshark -i eth1 -f "host 192.168.56.101 and tcp port 3000" -a duration:30 -w "$CAP/after-fix.pcapng"

Terminal 2:

curl -s -m 5 -o /dev/null -w "%{http_code}\n" http://192.168.56.101:3000/

Expected output after a working fix (sample): curl prints 000 because the connection failed. Then read the capture:

tshark -r "$CAP/after-fix.pcapng" -Y "tcp.flags.reset==1 || http" -T fields -e ip.src -e tcp.flags.str -e http.request.uri

192.168.56.101  ·······A·R··

A reset from lab-web-01 and no HTTP lines means nothing answers on port 3000 from the lab network. If a firewall on lab-web-01 drops the packets instead, you’ll see no reset and no HTTP lines, which also means port 3000 is closed to the lab network. If you still see HTTP requests and responses, the fix didn’t hold. Add the result to your Part 4 fix list with the file name as evidence.

How do you handle and delete captures safely?

Packet captures can hold passwords, cookies and private data from anything that crossed the interface, even in a lab. Treat them like secrets.

Step 13: Keep, hash or delete

Keep only what you need as evidence, hash it, and remove the rest:

cd "$CAP"
sha256sum after-fix.pcapng > after-fix.sha256
shred -u lab_*.pcapng lab-merged.pcapng
rm -rf objects
ls -l

Expected output (sample): only after-fix.pcapng, its hash file and your Nmap files remain. Never upload lab captures to public paste sites or AI chat tools, and never share a capture that includes someone else’s traffic.

What to do next

1. Run Steps 1 to 4 and confirm you can capture on the host only interface without root.
2. Generate your own traffic in Steps 5 and 6, then work through the filters in Steps 8 and 9.
3. Read the statistics in Step 10 and write one line on what the scan looked like on the wire.
4. Use Step 12 to check one fix from Part 4 and attach the capture as evidence.
5. Delete what you don’t need with Step 13.
6. Keep Wireshark current with the routine in Part 5.
7. For more open source network tools, browse my security GitHub repos roundup for October 2026.

Leave a comment

Cancel reply

Your email stays private. First-time comments are held for a quick review.

Comment *

Name *

Email *

Website

Save my name, email, and website in this browser for the next time I comment.