Wireshark for Security Analysts: The Filters and Workflows That Actually Matter

Image: network packet capture wireshark analyst screen

—

Wireshark is installed on more security analyst machines than almost any other tool and actively used on fewer. Most practitioners open it, watch packets scroll by, feel vaguely overwhelmed, and close it. The gap between “Wireshark is on my machine” and “I can actually use Wireshark to investigate incidents” comes down to about twenty display filters and three or four specific workflows.

This is those filters and workflows.

The Mental Model: What Wireshark Is Actually For

Wireshark captures and decodes network traffic at the packet level. It is not an IDS, it is not a SIEM, and it is not a traffic analysis tool in the same sense as Zeek or Arkime. What it does exceptionally well: take a PCAP file (or live capture) and let you inspect exactly what is happening at the protocol level on a specific network connection or during a specific time window.

The use cases where Wireshark is the right tool:

• Protocol-level investigation: You know something weird is happening on the wire and you want to see exactly what bytes are being exchanged
• Malware traffic analysis: A suspicious process is making network connections; you captured a PCAP; what is it doing?
• Incident reconstruction: Something happened on the network; you have a capture; reconstruct the session
• Detection rule development: You want to write a Snort/Suricata rule or a Sigma detection; you need to understand exactly what the traffic looks like

Essential Display Filters

Display filters are Wireshark’s superpower. Without them, a busy network capture is unreadable. With them, you can isolate exactly the traffic you care about in seconds.

The syntax is field operator value. Multiple filters chain with && (AND), || (OR), and ! (NOT).

Isolate a specific host:

ip.addr == 192.168.1.100

Shows all traffic to or from that IP. Refine with ip.src or ip.dst for directional filtering.

Isolate a conversation between two hosts:

ip.addr == 192.168.1.100 && ip.addr == 10.0.0.50

Filter by protocol:

http
dns
tls
smb
ftp

Protocol names alone are valid filters. tls shows all TLS-encrypted traffic; http shows cleartext HTTP.

DNS queries for suspicious domains:

dns.qry.name contains "suspicious"
dns.flags.response == 0

The second filter shows only DNS questions (not responses) — useful for tracking what a host is looking up.

HTTP requests only (not responses):

http.request

Pairs with http.request.method == "POST" to find data exfiltration candidates — POST requests, especially to external IPs, are worth examining.

Large HTTP responses (potential data exfiltration):

http.response && frame.len > 10000

TLS certificate inspection:

tls.handshake.type == 11

This catches Certificate messages in TLS handshakes, letting you inspect the certificate being presented — useful for identifying self-signed or suspicious certificates on encrypted connections.

SMB traffic (lateral movement / file share access):

smb || smb2

Look for smb2.cmd == 5 (Create — file open/create requests) with unusual paths or to unusual destinations.

Non-standard ports for common protocols:

http.request && tcp.port != 80 && tcp.port != 8080 && tcp.port != 443

HTTP traffic on non-standard ports is a common indicator of C2 or tunneling.

ICMP (ping sweeps, tunneling):

icmp

Combine with data.len > 100 to catch ICMP tunneling — legitimate ping payloads are tiny; tunneling exfiltration payloads are large.

Beaconing pattern detection (requires time reference):
Wireshark can’t directly detect statistical patterns, but you can filter for repeated connections to a single destination:

ip.dst == [suspected_c2_ip]

Then use Statistics → Conversations to see the timing pattern of connections.

Key Workflows

Workflow 1: Follow a TCP Stream

When you’ve found a suspicious connection, right-click any packet in that conversation → Follow → TCP Stream. This reconstructs the entire session as human-readable text (for cleartext protocols) or as a hex/data view (for binary protocols). For HTTP, FTP, SMTP, or any cleartext protocol, this immediately shows you the full request and response without packet-by-packet reading.

For HTTPS/TLS, Follow Stream shows encrypted data — not useful without the session keys. See TLS decryption below.

Workflow 2: Export HTTP Objects

Analysis → Export Objects → HTTP. For any HTTP session, this extracts files transferred (executables, documents, archives, scripts) and lets you save them for analysis. When investigating malware delivery or data exfiltration via HTTP, this is frequently the first step.

Workflow 3: TLS Decryption with Session Keys

Modern browsers (Chrome, Firefox) and some other applications support logging TLS session keys to a file specified by the SSLKEYLOGFILE environment variable. If you set this variable before capturing, Wireshark can use the log to decrypt TLS traffic in the PCAP.

export SSLKEYLOGFILE=/tmp/tls-keys.log
firefox &

In Wireshark: Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename → point to the key log file. Reload the capture. HTTPS sessions will now decrypt to cleartext HTTP.

This doesn’t work for all TLS traffic (only sessions from the process that wrote the key log), but for browser traffic analysis it’s invaluable.

Workflow 4: Protocol Statistics and Conversation Analysis

Statistics → Protocol Hierarchy shows the breakdown of protocols in the capture by packet count and bytes. Unusual protocol proportions — a lot of DNS relative to HTTP, a lot of ICMP, unexpected protocols — stand out here immediately.

Statistics → Conversations shows all unique conversations in the capture, sortable by bytes transferred. The conversations with the highest byte counts from an endpoint of interest are the ones worth examining first.

Statistics → Endpoints shows every IP, MAC, or other address seen in the capture with total traffic volume. New, external endpoints that appear during a suspicious time window are investigation targets.

Workflow 5: PCAP Time-Slicing

If you have a large PCAP and know the approximate time of the incident, slice it: File → Export Specified Packets → set a display filter or packet range. Working with a smaller, targeted PCAP is significantly faster and less error-prone than working the full capture.

Practical Malware Traffic Analysis Example

The workflow for analyzing a PCAP from a suspected malware infection:

1. Protocol Hierarchy — What’s in here? Unusual protocols or proportions?
2. Conversations by bytes — What external IPs are receiving the most data from the infected host?
3. Filter for DNS — What domains is the host resolving? Domain names give context that IPs don’t.
4. Filter for HTTP requests — What is the host fetching or sending?
5. Export HTTP objects — Any files transferred? What kind?
6. Follow TCP streams on suspicious connections — What is actually being communicated?
7. TLS inspection — If traffic is encrypted, can you get session keys? If not, what do the TLS certificates reveal?

The combination of these steps reconstructs what malware is doing on the network with remarkable completeness, even for moderately sophisticated samples.

Command-Line Wireshark: tshark

For automation, scripting, or remote capture, tshark is Wireshark’s command-line equivalent. Everything Wireshark does graphically, tshark does in a terminal.

# Capture live traffic to a file
tshark -i eth0 -w /tmp/capture.pcap
# Apply display filter on a PCAP
tshark -r capture.pcap -Y "http.request"
# Extract specific fields as CSV
tshark -r capture.pcap -T fields -e ip.src -e ip.dst -e http.request.uri -Y "http.request"
# Count connections per destination IP
tshark -r capture.pcap -T fields -e ip.dst | sort | uniq -c | sort -rn | head 20

The field extraction capability makes tshark useful for feeding Wireshark analysis results into other tools — grep, awk, Python scripts, or SIEM ingest pipelines.

Things Wireshark Won’t Tell You

A few important limitations to keep in mind:

• Encrypted traffic stays encrypted without session keys or a man-in-the-middle position. TLS 1.3 with forward secrecy can’t be decrypted retroactively even with a server private key — only session keys work.
• Large captures are slow. A multi-gigabyte PCAP will bring Wireshark to its knees. Use tshark to pre-filter and slice before opening in the GUI.
• Host context is missing. Wireshark shows what’s on the wire; it doesn’t show which process generated it. Combine with endpoint telemetry (process creation logs, Sysmon) for full context.
• It’s not a timeline. Wireshark’s time display is capture-relative by default. For correlation with event logs, convert to absolute timestamps.

Wireshark rewards investment. The first hour of learning display filters pays dividends across every packet capture you’ll ever touch. The goal isn’t to read every packet — it’s to know which filters to apply to find the packets that tell the story. That’s a learnable skill, and the ones above are where to start.