Packet analysis when the logs are not enough

Why this matters

Logs are summaries. Somebody decided in advance what was worth recording, and during an investigation you will regularly want something they did not choose. A packet capture is the raw article: every byte that crossed the wire, in order, with timing.

It is also expensive — in storage, in time to analyse, and in the privacy questions it raises. So the skill CS0-004 is testing is partly technical and partly judgement: knowing what a capture can settle that nothing else can, and not reaching for it when a flow record would have answered the question.

The lesson

Capture points, taps and span ports

Where you capture determines what you can possibly see — the vantage-point idea from lesson 3, applied at packet level.

• A network tap is a physical device inserted into a link. It copies every frame passively and does not drop traffic under load. It is the reliable option and requires touching cabling.
• A SPAN or mirror port tells a switch to copy traffic from selected ports to a monitoring port. Convenient, no cabling change, and it has real limitations: the mirror port can be oversubscribed and silently drop frames, and some switches deprioritise mirroring under load. A capture with gaps that nobody noticed produces confident wrong conclusions.
• Host capture on the endpoint itself sees exactly that host's traffic, including traffic to other VMs on the same host that never reaches a switch.
• Cloud packet mirroring does the same job inside a VPC, at a cost.
• Inline appliances — firewalls, IPS, proxies — can often export captures for traffic they already handle.

Placement questions to ask before capturing: is the traffic I want even routed past this point? Will I see both directions, or is routing asymmetric? Is there enough capacity? And for encrypted traffic, is there any decryption available here, or am I collecting metadata only?

Filtering to the conversation that matters

The default failure of packet analysis is opening a multi-gigabyte capture and scrolling. Filtering is the whole discipline.

Two kinds of filter, and mixing them up is a common confusion:

• Capture filters decide what gets written to disk. Applied before storage, so they save space and cannot be undone — anything excluded is gone.
• Display filters decide what you see in an existing capture. Applied afterwards, non-destructive, and far more expressive.

The general advice: capture broadly, filter on display. The exception is a long-running capture on a busy link, where an unfiltered capture is unusable — there, restrict by host or port at capture time and accept the trade.

A workable progression when you open a capture:

1. Start with a summary, not a packet. Protocol hierarchy and conversation statistics tell you what is in here and which pairs are talking most.
2. Narrow to the endpoint or port of interest.
3. Follow one conversation end to end.
4. Widen only when the conversation raises a new question.

Useful things to sort by early: total bytes per conversation (finds transfers), duration (finds long-lived sessions), and packet count with small average size (finds beacons — the shape from lesson 6).

Following a stream and reading a payload

Reassembling a conversation turns a list of packets into the exchange itself: the HTTP request and response, the SMTP dialogue, the plaintext protocol handshake.

What you can establish that logs often cannot:

• Exactly what was requested and returned, byte for byte — a proxy log records a URL, the stream contains the response body.
• Credentials in plaintext protocols, which is both a finding and a reason the protocol should be retired.
• The content of a transferred file, which can be carved out and hashed.
• Whether an attack succeeded. This is the recurring exam distinction: the log shows an injection attempt, and the stream shows whether the response contained data.
• Timing. Delays in a stream reveal blind injection and interactive shell use, where each keystroke produces a small packet.

Two cautions. Reassembly requires the capture to be complete — missing packets from an oversubscribed SPAN port produce partial streams that can mislead. And payload inspection means reading potentially personal content, which needs the same authorisation discipline the evidence lesson describes.

TLS: metadata, JA3 and what stays visible

Most traffic is encrypted, so most of the time you are analysing the envelope rather than the letter. That is less limiting than it sounds.

Still available in the handshake and the flow:

• Source, destination, ports, timing, and volume — enough for every behavioural technique in lesson 6.
• SNI, the server name the client asked for, unless encrypted client hello is in use.
• The server certificate: subject, issuer, validity dates, self-signed status. Certificates that are self-signed, very recently issued, or carry mismatched names are worth attention.
• Cipher suites and extensions offered by the client, which vary by software. Hashing that set produces a JA3 fingerprint, and the server side gives JA3S. Because the fingerprint reflects the TLS library rather than the domain, it identifies what kind of client is connecting even when everything else is encrypted — so a fingerprint that matches no approved software on that host is a strong signal, and it survives the attacker changing domains and addresses.
• Session duration and packet-size rhythm, which is how interactive shells and beacons remain recognisable.

Where decryption exists — typically outbound at a proxy, with exclusions for banking and health — you regain payload at the cost of complexity and a genuine privacy conversation. Certificate pinning breaks it for some applications, and that breakage is itself visible.

When a pcap is evidence and how to handle it

A capture can become evidence in a disciplinary matter, a legal case, or a regulatory response, and once it might, how you handled it from the start matters.

The practices, developed further in the evidence lesson:

• Hash the file on creation and record the hash somewhere separate.
• Work on a copy. Analysis tools can and do modify files.
• Record the provenance: where it was captured, by whom, on what device, with what clock, over what period. A capture with no recorded capture point is hard to interpret and easy to challenge.
• Note the completeness. Dropped-packet counters belong in the record; a capture with 8% loss supports weaker claims than one with none.
• Store it with access control. Captures contain other people's data.
• Mind retention and privacy obligations. Full packet capture of employee traffic engages privacy law in many jurisdictions and usually requires a documented basis, defined retention and restricted access. "We captured everything indefinitely, just in case" is a finding against you.

The judgement question the exam likes: when is a capture the right tool? The honest answer is when a specific question cannot be answered any other way — did this data actually leave, what exactly did the server return, what protocol is really running on this port. If flow records or endpoint telemetry answer it, use those: they are cheaper, already collected, and raise none of the above.

Topics this lesson owns

• [x] Capture points, taps and span ports
• [x] Filtering to the conversation that matters
• [x] Following a stream and reading a payload
• [x] TLS: metadata, JA3 and what stays visible
• [x] When a pcap is evidence and how to handle it