Packet Capture Basics: A Careful Wireshark Workflow
Plan a safe packet capture, distinguish capture and display filters, and interpret DNS, TCP, and TLS evidence without overclaiming.
Start with a question and scope
Packet analysis is most useful when it answers a specific question: did a client resolve a name, complete a TCP handshake, retransmit data, or receive an application response? Capturing everything without a question produces a large file and encourages unsupported conclusions.
Capture only traffic you own or are authorized to inspect. Select the correct interface, record the test time and network context, and avoid collecting unrelated user traffic. Packet captures can contain personal or operational information; protect, minimize, and delete them according to your organization’s retention rules.
Capture filters and display filters
A capture filter limits what is recorded and uses Berkeley Packet Filter syntax. For example, `host 192.0.2.10` limits a capture to traffic involving that documentation address. A display filter is applied after capture and uses Wireshark’s expression language; `ip.addr == 192.0.2.10` is a common display-filter form.
The two languages are not interchangeable. If a capture filter excludes a packet, a later display filter cannot bring it back. When uncertain, collect a short, tightly scoped capture and then refine the displayed evidence.
Example display filters:
dns
tcp.flags.syn == 1
ip.addr == 192.0.2.10
http.requestFollow a connection in layers
Begin with the endpoint and protocol summary. For a TCP connection, look for SYN, SYN-ACK, and ACK. A missing SYN-ACK may indicate filtering, a routing issue, or a service that is not responding, but a capture from only one side cannot prove which one. Compare captures at relevant points when you have permission.
For DNS, check the query name and response code, then note whether the answer is an address, a referral, or an error. For TLS, packet metadata can show connection setup, certificates in some handshake versions, and timing, but encrypted application payloads are not readable merely because a packet analyzer is being used.
Avoid common interpretation errors
A retransmission is evidence of a delivery or acknowledgment problem, not automatically evidence of a malicious actor. Check capture drops, interface load, offload behavior, and whether the capture point sees both directions. Similarly, a TCP reset can be sent by an endpoint or an intermediary; use surrounding packets and endpoint logs to establish context.
Record observations separately from hypotheses. For example: “The client sent three SYN packets and no SYN-ACK was visible at this interface” is an observation. “The server is compromised” is not supported by that observation alone.
- Use a short capture window and a written question.
- Check both directions and identify the capture point.
- Correlate packet timestamps with endpoint and service logs.
- Redact sensitive addresses and payloads before sharing a capture.
References and further reading
Use primary standards and vendor documentation to verify details and explore the subject further.
Practise this in a safe environment
Reading a guide changes your understanding; practising changes your reflex. The ByteBreach practice labs run in an isolated sandbox inside the browser, so you can apply the same reasoning without touching infrastructure that belongs to somebody else. The learning paths that surround each topic give you the theory in the order it is needed, and the resource vault holds the command syntax so you do not have to reconstruct it from memory in the middle of an exercise.
If you are applying any of this to a live system, confirm first that you are authorised to do so. The educational disclaimer explains the difference between an authorised engagement and an intrusion, and the terms and conditions describe the limits we place on how the material may be used.
Related ByteBreach material
This guide is one part of a larger body of published work. The field guides index lists every guide in the library, the learning paths catalogue shows how the underlying theory is sequenced, and the frequently asked questions cover the platform mechanics such as XP, rank tiers, and how flags are validated. If you want to report an error in this guide, the contact page reaches a maintainer directly.
ByteBreach guides are independently written educational material and are not official certification-provider documentation. Always verify configurations against the documentation for your software and equipment.