Reading Your First Wireshark Capture

The first time you open a packet capture, you get forty thousand rows and no idea which one matters. This is not a skill problem. Wireshark’s default view is deliberately unopinionated — it shows you everything it saw, in order, and leaves the judgement to you.

The way through is to stop reading packets and start asking questions. Here is the sequence that works on almost any capture.

Start with who, not what

Before touching a single packet, open Statistics → Conversations. Sort by bytes.

This one screen answers more questions than an hour of scrolling. You get every pair of endpoints that exchanged data, how much, and for how long. Nearly every investigation starts with one of three observations:

• One conversation dominates the byte count — that’s your file transfer, your backup, or your exfiltration.
• One host is talking to an unreasonable number of peers — that’s your scan, your P2P client, or your worm.
• A conversation is small but persistent, repeating on a steady interval — that’s a heartbeat, and heartbeats are how command-and-control channels stay alive.

Then open Statistics → Protocol Hierarchy. It tells you what the capture is made of by percentage. If you expected a web session and you’re looking at 60% DNS, you have already found something.

The filters worth memorising

Display filters are where Wireshark becomes usable. Six will carry you a long way.

ip.addr == 10.0.0.5              # everything to or from one host
tcp.port == 443                  # one service, both directions
http.request                     # just the requests, not the responses
dns                              # every lookup
tcp.flags.syn == 1 && tcp.flags.ack == 0    # connection attempts only
tcp.analysis.flags               # retransmits, resets, out-of-order

That last one is the underrated one. tcp.analysis.flags surfaces everything Wireshark thinks went wrong at the transport layer. If someone reports “the app is slow” and this filter lights up with retransmissions, the problem is the network and you can stop reading application logs.

Note the difference between capture filters and display filters — they use entirely different syntax and people lose hours to this. Capture filters (BPF, tcp port 443) decide what gets written to disk and are irreversible. Display filters (tcp.port == 443) only change what you’re shown. Capture broadly, filter narrowly.

Follow the stream

Right-click any packet in a TCP conversation and choose Follow → TCP Stream. Wireshark reassembles the whole exchange into readable text.

This is the single biggest jump from “looking at packets” to “reading what happened.” A scattered sequence of segments becomes an HTTP request and its response, or an SMTP conversation, or a plaintext protocol cheerfully handing over credentials.

For anything TLS, you’ll get ciphertext — which is the point. But you still learn a lot from the handshake, which is not encrypted. The Client Hello carries the SNI field, telling you which hostname the client asked for even though you can’t read the traffic. Filter for it directly:

tls.handshake.extensions_server_name

On an encrypted capture, SNI plus the Conversations view is often the entire investigation.

DNS is the cheapest narration you’ll get

If you only have time to look at one protocol, look at DNS. It is usually unencrypted, it is low volume, and it tells you the intent behind every connection that follows.

dns.flags.response == 0          # queries only

Read down the list of queried names. This is a plain-language log of what the host was trying to reach. Things worth a second look:

• Very long, high-entropy subdomain labels — a common shape for DNS tunnelling, where data is smuggled inside the query name itself.
• The same domain queried on a rigid interval, forever.
• A burst of lookups for algorithmically generated names, most of which fail. That’s a client hunting for whichever domain its operator registered this week.

Habits that save you

Set your time display to something useful. View → Time Display Format → Seconds Since Previous Displayed Packet. Suddenly gaps and intervals are obvious, which is exactly what you need for spotting beacons.

Add columns for what you’re hunting. Right-click any field in the detail pane → Apply as Column. Chasing TLS? Add the SNI field as a column and scan hundreds of connections at a glance.

Save your filters. The bookmark icon at the left of the filter bar stores named filters. Build a small personal library rather than retyping.

Mind what a capture doesn’t contain. A capture from one host shows that host’s traffic. A span port on one switch shows that segment. Absence of evidence in a pcap is very frequently just absence of visibility, and this is the mistake that most often produces a confidently wrong conclusion.

A practice run

Capture thirty seconds of your own machine doing something ordinary — load a news site. Then, in order:

1. Protocol Hierarchy. What is this traffic actually made of?
2. Conversations, sorted by bytes. Who did you really talk to?
3. Filter to dns.flags.response == 0. How many third parties did one page pull in?
4. Filter to tls.handshake.extensions_server_name. Do those hostnames match the site you thought you visited?

Step four is where most people have their first genuine “oh” moment about the modern web. Once you can read that much, a hostile capture is the same four steps with different answers.