You Open Wireshark. 40,000 Packets Appear. Now What?

The first time I opened a real packet capture in Wireshark, I froze.

Not because the tool is difficult to install. Not because the interface is broken, though it is genuinely not pretty. I froze because 40,000 packets were scrolling down the screen and every single one looked equally important and equally meaningless.

Nobody talks about that moment. Tutorials teach you filters. They explain TCP handshakes. They hand you a list of commands and send you off. What they do not tell you is what to do in the first 60 seconds when a real capture is open, a real alert is fired, and someone is waiting on your answer. This is that guide.

What Wireshark Is Actually Doing

Before the filters make any sense, the concept has to make sense.

Every device on a network constantly sends and receives small packets of data. Think of it like a postal system where every letter gets broken into pieces, each piece travels separately, and the receiving end reassembles them in order. Wireshark sits in the middle of that postal system and photographs every single piece going past.

The result is a .pcap file, short for packet capture. It is a recording of everything that happened on a network during a specific window of time. Open one in Wireshark and you see the full picture: every protocol, every connection, every handshake between machines.

That is genuinely powerful. It is also completely overwhelming until you have a methodology for where to look first.

The First 60 Seconds: Do Not Touch the Packet List

Here is the mistake almost every beginner makes. They open Wireshark and immediately start scrolling through the packet list, reading each line, trying to spot something suspicious. That approach fails at 200 packets. It is hopeless at 40,000.

The correct approach is to not look at the packets first. Look at the statistics.

Wireshark has a Statistics menu at the top of the screen. This is where every triage begins. Before filtering anything, before following a single stream, you go here.

Click Statistics, then Protocol Hierarchy. This tells you what percentage of the entire capture is HTTP, DNS, TCP, ARP, and everything else. If 60 percent of the capture is DNS traffic and you were not expecting that, you have found your first lead before reading a single packet. Normal networks do not look like that.

Then go back to Statistics, click Conversations, and select the IP tab. This shows which two IP addresses exchanged the most traffic. Sort by bytes transferred. The top result tells you where most of the data went. In a normal environment, high-volume conversations happen between known internal machines and known servers. An unfamiliar external IP moving large amounts of data is worth investigating before you read anything else.

This orientation phase takes under two minutes. It tells you where to look before you start looking. That sequence matters more than any filter.

Reading One Specific Attack: The Port Scan

Once you know where to point your attention, filters make the investigation fast.

A port scan is one of the most common things you will encounter in a real capture, and one of the most recognisable once you understand the signature.

When a scanner probes a host, it sends a SYN packet, which is the first part of a normal TCP connection request, to hundreds of different ports in rapid succession. If a port is closed, the target replies with RST-ACK, meaning nothing is running there. If a port is open, it replies with SYN-ACK, meaning something is listening. The attacker collects those responses and builds a map of which services are exposed.

In Wireshark, this pattern is unmistakable. One source IP, hundreds of destination ports, mostly RST-ACK responses, all happening within seconds. To find it, type this filter:

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

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

This shows every packet that is a SYN without an ACK attached, which is the opening move of a scan. If hundreds of these appear from the same source IP hitting dozens of different destination ports in a short window, you are looking at reconnaissance.

For confirmation, go to Statistics, then Conversations, then the TCP tab and sort by packet count. A scanner generates hundreds of one-packet conversations from the same source to different ports. That pattern does not appear in normal traffic.

The Filter That Removes the Noise

Packet captures contain enormous amounts of background traffic that is completely normal and completely uninteresting. ARP broadcasts, routine DNS lookups, ICMP pings. These fill the screen and make it harder to see what matters.

One filter removes most of it immediately:

!(arp || dns || icmp)

!(arp || dns || icmp)

The exclamation mark means "not." This hides everything that is ARP or DNS or ICMP. What remains is the application-layer traffic, the HTTP requests, the TCP connections, the actual conversations between machines. This is the first triage filter on any capture where I am not sure what I am looking at.

From there, you narrow. If you suspect malware communicating with an external server, you look for outbound HTTP requests at suspiciously consistent intervals. A legitimate browser session fires requests when a person clicks something. An implant checking in with its operator fires them like clockwork, every 30 or 60 seconds, regardless of what the user is doing.

The filter that surfaces that pattern:

http.request && frame.time_delta < 30

http.request && frame.time_delta < 30

This shows HTTP requests separated by less than 30 seconds. Humans are irregular. Malware is not. That rhythm in the packet list is the tell.

One Practical Thing to Do Today

If Wireshark is not installed, install it now. It is free. Then go to the Wireshark Wiki sample captures page and download any .pcap file from the list. These are real captures of real traffic, including several with attack patterns already in them.

Open the file. Do not touch the filter bar. Go to Statistics, Protocol Hierarchy, and write down what you see. Then go to Statistics, Conversations, IP tab, sort by bytes, and write down the top talker.

You just ran a triage. It took four minutes. It is the same first step a SOC analyst takes when an alert fires at 2am.

The filters matter. The methodology matters more. Learning to run the orientation phase before touching the filter bar is the thing that separates someone who uses Wireshark from someone who can actually read a capture.

The 40,000 packets are not all equally important. The statistics tell you which hundred actually are.

What is the first attack pattern you want to be able to spot in a capture? Drop it in the comments and I will give you the exact filter.