In 2024, the Volt Typhoon campaign showed exactly how attackers blend into legitimate network traffic — living off the land, using built-in tools, generating packets that look almost normal. Almost. Wireshark remains the best free tool for pulling those packets apart and finding what doesn’t belong. Here’s how to actually use it.
Cutting Through Noise with Display Filters
Wireshark captures everything. Without filters, a busy network produces hundreds of thousands of frames in minutes. Display filters let you isolate exactly what matters — a specific host, protocol, or behavioral pattern.
Say your IDS flagged suspicious outbound traffic from workstation ws-finance-04 at 192.0.2.47. You’ve loaded the PCAP. Start here:
ip.addr == 192.0.2.47 && tcp.flags.syn == 1 && tcp.flags.ack == 0
This filter shows every new TCP connection initiated by that host — SYN packets only, no ACKs. The output might look like this in Wireshark’s packet list:
No. Time Source Destination Protocol Info
14 0.000000 192.0.2.47 192.0.2.201 TCP 52341 → 443 [SYN]
31 0.412003 192.0.2.47 192.0.2.201 TCP 52342 → 443 [SYN]
48 0.824011 192.0.2.47 192.0.2.201 TCP 52343 → 443 [SYN]
65 1.236019 192.0.2.47 192.0.2.201 TCP 52344 → 443 [SYN]
...
A new SYN to the same destination every 412 milliseconds — that’s beaconing. A human isn’t clicking that fast. Legitimate software doesn’t reconnect at perfectly timed intervals like a metronome. This pattern screams C2 callback.
Your next move: right-click any of those packets, select Follow → TCP Stream, and inspect the payload. If TLS is in play, pivot to checking the certificate details — specifically the Subject Alternative Names and issuer. Self-signed certs to an IP address with no hostname are a red flag every time.
Hunting Credential Exposure in Cleartext Protocols
Cleartext protocols still exist in the wild. FTP, Telnet, basic HTTP auth — sysadmins inherit legacy infrastructure, and attackers know exactly where to look. During a post-incident review of a manufacturing client, we found credentials walking across the wire in plain sight.
Load the PCAP and apply this filter to isolate FTP control channel traffic:
ftp.request.command == "USER" || ftp.request.command == "PASS"
Here’s what that looks like in the packet details:
Frame 203: FTP Request: USER mrodriguez
Frame 207: FTP Response: 331 Password required
Frame 208: FTP Request: PASS S3cur3Fact0ry!
Frame 212: FTP Response: 230 Login successful
Username mrodriguez, password in cleartext, successful login. An attacker with a tap on that network segment has valid credentials with zero effort. From a forensics perspective, this also tells you the attacker’s lateral movement path — check what files were transferred next using the ftp-data filter.
To see exactly what was uploaded or downloaded, follow the FTP-DATA TCP stream. Wireshark will reconstruct the transferred file. If it’s a script or binary, you’ve just found the attacker’s tooling.
Reconstructing an Exfiltration Event with Statistics
Volume matters. An attacker exfiltrating a database doesn’t just generate suspicious packets — they generate a lot of them. Wireshark’s built-in statistics surface this fast.
Go to Statistics → Conversations and sort by bytes. During one investigation on a segmented R&D network, this stood out immediately:
Address A Address B Bytes A→B Bytes B→A Duration
192.0.2.88 192.0.2.9 1.2 GB 22 KB 00:04:33
192.0.2.88 192.0.2.14 890 MB 18 KB 00:03:51
192.0.2.88 192.0.2.23 744 MB 9 KB 00:03:12
Over two gigabytes leaving 192.0.2.88 in under five minutes, with almost no return traffic. That asymmetry is the signature of data exfiltration. Legitimate file sync services send traffic in both directions. This looks like a one-way firehose.
Drill into those conversations using the filter ip.src == 192.0.2.88 && ip.dst == 192.0.2.9, then follow the TCP stream. Look at what port is being used. Port 443 with a suspicious cert? DNS over a non-standard port? The stream content tells you the exfil channel being abused.
From here you’d correlate the timestamp against endpoint logs — what process on 192.0.2.88 owned those connections? EDR telemetry, Windows Event ID 5156, or Sysmon’s network connection events will name the binary.
What To Do Now
Open Wireshark today and capture five minutes of traffic on your own workstation. Apply the filter tcp.flags.syn == 1 && tcp.flags.ack == 0 and look at every destination your machine is connecting to. Sort by destination IP, look for patterns, and ask yourself: do I recognize every single one of those endpoints? Most security professionals are surprised by what they find — and that’s exactly the point.
