Skip to main content

Chapter 4 — Network Forensics

Networks carry the traffic of every modern system. When a host is breached, when data is exfiltrated, when an attacker establishes command and control, when a denial-of-service campaign hits a target — the activity passes over the network and, if captured, leaves recoverable evidence. Network forensics is the discipline of acquiring, analysing, and presenting that evidence. This chapter covers what network traffic carries forensically, how it is captured and analysed with PCAP and Wireshark, how IDS and IPS systems generate and use forensic data, and how network findings are documented for legal admissibility.

4.1 Network traffic capture and analysis with PCAP and Wireshark​

Network forensics​

Network forensics is the sub-discipline of digital forensics concerned with the capture, recording, and analysis of network traffic and network-related artefacts for the purposes of incident investigation, attack detection, and evidence gathering.

The boundary with broader network monitoring is intent — network forensics treats traffic as evidence and applies forensic discipline (preservation, integrity, chain of custody) that operational monitoring does not require.

Why network forensics matters​

Several forensic findings exist only in network data:

Lateral movement. An attacker who breaches one host then moves through internal systems leaves traces in east-west traffic — connections between internal hosts that should not normally communicate.

Command and control (C2). Compromised systems beacon out to attacker infrastructure. The beacon pattern (timing, destination, payload structure) is detectable in network data even when the attacker has cleaned local logs.

Data exfiltration. Large transfers out of the network are visible in traffic volume and destination, often before the recipient sees the data.

Denial-of-service attacks. Volumetric attacks have characteristic traffic signatures. The Government Integrated Data Centre DDoS in 2024 was traced through Nepal's upstream peering points; the traffic patterns identified the attack class.

Tunnelled communications. Encrypted tunnels, VPN abuse, DNS tunnelling — all carry indicators in traffic that local logs do not capture.

Anonymising layers. Tor exit nodes, commercial VPNs, residential-proxy services can be detected as the egress points of suspicious traffic.

Attribution-relevant timing. Network timestamps from infrastructure outside the compromised network are difficult for the attacker to manipulate; they often anchor the investigation's timeline.

Capture points and capture types​

Where to capture:

  • Network tap. A dedicated hardware device inserted into a network link. Provides a copy of traffic to a monitoring port. Forensically gold-standard; lossless; passive.
  • SPAN (Switched Port Analyzer) / mirror port. A switch is configured to copy traffic from monitored ports to a mirror port. Cheaper than taps but can drop packets under load.
  • Inline device. Traffic passes through a device that captures and forwards. IPS deployments are often inline. Forensic capture from inline devices is feasible but introduces operational risk.
  • Host-based capture. Each host captures its own traffic. Simpler to deploy but produces fragmented evidence and may itself be compromised by the attacker.

For a Nepali ISP-level investigation, captures might be taken at peering points (Nepal Internet Exchange, NPIX), at upstream gateways, or at customer-facing access points depending on the case.

What to capture:

  • Full packet capture (FPC). Every byte of every packet. Highest fidelity; storage-intensive.
  • Headers only. Packet headers without payload. Smaller; suitable for traffic analysis but loses content.
  • NetFlow / sFlow / IPFIX. Flow records summarising connections (source, destination, ports, bytes, packets, start, end). Compact; sampled from real-time traffic.
  • Application-layer logs. Web server logs, proxy logs, DNS query logs. Network-relevant but generated by applications.

Mature programmes capture multiple layers — full PCAP for short retention, flow data for medium-term, logs for long-term.

PCAP format​

PCAP (Packet Capture) is the standard file format for stored network traffic captures, used by virtually all network-analysis tools, organising packets into records with timestamps and link-layer headers, with the modern pcapng (PCAP Next Generation) format adding richer metadata.

PCAP files contain:

  • A global header (link-layer type, snap length, byte order, version).
  • A sequence of packet records, each with:
    • Timestamp (typically microsecond or nanosecond precision).
    • Captured length (bytes saved).
    • Original length (bytes on the wire — may exceed captured if truncated).
    • Packet bytes.

The format is open, simple, and supported everywhere. Capture tools (tcpdump, Wireshark/dumpcap, NetworkMiner) produce PCAP. Analysis tools accept PCAP.

pcapng is an extended format adding per-interface details, comments, statistics, and other metadata. Most modern tools handle both formats transparently.

tcpdump​

tcpdump is the standard command-line packet capture and analysis utility on Unix-like systems, using the libpcap library to read traffic from network interfaces or PCAP files and to display or save packet contents.

Standard usage:

tcpdump -i eth0 -w capture.pcap

Captures from interface eth0 and writes raw packets to capture.pcap.

tcpdump -r capture.pcap host 10.0.0.5 and port 443

Reads capture.pcap, displays packets involving host 10.0.0.5 on port 443.

tcpdump's filtering syntax (BPF — Berkeley Packet Filter) is the standard expression language for packet filtering. Used directly by tcpdump and accepted by other tools (including Wireshark's capture filter).

For forensic acquisition, common options:

  • -w file.pcap — write to file.
  • -s 0 or -s 65535 — full snap length (capture entire packets, not just headers).
  • -C and -W — rotate files by size.
  • -G — rotate by time.
  • -Z user — drop privileges after opening the interface.

Wireshark​

Wireshark is the open-source graphical network protocol analyser that reads PCAP and pcapng files, dissects packets into their protocol fields, displays them in a navigable interface, and supports advanced filtering, statistics, and reconstruction of higher-layer protocols.

Wireshark is the workhorse of network analysis. Free, cross-platform, with over 3,000 protocol dissectors.

Key Wireshark capabilities:

  • Protocol dissection. Each packet is parsed layer-by-layer (Ethernet, IP, TCP/UDP, application protocol). Field-by-field display.
  • Display filtering. Filter shown packets by any field. Different syntax from BPF — ip.addr == 10.0.0.5 and tcp.port == 443.
  • Follow stream. Reconstruct a TCP, UDP, or TLS stream from its constituent packets, showing the conversation as continuous text.
  • Export objects. Extract HTTP-transferred files, SMB-transferred files, FTP-transferred files directly from the capture.
  • Statistics. Conversation lists, endpoints, protocol hierarchies, IO graphs.
  • Decryption. With keys provided, decrypt TLS, WPA/WPA2 wireless, Kerberos. Modern TLS 1.3 with PFS requires session-key logging from clients to decrypt — possible in test setups but rarely in real cases.
  • Filtering on application data. Display filters can match on URLs, DNS query names, HTTP headers, TLS server names, etc.

Wireshark in a typical forensic workflow:

  1. Open the PCAP. Wireshark loads up to its memory limit; for very large files, command-line tools (tshark, capinfos, editcap) split or filter first.
  2. Run "Protocol Hierarchy" statistics to see what protocols are present.
  3. Look at "Conversations" to find unusual sources or destinations.
  4. Apply display filters to focus on interesting traffic.
  5. "Follow stream" interesting connections to see the conversation.
  6. "Export objects" if interesting files are transferred.
  7. Save filtered subsets for documentation.

tshark​

The command-line version of Wireshark. Useful for:

  • Scripted analysis.
  • Headless servers.
  • Very large captures where the GUI struggles.

Standard usage:

tshark -r capture.pcap -Y "http.request" -T fields -e ip.src -e http.host -e http.request.uri

Reads the PCAP, displays only HTTP request packets, outputs source IP, host, and URI as tab-separated fields. Equivalent to a Wireshark display filter with selected columns.

Other capture and analysis tools​

NetworkMiner. Open-source / freemium GUI tool focused on extracting artefacts from captures (files, credentials, sessions, hosts). Complementary to Wireshark for "what's in the traffic" rather than "what does this packet say."

Zeek (formerly Bro). Powerful network-security monitoring framework. Generates protocol-specific structured logs (HTTP, DNS, SSL, SSH, ...) instead of raw packets. Used in operational SOCs as well as forensic analysis.

Moloch / Arkime. Large-scale full-packet-capture indexing platform. Used at enterprise and ISP scale for retrospective searches.

SiLK (System for Internet-Level Knowledge). Suite from CERT/CC for flow-data analysis (NetFlow, IPFIX).

ngrep, tcpflow, chaosreader, justniffer. Various command-line tools for specific extraction tasks.

A worked Wireshark exercise​

Consider a captured network session at a small Nepali e-commerce company suspecting a database leak.

Open capture.pcap in Wireshark.

Protocol hierarchy shows mostly HTTP, HTTPS, DNS — and 2% SMB. Internal SMB is unexpected on an internet-facing capture.

Display filter smb or smb2 reveals an SMB session between an internal database server and an external IP. Suspicious — external SMB usually indicates a problem.

Follow stream of one TCP session shows the file transfer was for a file named customers_export.csv.

Export objects → SMB extracts the file. Open it: thousands of customer records.

Statistics → Endpoints identifies the external IP. Threat-intelligence lookup confirms it as a known data-exfiltration server.

Filter by source IP of the database server shows all of its external connections during the capture period — additional concerns may emerge.

The forensic findings are documented:

  • Time of the SMB session.
  • IP addresses involved.
  • The transferred file (with hash).
  • Total bytes transferred.
  • The threat-intelligence attribution.

Combined with disk analysis of the database server (Chapter 2) and memory analysis (Chapter 3), the picture is complete.

4.2 IDS, IPS systems for forensic analysis​

IDS​

An Intrusion Detection System is a network or host-based monitoring system that inspects traffic or activity for signs of malicious or unauthorised behaviour and generates alerts when suspicious patterns are observed, without taking direct action to block the traffic.

IDS is detective — it watches and reports. The decision about response is made by humans (or other systems).

IPS​

An Intrusion Prevention System is similar to an IDS but is positioned inline in the network path so that it can actively block traffic identified as malicious, combining detection with prevention in a single device or software component.

IPS is preventive — it watches and blocks.

Types of IDS/IPS​

Network IDS/IPS (NIDS/NIPS). Monitors network traffic at chosen capture points. Sees what passes the network; does not see encrypted-payload content unless decrypted.

Host IDS/IPS (HIDS/HIPS). Monitors a single host. Has visibility into local files, processes, memory, and logs. Can detect things invisible to NIDS — file modifications, process injection, registry changes, log tampering. Modern endpoint detection and response (EDR) products are descendants of HIDS.

A mature security architecture uses both — NIDS at network perimeters, HIDS on critical endpoints.

Detection approaches​

Signature-based detection.

Signature-based detection identifies known patterns of malicious activity by matching observed traffic or events against a database of pre-defined attack signatures.

A signature might match: HTTP GET requests containing a specific URL path used by a known web shell, network packets containing the byte sequence of a particular exploit, DNS queries for known malicious domains.

Signature-based detection is precise but limited to known threats. New attacks ("zero-days") are not detected until a signature is created.

Anomaly-based detection.

Anomaly-based detection identifies suspicious activity by comparing observed behaviour against a model of normal behaviour, flagging deviations that may indicate attack.

A baseline of normal traffic is built (volumes, destinations, protocols, timing). Deviations trigger alerts: a sudden 10x increase in outbound traffic; an internal host connecting to unusual destinations; a workstation running unusual processes at 2 AM.

Anomaly-based detection catches novel threats but produces more false positives. The combination of signature and anomaly approaches is the modern standard.

Behavioural / machine-learning detection. A generalisation of anomaly detection using ML models. Increasingly common in commercial products. Discussed briefly in Chapter 7 of the ML and Data Analytics subject.

Specific IDS/IPS tools​

Snort. The original open-source NIDS, dating to 1998. Signature-based; uses a domain-specific rule language. Still widely deployed. Cisco acquired Sourcefire (Snort's parent company) in 2013; Snort remains open-source.

Suricata. Modern open-source NIDS/NIPS. Multi-threaded (Snort 2.x was single-threaded; Snort 3 is multi-threaded). Compatible with Snort rules. Active community.

Zeek (Bro). Behaviour-focused. Generates rich logs rather than (just) alerts. More analytical than purely detective.

Suricata and Zeek are often deployed together — Suricata for signature-based alerting; Zeek for protocol logging and behavioural analysis.

Commercial NIDS/NIPS. Cisco Firepower, Palo Alto Networks IPS, Check Point IPS, Fortinet FortiGate, Trend Micro Deep Discovery. Often integrated into next-generation firewalls.

Commercial HIDS / EDR. Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, Carbon Black, Sophos Intercept X. Major Nepali commercial banks typically license one of these (or equivalent regional/open-source) for endpoint protection.

IDS/IPS as forensic data sources​

Beyond their operational role, IDS/IPS systems are rich forensic sources:

Alert logs. Every alert is a timestamped record of a detection. Even if the alert was false positive, the existence of the trigger is forensically interesting.

Full packet capture (PCAP) tied to alerts. Some IDS/IPS products store a PCAP snippet around each alert — the immediate traffic context. Invaluable for post-alert investigation.

Indexed packet data. Tools like Arkime/Moloch index full PCAP for fast retrospective search. After an alert, the analyst can ask "what else did this host do in the past week?"

Protocol logs. Zeek logs in particular are forensic gold — structured records of every HTTP request, DNS query, TLS handshake, SSH connection. Long-retainable due to small size.

Process and file telemetry. EDR products log process creation, file activity, registry changes, network connections — keystrokes if configured. The telemetry is the basis of post-incident reconstruction.

Limitations of IDS/IPS for forensics​

Encrypted traffic. Most modern traffic is encrypted (HTTPS, encrypted DNS, end-to-end-encrypted messaging). IDS sees only metadata: connection endpoints, timings, byte counts, certificate details. Detailed content analysis requires either decryption (SSL/TLS inspection, possible with internal CA and client cooperation) or relying on metadata alone.

Evasion. Attackers know about IDS and design their tradecraft to evade. Payload obfuscation, traffic timing manipulation, blending with legitimate traffic, using cloud services (whose traffic may be allow-listed) as relays.

Volume. A busy network generates more alerts than analysts can review. Tuning is essential; tuning-related missed alerts are a common failure pattern.

False positives. Signatures and anomaly thresholds produce false positives. The right level depends on the organisation's tolerance and analyst capacity.

Retention. Full packet capture for long periods is storage-intensive. Most organisations retain full PCAP for hours or days, flow data for weeks or months, logs for longer.

For a Nepali bank or telecom, the deployment pattern in 2026 is typically:

  • Signature-based NIPS at the perimeter (Suricata/commercial).
  • EDR on endpoints.
  • Zeek for protocol logging on key network segments.
  • Selective full PCAP at high-value capture points.
  • SIEM (Chapter 8) aggregating alerts and logs.

Categories of network attacks recoverable from network forensics​

A non-exhaustive catalogue of attack types and their typical network signatures:

Reconnaissance.

  • Port scans (sequential or random connection attempts to many ports).
  • Service enumeration (banner grabbing).
  • DNS reconnaissance (zone transfer attempts, brute-force subdomain queries).
  • Web-application enumeration (404s on unusual paths).

Initial access.

  • Exploitation of public-facing applications — signature-based detection of known exploits.
  • Phishing-link clicks visible as HTTP requests to attacker domains.
  • Credential brute force — many failed login attempts.

Command and control.

  • Beaconing patterns — periodic connections of small size to external infrastructure.
  • DNS tunnelling — unusual DNS query patterns to a single domain.
  • HTTPS C2 — TLS connections with unusual certificate properties or to suspicious destinations.
  • Specific malware-family signatures (Cobalt Strike, Sliver, Empire, Metasploit beacons).

Lateral movement.

  • East-west traffic between hosts that should not communicate.
  • Remote-management protocols (SMB, RDP, WMI, PowerShell Remoting) in unexpected directions.
  • Pass-the-hash attack patterns visible in Kerberos traffic.
  • Use of administrative shares.

Data exfiltration.

  • Large outbound transfers to unusual destinations.
  • Unusual cloud-storage activity (Dropbox, Google Drive, file-sharing services).
  • DNS exfiltration — encoded data in DNS queries.
  • HTTP POST or PUT of large payloads to unusual destinations.

Denial of service.

  • Volumetric: high packet/bandwidth rates from many sources (DDoS) or single sources (DoS).
  • Application-layer: HTTP request floods, slow-loris-style connection holding.
  • Protocol exploitation: amplification attacks using DNS, NTP, memcached.

Insider data theft.

  • Internal users accessing data outside normal patterns.
  • Email forwarding to external addresses.
  • USB device usage (visible to HIDS, not NIDS).
  • Unusual print-job destinations.

For each, network forensics can produce evidence — but only if the relevant data was captured at the time.

Network forensic findings used in legal proceedings need the same admissibility foundation as other digital evidence (Chapter 1):

Chain of custody. Every capture file, IDS alert export, and analysis result tracked from acquisition to presentation. Hash values for capture files.

Authentication of the source. The capture must be authenticated as coming from the claimed source at the claimed time. Capture-system clocks must be synchronised (NTP); deviations documented. Capture-process configuration documented.

Integrity. The PCAP file is hashed at acquisition; verified at each use. Any alteration (filtering, conversion) is documented and the modified version is hashed.

Reproducibility. The analysis steps that led to findings are documented in enough detail that another analyst can repeat them.

Tool validation. Tools used (Wireshark, Suricata, Zeek) are recognised; versions documented; any custom scripts shared.

Expert testimony. The examiner can explain the findings, the tools, and the methods in plain language to a court that lacks technical background.

Common pitfalls in network-evidence presentation​

Time-zone confusion. Timestamps from systems in different time zones; converted incorrectly; UTC vs local time mixed up. Always document the time zone of every timestamp.

Source/destination ambiguity. In a packet capture, "source" is the perspective at the capture point. A connection from an external attacker to an internal server has the attacker as source from the perspective of inbound traffic at the perimeter. Confusing left/right perspectives produces analysis errors.

NAT-related identity issues. Many internal hosts share a single public IP after NAT. Mapping an external observation to a specific internal host requires NAT translation logs, not just the PCAP.

Encrypted payload assumptions. "We saw the attacker download a file" — but if the traffic was encrypted, the analyst saw only metadata. Stating findings without qualifying the encryption status is misleading.

Misinterpretation of IDS alerts. An alert is not proof of attack; it is proof that the alert fired. Many alerts are false positives. Treating every alert as confirmed attack inflates findings.

Confirmation bias. Network data is voluminous; analysts find what they look for. The discipline of considering alternative explanations (legitimate but unusual activity; benign software with attack-like behaviours) is part of methodological rigor.

Practical guidance​

For an MSc student preparing network-forensic work that may be cited in legal contexts (a thesis, an internship case, a contribution to a publication):

  1. Acquire correctly. Document the capture point, the capture tool, the configuration, the start and end times, the analyst.
  2. Hash immediately. Compute hash of the capture file at acquisition; record it.
  3. Work on copies. Never alter the original capture file. Make working copies for analysis.
  4. Document analysis steps. Each filter applied, each export performed, each finding extracted — recorded.
  5. Cross-reference. Network findings should be cross-referenced against disk, memory, and log evidence. A single source of evidence is weaker than multiple corroborating sources.
  6. State limitations. Explicitly note what cannot be determined from the available data — encrypted payloads, unknown internal-to-NAT mapping, possible time-skew.
  7. Defer attribution. Naming an attacker country or group requires evidence beyond what network forensics typically provides. Stick to "the traffic originated from IP X" rather than "the attack was conducted by [country/group]" unless additional independent evidence supports the stronger claim.

Real-world example — the 2024 GIDC DDoS​

In early 2024, a sustained DDoS campaign against the Government Integrated Data Centre took 400+ government portals offline, including the TIA immigration portal and many ministry websites. From the perspective of network forensics, the investigation would have involved:

  • Capture at upstream peering points where the attack traffic entered Nepal.
  • Flow analysis showing attack volumes, source distributions, target destinations.
  • Identification of the attack vectors (TCP SYN flood, UDP amplification, application-layer).
  • Geographic and ASN analysis of source addresses (recognising that botnet sources rarely correlate with attacker identity).
  • Timeline reconstruction.

Public reporting on the incident was limited, but the technical pattern was familiar. The defensive response — traffic scrubbing through upstream providers — relies on the same network-forensic data that an investigation would use.

The next chapter shifts away from desktop and server forensics to a domain that increasingly carries the most-incriminating evidence in many cases: mobile devices.

· min read