PCAP Analysis with Wireshark

Why Wireshark Is Essential for SOC Analysts

Suricata tells you that something malicious crossed the wire. Wireshark tells you exactly what crossed the wire — byte by byte, packet by packet, protocol field by protocol field.

When Suricata fires an alert for "ET TROJAN Cobalt Strike Beacon Detected," you know there is a problem. But the alert does not show you the full HTTP request, the payload content, the TLS certificate details, or the timing pattern of the beacon. Wireshark gives you all of that. It is the difference between knowing a crime occurred and reconstructing the entire crime scene.

Every SOC analyst reaches for Wireshark in these situations:

• Alert validation — confirming whether a Suricata or Wazuh alert represents a real threat or a false positive
• Payload extraction — examining the actual data transferred in a suspicious session
• Protocol anomaly analysis — identifying non-standard protocol behavior that signature-based detection misses
• Incident reconstruction — building a packet-level timeline of attacker activity during an investigation
• Forensic evidence — capturing network evidence in a format suitable for legal proceedings

The Wireshark Interface

When you open a PCAP file in Wireshark, you see three primary panels that form the core of your analysis workspace.

Click to enlarge

Panel 1: Packet List (Top)

The packet list shows every packet in the capture, one row per packet. Each row displays:

• No. — sequential packet number (Wireshark assigns these, not the network)
• Time — timestamp relative to the first packet or absolute time
• Source / Destination — IP addresses (or MAC addresses for ARP)
• Protocol — the highest-level protocol Wireshark can decode (HTTP, DNS, TLS, TCP, etc.)
• Length — packet size in bytes
• Info — protocol-specific summary (e.g., "GET /login HTTP/1.1" for HTTP, "Standard query A evil.com" for DNS)

Color coding provides instant visual triage: green for TCP, blue for UDP/DNS, black for TCP errors/retransmissions, and red for RST packets. These colors are customizable, but the defaults are well-chosen for security analysis.

Panel 2: Packet Details (Middle)

Select any packet in the list, and the details panel shows the full protocol dissection — every header field at every layer of the OSI model, from the Ethernet frame header down to the application-layer payload. You can expand each protocol layer to inspect individual fields.

This is where you find the evidence: HTTP headers revealing a suspicious User-Agent, DNS queries resolving a known C2 domain, TLS certificates with anomalous issuer fields, or TCP flags indicating a port scan.

Panel 3: Packet Bytes (Bottom)

The raw hexadecimal and ASCII representation of the packet. When the protocol dissector cannot decode a field (encrypted payloads, custom protocols, binary data), the hex view is your last resort. Experienced analysts can spot Base64-encoded payloads, embedded PE headers, and protocol anomalies directly in the hex.

Display Filters — The Core Skill

Wireshark's display filter system is the single most important skill for efficient PCAP analysis. A typical enterprise PCAP contains millions of packets — finding the 50 that matter requires precise filtering.

Essential Display Filter Syntax

Click to enlarge

IP Address Filters:

ip.addr == 10.0.0.10            # Any packet involving this IP (source OR destination)
ip.src == 185.220.101.42        # Packets FROM this IP only
ip.dst == 10.0.0.10             # Packets TO this IP only
ip.addr == 10.0.0.0/24          # Entire subnet
!(ip.addr == 10.0.0.1)          # Exclude a specific IP (gateway noise)

Port and Protocol Filters:

tcp.port == 443                  # Any TCP traffic on port 443 (source OR destination)
tcp.dstport == 4444              # Destination port 4444 (common for reverse shells)
udp.port == 53                   # DNS traffic (UDP)
tcp.port == 445                  # SMB traffic (lateral movement indicator)
tcp.flags.syn == 1 && tcp.flags.ack == 0   # SYN-only packets (port scanning)

HTTP Filters:

http.request                     # All HTTP requests
http.request.method == "POST"    # POST requests only (data submission, C2 check-ins)
http.request.uri contains "cmd"  # URIs containing "cmd" (web shell activity)
http.user_agent contains "sqlmap"         # Specific User-Agent
http.response.code == 200        # Successful responses
http.content_type contains "executable"   # Executable downloads

DNS Filters:

dns                              # All DNS traffic
dns.qry.name contains "evil.com"         # Queries for a specific domain
dns.qry.type == 1                # A record queries
dns.qry.type == 28               # AAAA record queries
dns.qry.name matches "^.{40,}"  # Domain names longer than 40 chars (tunneling indicator)
dns.flags.response == 0          # DNS queries only (not responses)

Time-Based Filters:

frame.time >= "2026-01-15 14:00:00" && frame.time <= "2026-01-15 14:30:00"

Combining Filters:

ip.addr == 10.0.0.10 && tcp.port == 443          # HTTPS traffic to/from specific host
http.request && !(ip.dst == 10.0.0.0/8)          # HTTP requests to external destinations
dns.qry.name contains "exfil" || dns.qry.name contains "c2"   # OR logic

Following Streams

One of Wireshark's most powerful features for investigation is stream following — reconstructing the complete conversation between two hosts from individual packets.

TCP Stream

Right-click any TCP packet → Follow → TCP Stream. Wireshark reconstructs the entire conversation in a single window, showing client data in red and server data in blue. This is invaluable for:

• Reading the full HTTP request and response (headers, body, cookies)
• Seeing command-and-control traffic in plain text (many C2 frameworks use HTTP)
• Identifying data being exfiltrated in POST request bodies
• Reconstructing file transfers

UDP Stream

Follow → UDP Stream works similarly for UDP protocols. Most commonly used for reconstructing DNS conversations, TFTP transfers, or custom UDP-based protocols used by malware.

HTTP Stream

Follow → HTTP Stream is specifically optimized for HTTP conversations — it decompresses gzip content, decodes chunked transfer encoding, and presents the conversation in a readable format.

Statistical Analysis Tools

Before filtering individual packets, use Wireshark's statistical tools to get a high-level view of the PCAP. These tools help you understand the overall traffic profile and identify anomalies worth investigating.

Protocol Hierarchy (Statistics → Protocol Hierarchy)

Shows the percentage of traffic by protocol. In a normal enterprise capture, you expect to see mostly TCP (HTTP/HTTPS, SMB), some UDP (DNS), and small amounts of other protocols. Anomalies jump out immediately:

• 30% ICMP traffic? Possible ICMP tunneling or flood
• Significant DNS traffic volume? Possible DNS tunneling or exfiltration
• Unknown protocols or non-standard ports? Worth investigating
• IRC or Telnet traffic? Potentially malicious in a modern environment

Conversations (Statistics → Conversations)

Lists all unique communication pairs (host-to-host), sortable by bytes transferred, packet count, and duration. This immediately reveals:

• Top talkers — which hosts are generating the most traffic (potential exfiltration sources)
• Unexpected connections — internal hosts communicating with external IPs you do not recognize
• Long-duration sessions — persistent connections that may indicate C2 channels
• Asymmetric transfers — significantly more data leaving than arriving (exfiltration indicator)

IO Graphs (Statistics → I/O Graphs)

IO Graphs plot traffic volume over time. This is the fastest way to identify:

• Traffic spikes — sudden bursts that may correlate with exploitation or data theft
• Periodic patterns — regular intervals that suggest beaconing (C2 calling home every N seconds)
• Baseline deviations — times when traffic volume significantly departs from normal patterns

You can overlay multiple filters on the same graph — for example, plot all traffic in blue and DNS traffic in red to see if DNS spikes correlate with overall traffic patterns.

tshark — Wireshark's Command-Line Power

tshark is Wireshark's command-line sibling. It uses the same dissectors and filter syntax but runs without a GUI — making it ideal for automated analysis, scripting, and processing PCAPs on headless servers.

Common tshark Recipes

Extract all HTTP requests from a PCAP:

tshark -r capture.pcap -Y "http.request" -T fields -e ip.src -e ip.dst -e http.host -e http.request.uri -e http.user_agent

Extract all DNS queries:

tshark -r capture.pcap -Y "dns.flags.response == 0" -T fields -e ip.src -e dns.qry.name -e dns.qry.type

Find unique destination IPs and sort by frequency:

tshark -r capture.pcap -T fields -e ip.dst | sort | uniq -c | sort -rn | head -20

Extract TLS certificate common names:

tshark -r capture.pcap -Y "tls.handshake.type == 11" -T fields -e tls.handshake.certificate -e ip.dst

Detect beaconing — find connections with regular intervals:

tshark -r capture.pcap -Y "ip.dst == 185.220.101.42" -T fields -e frame.time_delta_displayed | sort | uniq -c | sort -rn

If the same time delta appears repeatedly (e.g., 60.0 seconds appearing 47 times), that is a beacon.

Common Analysis Workflows

Here are the specific workflows SOC analysts use repeatedly when investigating alerts with Wireshark.

Workflow 1: Finding C2 Beacons

C2 frameworks (Cobalt Strike, Metasploit, Sliver) communicate at regular intervals — the "beacon" pattern. To find them:

1. Open the PCAP and run Statistics → Conversations sorted by duration
2. Look for long-lived TCP connections to external IPs
3. Apply the filter for the suspicious destination: ip.dst == <suspicious_ip>
4. Check Statistics → I/O Graphs — a beacon shows as regular, evenly-spaced spikes
5. Use tshark to calculate inter-packet timing: if the time delta clusters around a specific interval (30s, 60s, 300s), it is likely a beacon
6. Follow the TCP stream to inspect the payload — encoded data, HTTP headers with anomalous User-Agents, or encrypted blobs

Workflow 2: Identifying Data Exfiltration

1. Run Statistics → Conversations sorted by bytes (descending)
2. Identify connections where significantly more data is leaving than arriving (asymmetric transfer)
3. Filter for those connections and follow the stream
4. Check the destination — is it a known cloud storage provider, a foreign IP, or an unexpected internal host?
5. Check the timing — was the transfer during business hours or at 3 AM?
6. For DNS exfiltration, filter dns.qry.name matches "^.{40,}" to find suspiciously long subdomain labels

Workflow 3: Analyzing Suspicious HTTP Traffic

1. Filter http.request to see all HTTP requests
2. Check User-Agent strings: http.user_agent — look for tools (sqlmap, curl, python-requests, powershell) or empty User-Agents
3. Check request URIs for encoded payloads, unusual parameters, or known web shell patterns
4. Filter POST requests specifically: http.request.method == "POST" — attackers use POST for data submission and C2 check-ins
5. Follow HTTP streams for any suspicious request to see the full request-response conversation
6. Check for executable downloads: http.content_type contains "octet-stream" || http.content_type contains "executable"

Filter Recipes for Common Scenarios

Here is a quick reference of filter combinations for scenarios SOC analysts encounter regularly:

What's Next

You now have the full toolkit for examining individual packets and sessions. But real-world investigations require going deeper — extracting files from packet captures, detecting C2 beacon patterns with mathematical precision, and building forensic timelines from network evidence.

In Lesson 5.7 — Network Forensics: File Extraction & C2 Detection, you will learn to extract transferred files directly from PCAPs, analyze beacon intervals using statistical methods, perform DNS forensic analysis including DoH detection and tunneling payload extraction, and build comprehensive network forensic timelines that integrate PCAP evidence with SIEM data. The packets are talking — it is time to learn everything they have to say.