Wireshark Forensic Analysis: Incident Investigation Workflow (2026)

The most surprising thing about Wireshark forensic analysis is that it’s less about "finding the bad guy" and more about reconstructing a narrative from digital crumbs, where the absence of data is often as telling as its presence.

Imagine you’ve just been handed a packet capture (PCAP) file from a server that’s been acting suspiciously. Your goal isn’t just to spot a malicious IP address, but to understand the sequence of events that led to the current state. Let’s walk through a typical incident investigation workflow using Wireshark.

The Scenario: A Compromised Web Server

We have a PCAP from a web server that has been reporting unusual outbound traffic and is suspected of being compromised.

Initial Triage: Getting the Lay of the Land

First, open the PCAP in Wireshark. The immediate goal is to get a high-level overview.

Statistics -> Conversations: This is your starting point. It lists all the IP and TCP/UDP conversations happening in the capture. You’re looking for anomalies:
- Unusual IP Addresses: Are there IPs you don’t recognize, especially those with high traffic volume?
- High Volume of Data: Which conversations are transferring the most bytes? This could indicate data exfiltration or a botnet command-and-control (C2) channel.
- Unexpected Protocols: Are there protocols running that shouldn’t be on a web server (e.g., IRC, P2P)?
Statistics -> Protocol Hierarchy: This gives you a breakdown of the protocols present. A web server should primarily show HTTP/HTTPS, DNS, and perhaps SMB if it’s on a Windows domain. Anything else warrants deeper inspection.

Drilling Down: Following the Suspect Traffic

Let’s say Statistics -> Conversations highlights a significant amount of traffic to an IP like 192.0.2.10 on port 443 (HTTPS), which is unusual for outbound traffic from your web server.

Filter for the Suspect IP and Port:
```
ip.addr == 192.0.2.10 and tcp.port == 443
```
This isolates all traffic involving that IP and port.
Follow TCP Stream: Right-click on one of the packets in the filtered list and select Follow -> TCP Stream. This reconstructs the data exchanged during that specific TCP connection.
- What to look for in the stream:
  - Plaintext Data: If it’s not truly HTTPS (e.g., misconfigured, or an HTTP connection masquerading as HTTPS), you might see commands, credentials, or data directly.
  - Encoded Data: Base64 or other encodings are common for hiding malicious payloads. You’ll need to decode these.
  - Suspicious Commands: Look for shell commands (cmd.exe, powershell.exe), file transfer commands (wget, curl), or unusual HTTP requests.
  - Data Exfiltration Patterns: Large amounts of seemingly random data being sent out to the suspect IP.

Investigating Command and Control (C2)

If you suspect the server is part of a botnet, you’ll be looking for C2 communication. This often involves:

DNS Lookups:
- Filter: dns
- Look for: Frequent DNS requests to unusual or newly registered domains. Tools like VirusTotal can help you check the reputation of these domains.
- Example Check: Look for DNS queries for random-string.malicious-domain.com.
HTTP/HTTPS Beaconing:
- Filter: http or tls.handshake.type == 1 (for TLS client hello, to identify connections to unknown HTTPS servers).
- Look for: Regular, periodic connections to a C2 server. These "beacons" often carry small amounts of data (e.g., "heartbeat") and can also be used to receive commands. The User-Agent string in HTTP requests can also be a telltale sign.

Reconstructing the Attack Chain

Often, a compromise involves multiple stages:

Initial Access: How did they get in? This might be an exploit in a web application (look for unusual HTTP requests, SQL injection attempts, shell metacharacters in URL parameters) or a vulnerability in the web server software itself.
- Filter Example: http.request.method == "POST" and http.request.uri contains ".." or http.request.uri contains "%" (for directory traversal attempts).
Lateral Movement (if applicable): Did the attacker move to other systems? Look for NTLM or Kerberos authentication attempts to other internal IPs, or SMB traffic.
Persistence: How did they ensure they could get back in? Look for unusual scheduled tasks, services, or registry modifications that might be indicated by network traffic.
Data Exfiltration: As mentioned, look for large outbound transfers, especially to unusual destinations or on non-standard ports.

The "Why" Behind the Data

When you find a suspicious piece of traffic, like a POST request to /admin.php?cmd=ls -la, you’re not just seeing the command. You’re seeing the TCP handshake that established the connection, the HTTP request packet carrying the command, and the TCP packets carrying the response (potentially listing files). Wireshark’s Follow TCP Stream reconstructs this exchange, showing you the dialogue between the attacker and your server.

Leveraging Other Tools

Wireshark is powerful, but it’s often one tool in a larger toolkit.

tshark: The command-line version of Wireshark. Essential for scripting and automated analysis.
- tshark -r capture.pcap -Y "http.request.method == \"POST\"" -T fields -e frame.time -e ip.src -e http.request.uri This extracts timestamps, source IPs, and URIs for all POST requests.
NetworkMiner / Brim Security: Tools that can automatically extract files, credentials, and metadata from PCAPs, which can significantly speed up initial analysis.
VirusTotal / Threat Intelligence Feeds: Use these to check the reputation of suspicious IPs, domains, and file hashes you might extract.

The End of the Beginning

Once you’ve identified the C2 server, the malicious domain, the exfiltration path, and the commands executed, you’ve built a strong narrative. The next steps involve blocking the C2 IP/domain at the firewall, isolating the compromised server, performing a full forensic analysis on the host itself to identify malware and persistence mechanisms, and then restoring the server from a known good backup.

More Deep Dives in Wireshark