PCAP overview: protocols, conversations and hosts
Open a capture and see what is in it before reading a single packet: the protocol histogram, the busiest conversations, and whether credentials or flags are already sitting in plaintext.
Open in ctfpalA capture challenge is a haystack with a stated size. The first question is never 'what does packet 4,812 contain' - it is 'what kind of traffic is this, and where is the interesting part'. The overview answers that in one screen: which protocols appear and how often, which pairs of hosts did the talking, and how much of it there was.
Reading the histogram
The shape of a capture usually gives the challenge away before you look at anything. A capture that is 95% TCP on port 80 is an HTTP exercise. One with hundreds of DNS queries to subdomains of a single zone is exfiltration over DNS. One that is almost entirely ICMP is a tunnel, and the payload is in the echo data rather than the headers.
| What dominates | What it usually is | Where to go next |
|---|---|---|
| HTTP | File transfer, a login, or a web exploit in the clear | HTTP requests tab |
| DNS, many unique names | Exfiltration or a C2 channel | DNS queries tab |
| TLS | Encrypted, and the challenge will have handed you a key log | TLS keys tab |
| FTP / Telnet / POP3 / IMAP / SMTP | Credentials in plaintext, by design | Credentials tab |
| ICMP or unusual UDP ports | A tunnel; read the payloads, not the headers | Packet list tab |
| A single long TCP conversation | A shell, or a custom protocol | Follow TCP stream tab |
Conversations are how you find the one that matters
The conversation list groups packets by host pair and sorts by volume. In a capture with real background noise this is what separates the challenge traffic from the machine's ordinary chatter: the exercise is nearly always the pair with an unusual amount of data going one way, or the one talking to an address that appears nowhere else.
Formats
Both classic .pcap (libpcap, either byte order, microsecond or nanosecond timestamps) and .pcapng are read. Nothing is uploaded: the file is parsed in the page, and a capture full of somebody's credentials should not be going anywhere else anyway.
Common questions
- Is my capture uploaded anywhere?
- No. The parser runs in your browser and the file never leaves the page. There is no server to upload it to.
- How large a capture can it open?
- It is bounded by your browser's memory rather than by a fixed limit. Multi-hundred-megabyte captures are slow to render; the practical move for one of those is to cut it down with `editcap` or `tcpdump -r` first, which is also what you would do in Wireshark.