Master Wireshark for incident response — navigating the Protocol Hierarchy and Conversations views to orient quickly in an unfamiliar capture, writing precise display filters to isolate attack traffic, following TCP streams to read application-layer conversations in full, identifying DNS tunnelling by subdomain entropy, extracting transferred files for malware triage, and building a complete IOC list from a single PCAP file.
Wireshark and PCAP Analysis
Wireshark is the world's most widely used network protocol analyser. It captures network packets and displays them in a human-readable format, allowing analysts to inspect every byte of network traffic. In incident response, PCAP analysis reveals exactly what happened on the wire — credentials, data exfiltration, C2 communication, and lateral movement — often with evidence that cannot be obtained from any other source.
Unlike log analysis, which shows what systems reported, packet capture shows what actually crossed the network. Logs can be tampered with; packets captured in transit at a TAP or SPAN port cannot be retroactively altered. For the full case for network forensics as a tamper-resistant evidence source, see the Network Forensics learn page — this page focuses on the Wireshark tooling itself.
Orienting in a New PCAP — The First Three Steps
Opening a large PCAP file to a scroll of thousands of packets with no context is a common analyst experience. Three Statistics views cut through this immediately and tell you what the capture contains before you look at a single packet in detail.
- Statistics → Protocol Hierarchy: Shows the percentage breakdown of all protocols in the capture. An unexpected 15% DNS when DNS is usually 1-2% signals anomalous DNS activity. HTTP when all legitimate traffic should be HTTPS is immediately suspicious. This view answers "what's in this capture?" in 10 seconds.
- Statistics → Conversations: Shows the top talkers — pairs of hosts by total bytes transferred. The largest conversations are usually the most relevant to the incident. An internal host sending 6.9 GB to an external IP will be at the top of this list.
- Statistics → Endpoints: All unique IP addresses seen, sorted by bytes. External IPs with high byte counts are C2 or exfiltration destinations. An internal IP you don't recognise at the top of the list may be a compromised server you didn't know was involved.
Analysing a large PCAP without using the Statistics views is like trying to understand a library by reading every book from the first shelf sequentially — technically complete but practically impossible. The Statistics views are the library's catalogue and floor plan: Protocol Hierarchy tells you which sections exist (reference, fiction, science), Conversations tells you which shelves have the most activity, and Endpoints tells you which patrons are most frequent. Within 60 seconds you know where to focus your time before you open a single book. The display filters are then how you walk directly to the shelf you need instead of browsing every aisle.
Wireshark Workflow
Step 1 Load PCAP: File > Open or drag-and-drop (or tshark -r file.pcap for CLI) Step 2 Statistics overview: Protocol Hierarchy, Conversations, Endpoints Step 3 Apply display filters to isolate traffic of interest by protocol/IP/port Step 4 Follow TCP/UDP streams to read full application-layer conversations Step 5 Export Objects: File > Export Objects > HTTP/SMB/FTP for file extraction Step 6 Extract IOCs: C2 IPs, domains, User-Agents, file hashes, credentials
Wireshark Analysis in Practice
Display filters isolate traffic of interest from thousands of packets without discarding the others — the capture remains intact, only the view changes.
# Protocol filters: http all HTTP traffic dns DNS queries and responses tcp.port==22 SSH traffic only tls all TLS/HTTPS handshakes and data # IP-based filters: ip.addr==185.12.44.21 all traffic to OR from this IP (either direction) ip.src==10.0.1.55 traffic FROM internal host only ip.dst==185.12.44.21 traffic TO specific external IP # Content-based filters: http.request.method==POST and http contains "password" dns.qry.name contains "evil.com" frame contains "cmd.exe" any protocol containing this string
Following a TCP stream reassembles the full conversation — essential for reading HTTP requests and responses, FTP sessions, Telnet commands, and other application-layer data in human-readable form.
# Right-click any packet → Follow → TCP Stream GET /login HTTP/1.1 Host: intranet.corp.com HTTP/1.1 200 OK POST /login HTTP/1.1 Host: intranet.corp.com Content-Type: application/x-www-form-urlencoded username=admin&password=Corp2024! HTTP/1.1 302 Found Location: /dashboard # Cleartext credentials captured from HTTP POST -- admin account compromised # IOCs: username admin, password Corp2024!, admin dashboard accessible
Malware using DNS tunnelling for C2 makes unusual queries — very long subdomains containing encoded data. The anomaly is visible in both subdomain length and character distribution.
# Normal DNS query: Query: google.com Type: A Length: 10 chars (readable word) # DNS tunnelling (base64-encoded data in subdomain labels): Query: aGVsbG8gd29ybGQ.c2VjcmV0LmV2aWwuY29t.c2 Length: 49 chars Query: bG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQ.evil.com Length: 48 chars # Same parent domain, random-looking subdomains, base64 character distribution # Filter to find: dns.qry.name.len > 50 # Or: Statistics > DNS → sort by Query Name Length to spot outliers
Wireshark reconstructs and exports complete files transferred over HTTP, SMB, and FTP from the PCAP — enabling malware triage without re-executing the attack.
# File > Export Objects > HTTP (shows all files transferred over HTTP) Exported: invoice.exe (1.2 MB) from 185.12.44.21 (malware delivery) Exported: update.zip (344 KB) from 103.45.12.99 (additional payload) # Hash the extracted file and check threat intel: sha256sum invoice.exe 3a4f8b2c1d9e7f6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a # VirusTotal hash lookup (never upload the file): Detection: 52/72 engines -- Trojan.GenericKD.46823411 (Emotet loader)
What You Need to Know
Security-Focused Display Filter Compendium
Effective Wireshark analysis requires building display filters quickly and accurately. The following reference covers the filters most commonly needed in security investigations — organised by the question they answer rather than by protocol.
| Question | Display Filter | Notes |
|---|---|---|
| Show all traffic involving a specific IP | ip.addr==185.12.44.21 | Both directions. Use ip.src or ip.dst to restrict to one direction. |
| Show HTTP POST requests | http.request.method==POST | Combine with http contains "password" to find cleartext credentials. |
| Find large DNS queries (tunnelling) | dns.qry.name.len > 50 | Legitimate DNS hostnames are rarely over 30 characters. Values over 50 warrant investigation. |
| Show only DNS queries (no responses) | dns.flags.response==0 | Useful for finding high-frequency beaconing domains without response noise. |
| Find failed TCP connections | tcp.flags.reset==1 | RST packets indicate rejected connections — port scanning leaves a trail of these. |
| Show TLS handshakes only | tls.handshake.type==1 | Type 1 = ClientHello. Used to find JA3 fingerprinting candidates and identify all TLS sessions. |
| Find cleartext passwords in HTTP | http contains "password" or http contains "passwd" | Case insensitive with matches operator: http matches "(?i)password" |
| Show all SMB traffic (lateral movement) | smb or smb2 | Internal SMB from unexpected sources at unusual hours = lateral movement candidate. |
| Find FTP credentials (always cleartext) | ftp.request.command==USER or ftp.request.command==PASS | FTP transmits credentials in the clear in every session without exception. |
| Show all traffic EXCEPT known-good hosts | not (ip.addr==10.0.1.1 or ip.addr==10.0.1.2) | Useful for excluding known infrastructure (DNS server, gateway) to focus on anomalous hosts. |
tshark — Wireshark's Command-Line Interface
tshark is the command-line version of Wireshark — all the same protocol analysis capability in a scriptable, pipeline-able interface. For large PCAP files, specific field extraction, and automated analysis, tshark is significantly more efficient than the GUI. It also enables PCAP analysis on headless servers and in scripts where a GUI is unavailable.
Read a PCAP and apply filter:tshark -r capture.pcap -Y "http.request"
Extract specific fields:tshark -r capture.pcap -T fields -e ip.src -e ip.dst -e http.host
Count by IP (top talkers):tshark -r capture.pcap -T fields -e ip.dst | sort | uniq -c | sort -rn | head
Extract DNS queries:tshark -r capture.pcap -Y dns -T fields -e dns.qry.name | sort -u
Capture to file:tshark -i eth0 -w capture.pcap
Capture with filter (BPF syntax):tshark -i eth0 -f "port 443" -w https.pcap
Ring buffer (capture with size limit):tshark -i eth0 -b filesize:100000 -w ring.pcap
Extract HTTP hosts in real time:tshark -i eth0 -Y http.request -T fields -e http.host
Note: tshark uses BPF syntax for capture filters (what to capture) and Wireshark display filter syntax for the -Y flag (how to filter what was captured). These are two different filter languages.
Extracting a complete IOC set from a suspicious PCAP using tshark commands — all unique external IPs, HTTP hosts, DNS queries, and User-Agent strings in one workflow.
# All unique external IPs the host connected to: tshark -r capture.pcap -T fields -e ip.dst -Y "ip.src==10.0.1.55" | \ grep -v "^10\.\|^172\.\|^192\.168" | sort -u 185.220.101.45 103.45.12.99 # All HTTP hosts (domains) accessed: tshark -r capture.pcap -T fields -e http.host -Y http.request | sort -u malicious-site.xyz c2-server.attacker.com # All DNS queries (find C2 domains, tunnelling): tshark -r capture.pcap -T fields -e dns.qry.name -Y dns | sort -u | head -20 google.com api.corp.com c2-server.attacker.com aGVsbG8.c2VjcmV0.evil.com (long base64 subdomain = DNS tunnelling) # All HTTP User-Agent strings (fingerprint malware by UA): tshark -r capture.pcap -T fields -e http.user_agent -Y http.request | sort -u Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) (IE7 in 2026 = malware UA) python-requests/2.28.0 (automated tool, not browser)
From Unknown PCAP to Complete IOC Set
Starting point: Security team receives a 2 GB PCAP file collected from a TAP on the core switch during a 4-hour window. Suspicion: one internal host (10.0.1.55) was behaving anomalously. No other context provided.
Step 1 — Statistics overview: Protocol Hierarchy shows: 68% HTTPS, 14% HTTP (unexpectedly high — legitimate traffic should be almost all HTTPS), 11% DNS (also high — baseline is ~2%), 4% FTP (FTP should not exist in this environment at all). Three immediate anomalies identified before a single packet was examined.
Step 2 — Conversations view: Top talker: 10.0.1.55 → 185.220.101.45, 1.4 GB transferred. Second: 10.0.1.55 → 103.45.12.99, 344 MB. Third: 10.0.1.55 → an internal FTP server (10.0.0.20). These three conversations account for 90% of the capture's traffic.
Step 3 — FTP stream (Filter: ftp): Follow TCP stream on FTP traffic. Cleartext: USER ftpuser, PASS ftppassword123, multiple RETR commands downloading .sql database backup files. FTP credentials and downloaded file names extracted as IOCs.
Step 4 — HTTP traffic (Filter: http): Follow TCP stream on HTTP to 185.220.101.45. POST requests with large bodies — base64-encoded content in POST parameters. HTTP object export retrieves 3 files: employees.csv, passwords.txt, financial_q1.xlsx. Files hashed. passwords.txt hash to VirusTotal: clean (it's actual plaintext passwords, not malware). employees.csv and financials clearly exfiltrated data.
Step 5 — DNS anomaly (Filter: dns.qry.name.len > 40): Reveals 47 queries to the pattern [base64].exfil.evil.com over a 30-minute window. DNS tunnelling confirmed — smaller data exfiltration channel running in parallel with HTTP exfiltration.
IOC set produced: C2/exfil IPs: 185.220.101.45, 103.45.12.99. Domains: c2-server.attacker.com, exfil.evil.com. Protocols abused: HTTP (exfiltration), FTP (credential theft and file download), DNS (tunnelling). FTP credentials: ftpuser/ftppassword123. Exfiltrated files: employees.csv, passwords.txt, financial_q1.xlsx, 8 SQL backup files. Malware User-Agents: IE7 (2026), python-requests. Complete incident scope reconstructed from a single PCAP with no prior context.
Core Concepts Summary
ip.src==10.0.1.55 and http.request.method==POST. Filters don't discard packets — they just hide them. Toggle off to return to full view.You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Wireshark→← Return to all labs