Wireshark Interface
Wireshark is the primary tool for interactive PCAP analysis. Knowing the interface deeply — the three panes, display vs capture filters, coloring rules, and the difference between what you see and what the network actually sent — makes the difference between a 10-minute triage and a 3-hour fumble.
You've opened a 2 GB PCAP. There are 4.3 million packets. Without a plan, you're lost. With the right Wireshark setup — custom columns showing the fields you care about, coloring rules that make suspicious traffic visually obvious, a saved display filter that instantly isolates C2 candidates, and the I/O graph showing the attack timeline — you can orient to the full capture in under 5 minutes and identify the key sessions in under 20.
Three-Pane Interface
Wireshark Interface Layout ═══════════════════════════════════════════════════════════════════ ┌─────────────────────────────────────────────────────────────────┐ │ Toolbar: Open / Save / Capture / Filter toolbar │ │ Display Filter Bar: [ tcp.flags.syn==1 and not tcp.flags.ack ] │ ├─────────────────────────────────────────────────────────────────┤ │ Packet List Pane (top 60% of screen) │ │ # Time Source Destination Protocol Len Info │ │ 1 0.000 10.0.1.50 185.220.101.47 TCP 74 49812→443 │ │ 2 0.021 185.220.101.47 10.0.1.50 TCP 74 443→49812 │ │ 3 0.021 10.0.1.50 185.220.101.47 TCP 66 ACK │ │ ... │ ├─────────────────────────────────────────────────────────────────┤ │ Packet Details Pane (middle 25%) │ │ ▼ Frame 1: 74 bytes on wire │ │ ▼ Ethernet II: Src: 00:11:22:33:44:55 │ │ ▼ Internet Protocol Version 4: Src: 10.0.1.50 Dst: 185... │ │ ▼ Transmission Control Protocol: Src Port: 49812 Dst Port: 443 │ │ ▼ Flags: 0x002 (SYN) │ │ ... 0 = ACK not set │ │ ... 1 = SYN set │ ├─────────────────────────────────────────────────────────────────┤ │ Packet Bytes Pane (bottom 15%) │ │ 0000 00 11 22 33 44 55 66 77 88 99 aa bb 08 00 45 00 │ │ 0010 00 3c a1 b2 40 00 80 06 ... │ └─────────────────────────────────────────────────────────────────┘ Click a field in the Details pane → corresponding bytes highlight in the Bytes pane AND the display filter populates with that field. Right-click a field → "Apply as Column" adds it to the Packet List.
Capture Filters vs Display Filters
| Capture Filter | Display Filter | |
|---|---|---|
| When applied | During live capture — before packets hit disk | After capture — to packets already in memory/file |
| Syntax | BPF (Berkeley Packet Filter) — host 1.2.3.4 | Wireshark display filter language — ip.addr == 1.2.3.4 |
| Effect of no match | Packet is DISCARDED — permanently lost | Packet is HIDDEN — still in the file, can be shown again |
| Protocol decoding | Limited — BPF only sees raw bytes and L3/L4 headers | Full — can filter by HTTP host, TLS SNI, DNS query, etc. |
| Performance | Very fast — kernel-level filtering | Slower on large files — all packets must be decoded first |
| Error on wrong syntax | Hard error — capture won't start | Red background in filter bar — filter not applied |
Capture filters use BPF syntax: host 1.2.3.4, tcp port 443. Display filters use Wireshark's own language: ip.addr == 1.2.3.4, tcp.port == 443. They look similar but are completely different: host 1.2.3.4 is not a valid display filter and will turn the bar red; ip.addr == 1.2.3.4 is not a valid capture filter and will fail to start the capture. The display filter bar turns green for valid syntax and red for invalid. The capture filter dialog shows a warning for invalid BPF. Learn both syntaxes as separate languages — there is no overlap.
Coloring Rules for Attack Traffic
Coloring rules for forensics work (Edit → Coloring Rules):
Priority 1 (highest — RED background, white text):
Name: TCP RST
Filter: tcp.flags.reset == 1
Purpose: Immediately visible connection resets and RST injections
Priority 2 (ORANGE background, black text):
Name: SYN Scan Candidate
Filter: tcp.flags.syn == 1 and not tcp.flags.ack == 1
Purpose: All SYN packets — scanning activity visible immediately
Priority 3 (YELLOW background):
Name: Large Transfer
Filter: frame.len > 1400
Purpose: Large packets suggest file transfers or exfiltration
Priority 4 (LIGHT BLUE background):
Name: DNS
Filter: dns
Purpose: Separate DNS traffic for tunneling analysis
Priority 5 (GREEN background):
Name: Retransmission
Filter: tcp.analysis.retransmission or tcp.analysis.fast_retransmission
Purpose: Network issues or IPS dropping packets
Priority 6 (PURPLE background):
Name: TLS Handshake
Filter: ssl.handshake
Purpose: New TLS session initiations — connection establishment events
Priority 7 (DARK RED background):
Name: TCP Experts
Filter: tcp.analysis.flags and not tcp.analysis.retransmission
Purpose: Wireshark expert information (window zero, etc.)
Import coloring rules: Edit → Coloring Rules → Import
Export for sharing: Edit → Coloring Rules → ExportCustom Column Layouts
Default Wireshark columns are not optimized for forensics.
Add these columns: Edit → Preferences → Columns → +
Recommended forensics column set:
Frame # → %m (frame number for reference)
Rel. Time → %t (seconds since capture start — use for timeline)
Abs. Time → %Yt (absolute UTC timestamp — essential for reports)
Source IP → %s (source address)
Dest IP → %d (destination address)
Src Port → %uS (source port)
Dst Port → %uD (destination port)
Protocol → %p (highest protocol decoded)
Length → %L (frame length in bytes)
Stream # → %q (tcp.stream or udp.stream — for follow stream)
Info → %i (default info column)
For TLS analysis, add:
TLS SNI → field: tls.handshake.extensions_server_name
TLS JA3 → field: tls.handshake.ja3 (requires JA3 plugin)
Right-click any column header → Hide/Remove/Resize
Right-click a field in Details pane → Apply as Column (fastest way to add)
Save your column set: Edit → Profiles → New
Save as "Forensics" profile — load it at the start of every investigationMarking, Ignoring, and Time References
| Action | Keyboard shortcut | Forensic use |
|---|---|---|
| Mark packet | Ctrl+M | Mark key evidence packets for later reference or export |
| Ignore packet | Ctrl+D | Exclude known-benign traffic from view without deleting from file |
| Set time reference | Ctrl+T | Set a specific packet as time=0 for relative timing from that event |
| Find packet | Ctrl+F | Search by display filter, hex string, or regex across all packets |
| Go to packet | Ctrl+G | Jump to specific frame number |
| Follow TCP stream | Ctrl+Alt+Shift+T | Reconstruct full conversation for the selected stream |
| Export marked packets | File → Export Specified Packets | Save only the evidence packets to a new PCAP |
Wireshark's protocol dissectors interpret every packet and present human-readable fields. This is extremely useful but occasionally misleading. Wireshark may identify a packet as "HTTP" based on port 80 even if the content is something else; it may show "SSL" for TLS 1.3 traffic; it will label a retransmission even if the original wasn't captured. Always verify critical interpretations against the raw bytes in the Bytes pane — right-click a field and "Show packet bytes" to see exactly what bytes correspond to that field. For unknown protocols or malformed traffic, the Bytes pane is your ground truth. Dissectors can be wrong; raw bytes cannot.
Q & A
Q: My PCAP has 4 million packets. Wireshark is too slow to filter interactively. What do I do?
For large PCAPs (>500 MB), interactive Wireshark filtering is painful. Better approaches: (1) Pre-filter with tshark: use tshark to extract just the time window and IPs you care about into a smaller PCAP: tshark -r big.pcap -Y "ip.addr==185.220.101.47" -w small.pcap. Then open small.pcap in Wireshark. (2) Use Arkime: Arkime indexes metadata and lets you search and download only the sessions you need — you only load relevant sessions into Wireshark, never the full 4M packet file. (3) Use tshark statistics first: tshark -r big.pcap -z conv,tcp -q gives you top talkers in seconds without rendering the full packet list. Identify the interesting sessions, note their src/dst, then filter to just those in a second tshark pass. (4) SSD matters: if Wireshark is reading from a spinning disk, moving the pcap to SSD reduces load time from minutes to seconds for multi-GB files.