First ten minutes with a packet capture
A packet capture usually arrives the way incidents do: unexpectedly, in the middle of something else, with a question attached that is either "is this host compromised?" or "why is this slow?" The file may hold a million packets; the answer is almost always visible in the first ten minutes, if the minutes are spent in the right order. This is that order.
Minute zero: keep the evidence where it is
Before any question gets answered, one rule: a capture is evidence, and evidence is not uploaded to random online analysers, pasted into AI chats, or attached to public tickets. It contains your internal addressing, your hostnames, your traffic patterns — and, on any network with legacy protocols still breathing, literal passwords in cleartext. Whoever holds the capture holds that map. So the triage below is done locally, on the machine that took the capture or one you control. The PCAP analyser on this site is built for exactly this: it parses the file in the browser tab and transmits nothing, so the triage cannot become the leak. Whatever tool you use, verify that property before the file leaves your disk — and if the answer is a shrug, keep the file home and use Wireshark.
Minutes one to three: conversations first
Resist the packet list. A million rows of individual packets answer nothing; aggregated conversations answer the first question — who talked to whom, how much, and in which direction? Sort flows by bytes and read the top of the table the way you would read a bar tab. Three shapes matter. Asymmetry: a workstation that downloaded 4 MB and uploaded 900 MB is telling you a story no content inspection needs to finish. Strangers: the long conversation with an address that belongs to no service anyone can name outranks everything else in the file. And rhythm, once you look at timing: a small flow that repeats at exact intervals, indifferent to working hours, is beacon-shaped, and machines do not keep metronome schedules by accident. Note what the flow table cannot say — a busy flow to your backup provider is the same shape as exfiltration to a stranger's server — which is why the next step is names.
Minutes four to six: DNS, because names are intent
IP addresses are where traffic went; DNS is what the host meant to reach. Read the query list as a diary: every name the machine asked about, in a form you can say out loud. Legitimate diaries are boring — update servers, licence checks, the SaaS the department pays for. The entries that matter read differently: a freshly-registered-looking domain nobody recognises, a dynamic-DNS hostname, a name that does not resolve (error responses are a signal too — malware checking in to a domain that was taken down still leaves the question in your capture). Two habits pay off here. Read the answers as recorded at capture time, because DNS changes — the capture freezes what the name pointed to then, which may not be what it points to now. And follow the diary back to the flows: a name is an accusation, the matching conversation's volume is the evidence.
Minutes seven to eight: SNI and JA3, the metadata encryption leaves behind
Most of the interesting traffic will be TLS, and the instinct is to skip it as unreadable. Skip the content, not the connection. The ClientHello still announces the server name in the SNI extension — the hostname the client asked for, visible to any observer, which is precisely what it was designed to be. And the same hello fingerprints the client: JA3 reduces its offered TLS version, cipher suites, extensions and curves to one hash, and client software has habits — the JA3 of a browser differs from the JA3 of a Python script, which differs from the JA3 of the thing you are hunting. SNI tells you the destination's name even when DNS was encrypted or cached; JA3 tells you what kind of thing made the connection. Neither tells you what was said. Claiming otherwise — products that promise to "see inside" encrypted traffic from a passive capture — is marketing, and the honest boundary is part of the workflow: metadata narrows the suspect list; it does not read the mail.
Minutes nine and ten: the cleartext surprises
Last, read what the network said out loud. On a healthy modern network this section is empty; on real networks it is where the unrelated incident hides. An HTTP request to an internal admin panel — with a Basic authentication header, which is the password wearing a name tag. An FTP login, password and all, from a backup script older than the person reading the capture. A mail submission authenticating without TLS. Each of these is a finding independent of the question the capture was taken to answer: a credential that crossed the wire readable by anyone positioned to record it must be treated as a credential that has been recorded, and rotated — not because this capture proves an attacker saw it, but because you can no longer prove one did not. The analyser flags the patterns it recognises; the honest caveat, which it prints next to the list, is that a clean result is the absence of sightings, not the absence of leaks.
When to stop triaging
Ten minutes buys a map: the talkers, the names, the clients, the leaks, and usually the one flow that deserves the next hour. That hour belongs in Wireshark — following a single TCP stream, decoding a protocol this page does not speak, applying a key log you hold under proper control. Triage is not a substitute for dissection; it is how you choose what to dissect. Keep the capture, note the timestamps of the flows you followed, and write the IOC list — addresses, domains, URLs, defanged — into the ticket, so the next person starts at your minute ten instead of your minute zero. And if the map comes back entirely ordinary, believe it: most captures are innocent, and saying so in ten minutes is also the job.
Frequently asked questions
My capture shows giant packets, thousands of bytes long. Is that real?
Probably not — it is segmentation offloading. When you capture on the sending host itself, tcpdump sees packets before the network card splits them into MTU-sized frames, so they appear as single 64 KB monsters with impossible checksums. The traffic on the wire was normal. Captures taken on a span port, tap or another machine show true frame sizes. It does not change the triage order here — flows, DNS, names, cleartext — but it is why per-packet sizes from a host capture should not be quoted as wire facts.
Everything is TLS. Is the capture useless?
No — it is shorter, not empty. Encryption hides content, not existence: the conversations still show endpoints, volumes and timing; DNS still shows what was asked for; SNI still names most services; JA3 still characterises the client. A beacon shows up as rhythm, not content. What you lose is the payload question — what was sent — and answering that needs endpoint logs or a key log in Wireshark, not a bigger capture.
Can I share a capture with a colleague or a vendor?
Treat it like a credential file, because it may literally contain credentials. Share it the way you would share a private key: encrypted, to a named person, for a stated purpose, and deleted afterwards. Never attach one to a public ticket or paste extracts into a public forum; the addresses and hostnames alone map your network. If you only need to share findings, share the IOC list and the flows table — that is what the export on the analyser is for.