In 2024, the Change Healthcare breach exposed how attackers moved laterally for weeks before detection — because nobody was watching the packets. Wireshark won’t prevent a breach, but it will show you exactly what happened, when, and to whom. This guide skips the basics and gets straight to forensic-grade packet analysis.
Isolating Suspicious Traffic with Display Filters
Wireshark’s display filters are your scalpel. You’re not capturing differently — you’re slicing through an existing PCAP to find exactly what matters. The difference between a useful filter and a useless one is specificity.
Imagine you’ve pulled a PCAP from ws-fin-04.corp.internal (192.0.2.44) after a user named mreyes reported strange slowness. You suspect beaconing — malware phoning home at regular intervals. Start here:
ip.src == 192.0.2.44 && tcp.flags.syn == 1 && !tcp.flags.ack == 1This filter shows every new outbound TCP connection initiated by that host — SYN packets without an ACK, meaning fresh handshakes only. The output might look like this in Wireshark’s packet list:
No. Time Source Destination Protocol Info
142 00:03:12 192.0.2.44 203.0.113.17 TCP 49821 → 443 [SYN]
611 00:13:12 192.0.2.44 203.0.113.17 TCP 49834 → 443 [SYN]
1089 00:23:11 192.0.2.44 203.0.113.17 TCP 49851 → 443 [SYN]
1544 00:33:12 192.0.2.44 203.0.113.17 TCP 49867 → 443 [SYN]Every ten minutes, almost to the second, 192.0.2.44 opens a new connection to 203.0.113.17 on port 443. That’s textbook beaconing — malware checking in with a command-and-control server. The regularity is the tell. Human-driven traffic is noisy and irregular; malware is punctual.
Your next move: reverse-lookup 203.0.113.17, run it through VirusTotal or Shodan, and check whether that destination appears in your threat intel feeds. Then isolate the full TCP stream by right-clicking any of those packets and selecting Follow > TCP Stream to see what data actually left the machine.
Extracting Credentials from Cleartext Protocols
Legacy protocols are still everywhere. FTP, Telnet, and basic HTTP auth transmit credentials in plaintext — and Wireshark captures every byte. This is as useful for defenders validating what’s exposed as it is dangerous in the wrong hands.
Here’s a real-world scenario: during a post-incident review, you find a PCAP from an internal file server, fs-legacy-01.corp.internal (192.0.2.12). You suspect an insider used FTP to exfiltrate data. Apply this filter:
ftp.request.command == "USER" || ftp.request.command == "PASS"Wireshark surfaces the FTP control channel and you see:
No. Time Source Destination Protocol Info
88 09:14:33 192.0.2.91 192.0.2.12 FTP Request: USER jdorman
89 09:14:33 192.0.2.12 192.0.2.91 FTP Response: 331 Password required
90 09:14:34 192.0.2.91 192.0.2.12 FTP Request: PASS S3cur3Pass!
91 09:14:34 192.0.2.12 192.0.2.91 FTP Response: 230 Login successfulUsername jdorman, password S3cur3Pass! — in the clear, timestamped, attributed to 192.0.2.91. Now follow the FTP-DATA stream to see which files were transferred. Use this filter to find data channel traffic:
ftp-data && ip.src == 192.0.2.91Right-click any FTP-DATA packet, follow the TCP stream, and use File > Export Objects > FTP-DATA to reconstruct transferred files directly from the PCAP. You just recovered the exfiltrated content without touching the endpoint.
Building a Timeline with Packet Statistics
Raw packets tell you what happened. Statistics tell you when and how much. For forensics, volume anomalies matter as much as content.
Navigate to Statistics > Conversations in Wireshark after loading your PCAP. Sort by bytes transferred. A healthy internal workstation rarely sends gigabytes of data to a single external IP. If 192.0.2.44 sent 4.2 GB to 203.0.113.17 overnight, that number alone is an incident.
For timeline reconstruction, use Statistics > IO Graph. Set the interval to 60 seconds and plot bytes per second. A flat baseline with a single massive spike at 02:00 AM tells a very different story than gradual traffic growth. Attackers often schedule exfiltration during low-visibility windows — IO Graph makes that visible in seconds.
Combine this with tshark (Wireshark’s command-line sibling) for scripting:
tshark -r capture-ws-fin-04.pcap -q -z conv,tcp | sort -k6 -rn | head -20This outputs the top 20 TCP conversations by packet count — sorted, ranked, ready for your incident report. No GUI required, runs on any Linux jump host.
What To Do Now
Open Wireshark on any machine on your network and capture five minutes of traffic during business hours. Apply the filter tcp.flags.syn == 1 && !tcp.flags.ack == 1 and sort the results by destination IP. Count how many unique external IPs your endpoints are initiating connections to — and check whether any of them repeat on a suspiciously regular interval. What you find in those five minutes will tell you more about your network’s real behavior than any asset inventory ever will.
