RDP Lateral Movement Forensics: Source Host Artifacts

TL;DR. In RDP lateral movement, the machine the attacker connected from keeps a lot: the bitmap cache (what the remote screen showed), the Microsoft-Windows-TerminalServices-RDPClient/Operational log (event 1024, with the target name), the Terminal Server Client registry keys (targets, UsernameHint, MRU list), Default.rdp, and execution traces of mstsc.exe. The cache has no timestamps, so these artifacts are how you date it and tie it to a target. On the target, the Security log (4624 logon type 10, 4778/4779) and RemoteConnectionManager 1149 confirm the other end.

This article complements the RDP bitmap cache forensics guide. It deliberately stays with a small set of well-known event IDs and keys.

Source and target: who holds what

The source side is often the one that survives. An attacker who cleans up the target leaves the client-side artifacts on the machine they came from, unless they clean that one too.

Source host artifacts

The bitmap cache

C:\Users\<user>\AppData\Local\Microsoft\Terminal Server Client\Cache\, per account. It shows screen content from the remote side: consoles, folder windows, tools. It does not tell you when or where. Collection is covered in RDP bitmap cache location and acquisition.

NTFS timestamps of the cache files

The cache files are ordinary files, so the file system dates them:

• $STANDARD_INFORMATION and $FILE_NAME timestamps in the $MFT: creation and last write of each bcache*.bmc and Cache*.bin.
• $UsnJrnl: create, write and close records for those files, if the journal still covers the period.

Treat these as bounds. A last-write time says the client wrote to the file at that moment; it does not say which tiles were written then, and a file used across several sessions only keeps its latest times. The MFT and USN journal parsers read these.

The RDP client event log

The RDPClient Operational log, Microsoft-Windows-TerminalServices-RDPClient/Operational, is on the source host. Event 1024 records that the client is trying to connect to a server and gives the target name. That gives you a time and a target to set next to the cache.

It records an attempt, not a successful logon. Pair it with the target's logs where you have them. Event log parsing: EVTX parser.

Terminal Server Client registry keys

In the user's NTUSER.DAT, under Terminal Server Client:

These give targets and accounts per user. Registry key last-write times can help order events, but they reflect the last change to the key, not each connection. The registry parser reads these hives.

Default.rdp

Default.rdp in the user's Documents folder holds the settings of the last connection made with the client's defaults. Among other settings it can show whether persistent bitmap caching was enabled (bitmapcachepersistenable:i:1), which tells you whether to expect a cache at all.

Execution of mstsc.exe

Execution traces for mstsc.exe put the client on the timeline: the Prefetch file for mstsc.exe (Prefetch parser) and the jump list of the Remote Desktop client (jump list parser), which can list recent targets.

Target host artifacts

When the target is available, confirm the other end:

We keep this list short on purpose. Many other event IDs appear in RDP write-ups; they vary by version and configuration, and they are not needed to date a cache.

Putting it together: dating the cache

A workable method:

1. Attribute the cache. Note the account from the path (Users\<name>\). That is who ran the client.
2. List targets for that account. Registry Servers subkeys and MRU list, Default.rdp, jump list.
3. Build the connection timeline. RDP client log event 1024 times and targets, Prefetch run times for mstsc.exe.
4. Bound the cache. Creation and last-write times of each cache file; USN records if available.
5. Read the tiles. Look for anything that ties content to a target or time: window titles with a host name, a taskbar clock, dates in file listings, transfer durations.
6. Cross-check on the target. 4624 type 10, 4778/4779, 1149 for the same account and period.

An example with the sample data

The tool ships a synthetic, fictional case (FIN-WKS-07, 2026-09-14) that follows this pattern. The cache collected from the source host, profile svc_backup, holds:

• in Cache0000.bin, a console titled FIN-WKS-07 - console (svc_backup) with an rclone.exe copy C:\Users\Public\data E:\exfil command, a folder window on E:\exfil, and a taskbar clock reading 10:52;
• in bcache22.bmc, an earlier view (about 10:14 on the clock) with tar -xf tools.zip -C C:\ProgramData\Intel and a slot remnant of a creds.txt editor title bar.

The window title names the target; the clocks give remote-screen times. On a real case you would then look for event 1024 entries naming that host around those times, a Servers\FIN-WKS-07 key in the svc_backup hive, and 4624 type 10 logons for the account on the target. Report the clock values as what the screen displayed, and the log times as the timeline.

What to write in the report

Keep the tool's triage hints out of the conclusions: "console-like" is a reason to read a tile first, not a finding.

FAQ

Which host holds the evidence of an outgoing RDP connection?

The source host, the machine where the Remote Desktop client ran. It holds the bitmap cache, the RDP client event log, the Terminal Server Client registry keys and execution traces of mstsc.exe. The target host holds the logon and session records.

Can the bitmap cache tell me which server a tile came from?

No. Tiles carry no host name and no time. Tie them to a target with the RDP client log, the Terminal Server Client registry keys and the target host's logs, and with anything visible in the tiles themselves, such as a window title.

Is event 1024 proof that a session was established?

No. Event 1024 in the RDPClient Operational log records that the client was trying to connect to a server, with the target name. Confirm the logon on the target (Security 4624 logon type 10, or RemoteConnectionManager 1149) when those logs exist.

Related articles

• Reconstructing RDP screens from cache tiles
• How to analyze the RDP bitmap cache in your browser
• RDP bitmap cache location and acquisition