13.1 Network Forensics: PCAP Analysis, Protocol Dissection, Snort/Suricata & Flow Analysis

13.1 Network Forensics: PCAP Analysis, Protocol Dissection, Snort/Suricata & Flow Analysis

Quick Answer: Network forensics is the capture, recording, and analysis of network events to discover the source of security attacks or policy violations. Under RFC 3227 (Order of Volatility), live network traffic represents volatile, ephemeral data that must be captured using dedicated hardware Test Access Points (TAPs) or Switch Port Analyzer (SPAN / port mirroring) interfaces. TAPs provide full-duplex, non-intrusive traffic mirroring without frame drops during link saturation, whereas SPAN ports share the switch backplane and drop packets under high load. Packet analysis relies on tcpdump with Berkeley Packet Filters (BPF) and Wireshark display filters to isolate anomalous protocols. Covert channels like DNS tunneling (identifiable by high-entropy subdomains and unusual TXT queries) and ICMP tunneling (abnormal payload bytes) allow stealthy exfiltration. Where full packet capture (FPC) is prohibitive, NetFlow (v5/v9) and IPFIX supply connection-level telemetry, while Snort and Suricata rule engines detect and flag malicious network signatures.

---

Network Forensics Fundamentals & The Order of Volatility

While host forensics examines static artifacts preserved on non-volatile disks or volatile memory dumps, network forensics deals with data in transit. Network evidence is inherently dynamic, transient, and volatile.

According to RFC 3227 (Guidelines for Evidence Collection and Archiving), network data appears at multiple tiers of volatility:

+-------------------------------------------------------------------------+
|                    NETWORK DATA IN RFC 3227 VOLATILITY                 |
+-------------------------------------------------------------------------+
| Priority 1: Network interface card (NIC) buffers, kernel packet queues  |
| Priority 2: Ephemeral socket tables, ARP cache, routing tables          |
| Priority 3: Volatile memory state (uncommitted connection data)         |
| Priority 4: Temporary proxy caches, local DNS resolver caches           |
| Priority 6: Persistent firewall, IDS/IPS, proxy, and flow log archives  |
+-------------------------------------------------------------------------+

The Golden Rule of Network Forensics

Unlike a hard drive where deleted clusters can often be carved days or weeks later, network packets exist on physical transmission media for only microseconds. If an organization does not have an active capture mechanism (Full Packet Capture - FPC) or flow logging sensor operating at the moment of an intrusion, the raw data payload is lost forever. Post-incident reconstruction must then rely solely on secondary perimeter logs (firewall state tables, DNS resolver queries, web proxy logs).

---

Packet Collection Architecture: TAP vs. SPAN Port Mirroring

To capture network traffic for forensic examination or intrusion detection, investigators and security engineers deploy packet sensors at strategic aggregation points. The method used to divert packets into the capture interface determines the evidentiary integrity of the resulting packet capture (PCAP).

+-------------------------------------------------------------------------+
|                  NETWORK CAPTURE SENSOR MECHANISMS                      |
+-------------------------------------------------------------------------+
| Feature             | Hardware Network TAP      | Switch SPAN / Mirror  |
|---------------------|---------------------------|-----------------------|
| **Mechanism**       | Dedicated physical device | Logical configuration |
|                     | spliced into cable link   | on managed switch     |
| **Duplex Handling** | Separate Transmit (Tx)    | Combines Tx + Rx onto |
|                     | and Receive (Rx) channels | single output port    |
| **Frame Dropping**  | Zero packet loss even at  | Discards packets when |
|                     | 100% link saturation      | backplane/port maxes  |
| **Error Frames**    | Captures malformed CRC    | Discards Layer 1/2    |
|                     | and runt/giant frames     | checksum & runt errors|
| **Switch Overhead** | Zero CPU/memory impact    | Consumes switch CPU   |
|                     | on network infrastructure | and internal buffers  |
| **Stealth / Security**| Transmit pairs unpinned;| Vulnerable to mis-    |
|                     | completely invisible      | configuration/hopping |
| **Cost & Placement**| Higher cost; requires     | Low cost (software);  |
|                     | physical cable cut        | configured via CLI    |
+-------------------------------------------------------------------------+

1. Hardware Test Access Point (TAP)

A network TAP is a specialized hardware device inserted directly between two network nodes (e.g., between an edge router and an internal firewall).

• Non-Intrusive & Passive: A passive fiber optic TAP splits the optical beam (e.g., 70% pass-through, 30% monitor), while an active copper TAP introduces zero-delay buffer circuitry with battery or failsafe bypass relays ensuring physical link continuity during power loss.
• Full-Duplex Capture: A 1 Gbps full-duplex link can theoretically transmit 1 Gbps in each direction simultaneously (2 Gbps aggregate). A hardware TAP outputs the Transmit (Tx) and Receive (Rx) streams on two separate physical monitor ports, preventing buffer overruns.
• Forensic Fidelity: TAPs replicate all Layer 1 and Layer 2 physical anomalies, including corrupted cyclic redundancy check (CRC) checksums, jabber frames, runt packets (< 64 bytes), and oversized giant frames (> 1518 bytes). These corrupted frames often indicate low-level network tampering or covert signaling.

2. Switch Port Analyzer (SPAN / Port Mirroring)

A SPAN port is a software-configured feature on a managed network switch that directs a copy of network traffic seen on one or more switch ports (or VLANs) to a designated monitoring port.

• The Over-Subscription & Packet Drop Vulnerability: If a SPAN session mirrors a 1 Gbps full-duplex link (up to 2 Gbps aggregate traffic) to a single 1 Gbps destination SPAN port, the switch must drop packets whenever aggregate throughput exceeds 1 Gbps. In an active Distributed Denial of Service (DDoS) attack or high-volume data exfiltration incident, SPAN ports drop the very packets needed for forensic attribution.
• Layer 2 Filtering: Most switch ASICs automatically discard corrupted frames, runt packets, and invalid preamble sequences before traffic reaches the SPAN forwarding engine, sanitizing critical anomalous frames.

3. Promiscuous Mode & Inline Sensors

• Promiscuous Mode: Configures the host Network Interface Card (NIC) driver to bypass its hardware MAC address filter, passing all Ethernet frames observed on the physical segment up to the operating system kernel, regardless of the destination MAC.
• Inline Sensors vs. Passive Sensors: An inline sensor (such as an active IPS or firewall) sits directly in the traffic flow; packets pass through it and can be dropped in real time. A passive sensor (such as an IDS or PCAP recorder attached to a TAP/SPAN) receives an out-of-band copy of the traffic, ensuring that sensor latency or crashes never disrupt production traffic.

---

Packet Capture Tools, Formats & tcpdump Syntax

Capture File Formats: Libpcap vs. Pcapng

+-------------------------------------------------------------------------+
|                     PCAP vs. PCAPNG SPECIFICATIONS                      |
+-------------------------------------------------------------------------+
| Metric              | Legacy Libpcap (.pcap)   | PCAP Next Generation   |
|                     |                          | (.pcapng)              |
|---------------------|--------------------------|------------------------|
| **Magic Number**    | 0xA1B2C3D4 (standard)    | 0x0A0D0D0A (Section    |
|                     | 0xA1B23C4D (nanosecond)  | Header Block - SHB)    |
| **Multiple Ifaces** | Single interface per file| Multiple interfaces in |
|                     |                          | a single capture file  |
| **Timestamp Res.**  | Microsecond (default)    | Microsecond, nanosecond|
|                     | or nanosecond            | or custom resolution   |
| **Metadata & Notes**| No native commentary or  | Supports per-packet    |
|                     | interface statistics     | comments and OS stats  |
| **Extensibility**   | Fixed 24-byte file header| Extensible block-based |
|                     | followed by packet records| architecture (SHB/IDB) |
+-------------------------------------------------------------------------+

Mastering tcpdump Command-Line Capture Syntax

tcpdump is the quintessential command-line packet analyzer for Linux, Unix, and macOS environments (with windump on legacy Windows). Operating directly within the terminal, it imposes minimal CPU and memory overhead compared to graphical analyzers, making it the preferred tool for live triage.

# Standard Forensic Capture Command Line:
tcpdump -i eth0 -nn -s0 -w /evidence/incident_capture.pcap 'tcp port 80 or tcp port 443'

Breakdown of Essential tcpdump Switches:

• -i <interface>: Specifies the physical or logical network interface (e.g., eth0, ens192, any).
• -nn: Disables both DNS hostname resolution and port-to-service translation (e.g., outputs 192.168.1.10.80 instead of host.http). Crucial in forensics to eliminate DNS query leakage during analysis and prevent capture latency.
• -s0 (or --snapshot-length=0): Sets snapshot length to 0 (default in modern versions is 262,144 bytes), ensuring the entire packet payload is captured without truncation.
• -w <file>: Writes raw packet bytes directly to an output file rather than parsing and printing them to standard output.
• -r <file>: Reads packets from an existing PCAP file for offline filtering.
• -v, -vv, -vvv: Increases verbosity, displaying TTL values, IP identification numbers, protocol options, and checksum verification status.
• -X / -XX: Prints packet headers and payload in both hexadecimal and ASCII format (-XX includes Layer 2 Ethernet headers).
• -e: Displays Layer 2 framing headers, including source and destination MAC addresses and 802.1Q VLAN tags.
• -c <count>: Terminates capture automatically after acquiring exactly <count> packets.

Berkeley Packet Filter (BPF) Syntax

BPF allows kernel-level packet filtering before packets are copied to user-space memory, minimizing packet drops under heavy network utilization.

# Capture only SYN packets (new TCP connection attempts):
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'

# Capture DNS queries directed to external recursive resolvers:
tcpdump -i eth0 -nn 'udp port 53 and not dst net 192.168.0.0/16'

# Filter packets containing specific hex payload bytes (e.g., HTTP GET: 0x47455420):
tcpdump -i eth0 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420'

---

Wireshark Display Filters & Stream Dissection

While BPF filters determine what packets are saved to disk during acquisition, Wireshark Display Filters allow investigators to drill down into captured PCAP data during post-incident analysis.

+-------------------------------------------------------------------------+
|               ESSENTIAL FORENSIC WIRESHARK DISPLAY FILTERS              |
+-------------------------------------------------------------------------+
| Forensic Objective     | Wireshark Display Filter Syntax                |
|------------------------|------------------------------------------------|
| HTTP POST Requests     | http.request.method == "POST"                  |
| Outbound HTTP Uploads  | http.content_length > 100000                   |
| Half-Open SYN Packets  | tcp.flags.syn == 1 and tcp.flags.ack == 0      |
| Abnormal RST Teardowns | tcp.flags.reset == 1 and tcp.seq == 1          |
| Successful DNS Resolv. | dns.flags.response == 1 and dns.flags.rcode == 0|
| Large DNS Responses    | dns.count.answers > 5 or frame.len > 512       |
| Suspicious User-Agents | http.user_agent contains "python" or           |
|                        | http.user_agent contains "curl"                |
| Cleartext Passwords    | ftp contains "PASS" or pop.request.command ==  |
|                        | "PASS" or imap contains "login"                |
| TLS Client Hello (SNI) | tls.handshake.extension.type == 0              |
| Potential ICMP Tunnels | icmp.type == 8 and data.len > 64               |
+-------------------------------------------------------------------------+

Stream Reconstruction and Object Carving

1. Follow TCP Stream: In Wireshark, right-clicking any TCP packet and selecting Follow -> TCP Stream reassembles out-of-order packets, acknowledges sliding windows, strips protocol transport headers, and displays the complete bidirectional conversation in an ASCII/Hex view (red for client-to-server, blue for server-to-client).
2. Export Objects: Forensic artifacts (e.g., downloaded malware DLLs, exfiltrated spreadsheets, uploaded PHP scripts) can be carved directly from reassembled application sessions via File -> Export Objects -> HTTP / SMB / IMF / TFTP.

---

Protocol Dissection & Covert Tunneling Detection

1. TCP 3-Way Handshake & Abnormal Teardown Signatures

The Transmission Control Protocol (TCP) enforces reliable, connection-oriented communication through a standardized three-way handshake.

Normal Handshake:           SYN Flood Attack:           RST Abrupt Teardown:
Client         Server       Client         Server       Client         Server
  |--- SYN ------>|           |--- SYN 1 ---->|           |--- DATA ----->|
  |<-- SYN/ACK ---|           |--- SYN 2 ---->|           |<-- ACK -------|
  |--- ACK ------>|           |--- SYN 3 ---->|           |<-- RST -------|
                              (Spoofed IPs; no            (Session abruptly
                              ACK; Backlog fills)         terminated/reset)

• Normal Connection Establishment: Client transmits [SYN], Server responds with [SYN, ACK], Client replies with [ACK]. The connection enters the ESTABLISHED state.
• SYN Flood (DoS): An attacker transmits an overwhelming volume of [SYN] packets with spoofed source IP addresses. The target server responds with [SYN, ACK] and allocates a Transmission Control Block (TCB) in its kernel memory backlog queue. Because the spoofed client never transmits the final [ACK], the half-open connections exhaust server memory, denying service to legitimate clients.
• RST Teardowns & Port Scans:
  • A connection terminated cleanly uses [FIN] followed by [ACK], closing the stream gracefully.
  • A [RST] (Reset) packet indicates an abrupt, ungraceful teardown. If a client transmits [SYN] to a closed port, the host replies with [RST, ACK], a core signature in Nmap TCP Connect (-sT) and SYN Stealth (-sS) port scans.
  • Stateful firewalls or active intrusion prevention systems (like Great Firewall or enterprise proxies) frequently inject spoofed [RST] packets into active sessions to terminate forbidden connections.

2. DNS Tunneling & Covert Exfiltration

Domain Name System (DNS) traffic is rarely blocked by enterprise egress firewalls because internal endpoints must resolve domain names to function. Adversaries exploit this trust by encoding arbitrary command-and-control (C2) communications or exfiltrated data into DNS queries routed to an attacker-controlled Authoritative Name Server.

Victim Workstation                    Internal DNS Resolver          Attacker Auth NS
       |                                      |                             |
       |--- Query: aW52b2ljZS54bHNY.c2.att.com ---->|                             |
       |    (Base64 payload in subdomain)     |--- Forwarded Query -------->|
       |                                      |                             | (Decodes data)
       |<-- Response: TXT "c3VjY2Vzcz==" -----|<-- TXT "c3VjY2Vzcz==" ------|

Forensic Indicators of DNS Tunneling:

• High Shannon Entropy in Subdomain Labels: Legitimate domain labels have predictable linguistic patterns. Encrypted or compressed data (e.g., 7f8a9b2c3d4e5f6a.tunnel.evil.com) exhibits high mathematical entropy (> 4.5).
• Abnormal Label Length: Subdomain labels approach the maximum RFC 1035 limits (up to 63 octets per label and 253 characters for the Fully Qualified Domain Name - FQDN).
• Unusual Query Types: Excessive volume of TXT (used to deliver large base64 encoded payloads back to clients), NULL, CNAME, or MX queries compared to standard A and AAAA lookups.
• Low Time-to-Live (TTL): DNS records configured with TTL = 0 or near-zero seconds to prevent intermediate DNS caching and force every query to reach the attacker's authoritative server.
• Volume Anomalies: A single host sending thousands of unique DNS lookups to a single parent domain within a brief timeframe.

3. ICMP Tunneling

Internet Control Message Protocol (ICMP) Echo Request (Type 8) and Echo Reply (Type 0) packets are intended for network diagnostic ping testing. RFC 792 allows arbitrary data to be included in the ICMP payload to measure transmission integrity.

Forensic Detection of ICMP Tunnels (e.g., ptunnel, icmpsh):

• Standard Windows ping utilities populate payload bytes with the repeating lowercase English alphabet (abcdefghijklmnopqrstuvwabcdefghi...), totaling 32 bytes of data (40 bytes total ICMP).
• Standard Linux ping implementations transmit a 56-byte payload (64 bytes total) including a microsecond timestamp followed by sequential bytes (0x00, 0x01, 0x02...).
• Tunneling Signature: ICMP packets with payloads exceeding 64 bytes (frequently 512 to 1024+ bytes), high entropy, non-sequential binary data, or ICMP Echo Replies transmitted without preceding Echo Requests.

4. DHCP Forensic Logs

The Dynamic Host Configuration Protocol assigns IP configurations through the four-step DORA process: Discover (Broadcast), Offer (Unicast/Broadcast), Request (Broadcast), and Acknowledge (Unicast).

Client                                                 DHCP Server
  |--- DHCPDISCOVER (Src: 0.0.0.0, Dst: 255.255.255.255) ---->|
  |<-- DHCPOFFER (Proffered IP: 192.168.1.105) --------------|
  |--- DHCPREQUEST (Accepts proffered IP) ------------------>|
  |<-- DHCPACK (Commits Lease: Duration 86400s) -------------|

Key Evidentiary Artifacts in DHCP Logs:

• IP-to-MAC Binding: Links an ephemeral, dynamically assigned IP address to a physical hardware MAC address at a specific microsecond timestamp.
• Client Hostname (Option 12): Transmits the local computer name configured on the endpoint.
• Rogue DHCP Detection: An adversary operating a rogue DHCP server responds faster than the legitimate enterprise server, handing out malicious Default Gateway (Option 3) or DNS Server (Option 6) parameters to execute a Man-in-the-Middle (MitM) attack.

---

Denial-of-Service Flood Signatures in Captured Traffic

Volumetric attacks are graded on the exam by their packet-level fingerprint, because each flood leaves a different residue in a capture. Work from the flags and the reply pattern, not from raw bandwidth.

The ratio test is what separates a flood from a busy service. In healthy traffic nearly every SYN is matched by a SYN, ACK and a final ACK; in a SYN flood the first number dwarfs the other two. Distinguishing an HTTP flood from a flash crowd — a legitimate traffic spike — relies on diversity rather than volume: genuine crowds show varied Referer headers, varied User-Agents, and normal asset fetches for CSS and images, while a flood repeatedly hammers the same dynamic endpoint with uniform headers and no supporting asset requests.

Detecting Sniffing Attempts on a Switched Network

Bullet-for-bullet, the blueprint separates gathering evidence with a sniffer from investigating someone else's sniffer. The collection side is covered by the TAP, SPAN, and promiscuous-mode architecture above; the investigative side asks how an attacker obtained traffic that a switch should never have delivered to them.

A switch forwards frames only to the destination port, so passive sniffing on a switched LAN requires the attacker to break that assumption in one of three ways, each of which leaves evidence:

• ARP cache poisoning. The attacker floods gratuitous ARP replies binding the gateway's IP to their own MAC. The residue is an IP-to-MAC mapping that changes, and the same MAC claiming multiple IP addresses. Wireshark raises arp.duplicate-address-detected, and arpwatch or XArp logs the flip with a timestamp that anchors the intrusion window.
• MAC flooding / CAM table overflow. The attacker injects thousands of frames with forged source MACs until the switch's content-addressable memory table is exhausted. Many switches then fail open, flooding frames out every port like a hub. The evidence lives on the switch: port-security violation counters, MAC-move and MAC-learn log entries, and an implausible number of MAC addresses learned on a single access port.
• An unauthorized mirror. A SPAN session or an inserted inline tap configured without authorization. The artifact is a configuration change in the switch's audit log, cross-checked against the change-management record.

Host-level confirmation uses promiscuous-mode detection: an ARP request addressed to a deliberately bogus destination MAC will be dropped by a normal NIC but may be answered by a host whose adapter is passing all frames to the operating system, and a suspected sniffer frequently shows a measurable latency increase when the segment is loaded, because it is processing every frame instead of its own. Neither probe is conclusive on its own, so the examiner corroborates with the switch logs and the ARP evidence before naming a machine.

When the sniffer is the investigator's own, the evidence integrity requirements from earlier in this chapter still apply: document the capture authority and scope before starting, record the interface, filter, and system clock, and hash the resulting capture file the moment collection stops so the pcap can be authenticated later.

Flow Analysis: NetFlow v5/v9 & IPFIX

Full packet capture at 10 Gbps or 40 Gbps line speeds consumes petabytes of high-performance storage within days. To retain visibility over months or years, network architects deploy Flow Telemetry.

+-------------------------------------------------------------------------+
|                    NETFLOW v5 vs. v9 vs. IPFIX                          |
+-------------------------------------------------------------------------+
| Attribute           | NetFlow v5             | NetFlow v9 / IPFIX       |
|---------------------|------------------------|--------------------------|
| **Standardization** | Cisco Proprietary      | Cisco (v9); IETF RFC 7011|
|                     | (De facto standard)    | (IPFIX - Open Standard)  |
| **Template Engine** | Fixed 7-tuple header;  | Dynamic templates;       |
|                     | cannot be modified     | fully extensible records |
| **IPv6 Support**    | No (IPv4 only)         | Full IPv6 support        |
| **MPLS & VLAN**     | No                     | Supported                |
| **Transport Layer** | UDP (typically 2055)   | UDP, TCP, or SCTP        |
| **Payload Data**    | None (Metadata only)   | None (Metadata only)     |
+-------------------------------------------------------------------------+

NetFlow Architecture & The Traditional 7-Tuple

A network flow represents a unidirectional sequence of packets sharing seven common attributes:

1. Source IP address
2. Destination IP address
3. Source transport layer port
4. Destination transport layer port
5. Layer 3 Protocol type (TCP, UDP, ICMP)
6. Ingress interface index
7. Type of Service (ToS) / Differentiated Services Code Point (DSCP)

Forensic Utility of Flow Data

• Top Talkers Identification: Rapidly identifies internal endpoints transmitting anomalous volumes of outbound traffic (e.g., host transmitting 80 GB to an external IP at 02:00 AM).
• Beaconing Analysis: Identifies periodic, regular outbound connections characteristic of Command and Control (C2) agents (e.g., connection every 60 seconds with ±5% jitter).
• Lateral Movement Mapping: Uncovers internal port scanning, SMB spread (port 445), and SSH probing across internal VLAN boundaries.

---

Network IDS/IPS Log Correlation: Snort & Suricata

Network Intrusion Detection Systems (NIDS) evaluate live packet streams against signature databases and protocol anomalies, generating forensic alert logs.

Snort / Suricata Rule Anatomy:

 alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (msg:"EXPLOIT SQLi - SELECT statement"; flow:to_server,established; content:"UNION"; nocase; content:"SELECT"; distance:0; classtype:web-application-attack; sid:1000045; rev:1;)
 \_______/ \_______________________________/ \________________________________________________________________________________________________________________________________________________________________/
  Action            Rule Header                                                         Rule Options

Dissecting Snort Rule Syntax

1. Rule Actions: alert (generate alert and log packet), log (log packet without alerting), pass (drop/ignore packet), drop (block and drop packet in inline IPS mode).
2. Rule Header: Specifies Protocol (tcp, udp, icmp, ip), Source IP/Network ($EXTERNAL_NET), Source Port (any), Direction Operator (-> or <>), Destination IP/Network ($HOME_NET), and Destination Port (80, 443, any).
3. Rule Options: Enclosed in parentheses, semicolon-delimited:
   • msg: Plaintext descriptive alert message displayed in the SIEM/forensic console.
   • flow: Specifies session tracking state (to_server, to_client, established, stateless).
   • content: String or binary (|4D 5A|) payload match pattern.
   • nocase: Case-insensitive matching.
   • distance / within: Payload offset modifiers relative to preceding matches.
   • pcre: Perl-Compatible Regular Expression for complex regex payload matching.
   • classtype: Attack categorization (e.g., trojan-activity, attempted-admin).
   • sid: Snort Identifier (1–999,999 reserved for official rules; ≥1,000,000 for custom local rules).
   • rev: Rule revision integer.

Suricata Enhancements

Unlike legacy single-threaded Snort versions, Suricata features a multi-threaded architecture capable of line-rate inspection on 100 Gbps networks, native protocol parsers for HTTP, TLS, DNS, and SMB, and automatic file carving via its filestore keyword (extracting executables directly from PCAPs to disk for malware sandboxing).