Module 2 · Packet Analysis with Wireshark 🔒

In the last module you learned that networks use a layered protocol stack. This module is where you see that stack in action, byte by byte. If Networking Fundamentals taught you the vocabulary, Wireshark teaches you to read the language.

Every security skill that involves network traffic — detecting command-and-control beacons, decoding a broken TLS handshake, watching malware call home, reverse-engineering a binary protocol, investigating a breach — starts with packet capture. By the end of this module you will be able to:

• Capture packets on your own machine and read the protocols in them
• Filter captures to find the signal in the noise
• Extract objects (files, images, credentials) from captured traffic
• Spot common suspicious patterns (port scans, exfiltration, beaconing)
• Use tcpdump from the command line when Wireshark isn’t available

The two tools you will use

Wireshark — graphical packet analyser. Install from wireshark.org. Free, open source, cross-platform. Every security practitioner has it. Start here.

tcpdump — command-line packet capture. Pre-installed on every Linux/macOS system. Works over SSH where you can’t run a GUI. Captures into .pcap files that Wireshark then reads.

These two tools complement each other. You’ll use tcpdump on servers to capture, and Wireshark on your laptop to analyse.

The packet capture workflow

Every analysis follows the same four-step workflow:

1. Capture — record the raw packets hitting a network interface, either live or from a saved file
2. Filter — narrow the capture to the traffic you care about (out of thousands of packets, only 50 matter)
3. Decode — let Wireshark parse each packet’s layers (Ethernet → IP → TCP → HTTP)
4. Extract — pull out the specific evidence you need (a file, a password, a timestamp, a pattern)

First capture — walking through it

Open Wireshark. You’ll see a list of network interfaces (eth0, wlan0, lo, etc.). Double-click the active one. Wireshark starts recording every packet that enters or leaves that interface in real time.

Open a browser tab to http://example.com (plain HTTP, not HTTPS — we want to see the unencrypted traffic). Click around for 5 seconds. Go back to Wireshark. Stop capture (red square button).

You’ll see hundreds of packets. At the top of each is a one-line summary:

No.  Time     Source          Destination     Protocol  Length  Info
1    0.000    192.168.1.10    93.184.216.34   TCP       74      53410 → 80 [SYN] Seq=0 Win=64240
2    0.050    93.184.216.34   192.168.1.10    TCP       74      80 → 53410 [SYN, ACK] Seq=0 Ack=1
3    0.050    192.168.1.10    93.184.216.34   TCP       66      53410 → 80 [ACK] Seq=1 Ack=1
4    0.051    192.168.1.10    93.184.216.34   HTTP      459     GET / HTTP/1.1
5    0.107    93.184.216.34   192.168.1.10    HTTP      1332    HTTP/1.1 200 OK  (text/html)

Read the first four lines. What just happened?

• Line 1 — your machine sent a SYN to example.com on port 80 (the TCP 3-way handshake begins)
• Line 2 — example.com replied with SYN-ACK (server acknowledges)
• Line 3 — your machine sent ACK (handshake complete, connection established)
• Line 4 — your machine sent the actual HTTP GET request
• Line 5 — server sent back the HTML response

This is the foundation. Every TCP connection starts with SYN → SYN-ACK → ACK. If you ever see SYNs without the ACK response, something is wrong — either a firewall is dropping, the port isn’t listening, or you’re watching a port scan.

Display filters — the superpower

Wireshark’s filter bar is where novice users become intermediate. Ignore the capture-filter bar at startup — the display filter box above the packet list is what you’ll use 95% of the time. Some essentials:

Combine with and, or, not. Example: http and ip.src == 10.0.0.5 and http.request.method == "POST" — all HTTP POSTs originating from 10.0.0.5.

The layer view — understanding each packet

Click any packet. The middle pane expands into the protocol hierarchy:

▸ Frame 4: 459 bytes on wire
▸ Ethernet II, Src: xx:xx:xx (router), Dst: yy:yy:yy (laptop)
▸ Internet Protocol Version 4, Src: 192.168.1.10, Dst: 93.184.216.34
▸ Transmission Control Protocol, Src Port: 53410, Dst Port: 80
▸ Hypertext Transfer Protocol

Each triangle expands. Click Hypertext Transfer Protocol and you’ll see the full HTTP request — method, path, headers, body. This is the full content a server saw. You can copy the full HTTP request, paste it into curl, and reproduce it.

The bottom pane shows the same data as raw hex and ASCII. Useful when you need to see exact byte-level content — e.g. a binary protocol, a custom header encoding, or an obfuscated payload.

Five common analyses

1. Find credentials in cleartext traffic

Filter: http.request.method == "POST". Click any POST to a login endpoint. Expand HTTP → Form URL Encoded. Usernames and passwords appear in plaintext. This is why every login page must be HTTPS — over HTTP, credentials travel in readable form for any network observer.

2. Reconstruct a downloaded file

Filter: http.response. Right-click a packet carrying file content → Follow → HTTP Stream. You’ll see the full request/response. For binary files (images, PDFs, executables): File → Export Objects → HTTP. Wireshark extracts every file from the capture.

3. Identify a port scan

Filter: tcp.flags.syn == 1 and tcp.flags.ack == 0. Look at the Destination Port column. If you see one source IP hitting many different ports on the same destination in a short window — typical signature of a port scan. Tools like nmap generate this pattern.

4. Detect a DNS-based exfiltration

Filter: dns. Look for unusually long DNS subdomains. Normal: www.google.com. Suspicious: a7f3g2h8x9k1l4m2n6p3q8r5s1t9v.attacker.com. Attackers encode data into subdomain labels to smuggle it out past firewalls (because DNS is almost always allowed outbound). This is called DNS tunnelling.

5. Spot C2 beaconing

Statistics → I/O Graphs → Set up a filter for suspicious destination IP. A benign user’s traffic looks irregular — bursts and gaps. C2 beacons look rhythmic — small identical packets every 30 seconds, every 5 minutes, every hour. The regularity is the tell. Real users don’t click the refresh button exactly every 47 seconds.

tcpdump — the server-side tool

You SSH into a production server during an incident. There’s no GUI. You need a packet capture. tcpdump is your tool.

# List interfaces
sudo tcpdump -D

# Capture 100 packets on eth0, save to file
sudo tcpdump -i eth0 -c 100 -w /tmp/capture.pcap

# Capture only HTTP traffic
sudo tcpdump -i eth0 -c 100 -w /tmp/http.pcap 'tcp port 80'

# Capture everything to/from a specific IP
sudo tcpdump -i eth0 -w /tmp/target.pcap host 1.2.3.4

# Capture for 30 seconds, rotate the file every 10MB
sudo tcpdump -i eth0 -G 30 -w /tmp/cap-%Y%m%d-%H%M%S.pcap

# Print-only mode (human readable, no save)
sudo tcpdump -i eth0 -n -c 20

# Decode payload as ASCII too
sudo tcpdump -i eth0 -A -n -c 20 'tcp port 80'

Then transfer the pcap file to your laptop: scp user@server:/tmp/capture.pcap ~/Desktop/ — and open it in Wireshark locally.

Critical: tcpdump capture filters use BPF syntax (different from Wireshark display filters). Common BPF patterns:

• host 1.2.3.4 — traffic to or from this IP
• src 1.2.3.4 / dst 1.2.3.4 — only source or destination
• port 443 — traffic on this port
• tcp[tcpflags] == tcp-syn — SYN packets only
• not broadcast and not multicast — skip noise

Capturing securely

Two legal/ethical notes:

• Only capture on networks you own or have explicit authorisation on. Capturing packets on a network you don’t own can violate computer-misuse laws and workplace policies. On a pen-test engagement, “capture all traffic” is part of the scope of work signed with the client.
• Captures contain sensitive data. A production pcap has cookies, session tokens, potentially credentials, and personal data. Under DPDP, a pcap is a data store. Encrypt at rest. Delete when no longer needed. Don’t send over email or paste in Slack.

TLS — the thing you usually can’t see

Most modern traffic is TLS-encrypted. You’ll see only the encrypted handshake and then opaque bytes. But you can still extract signal:

• SNI (Server Name Indication) — the hostname the client asked for, sent before the TLS encryption fully starts. Filter: tls.handshake.extensions_server_name. This alone tells you every site a user is visiting.
• Certificate contents — the server’s cert is sent in clear. Issuer, subject, validity, SAN list. Useful for identifying a service even if the traffic itself is encrypted.
• JA3 / JA3S hash — a fingerprint of the client’s TLS handshake. Different TLS libraries (curl, Chrome, Firefox, Python requests, Cobalt Strike, various malware families) produce distinct JA3s. Advanced threat hunters use JA3 to identify malware even in encrypted traffic.
• Decryption in the lab — you can decrypt TLS if you have the session keys. Export SSLKEYLOGFILE from the client, load into Wireshark (Preferences → Protocols → TLS → Pre-Master-Secret log filename).

Wireshark gotchas

• Promiscuous mode on switched networks — modern Ethernet switches send only your own traffic to your port. On a switch, capturing other users’ traffic requires a SPAN port, a network TAP, or an ARP-spoofing attack (legal only in authorised testing)
• Capturing on lo (loopback) — if you want to see traffic between processes on the same machine (e.g. your app talking to localhost Postgres), capture on the loopback interface specifically
• Capturing all of /1 Gbit interface on a busy server — you’ll fill disk in minutes. Use narrow BPF filters from the start
• File size & performance — pcaps above a few hundred MB choke Wireshark. Use editcap to split: editcap -c 100000 big.pcap split.pcap
• Truncated packets — default snaplen may cut long packets. Use -s 0 in tcpdump to capture full size

The practice pcap — learn by looking

The Malware-Traffic-Analysis project (malware-traffic-analysis.net) publishes real-world malware pcaps with walkthroughs. Download one. Open in Wireshark. Try to answer: what was the attack? What did the attacker get? When? Over what protocol? Compare your answer to the published walkthrough. This one exercise, done weekly for 3 months, will turn you into a confident network analyst.

Quick reference summary

• Wireshark for GUI analysis; tcpdump for capture on servers
• 4-step workflow: capture → filter → decode → extract
• Display filters: http, dns, tls, ip.addr == x, tcp.port == x, frame contains "..."
• 3-way TCP handshake: SYN → SYN-ACK → ACK — the foundation
• File → Export Objects → HTTP — extract all downloaded files
• Follow → HTTP Stream — reconstruct a full request/response
• SYN-only from one source to many ports = port scan
• Long DNS subdomains = potential DNS tunnelling
• Rhythmic small packets = C2 beacon
• TLS: you still see SNI, certificates, JA3 fingerprints
• Legal: only capture on networks you own or are authorised to test
• DPDP: pcaps are personal-data stores — encrypt, retain with care

Take the quiz. Next module: Network Protocols Deep Dive — where we go beyond “TCP reliable, UDP not” into the actual internals of DNS, TLS, HTTP/2, and the quirks that attackers exploit in each.