Traffic Analysis and Protocol Dissection

Wireshark and tcpdump both offer two filtering mechanisms that operate at different points in the workflow. Capture filters, written in Berkeley Packet Filter (BPF) syntax, are applied by the capture engine before any packet is written to disk. A packet that does not match the capture filter is discarded immediately and never recorded. Display filters are written in Wireshark's own filter expression language and applied to a PCAP file that already exists; they hide non-matching packets from view but do not remove them from the file.

For forensic investigation, the default is to capture everything and use display filters to navigate. A capture filter that excludes traffic matching no known IOC today may exclude the pivot traffic discovered tomorrow. The exception is high-bandwidth environments where full-packet capture is technically impractical: on a multi-gigabit production link, even short capture windows produce files too large for most tooling. In those cases, a capture filter scoped to specific hosts or ports is acceptable provided the scope is documented and the legal authority covers it.

A TCP connection is identified by its four-tuple: source IP, source port, destination IP, destination port. Packets belonging to the same connection carry the same four-tuple and a sequence number that indicates where each segment fits in the stream. Reassembly involves collecting all matching segments, reordering them by sequence number, and concatenating their payload bytes to recover the application-layer data.

In Wireshark, right-clicking any packet in a TCP session and choosing Follow > TCP Stream opens a window showing the reassembled application data for that connection. Sent data (client to server) is shown in one colour; received data (server to client) in another. The raw stream can be saved to disk as binary or text. This is sufficient to read cleartext HTTP requests and responses, FTP command sessions, SMTP email transactions, and any other protocol carried over TCP without encryption.

UDP does not have a connection concept or guaranteed ordering. For UDP-based protocols such as DNS, DHCP, and many VoIP protocols, the analyst works at the individual datagram level rather than a reassembled stream. Wireshark's protocol dissectors for DNS decode each query and response pair. The Statistics > DNS menu item in Wireshark aggregates DNS queries across the whole capture, listing every queried name with query counts, which is useful for identifying beaconing or DNS tunnelling.

Once application-layer payloads are accessible through stream reassembly, any files transferred in cleartext can be recovered. Wireshark's File > Export Objects menu presents a list of files identified within specific protocols: HTTP objects (images, scripts, documents, executables), SMB/SMB2 objects, FTP data objects, TFTP and DICOM objects. Selecting an entry and clicking Save writes the file to disk in its original binary form. The recovered file can then be hashed and examined like any other forensic artefact.

NetworkMiner is a purpose-built network forensics tool that automates file carving from PCAP files across a wider range of protocols. It reconstructs files from HTTP, FTP, TFTP, SMB, and IMAP sessions automatically on import, presenting them in a file browser organised by source host. It also extracts credentials from cleartext authentication exchanges: HTTP Basic Auth headers, FTP USER/PASS sequences, POP3 and IMAP login commands, and SMTP AUTH exchanges.

Credential extraction from cleartext protocols is straightforward because the dissector exposes the relevant fields directly. HTTP Basic Authentication encodes the username and password as Base64 in the Authorization header; decoding the Base64 string recovers the plaintext. FTP authentication appears as explicit USER and PASS commands in the TCP stream. Telnet sessions carry every keystroke in cleartext, including login sequences. These credentials have evidential value in investigations involving account compromise, insider threat, or lateral movement.

Anomaly detection in network traffic combines statistical analysis of timing and volume with protocol-level inspection of content. The most common patterns of interest in forensic investigations are port scanning, beaconing, lateral movement, and data exfiltration.

Port scanning produces a characteristic pattern: many SYN packets from a single source to sequential or randomised destination ports on one or more hosts, with corresponding RST or ICMP unreachable responses from closed ports. In Wireshark, filtering for 'tcp.flags.syn == 1 and tcp.flags.ack == 0' isolates SYN packets. A high volume of such packets from one source within a short window identifies the scanner. Nmap's default SYN scan, SYN/ACK scan, and UDP probe patterns each produce recognisable signatures at the packet level.

Beaconing is detected by grouping outbound connections by destination and plotting connection intervals. A host infected with a command-and-control implant will contact its controller at a regular interval, often with small jitter. Tools such as Zeek (formerly Bro) produce connection logs that make this analysis faster than reading raw PCAPs: the conn.log lists every connection with timestamps, making interval analysis a straightforward statistical operation. JA3 and JA3S fingerprints, derived from TLS ClientHello and ServerHello parameters, identify the TLS client library in use and can match known malware families even when the server IP changes.

Data exfiltration leaves two main signatures. Volume-based exfiltration produces an unusually large outbound data transfer from a host that does not normally generate such volumes, visible in NetFlow records or in Wireshark's Statistics > Endpoints and Statistics > Conversations views. Protocol-based exfiltration abuses a permitted protocol, most commonly DNS, to carry data out of a network that blocks most outbound connections. DNS tunnelling produces DNS queries with unusually long, randomly-looking subdomain labels and high query rates to a single authoritative nameserver. The query name itself contains encoded data.

TLS encrypts application-layer payloads between the TCP handshake and the connection teardown. A PCAP of a TLS session shows the handshake (ClientHello, ServerHello, Certificate, ChangeCipherSpec, Finished) and then opaque encrypted records. Without the session keys, the application data cannot be recovered from the PCAP alone. The RSA private key of the server was historically sufficient to decrypt some older cipher suites, but cipher suites using ephemeral Diffie-Hellman key exchange (ECDHE, DHE) provide forward secrecy: even knowing the private key does not recover session keys.

The SSLKEYLOGFILE mechanism provides a practical path to decryption in controlled environments. When the SSLKEYLOGFILE environment variable is set on a host running a supported browser or application (Chrome, Firefox, and curl all support it), the TLS library writes the session keys for each connection to a file as they are negotiated. Loading this key log file into Wireshark via Edit > Preferences > Protocols > TLS decrypts the matching sessions in any PCAP that captured that traffic. This technique is used during controlled tests and in investigations where the suspect host is under the investigator's control.

Encrypted DNS (DNS over HTTPS, DNS over TLS) removes the previously reliable DNS query visibility. Where an investigation depends on DNS query logs as evidence of contacted domains, the analyst must work from resolver logs if the internal DNS resolver was configured to log, or from endpoint logs (browser history, application logs) rather than network captures. This shift is one reason endpoint forensic data is increasingly complementary to network forensic data rather than a substitute for it.

A PCAP file is only useful as evidence if its integrity can be demonstrated and its collection was lawful. The integrity requirement is met by hashing the file immediately after collection (SHA-256 is standard), storing the hash separately, and maintaining a chain-of-custody record that tracks every person who accessed the file and every tool used to open or copy it. Many collection tools, including tcpdump and Wireshark, do not automatically hash output files; the examiner must do this as a separate step immediately after capture stops.

Lawful authority varies by jurisdiction and investigation type. In the United States, the Wiretap Act (18 U.S.C. 2511) requires a court order for real-time interception; stored network records may be obtained with a subpoena or court order under the Stored Communications Act. In the United Kingdom, the Investigatory Powers Act 2016 governs both targeted interception and acquisition of communications data. The European Union's e-Evidence Regulation (Regulation 2023/1543) creates a framework for cross-border electronic evidence requests. India's Information Technology Act 2000 (Section 69) authorises the government to direct interception, monitoring, or decryption of information through any computer resource. In all cases, exceeding the scope of the lawful authority, for example collecting traffic from hosts not covered by the order, creates a legal problem that may result in evidence being excluded.

Time accuracy matters for PCAP evidence. Wireshark timestamps each packet with the system clock of the capturing machine. If that clock is unsynchronised, every timestamp in the file is offset by the same error, which can make correlation with logs from other systems incorrect. The capture machine's NTP synchronisation status and any known clock offset should be recorded and disclosed. This is especially important when correlating PCAP timestamps with server logs, authentication logs, or CCTV footage in a multi-source investigation.