Practical PCAP Analysis Workflow

Step-by-Step Guide for analysing pcap files in Wireshark

How to find the "Needle in the Haystack" in pcap files in Wireshark

The Analyst's Mindset

Opening a large PCAP file in Wireshark for the first time is overwhelming. This guide is not a list of every button in Wireshark. It is a repeatable methodology for systematically analyzing network traffic to find suspicious activity.

Your goal is not to understand every single packet. Your goal is to tell a story by answering these questions:

1. What is "normal" on this network?

2. What is "abnormal" or "suspicious"?

3. What is the full extent of the suspicious activity?

This guide provides the sequence of actions to get you from a "chaotic" sea of packets to a clear conclusion.

Phase 1: The 5-Minute Triage (Answering "Where do I even start?")

Your first look should be high-level. Do not look at individual packets yet. The goal is to get a "map of the world" you're in.

Action 1.1: Get Capture Statistics

• How: Go to Statistics -> Capture File Properties.

• What to look for:

  • Time: How long was the capture? (10 seconds? 24 hours?)

  • Packets: How many packets?

  • Avg. packets/sec: What's the packet rate?

• Why (The "Meat"): This gives you immediate context.

  • High packets/sec (e.g., 20,000 packets in 5 seconds): Suggests a packet burst, network storm, port scan, or Denial of Service (DoS).

  • Low packets/sec (e.g., 5,000 packets in 24 hours): Might be normal, or it could be the "low-and-slow" beaconing of malware (Command and Control, or C2).

Action 1.2: Find the "Top Talkers" (Endpoints)

• How: Go to Statistics -> Endpoints. Click the IPv4 tab and sort by the "Packets" or "Bytes" column.

• What to look for: The top 3-5 IP addresses that are sending/receiving the most data.

• Why: These are your main "actors." In any network investigation, the host sending or receiving the most data is either the main server or the victim/attacker. Write these IPs down.

Action 1.3: See the "Top Conversations"

• How: Go to Statistics -> Conversations. Look at the TCP and UDP tabs.

• What to look for: Patterns in the "Address A" and "Address B" columns.

  • One-to-Many: One IP talking to many different IPs on the same port.

  • Many-to-One: Many IPs talking to a single IP.

  • High-Volume One-to-One: Two IPs exchanging a huge amount of data.

• Why: This is how you spot scans and exfiltration.

  • One-to-Many on TCP port 445? That's a classic SMB scan.

  • One-to-Many on TCP port 3389? That's an RDP scan.

  • High-Volume One-to-One to an external IP? That's a massive red flag for data exfiltration.

Action 1.4: Check the "Top Protocols"

• How: Go to Statistics -> Protocol Hierarchy.

• What to look for: What are the dominant protocols? (e.g., 80% TLS, 10% DNS). More importantly, are there any unexpected protocols?

• Why: You're looking for things that don't belong.

  • See telnet, ftp, http (unencrypted)? This is a goldmine for finding credentials in cleartext.

  • See smb or dcerpc? This is Windows file sharing/remote procedure call traffic.

  • See modbus, s7comm, enip? This is Industrial Control System (ICS) traffic.

  • See a lot of ICMP? This could be a "ping sweep" scan or ICMP tunneling for C2.

Phase 2: Reducing the Noise (Answering "How do I filter?")

Now you have your "map" and a list of "suspects" (the top talkers). The next step is to filter out the "background noise" to focus on what matters.

Your filter strategy should be to remove what you know is "safe" to see what's left.

Action 2.1: Build a "Noise" Filter

• How: Start typing in the display filter bar. Common "noise" protocols are arp, dhcp, mdns, ssdp, ntp, browser (NetBIOS).

• Filter (Example): !(arp or dhcp or mdns or ssdp or browser)

  • This filter says: "Show me everything that is NOT ARP, DHCP, mDNS, SSDP, or NetBIOS Browser."

• Pro-Tip (The Right-Click Method): Find a "noise" packet (like ARP), right-click it, and select Apply as Filter -> ...and not Selected. This automatically adds and !(arp) to your filter bar. Keep doing this to build your filter.

• Why: You can't find the suspicious needle if you're staring at the entire haystack. This removes 90% of the "boring" traffic so you can focus on the real application data.

Phase 3: The Hunt (Answering "What is 'suspicious'?")

With the noise filtered, you now actively hunt for red flags.

Hunt 3.1: The Low-Hanging Fruit (Cleartext Credentials)

• What: Look for any unencrypted login protocols.

• Filter: tcp.port == 21 or tcp.port == 23 or tcp.port == 80 or tcp.port == 110 or tcp.port == 143

  • (These are FTP, Telnet, HTTP, POP3, IMAP)

• How to check:

  1. Find a packet in the stream (e.g., an HTTP POST or an FTP USER command).

  2. Right-click the packet -> Follow -> TCP Stream.

  3. A new window will pop up showing the reassembled conversation. Look for keywords like PASS, USER, password=, login=, Authorization: Basic.

Hunt 3.2: DNS Deep Dive (The "Phonebook" of Malware)

• What: DNS shows the intent of a host. It's what it tried to connect to, even if the connection failed.

• Filter: dns

• What to look for:

  • Weird Domains: Long, random-looking domains (e.g., x8f9abc-malware-server.ru). This is a classic sign of a Domain Generation Algorithm (DGA) used by malware to find its C2 server.

  • High NXDOMAIN: A high volume of NXDOMAIN (Non-Existent Domain) responses, especially from one host. This means the host is asking for domains that don't exist, often a sign of malware trying to find its C2.

    • Filter for NXDOMAIN: dns.flags.response == 1 && dns.flags.rcode == 3

  • Non-Standard Query Types: Look for TXT or NULL record queries. Malware uses these for DNS Tunneling to send/receive commands.

    • Filter for TXT queries: dns.qry.type == 16

Hunt 3.3: HTTP Analysis (The User-Agent)

• What: When a host makes an HTTP request, it sends a "User-Agent" string identifying the client software.

• Filter: http.request

• How to check:

  1. Apply the filter.

  2. Select a packet. In the "Packet Details" pane, expand the Hypertext Transfer Protocol section.

  3. Look for the User-Agent field.

• Why: Normal browsers look like Mozilla/5.0 (Windows NT 10.0...). Malware often uses non-standard agents.

  • Suspicious User-Agents: curl/7.68.0, Wget/1.20.3, python-requests/2.25.1, powershell, or a blank/missing User-Agent.

  • Filter for these: http.user_agent contains "curl" or http.user_agent contains "wget" or http.user_agent contains "python"

  • This is a strong indicator that a script or tool (not a user in a browser) is making the connection, often to download the next stage of an attack.

Hunt 3.4: Scanning Activity

• What: An attacker scanning the network.

• Filter (TCP SYN Scan): tcp.flags.syn == 1 && tcp.flags.ack == 0

  • Why: This filter shows only the first packet of a TCP handshake (the "connection attempt"). If you see one source IP sending thousands of these to different hosts or different ports, that is a port scan.

• Filter (Connection Refused): tcp.flags.reset == 1

  • Why: A high number of RST (Reset) packets from a host means it's actively refusing connections. This is the result of a scan hitting closed ports.

Phase 4: Following the Trail (Answering "How do I track what matters?")

You've found a red flag (e.g., a suspicious DNS query or a weird User-Agent). Now you "zoom in" and track only that activity.

Action 4.1: Isolate the Conversation

• How: You found a suspicious host (192.168.1.100) talking to a weird external IP (123.45.67.89).

• Filter: ip.addr == 192.168.1.100 && ip.addr == 123.45.67.89

• Why: This filter removes all other noise and shows you only the full conversation between the attacker and the victim.

Action 4.2: Reconstruct the Payload

• How: You can't understand the attack by looking at individual packets. You must reassemble them.

• Click Path: Find a packet in the isolated conversation -> Right-click -> Follow -> TCP Stream (or UDP Stream or TLS Stream).

• Why: This is where you find the actual commands.

  • In an HTTP stream, you might see GET /malware.exe.

  • In a Telnet stream, you'll see the exact commands the attacker typed (whoami, cat /etc/passwd).

  • In an FTP stream, you'll see STOR stolen_data.zip.

Action 4.3: Export Malicious Files

• What: If the attacker downloaded a file over HTTP, you can extract that exact file from the PCAP.

• How:

  1. File -> Export Objects -> HTTP...

  2. A new window will open listing all files transferred.

  3. Find the file (e.g., malware.exe) and click Save

• Why: You can now take this exported file and analyze it in a sandbox (like VirusTotal) to confirm it's malware.

Analysis Cheatsheet

Wireshark Display Filters

Filter	Why it's Useful
IP / Host Based
ip.addr == 10.1.1.5	Show all traffic (to/from) this IP. Your first step.
ip.src == 10.1.1.5	Show only traffic sent by this IP.
ip.dst == 10.1.1.5	Show only traffic received by this IP.
!(ip.addr == 192.168.0.0/16)	Show all traffic except internal (192.168) traffic. Good for finding all external connections.
eth.addr == 00:bb:cc:dd:ee:ff	Filter by MAC address.
Protocol / Port Based
tcp.port == 445 or smb	Find Windows File Sharing (SMB). Common attack vector.
tcp.port in {21 23 80 110 143}	Find common cleartext protocols (FTP, Telnet, HTTP, POP3, IMAP).
http or dns or icmp	Simple filters to show only these protocols.
!(arp or dhcp or dns or icmp)	"Show me the real data" filter. Hides common noise.
TCP Flags (CRITICAL for Scans)
tcp.flags.syn == 1 && tcp.flags.ack == 0	TCP SYN Scan. Shows only connection attempts.
tcp.flags.reset == 1	Connection Resets. The result of a scan on closed ports.
tcp.flags.fin == 1	FIN Scan. A type of stealthy scan.
tcp.flags.push == 1	Show packets with the PUSH flag. Often indicates data transfer.
Application Layer (The "Money")
http.request.method == "POST"	Find all data sent to a web server (logins, uploads, form data).
http.host contains "malicious.com"	Find all HTTP requests going to a specific domain.
http.user_agent contains "curl"	Find requests made by the curl tool (very suspicious).
http contains "password"	A very "dirty" filter to quickly find cleartext passwords in HTTP.
dns.flags.rcode == 3	NXDOMAIN. Find all failed DNS lookups (malware C2 hunting).
dns.qry.type == 16	TXT Query. Find DNS Tunneling attempts.
ftp.request.command == "PASS"	Find FTP password commands.
Expert Info (Wireshark's Helper)
_ws.expert	Show all packets Wireshark thinks are "interesting" (errors, warnings, retransmissions).
_ws.expert.severity == "Error"	Show only critical errors (e.g., malformed packets).
tcp.analysis.retransmission	Show all retransmitted packets. A sign of a poor connection or network problems.

tshark (The Command-Line Power Tool)

tshark is the command-line version of Wireshark. It's faster and excellent for scripting and pulling specific data from huge files.

• Why use it? When a PCAP is too big for Wireshark (e.g., > 2GB) or you want to automate.

Command	Why it's Useful
tshark -r <file.pcap> -Y "dns"	Apply a display filter. Reads the file (-r) and applies a filter (-Y).
tshark -r <file.pcap> -q -z conv,ip	Get IP Conversations. The fastest way to get the "Top Talkers." (-q = quiet, -z = stats)
tshark -r <file.pcap> -q -z io,phs	Get Protocol Hierarchy. The CLI version of the Protocol Hierarchy stats.
THE KILLER TSHARK COMMAND (Extracting Fields):
tshark -r file.pcap -Y "dns" -T fields -e dns.qry.name	Get all DNS queries. This command will print only the domain names from all DNS queries.
tshark -r file.pcap -Y "http.request" -T fields -e ip.src -e http.host -e http.user_agent	Get a CSV of HTTP requests. This extracts the Source IP, Host Requested, and User-Agent. Incredibly powerful.
tshark -r file.pcap -Y "smb.file.name" -T fields -e smb.file.name	Get all accessed SMB file names. See what files users are opening.