Wireshark for Network Analysis: A Practical Guide from the Trenches

Grab a coffee. Let’s talk about Wireshark.

If you’re in cybersecurity—or even just IT—you’ve probably opened Wireshark at least once. Maybe you saw a wall of colorful packets and thought, “Well, that’s neat,” then closed it. I get it. Wireshark is powerful, but that power comes with a learning curve.

After years of penetration testing, I’ve learned that Wireshark isn’t just about capturing packets—it’s about asking the right questions. It’s about knowing what “normal” looks like so you can spot what isn’t.

Let me walk you through how I actually use Wireshark in the field. No fluff, no academic theory—just practical skills you can apply today.

1. Capturing Traffic Effectively

Before you can analyze anything, you need to capture it. And I’ve seen too many people capture everything, drowning in gigabytes of noise. Don’t be that person.

Choose the Right Interface

This sounds obvious, but I’ve watched people capture on the wrong interface for 20 minutes before realizing it. Fire up Wireshark, and you’ll see a list of interfaces with live traffic graphs. The one with activity is probably where you want to be.

For wireless analysis, use wlan interfaces. For wired, it’s usually eth0 or similar. On Windows, you’ll see friendly names like “Ethernet” or “Wi-Fi.”

Capture Filters: Your First Line of Defense

Here’s where most people mess up. Capture filters reduce what gets written to disk—use them before hitting Start. They use BPF (Berkeley Packet Filter) syntax, which is different from Wireshark’s display filters.

Some captures I use constantly:

host 192.168.1.100                    # Only traffic to/from this IP
net 192.168.1.0/24                    # Entire subnet
port 80 or port 443                   # Web traffic only
not port 22                           # Ignore SSH (when I'm tunneled in)
tcp port 3389                         # RDP sessions
host 10.0.0.5 and port 445           # SMB to specific host

During a pentest, if I’m monitoring traffic between a compromised machine and the target network, I’ll filter out my own management traffic:

not host <my_ip> and not port 22

This keeps the capture clean and saves disk space.

Promiscuous and Monitor Modes

Promiscuous mode means your NIC grabs all packets on the wire, not just those addressed to you. You almost always want this—it’s enabled by default when you start capturing in Wireshark.

But for wireless, you need monitor mode. This captures all Wi-Fi frames in the air, including management frames, Beacons, and data from networks you’re not connected to. On Linux, use airmon-ng start wlan0 before capturing. On macOS, it’s built into Wireshark’s interface options.

Ring Buffers for Long Captures

Running a long capture? Enable a ring buffer. You can set it to rotate files every 100 MB or every 60 minutes. This prevents a single massive file that takes forever to load. Configure it under Capture → Options → Output.

I used this during a week-long APT hunt. We captured everything, rotated hourly, and only analyzed files during active hours. Saved us from drowning in 500 GB of packets.

2. Essential Display Filters for Analysis

Once you’ve captured traffic, display filters are where the magic happens. They’re Wireshark’s query language—and they’re completely different from capture filters. Learn both, or you’ll be confused.

Display filters use a different syntax and can inspect deep into packet contents. Here are my go-to filters:

IP and Network Filters

ip.addr == 192.168.1.100              # Traffic to OR from this IP
ip.src == 10.0.0.5 && ip.dst == 10.0.0.10  # Specific conversation
ip.ttl < 10                           # Suspicious: short TTL (possible tunnel)
ip.flags.df == 1                      # Don't Fragment flag set

Protocol Filters

tcp                                    # All TCP traffic
udp                                    # All UDP
dns                                    # DNS queries and responses
http                                   # HTTP traffic
tls                                    # Encrypted traffic (HTTPS handshake)
icmp                                   # Pings and unreachable messages
smb || smb2                           # SMB file sharing
kerberos                               # Authentication traffic

Port and Service Filters

tcp.port == 443                       # HTTPS port (any direction)
tcp.dstport == 3389                   # Inbound RDP
udp.port == 53                        # DNS traffic
tcp.flags.syn == 1 && tcp.flags.ack == 0  # SYN packets (new connections)
tcp.flags.reset == 1                  # RST packets (abnormal terminations)

HTTP and Application Filters

http.request.method == "POST"         # Form submissions, uploads
http.response.code == 401             # Unauthorized responses
http.host contains "malware"           # Suspicious domains
http.user-agent contains "curl"        # Scripted requests
http.request.uri contains "login"      # Login pages

DNS Analysis Filters

dns.qry.name contains "update"         # Possible C2 domain
dns.qry.type == 1                      # A record queries
dns.flags.response == 0                # Queries only (not responses)
dns.qry.name.len > 50                  # Unusually long domain names

Combine and Refine

You can chain filters with && (AND), || (OR), and ! (NOT):

http && ip.addr == 192.168.1.50        # HTTP to/from this host
tcp.port == 443 && tls.handshake.type == 1  # TLS Client Hello
dns && !ip.addr == 192.168.1.1         # DNS NOT involving the DNS server

Pro tip: Right-click any packet field → “Apply as Filter” → “Selected” to instantly filter on that value. This is faster than typing for common values.

Another pro tip: After building a filter you like, hit the + button in the filter toolbar to save it. I have dozens saved—my “SYN Floods” filter, “DNS Exfil” filter, and others are one click away.

3. Following TCP Streams and Sessions

Here’s something I use every single day: Follow TCP Stream.

When you’ve filtered down to a conversation, right-click any packet and select “Follow → TCP Stream.” Wireshark reassembles the entire conversation and shows you the application-layer data—all the packets reassembled in order.

This is game-changing for:
– Reading HTTP requests and responses
– Seeing clear-text authentication (FTP, Telnet, basic HTTP auth)
– Analyzing malware communication
– Understanding application behavior

What You’ll See

The stream opens in a separate window. Traffic from one direction (usually the initiator) appears in red, and the other direction in blue. You can toggle “Show data as” between ASCII, EBCDIC, Hex Dump, C arrays, or YAML.

For HTTP, you’ll see the full request and response headers plus bodies (if unencrypted). For FTP, you’ll see commands and responses. For cleartext protocols, this is where you’ll find credentials.

Practical Example: Captured Credentials

During one pentest, I captured a developer FTP session. Following the stream showed:

USER devops_team
PASS SuperSecretPassword123!
CWD /var/www/html
TYPE I
PASV
STEL config.php

Game over. That password worked on their SSH server, admin panel, and internal Git.

Follow Other Streams

You can also follow:
– UDP streams: Useful for DNS, RTP (VoIP), and custom protocols
– TLS stream: Shows handshake and decrypted traffic (if you have the session keys)
– HTTP stream: Similar to TCP stream butHTTP-aware

Session Statistics

Wireshark can also show conversation statistics. Go to Statistics → Conversations. You’ll see tabs for Ethernet, IP, TCP, and UDP. This shows bytes transferred, packet counts, and duration.

I use this to:
– Identify the top talkers on a network
– Spot asymmetry in connections (could indicate spoofing)
– Find long-lived connections that shouldn’t exist

4. Detecting Malicious Traffic Patterns

Alright, let’s get into threat hunting. This is where Wireshark becomes a defensive weapon.

Traffic Baselines Matter

First, you need to know what normal looks like. On any network, there’s baseline patterns: DNS queries to local resolvers, HTTP/HTTPS to web servers, SMB to file servers, LDAP to domain controllers.

When you see deviations, that’s when you investigate.

Red Flags I Hunt For

Beaconing (C2 Communication)

Malware often “phones home” at regular intervals. Look for:
– Consistent timing between connections (every 60 seconds, on the dot)
– Similar packet sizes every time
– Connections to unusual ports (443 is common for blending in, but also sketchy destinations)
– TLS handshakes without expected SNI domains

Use Statistics → IO Graphs to visualize connection timing. Set the X-axis to time and filter to a suspicious IP. Regular spikes = possible beacon.

DNS Anomalies

DNS exfiltration is real. Attackers encode stolen data in subdomains. Watch for:
– Unusually long domain names (<base64-encoded-junk>.attacker.com)
– Many queries to domains that don’t exist (NXDOMAIN responses)
– Queries to dynamic DNS domains (.dyndns.org, .no-ip.com)
– High volume of TXT record queries

Filter for: dns && dns.qry.name.len > 50

I once saw DNS queries that were 200+ characters long, each containing encoded data. It was data exfiltration through DNS.

Port Scans

If you see a flood of SYN packets to many ports on one host, that’s a port scan:

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

You’ll see a ton of different destination ports from the same source.

Alternatively, if you see one host trying to connect to many different IPs on the same port, that’s a network sweep. I’ve seen worms that scan for open SMB ports across entire /16 subnets.

Cleartext Credentials

Check for cleartext auth on:
– FTP (tcp.port == 21)
– Telnet (tcp.port == 23)
– HTTP Basic Auth (http.authorization contains “Basic”)
– IMAP/POP3 (tcp.port == 143 || tcp.port == 110)

If you’re still seeing cleartext credentials in 2026, that’s a problem.

Suspicious User-Agents

HTTP traffic often includes a User-Agent header. Watch for:
– curl, wget, python-requests when you don’t expect automation
– User-Agents that don’t match your organization’s browsers
– Empty User-Agents
– History referring domains that don’t exist

Statistical Analysis

Wireshark’s Statistics menu is underrated:
– Protocol Hierarchy: Breakdown of traffic by protocol. If you see 40% DNS, something’s wrong.
– Conversations: Who’s talking to whom. Look for top talkers and unusual pairs.
– Endpoints: Summary of each host’s traffic. Spot compromised hosts.
– IO Graphs: Visualize throughput over time. Great for spotting spikes.

5. Practical Hunting Scenarios

Let me walk you through three real scenarios I’ve encountered.

Scenario 1: “Something’s Wrong with the Network”

A client called saying their network was slow. Nothing obvious on the firewall logs.

I mirrored their core switch port and captured 5 minutes of traffic.

Step 1: Protocol Hierarchy showed 60% of traffic was ARP.

Step 2: Filtered arp and found one host sending thousands of ARP requests per second.

Step 3: That host was a misconfigured printer with a looping network discovery process.

The fix: Update the printer firmware and configure it correctly. Network latency dropped by 80%.

Scenario 2: Compromised Host

During an IR engagement, we suspected a workstation was compromised. I captured traffic from that host.

Step 1: Filtered ip.addr == <suspect_host>.

Step 2: IO Graph showed regular spikes every 300 seconds to an external IP on port 443.

Step 3: Followed the TLS stream. The handshake looked normal, but the SNI was for a domain registered 2 weeks prior with no WHOIS data.

Step 4: Checked VirusTotal—the domain was flagged as C2 for a known banking trojan.

Step 5: Quarantined the host, found malware in AppData\Roaming, cleaned it up.

The regular beaconing pattern was the dead giveaway. Normal traffic doesn’t phone home like clockwork.

Scenario 3: Insider Threat

A company suspected an engineer was exfiltrating data. They had DLP, but nothing triggered.

I set up a capture on their internal gateway.

Step 1: Captured 24 hours, used ring buffers every 100 MB.

Step 2: Filtered http.request.method == "POST" && http.host contains "cloud".

Step 3: Found large POST requests to a cloud storage service that wasn’t company-approved.

Step 4: Followed TCP streams. The engineer was uploading source code in chunks overnight.

Step 5: The filenames were visible in the HTTP requests (not TLS-encrypted destination, ironically).

They confronted the engineer, who admitted to planning to join a competitor. Legal handled the rest.

Bonus Tips from the Field

Colorizing Traffic

Wireshark’s default coloring is okay, but I’ve customized mine:
– Black background for TCP RST packets
– Bright red for known malicious IPs (I use ip.addr filters in Wireshark’s coloring rules)
– Green for HTTP 200 OK responses
– Yellow for DNS queries

Go to View → Coloring Rules to customize. It helps you spot anomalies at a glance.

GeoIP Lookups

Wireshark can resolve IPs to approximate locations. Enable it under Edit → Preferences → Name Resolution → MaxMind GeoIP database paths.

This is useful for spotting traffic to unusual countries. If your network only operates in North America but you see traffic to Eastern Europe, that’s worth investigating.

Decrypting TLS Traffic

If you’re analyzing your own clients or servers, you can decrypt TLS traffic by:
1. Exporting session keys from the browser/app (SSLKEYLOGFILE environment variable)
2. Configuring Wireshark to use those keys (Preferences → Protocols → TLS → (Pre)-Master-Secret log filename)

This lets you see decrypted HTTP/2, API calls, and more. Invaluable for debugging and security testing.

Extracting Files

Wireshark can extract files from captured traffic. Go to File → Export Objects → HTTP or SMB.

I’ve recovered malware samples, exfiltrated documents, and phishing payloads this way. Just be careful—extracted files can be malicious.

Bringing It All Together

Wireshark is a Swiss Army knife. It can be overwhelming at first, but focus on these fundamentals:

1. Capture smart: Use capture filters, ring buffers for long captures, and choose the right interface and mode.

2. Filter ruthlessly: Learn display filter syntax. Save useful filters. Filter to the signal, not the noise.

3. Follow streams: Reassemble conversations for cleartext protocols. Read the application data.

4. Hunt patterns: Know your baseline. Look for beaconing, DNS anomalies, scans, and cleartext credentials.

5. Use statistics: IO Graphs, Protocol Hierarchy, and Conversations tell stories that packet lists can’t.

Before I wrap up, here’s the truth: packet analysis is part science, part art. The more you do it, the more you’ll develop an intuition. You’ll start seeing patterns without consciously looking for them.

So go practice. Capture traffic on your own network. Break things on purpose and see what the packets look like. Run a port scan (with permission!) and watch it in Wireshark. Browse a test site over HTTP (not HTTPS) and follow the stream.

The packets don’t lie. Learn to read them, and you’ll see everything that happens on your network—both good and bad.

Now finish that coffee, fire up Wireshark, and start hunting.

This guide is part of the acefortis.com cybersecurity blog. I’m mrakashkumar.in—a pentester who’s spent too many hours staring at packet captures. If you found this useful, share it with someone learning the ropes. Questions? Hit me up.