Network Forensics: Acquisition, Analysis, and Detection

• Network Forensics: Acquisition, Analysis, and Detection
  • Network Evidence Acquisition
    • Application-Layer Protocols
    • Physical Acquisition Methods
    • libpcap and BPF
    • Active Acquisition
    • Evidence Collection Strategy
  • Protocol and Statistical Flow Analysis
    • Protocol Analysis
    • Packet Analysis Techniques
    • Flow Analysis
    • Flow Record Processing Architecture
    • Flow Analysis Techniques
    • Common Malicious Traffic Patterns
  • Network Intrusion Detection and Prevention Systems
    • Functionality
    • Detection Modes
    • Evidence from NIDS/NIPS
    • Snort
    • Snort Rule Language
    • Other NIDS Platforms
  • Summary

Network Evidence Acquisition

Application-Layer Protocols

Understanding common application-layer protocols is necessary to recognize what traffic contains and to reconstruct user activity from packet captures.

HTTP uses a request-response model. Key methods:

HTTP is cleartext; all headers, URLs, and payloads are readable in a capture without decryption. Response codes (200 OK, 301 Redirect, 404 Not Found, 500 Server Error) provide behavioral context.

DHCP assigns IP addresses dynamically via a four-step handshake:

1. DISCOVER — client broadcasts to find DHCP servers
2. OFFER — server offers an IP address
3. REQUEST — client requests the offered address
4. ACK — server confirms the lease

DHCP logs link an IP address to a MAC address at a specific time, allowing an investigator to identify which physical device used an IP seen in other logs.

SMTP (Simple Mail Transfer Protocol) uses human-readable commands to transfer email:

SMTP traffic may carry email body content and attachments encoded in Base64. These can be decoded directly from a packet capture.

Case study: In a network investigation, an analyst used Wireshark to capture SMTP traffic and observed Base64-encoded content in the DATA portion of a session. Decoding the content revealed an attachment that constituted evidence of data exfiltration.

Physical Acquisition Methods

Wired networks:

• Inline network tap: a hardware device inserted into a cable run that copies all traffic to a monitoring port. Completely passive and transparent to the network.
• Vampire tap: clamps onto a cable and inductively couples to the signal. Used on older coaxial (10BASE5) networks.
• Induction coil: non-invasive electromagnetic tap for copper wire; detects the magnetic field without breaking the circuit.
• Fiber optic splitter: bends a fiber strand slightly and captures the light that escapes, or uses a beam splitter to divert a copy of optical traffic to a monitoring interface. Passive and undetectable.

Wireless networks:

• Promiscuous mode: a network interface setting that causes the card to accept all frames, not just those addressed to it. Required for wireless packet capture.
• Monitor mode: a wireless-specific mode that captures all 802.11 frames on a channel, including management and control frames, without associating with an access point.

Hub vs. switch considerations:

• A hub broadcasts all frames to all ports — passive capture on any port sees all traffic.
• A switch forwards frames only to the destination port — a capture device on another port sees nothing.
• To capture on a switched network without a hardware tap:
  • Mirror port / SPAN port: configure the switch to copy traffic from selected ports to a monitoring port.
  • MAC flooding: overflow the switch’s MAC address table so it reverts to hub-like broadcast behavior (an active and potentially disruptive technique).
  • ARP spoofing: poison ARP caches to redirect traffic through the capture host (a man-in-the-middle technique; also active and detectable).

libpcap and BPF

libpcap (and its Windows counterpart WinPcap/Npcap) is the standard capture library. It provides a portable API for capturing packets from a network interface and applies BPF (Berkeley Packet Filter) expressions to filter which packets are captured.

BPF filters are evaluated in-kernel before packets are copied to user space, minimizing overhead. Common primitives:

host 10.0.0.1
net 192.168.0.0/24
port 80
tcp
udp
src host 10.0.0.5 and dst port 443
not broadcast and not multicast

tcpdump is the primary command-line tool built on libpcap:

tcpdump -i eth0 -w capture.pcap 'host 10.0.0.1 and port 80'
tcpdump -r capture.pcap -nn 'tcp[tcpflags] & tcp-syn != 0'

Active Acquisition

When passive capture is not feasible, investigators may collect logs and configurations directly from network devices using remote access protocols:

• SSH / Telnet: command-line access to routers and switches to retrieve routing tables, ARP caches, connection state, and logs
• SNMP (Simple Network Management Protocol): poll device MIBs (Management Information Bases) for interface statistics and configuration data
• SCP / TFTP: file transfer protocols used to retrieve device configurations and log files

Active acquisition involves authenticating to the target device, which creates log entries and may alert administrators. It requires proper authorization.

Evidence Collection Strategy

Priority hierarchy: collect in order of decreasing value and decreasing volatility.

• Act quickly — network state is volatile. ARP caches, connection tables, and in-memory logs disappear when power is cut or the device is rebooted.
• Document everything: which interfaces were accessed, by whom, at what time, using what method.
• Prioritize by relevance: not every device needs to be captured. Target the devices most likely to have seen the traffic or activity of interest.
• Capture full packets when possible. If storage is a constraint, capture headers only — full payloads can always be discarded later, but cannot be reconstructed from headers.

Protocol and Statistical Flow Analysis

Protocol Analysis

Protocol analysis reconstructs what happened on a network by examining the content and structure of individual packets.

Header identification: each protocol header appears at a predictable offset. Given raw packet bytes, an analyst can identify the Ethernet, IP, TCP/UDP, and application headers sequentially and extract fields of interest.

Port numbers: well-known ports identify the application protocol in use (port 80 = HTTP, 443 = HTTPS, 25 = SMTP, 53 = DNS, 22 = SSH). Non-standard ports may indicate tunneling or obfuscation. IANA maintains the authoritative port registry.

WHOIS: a query tool for IP address and domain name registration records. Useful for identifying who owns an IP address range or domain seen in captured traffic.

Packet dissection example — reading hex dumps:

A raw IP packet begins with the IP header (version, IHL, DSCP, length, ID, flags, fragment offset, TTL, protocol, checksum, source IP, destination IP), followed by the transport header (TCP or UDP), followed by the payload. Forensics tools and tcpdump -X display packets in hex+ASCII format, allowing manual field identification.

Packet Analysis Techniques

Pattern matching: search packet payloads for specific strings or byte sequences. Unlike packet filtering (which decides whether to capture a packet), pattern matching searches inside captured packets for content of interest.

ngrep: a packet capture tool that applies regular expressions to packet payloads. Useful for finding specific strings in cleartext protocols:

ngrep -d eth0 'password' 'tcp port 23'
ngrep -I capture.pcap 'USER|PASS'

tcpdump with byte offsets: BPF allows filtering on specific byte values at specific offsets. For example, to match HTTP GET requests:

tcp[20:4] = 0x47455420

(0x47455420 is the ASCII encoding of “GET “)

Flow Analysis

A flow (or session) is defined by a 5-tuple:

1. Source IP address
2. Destination IP address
3. Source port
4. Destination port
5. Protocol (TCP/UDP/ICMP)

Flow analysis aggregates packets into sessions, allowing analysis at a higher level of abstraction than individual packets. It is more scalable — flow records are far smaller than full packet captures.

Tools for flow reconstruction from pcap files:

• tcpflow: reassembles TCP streams from packet captures and writes each stream to a separate file
• Tcpxtract: extracts files from TCP streams based on file signatures (similar to file carving but for network traffic)
• pcapcat: extracts individual connections from a pcap file

Flow Record Processing Architecture

Large networks use a distributed architecture for flow collection:

[Sensors] → [Collectors] → [Aggregators] → [Analysis]

• Sensor: a device or process that observes network traffic and generates flow records. Examples:
  • Argus: a comprehensive flow monitor that produces detailed session records
  • Softflowd: converts packets to NetFlow records
  • YAF (Yet Another Flowmeter): high-performance flow generation with application identification
• Collector: receives flow records from sensors and stores them. Examples:
  • SiLK (System for Internet-Level Knowledge): a suite of tools for collecting and analyzing flow data at internet scale
  • Nfdump: collects and analyzes NetFlow data; paired with NfSen for visualization

• Aggregator: merges and normalizes records from multiple collectors

• Analysis: queries and correlates the stored records

Flow Analysis Techniques

• Filtering: select flows matching specific criteria (IP ranges, ports, time windows)
• Baselining: establish what normal traffic looks like; deviations are anomalies
• Dirty values: look for unusual or invalid field values (e.g., TTL values that don’t match expected OS fingerprints, unexpected protocol numbers)
• Activity pattern matching: identify traffic patterns characteristic of specific behaviors

Common Malicious Traffic Patterns

Network Intrusion Detection and Prevention Systems

Functionality

A Network Intrusion Detection System (NIDS) monitors network traffic and generates alerts when it detects patterns matching known attacks or policy violations. A NIPS goes further, blocking or modifying suspicious traffic inline.

A NIDS typically provides:

• Alerting: generates log entries when rules match
• Packet capture: records the packets that triggered the alert for subsequent analysis
• Session reconstruction: assembles the full context of an alerted connection

Detection Modes

Signature-based detection: compares packets or streams against a database of known attack patterns. Fast and precise for known threats; blind to novel attacks.

Protocol awareness: the NIDS understands application protocol structure and can detect anomalies — e.g., HTTP requests with invalid headers, DNS responses that exceed expected sizes, or FTP commands used in unusual sequences.

Behavioral/statistical detection: establishes a baseline of normal traffic and alerts on deviations — e.g., a sudden spike in outbound connections, unusual port activity, or traffic to known-malicious IP ranges.

Evidence from NIDS/NIPS

A NIDS deployment provides several categories of forensic evidence:

• Configuration files: define which rules are active, which interfaces are monitored, and what the alerting thresholds are
• Alert data: timestamped records of rule matches, including the rule that fired, source/destination, and severity
• Packet headers: the headers of packets that triggered alerts
• Packet content: full payload of alerting packets (if configured for comprehensive logging)
• Cross-sensor correlation: matching alerts across multiple NIDS sensors to reconstruct an attack path that traversed multiple network segments

Comprehensive packet logging: many NIDS deployments are configured to log all packets, not just alerting ones. This creates a full packet capture of all network traffic, which is the most complete possible forensic record — but requires significant storage.

Snort

Snort is the most widely deployed open-source NIDS. It has three operational modes:

1. Sniffer mode: displays packets to the console (like tcpdump)
2. Packet logger mode: writes packets to disk
3. NIDS mode: applies rules and generates alerts

Snort architecture:

Packet capture (libpcap)
        ↓
Packet decoder
        ↓
Preprocessors (stream reassembly, protocol normalization)
        ↓
Detection engine (rule matching)
        ↓
Output plugins (alert logs, pcap, syslog, database)

Snort Rule Language

A Snort rule has two parts: a header and a body (rule options).

Rule header:

action  protocol  src_ip  src_port  direction  dst_ip  dst_port

Example:

alert tcp any any -> 192.168.1.0/24 80 (msg:"HTTP traffic"; sid:1000001;)

Rule body options (selected):

General options:

Detection options:

Post-detection options:

Example rule analysis:

alert tcp $EXTERNAL_NET any -> $HOME_NET 445 \
(msg:"MS17-010 EternalBlue SMB RCE attempt"; \
flow:to_server,established; \
content:"|FF|SMB|73|"; depth:8; offset:4; \
content:"PC NETWORK PROGRAM"; \
pcre:"/\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\x53\x4d\x42/"; \
classtype:attempted-admin; sid:41978; rev:5;)

Reading this rule:

• Header: alert on TCP from any external host to the home network on port 445 (SMB)
• flow:to_server,established: only match packets in an established connection going to the server
• First content: match the byte sequence FF 53 4D 42 73 (SMB header + NegotiateProtocol command) within the first 12 bytes
• Second content: look for “PC NETWORK PROGRAM” (a dialect string used in the vulnerable protocol negotiation)
• pcre: additional byte-level verification of the exploit structure
• classtype:attempted-admin: classified as an attempted administrative access (privilege escalation/remote code execution)

Other NIDS Platforms

• Bro / Zeek: a scriptable network analysis framework. Rather than simple rule matching, Bro executes event-driven scripts that can maintain state across connections, compute statistics, and generate structured logs. Produces rich protocol-specific logs (HTTP, DNS, SSL, SMTP, etc.) as structured text or JSON.
• Suricata: a multi-threaded NIDS/NIPS compatible with Snort rules but with additional features including multi-threading, file extraction, and built-in TLS inspection.
• Commercial NIDS: enterprise products (Cisco Firepower, Palo Alto, etc.) combine signature detection with behavioral analytics, threat intelligence feeds, and integrated response capabilities.

Summary