PCAP → Flows CSV

This tool collapses a packet capture into flows and hands you a CSV. Upload a PCAP or PCAPNG, optionally narrow it with a Wireshark display filter, and you get a sorted table of conversations with byte and packet totals — the view you want when the question is “what is actually using this link?” rather than “what is in packet 4,812?”

A flow here is the classic 5-tuple: source IP, destination IP, source port, destination port and transport protocol. Every packet sharing those five values folds into one row. A 200 MB capture of a file transfer collapses to a handful of rows; a browsing session might reduce 40,000 packets to 300 flows. That compression ratio is information in itself — a capture that barely collapses is full of short-lived connections, and short-lived connections at scale is what scanning and beaconing look like.

The reason to use this instead of opening Wireshark is the output. Statistics → Conversations gives you the same aggregation, but getting it out cleanly, sorting it the way you want and pasting it into a ticket is fiddly, and the GUI struggles on multi-gigabyte files. A CSV drops straight into a spreadsheet or a pivot table, and you can produce one from a browser on a machine where installing a packet analyser is not an option — a jump host, a customer’s laptop, a locked-down build agent.

The filter box takes Wireshark display filter syntax, not BPF capture filter syntax, and mixing them up is the single most common mistake. tcp.port == 443 works; port 443 does not. Useful starting points: ip.addr == 10.0.0.5 for everything to and from one host; !(ip.addr == 10.0.0.0/8) to drop internal chatter and see what left the network; tcp.flags.syn == 1 && tcp.flags.ack == 0 to isolate connection attempts; dns to look only at name resolution; and a frame.time range to window an incident down to the minutes that matter.

Sort by bytes to find bulk movement — backups, image pulls, a database replicating, or data going somewhere it shouldn’t. Sort by packets to find behaviour. A port scan produces thousands of tiny packets spread across destination ports; a command-and-control beacon produces a small, regular flow that repeats on an interval; a broken retransmission loop produces enormous packet counts carrying almost no data. The derived number worth eyeballing is bytes per packet: anything close to the MTU is bulk payload, anything near 60 bytes is control traffic, handshakes, or scanning.

Turning on DNS names maps addresses back to hostnames using the DNS responses contained in the same capture. That is deliberate — it shows what the host on the wire actually believed at the time, rather than what the address resolves to today, which is what you want when investigating something historical. The consequence is that flows to hard-coded addresses, or connections reusing an answer cached before the capture started, stay numeric. A numeric row is not suspicious by itself, but a numeric row to an external address on an odd port is worth a second look.

A few edges change how you read the results. UDP has no connection, so a QUIC or DNS “flow” is a time-bounded grouping rather than a session, and long-lived QUIC traffic may appear as one row where TCP would have given you several. A capture taken outside the NAT boundary shows translated addresses, so the internal host that generated the traffic is invisible. A small snaplen gives accurate packet counts but understated byte totals, because payloads were clipped at capture time. And if the capture came from a switch port without a SPAN or mirror configured, you are only seeing broadcast traffic and your own — the top-talker list will be confidently wrong.

This is a summarisation tool and stops where the summary stops. It will not reassemble TCP streams, decode application payloads, decrypt TLS, or tell you what was inside a transfer; once a flow looks interesting, open the capture in Wireshark and follow the stream. Uploads are processed to produce the CSV and are not retained. Treat any capture as sensitive regardless of where it is analysed — cleartext protocols in an old capture routinely contain credentials, session tokens and internal hostnames.