Learning Wireshark: From Packet Capture to Practical Packet Analysis

I recently completed two TryHackMe rooms — Wireshark: The Basics and Wireshark: Packet Operations — and they gave me a much better understanding of what Wireshark actually does beyond simply displaying packets.

Before working through these rooms, it was easy to look at a Wireshark capture and see thousands of packets without knowing where to start. After working through the exercises, I started to see packet analysis differently: the important skill isn’t just reading packets; it’s knowing how to narrow down the traffic, identify the protocol involved, and extract meaningful information from the capture.

In this post, I want to share some of the things I learned, particularly around Statistics, packet filtering, protocols, and display filters.

Starting with Wireshark

Wireshark is a network protocol analyzer that allows us to capture and inspect network traffic.

A packet capture can contain a huge amount of information:

Source and destination IP addresses

Source and destination ports

Protocols

Packet length

TCP flags

DNS queries

HTTP requests

TLS traffic

ARP traffic

ICMP messages

And much more

The challenge is that a large capture can quickly become overwhelming.

That’s where Wireshark’s filtering and analysis capabilities become extremely useful.

Instead of manually going through every packet, we can ask Wireshark questions such as:

— Show me only DNS traffic.

— Show me packets coming from this IP address.

— Show me TCP packets.

— Show me traffic going to port 443.

— Show me packets containing a particular piece of information.

This is where I started understanding the real value of Wireshark.

Understanding Protocols Through Packet Analysis

One of the most important things I learned was how protocols appear within packets.

A packet isn’t simply “a TCP packet” or “a DNS packet.” Network communication involves multiple layers of protocols working together.

For example, when a DNS request is made, we might see something like:

Ethernet → IP → UDP → DNS

This helped me understand something that initially confused me:

DNS is an Application Layer protocol, but it can use UDP.

DNS defines what information is being exchanged, such as a domain-name query and its response.

UDP, on the other hand, provides the transport mechanism used to carry that DNS data.

So these aren’t competing classifications.

They operate at different layers.

For example:

Application Layer
        ↓
       DNS
        ↓
Transport Layer
        ↓
       UDP
        ↓
Network Layer
        ↓
       IP
        ↓
Data Link Layer
        ↓
     Ethernet

Looking at packets in Wireshark made this relationship much easier to understand because I could actually see the protocols nested inside one another.

Statistics: Getting a Bigger Picture

One feature I found particularly useful was the Statistics menu.

When analyzing a capture, it’s useful to first understand the overall traffic before focusing on individual packets.

Instead of immediately examining packet number 1, 2, 3, and so on, Statistics allows us to step back and ask:

→ What is happening in this capture overall?

Depending on the capture and Wireshark version, the Statistics section provides different ways to summarize the traffic.

Some particularly useful areas include:

1. Protocol Hierarchy

The Protocol Hierarchy provides a breakdown of the protocols present in the capture.

This is useful because it quickly answers questions such as:

• What protocols are being used?
• Which protocols appear most frequently?
• Is the capture mostly TCP or UDP?
• Is DNS present?
• Is HTTP present?
• Are there protocols I wasn’t expecting?

Instead of looking at thousands of packets individually, I can get an overview of the protocol composition of the capture.

2. Conversations

The Conversations view helps identify communication between endpoints.

For example, it can show conversations between:

192.168.1.10  →  8.8.8.8
192.168.1.10  →  142.250.x.x
192.168.1.15  →  192.168.1.1

This becomes useful when trying to understand who is communicating with whom.

It can also help identify unusual communication patterns or endpoints worth investigating further.

3. Endpoints

The Endpoints statistics provide another useful perspective.

Instead of focusing on conversations, I can look at the individual network endpoints participating in the capture.

This can help answer:

→ Which IP addresses are involved in this traffic?

For security analysis, this can be a useful starting point for identifying suspicious or unexpected hosts.

Packet Filtering: Finding the Needle in the Haystack

One of the biggest lessons from the Packet Operations room was that filtering is essential.

Imagine opening a PCAP containing 50,000 packets. Going through them one by one isn’t practical. Instead, we can filter the capture. Wireshark essentially gives us a way to tell it:

→ “Only show me packets that match this condition.”

For example:

ip.addr == 192.168.1.10

This displays packets where the IP address is involved in the communication.

We can also filter by source or destination:

ip.src == 192.168.1.10

or

ip.dst == 192.168.1.10

This distinction is important.

ip.src asks:

Who sent the packet?

while ip.dst asks:

Who is receiving the packet?

Filtering by Protocol

We can also filter traffic based on protocol.

For example:

tcp

shows TCP traffic.

udp

shows UDP traffic.

dns

shows DNS traffic.

http

shows HTTP traffic.

And:

icmp

shows ICMP traffic.

This is extremely useful when investigating a specific protocol.

For example, if I am investigating DNS activity, instead of looking through all the TCP, UDP, ARP, ICMP, and other packets, I can simply use:

dns

Now the packet list becomes much easier to analyze.

Combining Filters

Filters become much more powerful when combined.

For example:

dns && ip.addr == 192.168.1.10

This means:

→ Show DNS packets involving 192.168.1.10.

We can also use conditions such as:

tcp.port == 443

to look at TCP traffic involving port 443.

Get Siri’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Or:

ip.src == 192.168.1.10 && tcp

which narrows the results to TCP traffic originating from that IP address.

This is where filtering starts becoming an investigative tool rather than simply a convenience.

Display Filters vs. Packet Capture Filters

One distinction I found important is the difference between capture filters and display filters.

Capture Filter

A capture filter controls what gets captured in the first place. It is applied while capturing traffic.

If I tell Wireshark to capture only certain traffic, packets that don’t match the capture filter aren’t collected.

Display Filter

A display filter is applied after the packets have already been captured.

The packets remain in the capture, but Wireshark only displays the ones matching the filter.

For example:

dns

doesn’t delete the non-DNS packets.

It simply hides them from the current view.

This distinction is important because display filters allow us to experiment with the captured traffic without losing information from the PCAP.

Packet Details: Going Inside a Packet

Another thing I became more comfortable with was the Packet Details section.

When selecting a packet, Wireshark breaks it down into protocol layers.

For example, a packet might look conceptually like:

Frame
 └── Ethernet
      └── IP
           └── UDP
                └── DNS

Each section can be expanded to reveal more information.

For an IP packet, I can investigate things such as:

• Source IP
• Destination IP
• TTL
• Protocol
• Header information

For TCP:

• Source port
• Destination port
• Sequence number
• Acknowledgment number
• TCP flags
• Window size

For DNS:

• Query name
• Query type
• Response
• Answers

This layered view helped connect the theoretical networking concepts I had learned with what actually happens on the wire.

Packet Bytes: Seeing What Is Actually Being Transmitted

The Packet Bytes section was another interesting part of the process.

Instead of only looking at Wireshark’s decoded representation, we can see the actual packet data in hexadecimal and ASCII representations.

This is useful because Wireshark is interpreting the raw bytes for us.

For example, a packet may contain:

48 65 6c 6c 6f

which corresponds to:

Hello

This helped me understand the relationship between:

raw bytes → protocol interpretation → human-readable information

It also explains why Wireshark provides options such as searching for strings, hexadecimal values, and regular expressions.

Searching Through Packets

Another useful feature is packet searching.

Instead of filtering the entire capture using a protocol expression, I can search for specific content.

For example, I might search for:

username

or a specific hexadecimal value.

Wireshark provides different search types, including:

• Display filter
• Hex value
• String
• Regular expression

These serve different purposes.

A string search is useful when looking for readable text.

A hex search is useful when looking for specific byte patterns.

A regular expression becomes useful when the information I’m looking for follows a particular pattern rather than being an exact string.

This can become very useful when investigating a large PCAP for a particular piece of evidence.

Why Display Filters Matter So Much in Security

This was probably one of my biggest takeaways from these rooms.

A packet capture is essentially a large collection of network evidence.

The challenge isn’t necessarily obtaining the evidence.

The challenge is finding the relevant evidence.

Display filters allow us to turn a massive capture into a much smaller investigation.

For example:

dns

Find DNS activity

dns.qry.name

Focus on DNS query information

http.request

Focus on HTTP requests

tcp.flags.syn == 1

Investigate TCP SYN packets

ip.addr == x.x.x.x

Investigate a particular host

Each filter changes the question we’re asking of the capture.

What I Took Away From These Two Rooms

The biggest change for me wasn’t memorizing Wireshark commands.

It was learning how to approach a packet capture systematically.

Instead of:

“There are thousands of packets. Where do I even start?”

I can now think more like:

1. What protocols are present?
2. Which endpoints are communicating?
3. What type of traffic am I interested in?
4. Can I narrow the capture with a display filter?
5. What does the packet structure tell me?
6. Is there useful information in the packet contents?
7. Is there anything unusual that deserves further investigation?

That shift in thinking makes Wireshark much less intimidating.

Final Thoughts

Completing Wireshark: The Basics and Wireshark: Packet Operations on TryHackMe gave me hands-on experience with a tool that I had previously approached mostly from a theoretical perspective.

The most useful concepts I took away were:

Statistics → help understand the overall capture.

Protocols → help understand how communication is structured.

Packet filtering → reduces thousands of packets to relevant traffic.

Display filters → allow targeted investigation of captured packets.

Packet details → show how different protocol layers work together.

Packet bytes → provide visibility into the underlying raw data.

Most importantly, I learned that Wireshark isn’t just a tool for “looking at packets.”

It is a tool for asking questions about network traffic and using the packets as evidence to answer those questions.

And that’s what makes packet analysis so interesting.