Packet Capture Tools and Methods

Wireshark is the most widely deployed open-source network protocol analyser. It captures live traffic through the libpcap library (WinPcap or Npcap on Windows) and dissects packets from more than 3,000 protocols, displaying fields in a three-pane GUI: the packet list, the decoded field tree, and the raw hex view. Wireshark can also read pre-captured files from tcpdump, tshark, and commercial tools. Its display filter language (dfl) allows precise selection of packets by protocol, address, field value, or content match. Filters such as 'http.request.method == "POST"' or 'tcp.flags.syn == 1 and tcp.flags.ack == 0' isolate specific traffic patterns without modifying the underlying capture file.

For forensic work, Wireshark's Follow Stream function reconstructs the full byte sequence of a TCP or UDP session, allowing the analyst to read transferred files, commands, or messages as they appeared to the application. Export Objects extracts files transferred over HTTP, SMB, or FTP directly from the capture. The Statistics menu provides conversation summaries, endpoint lists, and protocol hierarchy breakdowns that orient the analyst quickly in a large capture. Wireshark does not modify the source PCAP file; all analysis operations read from the file without altering it, which satisfies the non-modification requirement for forensic evidence.

Wireshark requires root or administrator privileges to open a live capture interface. On Linux, the setcap utility can grant capture capability to the Wireshark binary without running the entire application as root, which is preferable on investigator workstations. On Windows, Npcap must be installed and its driver service running. In both cases, the capture interface should be placed in promiscuous mode and, where applicable, in monitor mode for wireless capture.

tcpdump is a command-line packet capture utility available on virtually every Unix-like operating system, including Linux, macOS, FreeBSD, and the embedded Linux found in many network devices. It uses the same libpcap library as Wireshark and writes PCAP-format files. Because it has no GUI, tcpdump is the standard choice for capturing on headless servers, virtual machines, and network appliances. A typical forensic capture command is: 'tcpdump -i eth0 -w /evidence/capture-2024-01-15.pcap -s 0' which captures all traffic on eth0, writes full-size packets (snaplen 0), and saves to a named file. Adding a BPF expression restricts capture to specific hosts or ports.

tshark is the terminal-mode equivalent of Wireshark's dissection engine. It can both capture and analyse, outputting decoded fields as plain text or JSON, which makes it suitable for scripting and pipeline integration. The command 'tshark -r capture.pcap -T fields -e ip.src -e ip.dst -e http.request.uri' extracts source IP, destination IP, and HTTP URI from every HTTP request in a capture file. This output can be piped to grep, awk, or Python for rapid triage without loading the full file into a GUI.

For very high-speed links (10 Gbps and above), both tcpdump and Wireshark may drop packets because the kernel cannot buffer frames fast enough for user-space processing. Purpose-built high-performance capture solutions use kernel bypass techniques such as AF_PACKET TPACKET_V3 on Linux, PF_RING, or DPDK. These frameworks allow packet data to be written directly to ring buffers mapped into user space, bypassing the normal network stack. Investigators encountering high-speed capture requirements should evaluate tools such as ntopng, Zeek (formerly Bro), or commercial appliances from vendors such as Netscout or Corelight.

A SPAN port (also called a mirror port) is configured on a managed switch to copy frames from one or more source ports, or from a VLAN, to a designated monitoring port. The analyst connects a laptop or dedicated capture appliance to the monitoring port and runs a capture tool in promiscuous mode. SPAN configuration is done through the switch's management interface and requires no physical cable changes after initial setup, making it the fastest way to begin capturing in an enterprise environment where physical access to cable paths is difficult.

SPAN has four documented limitations that investigators must understand. First, the switch processor implements mirroring in software; under heavy load the processor prioritises forwarding over mirroring, and the monitoring port may receive fewer packets than actually traversed the source ports. Second, some switches do not mirror error frames (frames with CRC errors or undersized frames), which may be forensically relevant in certain attack scenarios. Third, bidirectional SPAN (copying both ingress and egress on a port) can exceed the monitoring port's bandwidth if the source port is near line rate, causing additional drops. Fourth, a SPAN configuration that was not present before the investigation leaves a change record on the switch, which the opposing party may scrutinise in litigation.

A network tap is a hardware device that sits physically inline in the cable path between two network devices. It passes the signal between its two inline ports (maintaining the original connection) and simultaneously copies the signal to one or more monitoring ports. Passive optical taps split the light signal with no active components and consume no power from the network path; they are completely transparent and invisible to the devices on either side. Active regenerating taps are used on copper links where passive splitting is not practical and introduce minimal latency, typically under 5 microseconds.

The principal forensic advantage of a tap over a SPAN port is completeness. Because the tap operates at the physical layer, it copies every bit on the wire, including error frames, malformed packets, and traffic during link negotiation. It does not drop packets under load because the monitoring port output is independent of the switch processor. For investigations where completeness of capture is critical, such as reconstructing a data exfiltration or proving the exact sequence of an intrusion, a hardware tap is the preferred collection point. Common vendors include Garland Technology, Ixia (now Keysight), and Gigamon.

The operational disadvantage is installation. Inserting a tap requires breaking the cable connection, which causes a brief link interruption. In a production network this must be coordinated with the network team and, in some organisations, approved through change management. Inline taps also introduce a physical single point of failure on the monitored link: if the tap hardware fails, the link fails. Bypass taps with fail-safe relays mitigate this by restoring the direct cable connection if the tap loses power, but they add cost and complexity.

Where a capture device is placed determines what evidence it can collect. No single placement captures all forensically relevant traffic in a modern enterprise network, so investigators must match placement to the specific investigation question. A perimeter capture point (at the firewall or internet gateway) captures all traffic entering or leaving the network and is the correct placement for investigating external attacks, command-and-control communications, or data exfiltration to an external destination. It misses all traffic that stays within the internal network, including lateral movement and internal data transfers.

A core switch capture point, using a SPAN port or tap on a link carrying aggregated internal traffic, captures both internal lateral movement and external traffic passing through the core. The trade-off is volume: core links on a large network carry terabytes per day, requiring high-performance capture hardware and large storage. Selective BPF filters reduce volume but risk discarding relevant traffic if the investigator's assumptions about the attack path are wrong. Distributed capture, with sensors at multiple network segments, provides the broadest coverage but requires a centralised collection and analysis platform.

For mobile device investigations, the network capture placement depends on what is being investigated. Capturing the traffic of a single suspect device requires placing a capture point on the access layer switch port or wireless access point that the device connects to. On a wireless network, a dedicated monitor-mode capture interface can capture all 802.11 frames on a channel, including management and control frames that reveal device associations, probe requests (which disclose SSIDs the device has previously connected to), and authentication sequences. See Legal and Jurisdictional Frameworks for the authority requirements before targeting an individual device.

A forensically sound packet capture requires documentation at five points: before capture starts, at capture start, during capture, at capture stop, and during storage and transfer. Before starting, record the legal authority for capture, the name and role of the person conducting it, the make, model, and serial number of the capture hardware, and the version of the capture software. At start, record the exact UTC time, the interface name, the BPF capture filter (if any), and the network segment being monitored. During capture, log any errors, dropped packet counts (reported by the tool at exit or via ifconfig), and any interruptions. At stop, record the UTC time, the number of packets captured, and the file path.

Immediately after the capture file is closed, compute a cryptographic hash of the file. SHA-256 is the current standard in most jurisdictions; MD5 is no longer considered collision-resistant and should not be used as the sole hash. Record the hash value in the chain-of-custody document and, where possible, in a signed electronic record. Copy the file to evidence storage and compute the hash again to verify that the copy is identical to the original. All subsequent analysis should be conducted on copies, never on the original file. The original should be stored on write-protected media or in a write-once storage system.

Packet drops are the primary completeness risk. tcpdump reports the number of packets received, filtered, and dropped by the kernel at the end of a capture session. A drop count above zero means the capture file is incomplete. High drop counts indicate that the capture system is too slow for the traffic volume and that either hardware must be upgraded, the BPF filter must be narrowed, or a high-performance capture solution must be used. In a court submission, the drop count must be disclosed, and the investigator should explain what class of traffic was most likely to have been dropped and whether that affects the conclusions drawn from the capture.