Reading Packets with Wireshark

Every attack and every defense eventually comes down to packets. Wireshark lets you see them. Once you can read a capture, you stop guessing what a tool did and start knowing.

Only capture traffic on networks you own or have permission to monitor. On shared networks, capturing other people’s traffic can be illegal even if you never use it.

Capture filters versus display filters

Wireshark has two filter languages, and mixing them up is the most common beginner frustration.

	Capture filter	Display filter
When it applies	Before packets are saved	After, on what you captured
Syntax	BPF, like tcpdump	Wireshark’s own field syntax
Example	host 192.168.56.10 and port 80	ip.addr == 192.168.56.10 && http
Mistake cost	Packets you filtered out are gone	None, change it any time

Rule of thumb: capture broadly, then filter on display. Only use capture filters when traffic volume forces you to.

Display filters worth memorizing

http.request                         # every HTTP request
http.response.code >= 400            # errors, often interesting
dns.qry.name contains "corp"         # DNS lookups for internal names
tcp.flags.syn == 1 && tcp.flags.ack == 0   # connection attempts, shows scans
tcp.analysis.retransmission          # network trouble
frame contains "password"            # cleartext credentials in a lab
tls.handshake.extensions_server_name # which sites TLS clients asked for
!(arp || dns || icmp)                # hide the background noise

The last one is the most useful filter nobody tells you about. Strip the chatter first, then look at what’s left.

Follow the conversation

Right-click any TCP packet and choose Follow > TCP Stream. Wireshark reassembles the whole conversation, client in one color and server in another. For HTTP, FTP, SMTP, or Telnet in a lab, you’ll read the session exactly as the two machines saw it.

Then try Statistics > Conversations and Statistics > Protocol Hierarchy. Within ten seconds you know who talked to whom, how much, and over what. Analysts start every investigation here.

See your own scan

The best way to learn is to watch your own tools:

1. Start a capture on your lab’s host-only interface.
2. From your attack VM, run nmap -sS 192.168.56.10 against a lab target.
3. Stop the capture and apply tcp.flags.syn == 1 && tcp.flags.ack == 0.

You’ll see a wall of SYN packets to different ports from one source in a second or two. Now you know exactly what an intrusion detection system sees, and why scans are so easy to spot.

TLS hides content, not everything

Encrypted traffic still leaks:

• Server Name Indication in the TLS ClientHello shows the hostname being visited.
• DNS queries often go out in cleartext before the encrypted connection starts.
• Timing, size, and destination reveal a lot about what an application is doing.

To decrypt your own browser’s TLS in a lab, set the SSLKEYLOGFILE environment variable before launching the browser, then point Wireshark at that file under Preferences > Protocols > TLS.

Practice captures

• Malware-Traffic-Analysis.net publishes real captures with exercises and answers. Treat them as hazardous: open them only in your analysis VM.
• Wireshark’s sample captures wiki covers nearly every protocol.
• CyberDefenders and Blue Team Labs Online turn captures into investigation challenges.

Takeaway

When a tool behaves oddly, capture it. Ten minutes in Wireshark answers questions that an hour of reading documentation will not.