A DNS request may show which name a device tried to resolve. The packets that follow may show whether it connected to the returned address. Read together, they tell you more than an unfamiliar IP address on its own. Packet analysis means examining captured traffic—timing, endpoints, protocol fields, and sometimes content—to work out what happened on a connection.
In security work, a capture can help investigate an unexpected outbound connection, check a firewall rule, or tell a failed service apart from a failed name lookup. It records what was visible at one observation point, not everything a device did.
What a packet capture can show
A packet is a unit of data carried across a network. A capture file, often saved as PCAP or PCAPNG, contains packets observed by a capture interface. Wireshark displays decoded fields; command-line tools such as tcpdump can record traffic and apply capture filters. In a permitted lab, these tools let you compare what an application reports with what crossed the interface.
Read packets in layers. An Ethernet frame may show local hardware addresses. An IP header gives source and destination IP addresses. TCP or UDP adds port numbers; TCP also carries flags, sequence information, and acknowledgments. Higher-layer protocols may expose DNS questions or HTTP methods when those details are not encrypted. A protocol label is a decoder’s interpretation of the bytes it sees—not proof that the traffic is benign or that the application behaved as expected.
Metadata is not the same as content
With HTTPS, a capture generally shows connection metadata, such as endpoints, timing, packet sizes, and whether the transport is TCP or UDP. It does not reveal encrypted page contents or application messages. Some setup details may be visible, depending on the protocol and configuration. DNS names may be missing if the client used encrypted DNS or a cached answer. And a visible IP address does not necessarily identify the user-facing service: shared hosting, proxies, and content delivery networks make that inference unreliable.
Capture safely and with permission
Capture traffic only on systems and networks you own or are explicitly authorized to inspect. Capture files can contain personal information, internal hostnames, session identifiers, or unencrypted credentials. Collect only for as long as needed, restrict access to the files, and follow your organization’s retention rules. Before sharing a sample for troubleshooting, inspect it and remove sensitive details where possible. Even a screenshot may disclose names or addresses.
Where you capture matters as much as which tool you use. A capture on your laptop normally shows its own traffic and broadcasts it receives—not every conversation on a switched network. A server capture shows packets visible at that server’s interface; a capture inside a virtual machine may differ from one taken on its host. Interface offloading can also make local captures look different from packets on the wire. Record the interface, capture time, and test action before drawing conclusions.
For a first exercise, use a lab machine you control. Start a short capture on its active interface, request a page from a local test service or make an ordinary DNS lookup, then stop. Don’t collect unrelated household or workplace traffic just to get more examples. A small, repeatable capture is easier to read than a large file of background activity.
Follow one connection from start to finish
Start with a known event: an application tried to connect at a recorded time. In Wireshark, a display filter such as dns narrows the packet list without changing the saved file. Filtering on a known host address or TCP port can then isolate a possible conversation. A capture filter works differently: it decides what gets recorded. Set it too narrowly, and the missing context cannot be recovered from that file.
- Locate the request. Check the timestamp, client, and destination. If you can see a DNS question, match it to its answer; don’t assume the next IP address belongs to that name.
- Check connection setup. A typical TCP connection begins SYN, SYN-ACK, then ACK. A SYN with no visible reply suggests a different problem from a reply that resets the connection. Neither pattern establishes the cause by itself.
- Inspect what happens next. Look for an application request or encrypted session setup, any response, and whether either side closes the connection. Note delays and repeated transmissions.
- Compare with expectations. Do the destination, port, and timing fit the action you performed? If not, collect another controlled sample before assigning a security explanation.
Source and destination IP addresses, source and destination ports, and the protocol can identify one TCP conversation among several connections to the same service. Those values do not tell you which process made the connection. For that, compare the capture with authorized endpoint logs or operating-system connection information.
Recognize common patterns without overclaiming
| Observation | Reasonable next check |
|---|---|
| DNS query has no visible answer | Confirm the capture includes the return path and check resolver logs or retry timing. |
| Repeated TCP SYN packets | Check routing, firewall policy, and whether replies are visible at the capture point. |
| TCP reset after connection setup | Identify which endpoint sent it and compare with service and application logs. |
| Retransmissions or long gaps | Check loss, congestion, and capture limitations before calling it malicious. |
One symptom can have several causes. Missing replies might mean a blocked path, an offline destination, asymmetric routing, or an incomplete capture. Frequent connections to an unfamiliar endpoint might be an ordinary software update. Packet data is more convincing when it lines up with DNS records, system logs, configured application destinations, and the time of a known user action.
Use filters to answer narrow questions
Choose display filters to answer a specific question. dns shows decoded DNS traffic; tcp.port == 443 selects TCP packets using port 443; ip.addr == 192.0.2.10 selects packets involving that example address. A port does not prove which application protocol is in use, and a DNS filter will not reveal lookups inside encrypted transport. Keep the unfiltered capture so you can revisit your assumptions.
When documenting a finding, record the filter, relevant packet timestamps, and observation point. Keep what you saw separate from what you think it means. “The client sent three SYN packets with no reply visible in this capture” is supportable; “the remote server blocked the client” needs more evidence. That distinction keeps the report useful if later checks change the explanation.
Limits that matter in security investigations
Packet analysis alone cannot prove intent, identify a person, or reveal encrypted payloads. Sampling, dropped packets, incorrect clocks, network address translation, and a capture taken on only one side can distort the picture. If a tool flags malformed packets, check for capture loss or interface offloading before treating the warning as a sign of hostile activity.
Try capturing one DNS lookup and one connection to a service you control. Save the file, then write four lines: the capture interface and time; the DNS question and answer, if visible; the TCP setup result; and one limitation of your observation. If the DNS answer is missing, note that it is missing. Don’t fill the gap by guessing from the destination IP.
