Windows Memory Forensics: Network Artifacts Review

 

Network artifact analysis remains a foundational and high-fidelity technique within modern digital forensics and incident response (DFIR) for the identification of malicious activity. While early remote access trojans (e.g., Back Orifice) characteristically exposed persistent listening sockets as command-and-control (C2) backdoors, contemporary adversaries have largely abandoned inbound listener models in favor of infrequent, outbound beaconing architectures designed to evade perimeter controls and blend with legitimate traffic volumes.

Memory-resident network structures continue to yield critical investigative value. Analysts should systematically examine the following categories of anomaly, always interpreting findings against an established environmental baseline and in conjunction with process lineage, code injection indicators, and temporal correlation:

Anomalous Listening Ports and Socket Ownership

Although persistent inbound listeners are comparatively rare, they persist in certain toolsets and misconfigurations. Deviation from the expected process ownership of well-known ports warrants immediate scrutiny. For example, SMB (TCP/445) traffic is almost exclusively owned by the System process under normal Windows operation; attribution to an alternate process image may indicate an internal Cobalt Strike SMB beacon, named-pipe pivot, or covert port-forwarder/redirector. Socket creation timestamps further enable correlation with proximate process and thread instantiation events.

Suspicious Connection Semantics and Directionality

Modern C2 frequently egresses over high-utilization ports (TCP/80, 443, 8080) to reduce signature detection. Observing such a connection originating from a non-browser process (or, conversely, a browser process using atypical ports) raises suspicion relative to a connection terminating on an ephemeral high port. Port selection itself often encodes directional intent: reserved or well-known ports more commonly designate the listening endpoint. Protocol diversity must not be overlooked—UDP remains deliberately employed by multiple malware families for peer-to-peer C2 and is the transport of choice for DNS tunneling (UDP/53). Critically, memory forensics frameworks can recover both active and previously terminated sockets, extending visibility beyond the narrow temporal window of acquisition.

Process-Level Network Legitimacy

Not every process possesses a legitimate requirement for network interaction. The recovery of residual socket objects associated with terminated or short-lived processes can surface otherwise ephemeral C2 activity that would escape live network monitoring.

High-Value Heuristic Indicators

When evaluating network behavior, the following patterns merit elevated scrutiny (none of which are independently dispositive):

• Any non-browser process communicating over TCP/80, 443, or 8080.
• Any browser process communicating outside those ports.
• Connections to unexplained internal or external IP addresses (geolocation and IP-reputation enrichment may supply additional context, though geography alone—e.g., unexpected destinations in specific jurisdictions—must be evaluated relative to organizational baselines).
• HTTP(S) requests directed to raw IP addresses rather than fully qualified domain names.
• Remote Desktop Protocol (TCP/3389) sessions originating from atypical source addresses, particularly those bypassing expected VPN or jump-host infrastructure.
• DNS queries for anomalous or previously unobserved domain names.
• Workstation-to-workstation connections (RDP, SMB share mapping, or authentication). Enterprise traffic models are predominantly client-to-server; lateral workstation communication frequently indicates unauthorized movement.

No single network indicator is conclusive. Legitimate enterprise software—update agents, endpoint detection platforms, cloud synchronization clients, and monitoring tooling—can generate traffic patterns that superficially resemble the heuristics above. Consequently, findings must be contextualized through multi-artifact correlation (process trees, parent-child relationships, injected modules, and temporal proximity) and evaluated against a pre-established baseline of normal network behavior. The absence of such a baseline substantially degrades signal-to-noise ratio.

Furthermore, the increasing prevalence of encrypted transports (TLS, DNS-over-HTTPS, QUIC) and domain-fronting or CDN-abuse techniques diminishes the efficacy of pure packet-level inspection, reinforcing the comparative advantage of memory-resident network object recovery. Analysts should therefore treat network artifacts as high-value leads rather than standalone evidence of compromise, integrating them into a broader forensic hypothesis-testing framework.

Within the Volatility 3 framework, network artifact recovery is realized through two complementary plugins that mirror the dual methodological paradigm employed by the process-enumeration plugins (list walking versus pool-tag scanning).

The windows.netstat plugin implements the high-fidelity structural traversal approach. It first locates the tcpip.sys driver image in kernel memory, then systematically enumerates the live network objects maintained within its internal tracking structures—specifically the UdpCompartmentSet, TcpCompartmentSet, and the TCP Endpoint partition tables (or their predecessor PortPool constructs on earlier Windows 10 builds). This yields a temporally constrained view of network activity that existed at the moment of memory acquisition, with comparatively low false-positive rates because it relies on intact, linked kernel data structures.

By contrast, windows.netscan employs a brute-force pool-tag scanning methodology. It carves candidate objects from non-paged pool (and free pool pages) by matching well-known pool tags—TcpE for TCP endpoints, TcpL for TCP listeners, and UdpA for UDP endpoints—then applies structural validation. This approach can recover residual or historically terminated network objects as well as structures that malware may have deliberately unlinked from the active lists in an attempt at concealment. The trade-off is an elevated risk of false positives and partially overwritten remnant structures that may yield incomplete or unreliable field values. Consequently, the optimal investigative practice is the concurrent execution of both plugins, leveraging the precision of structural enumeration alongside the residual-artifact recovery of pool scanning.

Volatility 2 Network Plugin Architecture

Network artifact plugins constitute the sole class of Volatility 2 plugins that remain strictly operating-system-version dependent. Significant architectural changes to the Windows TCP/IP stack beginning with Vista rendered the earlier linked-list walking techniques non-portable. Rather than retrofit the legacy plugins, the Volatility development team introduced the unified netscan plugin for all post-XP systems (Vista, Windows 7, Server 2008 and later). netscan consolidates both socket and connection data into a single, netstat-style output, thereby accelerating review.

Windows XP (and Server 2003) analysis continues to require the original, specialized suite:

• connections walks the single-linked list of active TCP connection objects rooted in tcpip.sys.
• connscan performs the complementary pool-tag scan for residual _TCPT_OBJECT structures.
• sockets enumerates the single-linked list of _ADDRESS_OBJECT socket structures.
• sockscan applies pool-tag scanning to recover residual socket objects.

Thus, for any Windows XP memory image, both the list-walking and pool-scanning pairs must be executed to achieve comprehensive coverage; for all subsequent operating systems, the single netscan plugin suffices.

Neither plugin class is exhaustive. Structural traversal (netstat/connections/sockets) will miss deliberately unlinked or already-freed objects, while pool-tag scanning (netscan / connscan / sockscan) introduces the possibility of false positives and corrupted remnants. Encrypted transports, domain fronting, and short-lived sockets further constrain visibility. Results must therefore be correlated with process lineage, temporal proximity of process/thread creation, and an established network baseline before investigative conclusions are drawn.

Recovery of memory-resident network artifacts within Volatility 3 is accomplished through a dual-plugin methodology that parallels the list-walking versus pool-scanning dichotomy employed for process enumeration.

The windows.netstat plugin performs deterministic traversal of the live linked-list structures maintained by tcpip.sys (UdpCompartmentSet / TcpCompartmentSet and associated endpoint partition tables). In contrast, windows.netscan executes a pool-tag carving operation against the non-paged (and free) pool, locating residual _TCP_ENDPOINT (TcpE), _TCP_LISTENER (TcpL), and _UDP_ENDPOINT (UdpA) objects irrespective of their current linkage status.

A principal forensic advantage of this stage is the extended residence time of network objects in memory after connection termination. Because many command-and-control implants employ intermittent beaconing, the probability that an active socket exists at the precise moment of acquisition is often low; residual structures recovered by windows.netscan therefore supply critical historical visibility. For exhaustive coverage, the --include-corrupt flag may be supplied, expanding the scan to partially overwritten or structurally incomplete candidates—at the acknowledged cost of elevated false-positive rates and the potential inclusion of garbage data.

Best practice dictates concurrent execution of both plugins. Each is capable of surfacing activity invisible to the other: structural traversal yields high-confidence live objects, while pool scanning recovers unlinked or temporally distant remnants. All recovered objects must be evaluated against the investigative objective of anomaly detection. Particular attention is directed to:

• the legitimacy of the owning process (every socket and endpoint is bound to a discrete PID and process image);
• the geographic or organizational appropriateness of remote endpoints;
• the use of atypical protocols or ports relative to the process’s expected behavior;
• deviations from the established network baseline (for example, a process that should remain strictly intra-network or non-networked).

When available, the creation timestamp associated with each network object enables precise temporal correlation with process, thread, and other artifact timelines generated in parallel analysis stages. Note that timestamp recovery is profile- and structure-dependent and is not guaranteed across every Windows version or Volatility symbol set.

For each identified network object, the plugins surface the following fields: virtual (or physical) offset, protocol, local address and port, foreign address and port, owning PID, process image name, and—when present—creation time. These data points constitute high-value leads that must be cross-referenced with process lineage, code-injection indicators, and environmental baselines before any definitive attribution of compromise is asserted.

Figure 1: truncated output of the windows.netscan Volatility 3 plugin

Why this stands out

• Non-browser process on port 443—Exactly the classic indicator: “Any process communicating over port 80, 443, or 8080 that is not a browser.”
• Outbound to an unexplained external IP—203.78.103.109 is a public address (not internal, not localhost, not link-local). A direct IP connection (no domain name visible in the socket) is another red flag during analysis.
• Process name—coreupdater.ex (almost certainly coreupdater.exe) looks like a fake/system updater, which is a very common malware naming pattern.
• Everything else in the output is expected for a Windows Domain Controller / DNS server:
  • Massive number of high UDP ports owned by dns.exe (normal DNS query sockets)
  • lsass.exe listening on the LDAP-family ports (389, 636, 3268/3269)—this is the process's legitimate role as the domain controller's directory service.
  • dfsrs.exe, dfssvc.exe, and ismserv.exe (DFS Replication, DFS Namespace, and Intersite Messaging, respectively) communicating over RPC—these ride the dynamic/ephemeral port range negotiated through the RPC endpoint mapper (TCP/135).
  • Standard listening ports (53, 389, 636, 3268/3269, 3389, 5985, 135, 139, etc.).

This is the clear outlier and the one that would immediately warrant further investigation (process tree, command line, memory dump of PID 3644, IP reputation, etc.).

Examination of network connections remains a foundational technique in incident response and retains equivalent analytical value within a memory-centric investigative methodology. Malware must balance concealment with the operational necessity of network communication; without the ability to transmit or receive data, a compromised host provides limited utility to an adversary. Recovery and analysis of active and residual network sockets therefore enables identification of malicious connections, including those established prior to memory acquisition.

Because network objects maintain explicit process ownership, a suspicious connection can be attributed directly to a specific process and temporal context. Socket creation timestamps further support timeline reconstruction by facilitating correlation with concurrent process, thread, and file-system artifacts. Network artifacts constitute among the most readily interpretable data sources for detecting malicious activity. Analysts should prioritize examination of the following indicators:

• Anomalous ports.
• Suspicious connection endpoints and directionality.
• Known-malicious IP addresses.
• Atypical network behavior exhibited by processes.
• Anomalous creation timestamps of network objects.