Packet Analysis with Wireshark — From “Open the PCAP” to Diagnosing Real Incidents

Last updated: May 1, 2026

Wireshark looks intimidating because the default UI shows you 50 columns of mostly-irrelevant data. The trick is knowing which 6 you actually need and which 12 display filter expressions cover 90% of investigations. This module walks you from a fresh install to confidently diagnosing slow connections, broken TLS handshakes, ARP storms, and exfiltration attempts. We use the same captures Indian SOC teams analyse daily; PCAPs you can download appear at the end of the module.

Capture filter vs display filter — the difference that matters

These two filter types use different syntax and serve different purposes, and confusing them is the #1 beginner mistake. Capture filters use BPF (Berkeley Packet Filter) syntax — host 1.1.1.1, port 443, tcp port 80 or tcp port 443. They run in the kernel before packets reach Wireshark, so they decide which packets even hit disk. Use them for high-traffic captures where you cannot afford to record everything. Display filters use Wireshark’s expression syntax — ip.addr == 1.1.1.1, tcp.port == 443, http.request.method == "POST". They run inside Wireshark on already-captured packets, are infinitely more expressive, and can be changed at any time without losing data.

Rule of thumbcapture liberally (no filter), filter aggressively at display. Disk is cheap; the packet you did not capture is gone forever.

The 12 display filters every analyst must know cold

These cover 90% of investigations:

Reading a TCP three-way handshake (and what is wrong if you cannot)

Filter to tcp.flags.syn == 1 or tcp.flags.fin == 1 or tcp.flags.reset == 1 and you can see every connection attempt + close + reset on a capture. A clean handshake is three packets: SYN from client (Seq=0), SYN+ACK from server (Seq=0, Ack=1), ACK from client (Ack=1). What you might see instead —

SYN with no responsefirewall blocking, or the destination is dark.

SYN → RSTport closed, host alive.

SYN → SYN+ACK → RSTclient deliberately closing (port scan, half-open).

SYN → SYN+ACK → ACK → immediate RSTstateful firewall killed the session, or app crashed on accept. Each of these failure modes corresponds to a real production fault and a real attacker behaviour. Once you can identify them in a 30-second glance you are an intermediate analyst.

Following a stream — the productivity unlock

Right-click any TCP packet → “Follow” → “TCP Stream” reassembles the entire conversation into plain text (or hex if binary). For HTTP, this gives you the full request and response. For SMB, the file payload. For an SSH handshake, the algorithms negotiated. HTTP Object Export goes one step further: File → Export Objects → HTTP gives you every file transferred — useful in malware investigations for extracting downloaded payloads. There is also “Follow TLS Stream” which shows you encrypted bytes (useless) unless you have the session keys exported via SSLKEYLOGFILE environment variable from your browser; Wireshark then decrypts the entire session and shows plaintext (very useful for debugging your own traffic, do not do this on captures from people who have not consented).

Time analysis — finding the slow point in a chain

Right-click any packet → “Set/Unset Time Reference”. From there, the Time column shows seconds since that reference. Combined with tcp.stream eq N you can pinpoint exactly where in a multi-hop transaction the latency crept in. Even better: Statistics → Service Response Time → DNS / SMB / NFS gives you per-operation timing tables. The single most useful tool here is Statistics → IO Graph — plot throughput over time. A flat line punctuated by spikes means burstable traffic. A flat low line with packet loss markers in the same window means a saturated link. A sudden cliff means failover. Most “the network is slow” complaints are diagnosed in five minutes once you can read an IO Graph.

TLS — what you can see without decryption

Even encrypted, TLS gives you a lot. The Client Hello (filter: tls.handshake.type == 1) carries the SNI field — that is the destination hostname in plaintext, every time. The cipher suite list reveals which versions and algorithms the client supports. Server Hello (tls.handshake.type == 2) reveals the chosen cipher and (for TLS 1.2) the certificate chain. ALPN tells you whether HTTP/1.1, HTTP/2, or HTTP/3 was negotiated. TLS 1.3 hides certificates after the Server Hello (Module 10 covers this) but SNI is still visible — and increasingly Encrypted Client Hello (ECH) is being deployed to hide it too. Most “I cannot tell what this connection is” claims dissolve once you filter to tls.handshake.extensions_server_name and look at the SNI.

Capture hygiene — getting the right packets

Captures must be taken at the right place or the analysis is meaningless. On the host itself — easiest, you see only that host’s traffic, you miss anything that never reached the host. SPAN/mirror port on a switch — copies traffic to your capture port; standard for SOC visibility. TAP — physical hardware tap on a fibre or copper run, ideal for high-throughput links and forensics-grade work. Cloud — VPC Traffic Mirroring (AWS), packet capture on Azure NSG, GCP Packet Mirroring; each has cost and scale tradeoffs. Always capture both directions. Always include the link-layer (do not capture only IP). Always note the timezone and the capture point — a PCAP without that metadata is half-evidence.

Display filter cheat sheet — beyond the basic 12

Once the basic dozen are muscle memory, level up with these. tcp.flags == 0x14 = RST+ACK only (connection refused or middleware kill). tcp.analysis.zero_window = receiver out of buffer. tcp.analysis.duplicate_ack + tcp.analysis.fast_retransmission = packet loss diagnostic. http.user_agent contains "curl" = curl-shaped traffic. tls.handshake.extensions_server_name contains "salesforce" = SaaS inventory by SNI. dns.qry.name matches "[a-zA-Z0-9]{40,}" = high-entropy DNS labels (tunnelling). frame.len > 1500 = jumbo frames or IP fragmentation. icmp and not icmp.type in {0,3,8,11} = unusual ICMP. http.host != http.request.uri = mismatched host headers (smuggling). arp.opcode == 2 and arp.src.proto_ipv4 == 192.168.1.1 = unsolicited ARP for the gateway (poisoning). Print this list, tape it next to your monitor, retire it after a month when you no longer need it.

tshark — when Wireshark UI is the wrong tool

tshark is Wireshark’s CLI sibling — same dissectors, different ergonomics.

Real-world capture scenarios — three common SOC use cases

Scenario 1: “Why is the website slow for some users?” Capture at the LB egress; filter to tcp.analysis.retransmission or tcp.analysis.duplicate_ack; if you see them clustered by client subnet, it is a network problem to that subnet. Scenario 2: “Did this user exfiltrate data?” Filter to all flows from that user’s IP for the suspect window; sort by bytes; flag any flows >100 MB to non-corporate destinations; pivot to the destination IP and look up reputation. Scenario 3: “Why does this app fail intermittently?” Capture at app server; filter to the failed transaction’s timestamp; look at the TCP stream — RST mid-session, idle-timeout, certificate negotiation failure all show clearly.

The SOC reflexwhen Tier-1 escalates, do not look at logs first. Pull the relevant PCAP, filter to the time window, look at the stream. Logs say what the app thought happened; PCAP says what really happened on the wire.

Diagrams

Client                                                    Server
  | ----- SYN  Seq=0  ------------------------------------> |
  |                                                         |
  | <---- SYN+ACK  Seq=0  Ack=1  ------------------------- |
  |                                                         |
  | ----- ACK  Seq=1  Ack=1  ------------------------------>|
  |                                                         |
  |                  ESTABLISHED — data flows both ways     |
  |                                                         |
  | ----- FIN  ------------------------------------------->|
  | <---- ACK  -------------------------------------------- |
  | <---- FIN  -------------------------------------------- |
  | ----- ACK  ------------------------------------------->|
  |                       CONNECTION CLOSED                 |

  ┌─────────────────────────────┐
  │ Wire / Interface (kbps)     │   ← actual packets arriving
  └─────────────┬───────────────┘
                ▼
  ┌─────────────────────────────┐
  │ CAPTURE FILTER  (BPF)       │   ← decides what gets stored
  │   host 10.0.0.5   port 443  │     (cannot recover dropped)
  └─────────────┬───────────────┘
                ▼
  ┌─────────────────────────────┐
  │ Capture file (.pcapng)      │
  └─────────────┬───────────────┘
                ▼
  ┌─────────────────────────────┐
  │ DISPLAY FILTER (Wireshark)  │   ← decides what you SEE
  │   ip.addr == 10.0.0.5       │     (can be changed live)
  │   http.request.method=POST  │
  └─────────────────────────────┘

References & deeper reading

• Wireshark User's Guide
• Wireshark Display Filter Reference
• BPF (Capture Filter) syntax
• Sample captures (Wireshark wiki)
• Malware-Traffic-Analysis.net (free PCAPs)
• Tshark CLI manpage
• pktmon (Windows built-in)

FAQ

Wireshark or tcpdump?

tcpdump on the wire (small, ssh-friendly, lower overhead, scriptable), Wireshark on the desk (visual analysis, dissectors, statistics). The professional flow is: tcpdump captures into a rotating ring buffer on the production host, you copy a relevant slice down, you open it in Wireshark on a workstation. Capturing in Wireshark on a production server with X11 forwarding is something you only do once.

Is it legal to capture traffic on my company network?

In India, capture is permitted for authorised network management and security operations under the IT Act and your employee handbook. It is illegal under §43/§66 to capture traffic on a network you do not control or own without authorisation. DPDP Act 2023 layers privacy obligations: minimise capture scope, retain captures only as long as needed for the investigation, encrypt them at rest, and document the legitimate purpose.

Why is my capture missing packets?

Three usual culprits:

Can Wireshark decrypt TLS for me?

Yes if you have the keys. Either set the SSLKEYLOGFILE environment variable in Chrome/Firefox before the capture, or import the server’s RSA private key (only works for non-PFS ciphers — almost no modern site qualifies). On modern TLS 1.3 sites, only the SSLKEYLOGFILE path works. There is no magic packet decoder; if you do not have keys, you do not see plaintext.

How big should my capture buffer be?

For SOC monitoring, typical practice is 10-20 GB rolling per sensor, retaining 24-72 hours. For incident response, 7-30 days at sensor + perimeter. Size it as: average bandwidth × seconds you want to retain. A 100 Mbps link recording 24h = ~1 TB. Most teams under-size and discover too late that the packets they need rolled off two hours ago.

How do I capture only on one VLAN?

On the switch, mirror the VLAN to the SPAN port and capture there; or use a tagged trunk port + capture host with VLAN-aware NIC and filter vlan and vlan.id == 30. On Linux, vconfig add eth0 30 creates a VLAN-tagged sub-interface to capture from.

Why does my Wireshark not see all traffic?

Two common causes:

⚖️ Legal: Use any techniques described here only on networks you own or have explicit written authorisation to test. In India, unauthorised access is punishable under IT Act §66 (up to 3 years + fine). Pair offensive testing with a signed Statement of Work / Rules of Engagement; pair forensic activity with §65B-aligned chain of custody.