What a Packet Capture Gives Away

A capture taken on a network you control is the most honest description of that network you will ever get. It records what was actually sent, not what the documentation says should have been. That is what makes it useful, and it is also why a capture file is sensitive enough to handle carefully.

Here is what a few minutes of traffic exposes, roughly in order of how badly it hurts.

Credentials in the clear

Some protocols carry authentication in plaintext by design. If they are on your network, anyone capturing has the credentials:

FTP — username and password as plain commands.
Telnet — the entire session, keystroke by keystroke.
HTTP — form posts, session cookies, Basic authentication (base64 is encoding, not encryption).
SMTP, POP3, IMAP without TLS — mailbox passwords and message bodies.
SNMP v1 and v2c — the community string, which is effectively a device password.
LDAP without TLS — simple bind sends the password directly.

The uncomfortable finding is rarely a user's browser. It is a backup job, a printer, a monitoring agent or a piece of building equipment that has been authenticating in plaintext across the network for years.

Where everyone went, even over HTTPS

Encryption protects the contents. It does not hide who you talked to, and two things leak the destination:

DNS. Traditional DNS is unencrypted, and every connection starts with one. A capture containing DNS queries is a browsing history, regardless of how well the traffic that followed was encrypted.

TLS SNI. During the handshake, before encryption is established, the client states the hostname it wants in the Server Name Indication field, in the clear. Encrypted Client Hello fixes this and is not yet widely deployed.

So "we use HTTPS everywhere" and "an observer cannot tell what our staff are accessing" are two different claims, and only the first is usually true.

The shape of the traffic

Even with contents and hostnames hidden, metadata remains: which hosts talk to which, how much, how often and when. This is enough to identify a device beaconing to a command-and-control server on a fixed interval, spot an unexpected outbound connection from a server that should never initiate one, or see a data transfer far larger than anything that job should produce.

Volume and timing are frequently the only evidence available for well-encrypted malicious traffic, which is why they are worth looking at even when nothing is readable.

Internal structure

Broadcast and discovery traffic maps the network without anyone having to scan it. ARP reveals the local address space and MAC addresses; the first three bytes of a MAC identify the hardware vendor. mDNS and NetBIOS announce hostnames and often the device owner's name. DHCP exchanges carry hostnames and vendor identifiers. Any of these tells an attacker what is on the network and what it runs.

Reading one without drowning

A few minutes of traffic on a busy network is hundreds of thousands of packets. Nobody reads them in order. The approach that works is top-down:

Protocol breakdown first. What is on this network at all? Anything unexpected here is worth more attention than anything expected.
Then the conversations, sorted by bytes. The heaviest talkers are a handful of pairs. Recognise them or investigate them.
Then the plaintext, filtered by protocol. Go looking for the unencrypted protocols above specifically.
Then DNS, as a list of every name resolved. Fastest route to "why is this host asking for that domain?"
Only then individual packets, once you know which conversation you care about.

Two practical notes. A capture taken on a switched network with no port mirroring shows only traffic to and from the capturing machine plus broadcasts — if you expected to see other hosts and did not, that is why. And a truncated capture, taken with a small snapshot length, has headers but no payloads, which limits what you can conclude.

Treat the file as sensitive

A capture may contain credentials, session tokens, personal data, internal addressing and the contents of unencrypted messages. It deserves the same handling as a password database:

Capture only what you need, for as short a period as possible.
Do not upload one anywhere you have not read the retention policy.
Delete it when the investigation is done.
Capturing traffic on a network you do not own or administer is, in many places, illegal.