PCAPs and Panic Attacks: Learning to Read the Network Without Crying

There comes a moment in every student’s or analyst’s life when they double-click a .pcap file and realise, with quiet horror, that they’ve just opened the digital equivalent of War and Peace, written in hexadecimal and performed entirely by arguing machines.

You scroll for a bit, see some IP addresses, something about DNS, a few angry red lines, and then you close Wireshark again, whispering “maybe next semester.”

But that .pcap file isn’t nonsense. It’s a diary. Every packet is a little gossiping note about what your devices have been up to, who they met, what they said, and whether they did something dodgy. Once you learn how to read it, you can reconstruct whole stories from it: everything from someone streaming YouTube to a malware sample phoning home to a suspicious domain in Iran.

The trick is to start thinking structurally, not packet by packet. Don’t open Wireshark and immediately zoom into line 12. You’ll drown. Instead, zoom out first, learn the lay of the land, identify the characters, and then follow the conversations.

This guide walks you through exactly that: how to make sense of a PCAP when you’ve never seen the network before.

The First Ten Minutes: Surveying the Battlefield

Before you can understand what’s happening, you need to get your bearings. Treat it like walking into a party, you don’t start by interrogating one guest about their life story; you step back, see who’s talking to whom, and gauge the general chaos level.

So, open your .pcap in Wireshark and resist the temptation to click on random packets. Instead, go to the top menu, Statistics -> Summary.

That’s your first snapshot of the “party.” You’ll see how long the capture ran, how many packets it contains, the data throughput, and perhaps most importantly, how big the file is. A 20 MB PCAP is a polite dinner conversation. A 2 GB PCAP is a nightclub brawl.

Next stop, Statistics -> Protocol Hierarchy. This will tell you which protocols dominate your capture. Maybe you’ve got 70 % TCP, 20 % UDP, and a sprinkling of ARP and ICMP. This gives you your first sense of what kind of network you’re looking at. A lot of HTTP and HTTPS traffic? Probably user browsing. A ton of SSDP and mDNS? You’re in IoT hell.

Then check Statistics -> Conversations. This feature lists all the “who talked to whom” pairs, by MAC address, IP, TCP port, and so on. You can sort by bytes to find the loudmouths in the room.

A good mental model here is a neighbourhood watch report: who lives on the street (endpoints), who talks to whom (conversations), and what kind of language they use (protocols).

Even this cursory glance can tell you a lot. You might notice one internal device talking to a DNS resolver every few seconds, normal. You might notice that same device quietly sending UDP packets to a random external IP every five seconds, not normal.

At this stage, you’re not analysing packets. You’re building a mental map. The trick is to get a sense of scale, rhythm, and pattern before you ever double-click a frame.

Who’s Who in the Zoo

Once you’ve got a rough overview, it’s time to identify the actors. Who are these machines, and what are they doing?

Start with the basics: ARP packets. ARP (Address Resolution Protocol) is how devices shout “who has 192.168.0.10?” and someone replies “that’s me, 00:11:22:33:44:55.” These exchanges reveal the local cast of characters.

You can filter them with arp and watch devices introduce themselves. It’s charmingly social, like watching a bad networking event.

Then look for DHCP traffic. DHCP handshakes tell you who joined the network, when, and which IP they got. If you see DHCP Discover and DHCP Offer messages, you can even guess the gateway’s address.

Once you’ve mapped the basics, move up to DNS queries. DNS is one of the most revealing protocols in any capture. Each query is effectively a machine saying, “I’m interested in this thing.”

Filters like dns.qry.name or dns.qry.name contains "facebook" are gold for quick reconnaissance. They show you what each device tried to resolve. Suddenly, your anonymous IPs have personalities: someone who watches YouTube, another who talks to api.spotify.com, and one suspicious little box that keeps resolving update.cn.

You can start inferring device types from their behaviour. IoT devices tend to be chatty with specific cloud endpoints. Phones often contact push notification servers. PCs open a wide range of ports and domains. Even without names or MAC vendors, the pattern gives them away.

Once you’ve found your main endpoints, use Statistics -> Endpoints to list them cleanly. Sort by bytes or packets. Your top talkers are usually the main storylines in your capture.

The goal here isn’t to label every IP with certainty, but to get an intuitive sense of who’s active and who’s suspiciously quiet. Think of it like profiling, not of people, but of machines with terrible communication habits.

Conversations and Storylines

By this point, you should have a good map of who’s in the room. Now it’s time to eavesdrop. Packets on their own are atomic, a single breath in a long sentence. What you really want is the conversation.

Wireshark makes this relatively easy. Under Statistics -> Flow Graph, you can see directional arrows representing who’s talking to whom over time. It’s messy but illuminating. Alternatively, right-click any packet and choose Follow -> TCP Stream. That opens a linear view of an entire conversation, every request, every response, neatly assembled in chronological order.

This is where things start to click. You’ll see patterns like:

1. A DNS request for example.com.
2. A TCP three-way handshake to the IP returned.
3. An HTTP GET request for /index.html.

That’s the internet in miniature: curiosity, connection, and consumption.

Try following one host through multiple streams. Maybe that IoT camera you identified earlier checks time.nist.gov for sync, then uploads to cloudcamvendor.com, and then, oddly, reaches out to an unknown IP on port 8080. You can watch that behaviour unfold across layers.

Temporal awareness also matters. Use the I/O Graph to visualise packet rates over time. Peaks often correspond to specific events: a file download, a device update, or an attack. Flat lines suggest idleness. Sudden bursts can indicate retries, floods, or someone suddenly watching 4K Netflix movie during your analysis.

When you start to correlate DNS lookups, TCP streams, and time patterns, you’re no longer just “reading” a PCAP. You’re reconstructing behaviour. It’s like digital archaeology, except the ruins are still live on your network.

Filtering for Meaning

Wireshark’s power isn’t in staring at packets, it’s in filtering out the noise.

Imagine you’re a detective in a crowded bar. You don’t listen to everyone at once; you tune your ear to the interesting bits. Filters are how you do that.

Start simple.

http.request
tcp.port == 80
tcp.flags.syn == 1 && tcp.flags.ack == 0
tcp.analysis.retransmission || tcp.analysis.lost_segment
dns.qry.name contains ".ru"

You can chain these filters together:

ip.src == 192.168.0.10 and dns.qry.name contains "update"

Think of filters as questions. “Who’s talking to external IPs?” -> ip.dst != 192.168.0.0/16.
“Who’s sending large packets?” -> frame.len > 1000.
“Who’s doing HTTPS without DNS first?” -> tls && !dns.

For more complex work, use Follow Stream again. You can see full HTTP requests and responses, or even reconstruct downloaded files via File -> Export Objects -> HTTP.

Colouring rules help too. Set TCP resets, retransmissions, or DNS queries to stand out. Your eyes are lazy, give them visual shortcuts.

The best analysts don’t scroll endlessly; they ask precise, filtered questions and let the data answer them.

Seeing the Matrix

After a while, the noise starts to fade, and the patterns come into focus. You’ll begin recognising common signatures without consciously thinking about them.

A device repeatedly sending ARP requests without getting replies? Duplicate IP or network loop. Constant small DNS queries to random domains every 60 seconds. Beaconing, likely malware or telemetry.
Long TCP streams to cloud endpoints with encrypted payloads? Probably normal HTTPS traffic, or exfiltration if it’s in the wrong direction.

At this level, PCAP analysis becomes more art than science. You’re interpreting context as much as packets.

Take broadcast storms, for instance. In a congested network, you’ll see waves of ARP or mDNS flooding across the LAN. Wireshark will show hundreds of nearly identical packets from different devices. That tells you the network’s noisy, maybe misconfigured, maybe just full of desperate IoT gadgets begging for attention.

Or take the classic “why is everything slow?” PCAP. Check for retransmissions (tcp.analysis.retransmission), or long tcp.time_delta > 1 values showing latency spikes. Maybe someone’s streaming, or maybe you’ve got packet loss from a dodgy switch.

Sometimes you’ll find darker things: DNS tunnelling (look for suspiciously long TXT records), data exfiltration disguised as HTTPS, or rogue devices impersonating DHCP servers.

The beauty of PCAP analysis is that it’s all there. Every packet is evidence. The challenge is knowing which patterns matter. And patterns are habits. Once you’ve gone through a few dozen captures, you start seeing the same archetypes repeat, like species in an ecosystem. The loud printer. The gossiping phone. The chatty smart TV. The sulking IoT bulb sending encrypted nonsense to a server in Singapore.

Eventually, you’ll stop consciously thinking about what to click. You’ll just see it. It’s not mystical, it’s familiarity layered on logic. At that point, you’ve learned to read the network like a book.

Scaling Up and Staying Sane

Of course, not every PCAP is friendly. Some are monstrous, gigabytes of raw traffic that will make Wireshark weep. When that happens, don’t even try to open it whole. Use editcap to slice it into smaller segments:

editcap -c 50000 bigcapture.pcap smallchunk.pcap

That chops the file into chunks of 50 000 packets each. For automation, there’s tshark, the command-line version of Wireshark:

tshark -r capture.pcap -Y "dns.qry.name" -T fields -e dns.qry.name

If you’re a data-science type, you can even feed PCAPs into Python with pyshark or convert them to CSV using tshark and explore them with pandas.

No matter the toolset, the method stays the same: summarise, identify, follow, filter, interpret. The rest is just tooling.

Seeing the Network for the First Time (Again)

When you start out, PCAPs are noise. Then you learn to read structure, Ethernet, IP, TCP, DNS, HTTP, and suddenly the noise becomes speech.

At first it’s tedious: you have to look everything up. Why is there a SYN/ACK? What’s TTL? Why are there ARP packets every few seconds? But slowly, it becomes intuitive. You’ll look at a trace and instantly recognise a DHCP handshake, a TCP timeout, or a client resolving a CDN domain.

This is what makes packet analysis oddly satisfying. You’re watching a living system communicate, part technology, part behaviour. Every packet is a clue about what’s happening somewhere you can’t see. A laptop syncing files. A printer screaming for drivers. A smart fridge asking for firmware. Or, occasionally, a compromised device whispering secrets to a remote server.

The PCAP is never just data, it’s evidence of behaviour. And once you learn to read it, you can’t unsee it.

You’ll be on public Wi-Fi and instinctively wonder who’s flooding the network with mDNS, and then, responsibly, you’ll resist the urge to actually check. Because as much as your inner analyst is dying to open Wireshark, capturing traffic on networks you don’t own or have explicit permission to monitor is not just bad manners, it’s most likely illegal.

In most countries, “open” doesn’t mean “free-for-all.” Even if a café’s Wi-Fi has no password, the data flying through it belongs to other people, and intercepting it can land you on the wrong side of privacy laws like the Computer Misuse Act (UK), GDPR (EU), or the Wiretap Act (US).

Stick to your own network, your own machine, or a controlled lab. Spin up a few virtual machines if you’re curious, it’s infinitely safer, and the only person whose traffic you’ll be violating is your own.

Better yet, there’s no shortage of legitimate PCAPs available online for practice. Sites like Wireshark’s Sample Captures, Malware-Traffic-Analysis.net, and PacketTotal offer ready-made scenarios, from clean web-browsing sessions to full-blown malware infections, all perfectly legal to explore. These let you sharpen your instincts without breaching ethics or the law.

Once you start thinking like a packet analyst, you’ll see networks everywhere, but remember, observation doesn’t require intrusion.

You’ll start running tcpdump just to see what your laptop is gossiping about, build tiny sandbox networks for fun, and catch yourself explaining to friends why their smart TV is probably phoning home to a server in North Korea.

You’ll have developed one of the most powerful analytical skills in cybersecurity: the ability to understand a network from raw observation alone. No dashboards. No context. Just packets.

That’s the real art of PCAP analysis, not knowing every protocol spec by heart, but being able to think like the network, and to do so responsibly.

So next time you open a capture and feel the panic rise, remember: you’re not staring at chaos. You’re staring at stories, and you already know how to read.

Closing Thought

In the end, packet analysis is a lot like therapy, except your client is the network, it never shuts up, and you’re billed in lost evenings instead of money. You’ll spend hours chasing a single IP through layers of encapsulation, only to discover it was a printer looking for toner. You’ll curse DHCP, develop irrational trust issues with DNS, and find yourself arguing with TCP retransmissions at 2 a.m. like they’re sentient.

But then there are those rare, blissful moments when everything clicks. You spot one weird handshake, follow the trail, and suddenly you’ve uncovered a misconfigured gateway, a malware beacon, or an IoT device that’s been tattling to a C2 server. You lean back, sip your cold coffee, and think, yeah, I understand the network now.

At that point, congratulations, you’re officially ready for your first SOC Analyst internship, where you’ll spend three months doing exactly this, only with more dashboards, more acronyms, and slightly less hope. Or perhaps you’ll volunteer to “help” your Uni’s IT department, which is to say, you’ll watch a switch loop itself into oblivion and quietly wonder why you ever thought networks were fun.

Still, there’s something weirdly addictive about it. Once you start seeing the patterns, you can’t unsee them. You’ll never trust a packet again, but you’ll also never look at a network the same way.

So the next time someone drops a .pcap on you and says, “Can you take a look?”, don’t panic. Take a deep breath, open Wireshark, and remember: it’s not chaos, it’s communication, just very badly organised.

And if all else fails, smile, nod, and say: “Looks like DNS.”