Registry Parser
← All articles

Tracing lateral movement through the registry

7 min read

You have a machine that an attacker used as a pivot. EDR flagged a credential-theft event on a finance workstation, the SOC pulled the disk, and the incident lead has one question for you: from this box, where did they go next? Lateral movement leaves its loudest evidence on the network and in the Security event log on the destination hosts. But the lateral movement registry artifacts on the source machine — the box doing the reaching — are where you reconstruct the operator's intent and footprint when the network telemetry is gappy and the destination logs have rolled. This post is about reading the RDP and SSH history out of a single set of hives and turning it into an answerable map: which remote hosts, with which tools, over which networks.

This is the source-side view. Everything below is read from the hives of the pivot machine itself. It tells you what the operator did from here, which is exactly the question the IR lead asked.

The artifacts that matter

Each of these answers a different slice of "where did they go." Read them together; none is conclusive alone.

  • RDP client history — HKCU\Software\Microsoft\Terminal Server Client\Servers and the Default\MRU* values in NTUSER.DAT. Every host this user typed into mstsc, plus the username hint cached per server. This is your primary RDP target list.
  • Saved SSH/SFTP sessions and SshHostKeys — PuTTY and WinSCP under NTUSER.DAT. Configured targets, and — for PuTTY's SshHostKeys — proof of an actual handshake. See the PuTTY/WinSCP sessions deep-dive; a cached host key means they connected, not just configured.
  • TypedPaths and RunMRU — ...\Explorer\TypedPaths and ...\Explorer\RunMRU in NTUSER.DAT. UNC paths and admin shares (\\dc01\c$, \\fileserver\share) typed into the address bar or the Run box. See the TypedPaths/TypedURLs deep-dive.
  • Mapped network drives — ...\Explorer\Map Network Drive MRU and the ...\Network\<drive> keys in NTUSER.DAT. Which remote shares were mapped to a drive letter, i.e. persistent SMB destinations.
  • NetworkList — HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList in the SOFTWARE hive. Which networks and segments the machine joined, with first/last-connected timestamps. See the NetworkList deep-dive.
  • TCP/IP host identity — HKLM\SYSTEM\...\Services\Tcpip\Parameters\Interfaces in the SYSTEM hive. The machine's own hostname, domain, and per-interface IP/DHCP history — who this box was on the wire. See the TCP/IP interfaces deep-dive.

A working order

Sequence matters. Establish identity, then build the target list, then constrain it in time and space.

1. Pin down who this machine was. Start in SYSTEM with the TCP/IP interfaces. You need the hostname, the domain, and the IP(s) this box held — including the DHCP lease history, because the IP an attacker pivoted from may not be the one on the disk today. Everything downstream is "host X reached host Y"; without X you have an orphaned list. Write the hostname and IPs at the top of your notes.

2. Build the raw destination list. Now harvest every remote host named anywhere on the box, without yet judging it:

  • RDP: every server under Terminal Server Client\Servers, and the ordered Default MRU. The MRU order is itself useful — it is roughly recency-ranked.
  • SSH/SFTP: every HostName across PuTTY and WinSCP sessions, and — separately — every host:port in PuTTY's SshHostKeys.
  • UNC: every server in TypedPaths and RunMRU that starts with \\, and every remote target in Map Network Drive MRU.

Dump them into one table, deduplicated by host. You now have the full set of remote endpoints this box ever pointed at.

3. Separate intent from connection. This is the step analysts skip, and it is where the report gets its spine. A saved RDP server, a WinSCP session, a typed UNC path — these prove someone configured or typed a target. They do not prove a session happened. The artifacts that move you to "connected":

  • A PuTTY SshHostKeys entry — written only after a completed handshake.
  • A mapped drive (a populated ...\Network\<letter> key) — the OS persisted the mapping, which implies a successful mount, not just a typed path.
  • An RDP server with a cached username — mstsc writes that hint after a connection attempt.

Mark each destination "configured" or "connected." The IR lead cares about the difference, and so will anyone reading the report later.

4. Constrain it in space and time with NetworkList. Pull the NetworkList from SOFTWARE. Each network profile carries first- and last-connected timestamps and a profile GUID that ties to the interface. This answers a question the host list alone cannot: was the box even on a network from which the target was reachable, and when? If the destination is on 10.0.5.0/24 and NetworkList shows the machine joined the "CORP-VPN" profile only during the intrusion window, you have just placed the pivot in time and in segment. Cross the NetworkList timestamps against the recency ordering of the RDP and UNC MRUs.

5. Write the narrative. "Workstation FIN-WS07 (10.0.3.42, joined CORP-VPN 2026-06-10) reached bastion jumphost-dmz over SSH (host key cached), then mapped \\dc01\c$ and RDP'd to dc01 and app03." That sentence is the deliverable. Every clause traces back to a specific value in a specific hive.

Gotchas

  • MRU order is recency, not a timestamp. Servers\Default and the Map Network Drive MRU give you an ordering, not per-entry times. The key's own LastWrite is when the most recent entry was added — it does not date the older ones. Do not present MRU position as a timeline; use NetworkList and the destination-side logs for actual times.
  • A typed UNC path is not a successful access. TypedPaths and RunMRU record what was typed, including typos and paths to hosts that refused the connection. Treat them as intent until a mapped drive, a shellbag, or a destination log corroborates the access.
  • PuTTY percent-encodes session names. A session named web 01 is stored as web%2001. Decode before you match host lists, or you will miss correlations.
  • WinSCP keeps no registry host-key cache by default. Unlike PuTTY, you cannot make the airtight "they connected" claim from WinSCP alone — its session list is configured targets. Corroborate elsewhere.
  • Per-user vs per-system scope. RDP, SSH, TypedPaths and mapped drives live in NTUSER.DAT — per user profile. If multiple users logged in, parse each NTUSER.DAT separately and attribute destinations to the right account. NetworkList and TCP/IP are system-wide in SOFTWARE/SYSTEM.
  • DHCP history misleads. The IP on the SYSTEM hive at acquisition may not be the lease the box held during the intrusion. Check the lease timestamps in the Tcpip interface values before you assert "this box was X."
  • Profile reuse. A wiped-and-reimaged box, or a roaming profile, can carry destinations from a prior life. Anchor everything to the NetworkList and lease timestamps so you do not attribute a stale session to the current incident.

Work the case in your browser

You can do every step above against the dropped hives without uploading anything. Load NTUSER.DAT, SOFTWARE and SYSTEM into the browser-based registry parser — the relevant plugins render the RDP server list, the PuTTY/WinSCP session tables (PuTTY names URL-decoded), TypedPaths/RunMRU, the mapped-drive MRU, NetworkList with timestamps, and the TCP/IP interface identity. The hives are parsed client-side and discarded when you close the tab; nothing leaves the workstation, which keeps chain of custody intact for credential-bearing hives.

Then build the timeline by hand: SYSTEM identity at the top, the deduplicated destination table next (each row tagged configured or connected), and the NetworkList join/leave windows as the time axis. Export the artifact extractions with the load-time hash for your case notes, and reconcile the source-side picture against the destination hosts' Security logs.

Related

The source-side hives will not give you the whole intrusion — the destination logs and the network telemetry close the loop. But on a pivot host, the RDP server list, the SSH sessions and host keys, the typed UNC paths and mapped drives, fenced in time by NetworkList and anchored by the box's own TCP/IP identity, reconstruct the operator's reach from one place. Build the destination table, split configured from connected, and put a network and a timeframe around every hop. That is lateral movement, read backwards from the machine that did the reaching.