threat hunting a pcap with tshark

packet captures feel intimidating until you realize they're just a giant pile of "who talked to who, and what did they say." wireshark's gui is great for digging into one weird packet, but when you've got a multi-gigabyte pcap and you're hunting for a needle, you want tshark. same engine, no windows to click through, and it scripts beautifully. here's how to actually threat hunt with it on your own network captures.

start with top talkers

before you look at any single packet, you want the big picture. who is sending the most traffic, and who is receiving it. a compromised host doing beaconing or exfil usually stands out once you sort by volume or connection count.

tshark -r capture.pcap -q -z conv,ip

this dumps every ip conversation with packet and byte counts. look for a host inside your network that's talking to an ip it has no business talking to, especially if that connection repeats on a suspiciously regular interval. regular, low and slow traffic to one external ip is a classic c2 pattern.

dns is where malware trips over itself

legit domains are short and readable. malware using a domain generation algorithm (dga) spits out long strings of near-random characters because it's trying to stay ahead of blocklists. filtering dns traffic and eyeballing the queried names is one of the fastest ways to catch a beacon.

tshark -r capture.pcap -Y "dns" -T fields -e frame.time -e ip.src -e dns.qry.name

you're scanning for domains that look like keyboard mash, high entropy, no vowels in the right places, or a pile of subdomains that all resolve to the same weird thing. also watch for a huge volume of NXDOMAIN responses, that's a sign something is grinding through a domain list trying to find its live c2.

http host and user-agent, the lazy malware giveaway

a lot of malware still phones home over plain http, and a lot of it uses a user-agent string that nobody's real browser would ever send. chrome, firefox, edge, they all have long, boring, consistent ua strings. malware authors often hardcode something short, outdated, or just plain wrong.

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

run this and scroll the list. anything using "curl", a bare python-requests string, an ancient IE user-agent on a network with no windows xp boxes, or a host header that doesn't match any site your org actually uses, that's worth a closer look.

follow the stream, read it in the clear

once you've flagged a suspicious conversation, stop looking at field-by-field output and just read the conversation like a chat log. tshark can reconstruct the full tcp stream for you.

tshark -r capture.pcap -q -z follow,tcp,ascii,0

swap the last number for the stream index you care about. if the traffic isn't encrypted, you'll see the raw http request, headers, and response body, which is often enough to confirm it's a c2 checkin, a data exfil upload, or a benign false alarm. if it's tls, you obviously won't get plaintext, but the metadata (sni, cert details, ja3 if you're pulling that separately) still tells you a lot.

the takeaway

tshark isn't a hacking tool, it's a magnifying glass for traffic that already crossed your wire. the whole point of running this on your own network is to shrink the time between "something's off" and "here's the host, here's the process, here's the fix." capture traffic at a span port or your gateway, keep pcaps rotated so you actually have history to hunt through when an alert fires, and get comfortable running these four checks as a routine, not a last resort. if you find a host with a beacon pattern, isolate it, pull it off the network, and start your incident response from there. the tool is free, it's scriptable, and it sees everything, which means so can you, as long as you're pointing it at your own house.