Registry Parser
← All articles

Host network identity: the RegRipper tcpip and network interfaces plugins

7 min read

Ask a SYSTEM hive what the machine's network identity was at the moment of acquisition and it will tell you, precisely: the hostname, the domain, every IP address it held, the DHCP server it leased each one from, and when those leases were granted. The RegRipper tcpip and network_interfaces plugins read that out of the Tcpip service parameters. This is the artifact that places a host on a specific network segment at a specific time, and it does it from a single hive, no logs required.

Where it lives

There are two layers, and they sit under the active control set in the SYSTEM hive.

The machine-wide layer is at SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. The values that matter:

  • Hostname: the current computer name as TCP/IP sees it.
  • NV Hostname: the "non-volatile" hostname, i.e. the name written to disk at configuration time. Under normal conditions Hostname and NV Hostname agree. When they disagree, the box was renamed and has not rebooted since, or someone changed it live. That discrepancy is worth noting in your report.
  • Domain: the primary DNS domain suffix, statically configured.
  • DhcpNameServer: the DNS server(s) handed out by DHCP at the machine scope.

The per-interface layer is one key down: SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<GUID>. Each network adapter that has ever been bound to TCP/IP gets a subkey named for its interface GUID, for example {1B2F3C4D-...}. Inside each, the IP configuration:

  • DhcpIPAddress: the address the interface was assigned by DHCP.
  • DhcpServer: the DHCP server that issued the lease.
  • DhcpNameServer: the DNS server(s) for this interface.
  • DhcpDefaultGateway: the gateway handed out with the lease.
  • DhcpSubnetMask: the subnet mask for the leased address.
  • Lease timing: LeaseObtainedTime and LeaseTerminatesTime, stored as Unix epoch seconds (not FILETIME), plus T1 and T2 (the renewal and rebinding timers).

If the interface is statically configured rather than DHCP, you get IPAddress, SubnetMask, DefaultGateway, and NameServer instead, and EnableDHCP will be 0. The presence of the Dhcp* values versus the static ones tells you which mode the adapter was in.

The parser on this site surfaces both. The tcpip_params plugin reads Hostname, NV Hostname, Domain, and DhcpNameServer from the machine-wide key. The network_interfaces plugin walks every subkey under Interfaces, and for each one resolves the IP as DhcpIPAddress or, failing that, IPAddress — so a statically configured NIC still shows up — then reports the interface GUID, the IP, the DhcpServer, and the DhcpDomain. It skips interfaces with neither an IP nor a DHCP server, which filters out the empty tunnel and loopback pseudo-adapters that otherwise clutter the output.

The interface GUID is not a name

The Interfaces key gives you a GUID and an IP. It does not tell you whether that GUID is the Ethernet port, the Wi-Fi card, or a VPN virtual adapter. For an analyst writing "the host was cabled into the 10.20.x.x segment," that distinction matters.

The mapping lives in the SOFTWARE hive, not SYSTEM. Under SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkCards each adapter has a numbered subkey containing:

  • Description: the friendly adapter name, e.g. "Intel(R) Ethernet Connection I219-LM".
  • ServiceName: the interface GUID.

ServiceName is the join key. It is the same GUID that names the subkey under Tcpip\Parameters\Interfaces. So the pivot is: take the GUID from network_interfaces, look it up as a ServiceName under NetworkCards, and read the Description. The network_cards plugin does exactly this lookup against the SOFTWARE hive and reports Description alongside the ServiceName / GUID.

Practically, this means you need both hives loaded to tell the full story. SYSTEM gives you "GUID X had IP 10.20.4.55 from DHCP server 10.20.0.1." SOFTWARE turns that into "the Intel onboard Ethernet had IP 10.20.4.55." RegRipper's nic2.pl does the same correlation; if you want to see exactly which values it pulls and how it joins them, the source is worth reading.

What this actually proves

The hostname and domain are the machine's identity at acquisition. If your incident references "WIN-MKTG-04" and the hive says Hostname = WIN-MKTG-04, you have tied the image to the named host. The NV Hostname versus Hostname comparison can catch a recent rename, which is occasionally how an attacker disguises a staging box.

The per-interface IP and DHCP server are the stronger evidence. An IP address alone is weak — it could be stale, it could be from any network. But DhcpServer plus DhcpIPAddress plus DhcpDefaultGateway together describe a specific network segment. A DHCP server at 10.20.0.1 handing out 10.20.4.55 with a gateway of 10.20.4.1 places the host on that subnet, on that broadcast domain, talking to that specific DHCP infrastructure. In an enterprise where each VLAN has a known DHCP scope, the DhcpServer value alone can tell you which physical or logical segment the machine sat on — which floor, which site, which VRF.

Then the lease timestamps. LeaseObtainedTime is when DHCP granted the address; LeaseTerminatesTime is when that lease would have expired. These bound a window during which the host demonstrably held that IP and was therefore powered on and attached to that network. If you are correlating against firewall logs, NetFlow, or a DHCP server's own lease database, these two timestamps are the anchor. They convert "this host had this IP at some point" into "this host held this IP from 2026-06-15 08:14 UTC and the lease ran to 2026-06-18 08:14 UTC."

A note on the format: the lease times are Unix epoch seconds stored in REG_DWORD, not the FILETIME you see elsewhere in the registry. A decoder expecting 64-bit FILETIME will produce garbage. Make sure whatever you use treats them as 32-bit epoch seconds.

Pair it with networklist

tcpip/network_interfaces tells you the host's own addressing. It does not tell you which named networks the host connected to over time, or whether they were "Public" or "Domain" profiled. That is the job of the networklist plugin, which reads SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList. Used together they are complementary:

  • tcpip gives the current per-interface IP, DHCP server, and lease window — a point-in-time snapshot, mostly the present.
  • networklist gives the history of named networks, their first/last connection dates, and their gateway MAC addresses — a timeline of where the machine has been.

The gateway MAC from networklist and the DhcpDefaultGateway IP from tcpip describe the same upstream device from two angles. When both point at the same network, you have a corroborated location. The DhcpServer from tcpip and the network profile from networklist together answer "was this a corporate network or a coffee-shop Wi-Fi" for the segment the host was last on.

The CurrentControlSet gotcha

CurrentControlSet does not exist on disk. It is a volatile key that Windows constructs at boot by pointing at one of the numbered control sets — ControlSet001, ControlSet002, and so on. When you mount a hive offline, there is no CurrentControlSet to read. If a tool blindly opens CurrentControlSet\Services\Tcpip\Parameters against a dead hive, it either fails or, worse, silently reads the wrong control set.

The correct resolution: read SYSTEM\Select\Current, which is a REG_DWORD. A value of 1 means ControlSet001 is the active set, 2 means ControlSet002, and so on. The plugins here do this — they read Select\Current, and if it is a positive number they target ControlSet00N zero-padded to three digits; only if that fails do they fall back to ControlSet001, and then to the literal CurrentControlSet for the live-hive case. Reading the wrong control set is not a hypothetical: after certain failed boots, LastKnownGood and Current diverge, and the inactive set can hold a different IP configuration. Always resolve through Select\Current, and state in your notes which control set you read.

One more caveat worth hedging on: the Interfaces subkeys persist. A GUID with an IP in the hive does not guarantee that interface was active at acquisition — it may be a stale entry from a previous DHCP lease on a now-disconnected adapter. The lease timestamps are how you tell live from stale. Treat an interface with no recent LeaseObtainedTime as historical, not current.

Tools

  • RegRipper's tcpip / nic2 plugins. These read the Tcpip parameters, walk the interfaces, decode the lease epoch times, and correlate the GUID to NetworkCards. See the RegRipper plugins reference for the broader set.
  • Eric Zimmerman's Registry Explorer / RECmd. Browse Tcpip\Parameters\Interfaces directly and read the raw lease values.
  • You can analyze a SYSTEM hive in your browser on this site, which runs the tcpip_params and network_interfaces plugins and, with the SOFTWARE hive loaded, resolves the GUID to its friendly adapter name.

Load SYSTEM and SOFTWARE together, resolve the control set through Select\Current, read the lease timestamps as epoch seconds, and pair the result with networklist. Done that way, the registry alone reconstructs the host's network identity — name, addresses, segment, and the window it held them — with timestamps precise enough to anchor a timeline.