Live Network State and Process Capture

RFC 3227, published in 2002, established the order of volatility as a guiding principle for digital evidence collection. The categories, from most to least volatile, are: registers, cache, and memory contents; network state and active connections; running processes; disk data; backup media; and finally printed output or remote logs. This ordering exists because actions taken later in the sequence can destroy evidence collected earlier. A responder who captures a disk image before recording active connections has potentially flushed network buffers, closed TCP sessions, and caused the kernel to evict memory pages that held connection-state data.

In practice, the live capture phase typically collects four categories of network state in sequence: the active connection table (TCP and UDP connections with remote addresses and states), the ARP cache, the DNS resolver cache, and the routing table. Each takes seconds to collect. Together they give the responder a snapshot of who the compromised host was talking to at the moment of capture, which hosts it had recently contacted, which domains it had resolved, and how traffic was being routed. This snapshot informs every containment decision that follows.

Some responders argue that network state capture should be deferred until after memory acquisition so that the memory image includes the connection-state data redundantly. This is a reasonable position on isolated, stable systems. On live enterprise hosts under active attack, the compromise may be spreading laterally while the memory acquisition runs. Capturing network state first provides an immediate picture that the containment team can act on in parallel with the acquisition.

The active connection table is the most actionable single artefact in a live response. It shows every established TCP session, every UDP socket awaiting packets, and every listening port, together with the process ID and, on most platforms, the owning process name. A connection to an unfamiliar IP address on a high-numbered port from a process that should not be making network connections is a strong indicator of compromise even before any log analysis begins.

After recording the connection table, the responder cross-references each PID against the process list to confirm the process name and its executable path. A PID listed in netstat as owning a connection to an external IP, but whose process name resolves to 'svchost.exe' or 'lsass.exe', warrants immediate investigation: those process names are frequently spoofed by malware, and a legitimate svchost would not typically hold an outbound connection to a residential IP address. The combination of connection record and process detail is more informative than either artefact alone.

The ARP cache records IP-to-MAC mappings for hosts the system has communicated with on the local network segment. Its forensic value is in revealing lateral movement. If a workstation's ARP cache contains entries for servers it has no legitimate reason to contact, those entries are evidence of scanning, credential spraying, or lateral movement attempts. ARP entries typically expire after a few minutes of inactivity, so their presence at capture time implies recent contact. On Windows, 'arp -a' lists the cache. On Linux, 'arp -n' or the preferred modern form 'ip neigh' displays the same data including entry state (REACHABLE, STALE, DELAY, FAILED).

The DNS resolver cache records the results of recent DNS queries. Entries persist for the duration of the DNS TTL, which can range from a few seconds to several hours. The cache exposes every domain the system has resolved recently, including command-and-control domains, data exfiltration endpoints, and phishing sites. On Windows, 'ipconfig /displaydns' lists all cached entries with their TTLs and resolved addresses. On Linux, the cache is held by the stub resolver service (systemd-resolved on most modern distributions), accessible via 'resolvectl statistics' and 'resolvectl query' for individual names, or by inspecting '/var/cache/nscd/hosts' on nscd-based systems.

The routing table is less likely to reveal attacker activity directly, but it is captured as a standard part of live triage because attackers sometimes inject routes to redirect traffic or to ensure malware-generated connections leave through a specific interface. On Windows, 'route print' or 'Get-NetRoute' shows the routing table. On Linux, 'ip route' or 'netstat -rn' provides the same view. Unexpected routes to specific hosts or subnets, particularly routes pointing to interfaces not normally used for outbound traffic, are an indicator of a persistent routing manipulation.

A process tree shows every running process together with its parent process ID (PPID). The parent-child relationship is central to detecting malicious activity. Legitimate processes follow predictable ancestry: 'explorer.exe' spawns user applications; 'services.exe' spawns service host processes; 'wininit.exe' spawns 'lsass.exe' and 'services.exe'. When a process appears under an unexpected parent, such as 'cmd.exe' spawned by 'iexplore.exe', or a PowerShell session spawned by a document editor, the anomaly is immediately visible in the tree and would be invisible in a flat process list sorted by PID.

On Windows, the Sysinternals tool PsList with the '-t' flag displays the process tree in text form. The PowerShell command 'Get-WmiObject Win32_Process | Select-Object ProcessId,ParentProcessId,Name,ExecutablePath' provides the raw data for tree reconstruction and includes the full executable path, which is useful for detecting process name spoofing. On Linux, 'ps auxf' renders the process tree directly in the terminal using ASCII art indentation. The 'pstree -p' command provides a compact tree with PIDs. Both show command-line arguments, which frequently reveal the exact payload a malicious process was launched with.

Common malicious parent-child patterns include: a web server process (IIS w3wp.exe, Apache httpd, nginx) spawning cmd.exe or powershell.exe, indicating web shell execution; a document reader or email client spawning a scripting engine, indicating a malicious macro or attachment exploit; a process with a legitimate-sounding name in an unusual directory (for example, svchost.exe in C:\Users rather than C:\Windows\System32) spawning network-connected children; and a scheduled task runner spawning an unexpected binary, indicating persistence via task scheduler. Recognising these patterns requires familiarity with normal process hierarchies on the platform being examined.

Every command executed on a live system modifies it. Timestamps change. Memory pages are allocated and released. If an attacker has replaced system utilities with trojaned versions, running the system's own 'netstat' or 'ps' may return filtered output that hides the attacker's connections and processes. The trusted response kit addresses both problems. It is a portable collection of statically compiled binaries for the target platform, stored on write-protected media such as a USB drive with a physical write-protect switch, and cryptographically verified with a known hash before each use.

Forensic readiness programmes, described in standards such as ISO 27035 and the UK National Cyber Security Centre's incident management guidance, specify that response kits should be maintained, tested, and available before an incident occurs. See Forensic Readiness and Toolkits for toolkit composition guidance. In practice, many organisations run their first live response using whatever tools are available on the system, then update their toolkit after the incident. This is understandable but avoidable.

Contamination documentation is as important as contamination minimisation. Every command executed during live response, its exact syntax, the timestamp of execution, and the responding analyst's identity should be recorded. This record forms part of the chain of custody documentation. Under the UK's PACE 1984 Code B guidelines, the Indian Bharatiya Sakshya Adhiniyam 2023 provisions on electronic records, and US Federal Rules of Evidence Rule 901, evidence integrity challenges in court often focus on who had access to the system and what they did to it. A complete action log answers that question before it is asked.

The purpose of live network state and process capture is to inform containment, not to conclude the investigation. Once the responder has captured the connection table, ARP cache, DNS cache, routing table, process tree, and open file handles, the data should be analysed immediately against specific containment questions: Is there an active outbound connection to a known-malicious or unrecognised IP that must be blocked at the firewall or host? Has the attacker's process established persistence that will survive a process termination? Are ARP entries present for hosts that have not yet been scoped into the investigation, suggesting lateral movement that must be traced? Are DNS cache entries pointing to command-and-control domains that can be sinkholed or blocked at the DNS resolver?

Containment decisions made without live state data risk being incomplete. Blocking a single IP address while the attacker maintains a second active connection through a different path achieves nothing. Terminating a visible malicious process that has already written a persistence mechanism to disk only delays the next execution. The live capture provides the map; containment uses that map to close every exit at once rather than one at a time. This containment-first logic is explicitly reflected in the NIST SP 800-61 lifecycle and the SANS PICERL containment phase. More detail on how these triage findings feed into formal containment strategy is covered in Triage and Incident Prioritisation.

After containment actions are taken, the live capture data also seeds the investigation's scope. The list of remote IPs from the connection table becomes the starting point for threat intelligence lookups and firewall log searches. The domains from the DNS cache feed into historical DNS query analysis to establish the timeline of C2 communication. The process tree and open file handle data feed into the memory analysis and disk forensics phases that follow. Live capture is not a standalone activity: it is the bridge between the detection alert and the structured forensic investigation described in the broader digital forensics discipline.