Wireshark Part 09 — Investigate suspicious traffic without jumping to conclusions

Triage unusual traffic with Wireshark using scoped patterns, benign alternatives, and corroborating evidence.

Series index · Previous: Device privacy · Next: Voice and media

The Hardware Ledger · 18 September 2026. Official documentation source-checked. This exercise has not been hardware-tested; described observations are expected examples, not measured results. Menu wording can vary by version.

Question: Does this saved trace contain activity that deserves investigation, and what evidence would distinguish an incident from normal software?

Outcome: A short triage note with three candidate patterns, packet references, alternative explanations, and the next corroborating log to request.

Wireshark shows who communicated, when, and how much traffic was observed. A large upload is not proof of theft; regular connections are not proof of malware. These patterns are leads to investigate, not verdicts.

The legitimate use is examining traffic you are authorized to investigate. The harmful use is surveilling other people, mapping their systems for an attack, or mining a capture for private material. Access to a capture file does not confer permission to use everything it contains. Keep analysis within the approved devices, dates, and purpose; stop if unrelated personal material appears. Do not contact suspicious destinations or execute captured files to “see what happens.”

Prepare a suitable trace

Use a saved capture from your own disposable lab or an instructor-provided, sanitized training PCAP. It should include a documented client address and several minutes of ordinary TCP/DNS traffic. No malicious sample is required: finding no evidence of any candidate pattern is a valid result. Keep the original private and work on a copy.

Record the capture point. An endpoint trace, a gateway trace after address translation, and a switch mirror can give different views. Ask whether both directions were recorded and whether packets were truncated or dropped. Start with Statistics → Capture File Properties, which exposes available interface, timing, capture, and file information; absent metadata does not prove a complete capture. Capture File Properties

Work through the evidence

  1. Define the subject. Open the copy with File → Open. Replace the documentation address in ip.addr == 192.0.2.10 with the training client’s actual address. For IPv6 use ipv6.addr == 2001:db8::10 with the actual address. Note the first and last relevant frame numbers and the available time span. A short trace may miss the beginning or end of an event.

  2. Inventory conversations. Open Statistics → Conversations, select TCP, and enable Limit to display filter if available. Compare destinations, destination ports, duration, and bytes in each direction. Sort a byte column to find large conversations. Record which endpoint is A and which is B before interpreting A→B. These are captured traffic totals, not a count of unique document bytes. Conversations

  3. Look for many connection attempts. Apply ip.src == 192.0.2.10 and tcp.flags.syn == 1 and tcp.flags.ack == 0, substituting the client address. For IPv6, replace the first clause with ipv6.src == 2001:db8::10, using the actual address. Compare destination addresses and ports. Repeated SYNs to one tuple may be retries; attempts across many different tuples may merit investigation. Select a candidate packet, expand TCP, find its stream index, then apply tcp.stream == N with that number. This restores both directions so you can inspect replies. A SYN-only display hides later acknowledgements. TCP field reference

  4. Check repetition over time. For a candidate peer, open Statistics → I/O Graphs. Add a graph with ip.addr == 192.0.2.10 and ip.addr == 192.0.2.20, replacing both addresses. For an IPv6 pair, use ipv6.addr == 2001:db8::10 and ipv6.addr == 2001:db8::20 with the actual addresses. Use Packets and a one-second interval initially. Repeat with a coarser interval if the trace is long. Look for recurring bursts, then inspect their packets; graph buckets can make uneven traffic look regular. I/O Graphs

  5. Check context rather than content alone. Keep the client scope: apply (ip.addr == 192.0.2.10 or ipv6.addr == 2001:db8::10) and dns.flags.response == 0, substituting its known addresses and omitting an address family if it is not in scope. Inspect visible DNS questions around the candidate event. Record relevant names and times privately. Encrypted DNS or caching may leave no matching question. A name in a packet is a clue to correlate, not proof that its owner is malicious. DNS field reference

  6. Build a competing explanation. For each lead, complete the following table using your observations. Correlate matching timestamps, endpoint addresses, and ports with authorized process/network logs, DNS logs, proxy records, or scheduled-job records. Account for clock differences and address translation before attributing a flow to a process or person.

Candidate pattern Possible concern Ordinary explanation to check
Many destination ports or hosts Scanning or discovery Approved inventory, monitoring, failed application retries
Recurring small exchanges Command-and-control check-ins Health checks, synchronization, software updates
Large outbound conversation Data leaving without approval Backup, video upload, cloud synchronization

Interpret and protect

Use wording such as “observed recurring connections; purpose unconfirmed.” A packet capture ordinarily does not identify the initiating process, a human’s intent, or encrypted file contents. Missing responses may reflect the capture point. Wireshark’s TCP analysis labels also depend on the recorded packet sequence; they are analytical findings rather than independent proof of network loss. TCP analysis

If corroboration supports an incident, pass the scoped evidence to the responsible response team and follow its containment process. Recommend changes tied to the finding: restrict an unexpected service, correct excessive application retries, or review an unapproved data transfer. Avoid broad blocking based only on a graph spike.

Completion criterion: Produce three rows, even if marked “not observed,” with the exact filter, time span, relevant frames, one plausible benign explanation, and the log needed to resolve uncertainty. A justified “inconclusive” completes this exercise.