RDP Lateral Movement Analysis

RDP is widely used by system administrators to manage remotely Windows hosts across an environment. However, attackers abuse this same capability for lateral movement, pivoting through stolen credentials and chaining across multiple hosts to reach high-value targets. Sophos's Active Adversary Report for 1H 2024 (opens in new tab) found that attackers abused RDP in 90% of the incidents it investigated, and used it for internal lateral movement in 90% of those cases, and Mandiant's ransomware retrospective (opens in new tab) reported similar numbers, with ransomware operators like BianLian (opens in new tab) and RansomHub (opens in new tab) and nation-state actors like Volt Typhoon (opens in new tab) all documented using it under MITRE ATT&CK T1021.001 (opens in new tab).

In this room, we will focus on RDP as a lateral movement technique in Windows environments. We'll learn how to identify, correlate, and reconstruct RDP-based lateral movement during real-world investigations.

Learning Objectives

• Read RDP-specific event log entries on source and destination hosts and identify malicious sessions by the patterns that distinguish them from legitimate ones
• Correlate RDP activity between source and destination using IP pivots, account names, and Terminal Services session events
• Recover RDP-specific on-host artifacts (the Terminal Server Client registry keys and the bitmap cache) when event logs are cleared
• Apply audit policies, network controls, and detection rules that actually reduce RDP-based lateral movement exposure

Prerequisites

• Windows Event Logs: Reading Security and Operational channels (Windows Event Logs room)
• Windows Forensics: Registry hives, Prefetch, Jump Lists, MFT (Windows Forensics 1 and Windows Forensics 2 rooms)
• Active Directory authentication: Logon types, Kerberos/NTLM basics (Active Directory Basics room)

Machine Access

Before proceeding, start the lab by clicking the green Start Machine button. Please wait about three minutes for the machine instance to launch.

Set up your virtual environment

To successfully complete this room, you'll need to set up your virtual environment. This involves starting the Lab Machine, ensuring you're equipped with the necessary tools and access to tackle the challenges ahead.

Lab machine

Status:Off

Start Lab Machine

We provide access to an analyst workstation preloaded with the Velociraptor Windows.KapeFiles.Targets triage collections for this room. Once it's up, a session opens on the right side of the screen; if you don't see it, click the blue Show Split View button at the top of the page. If you prefer using RDP, you can use the following credentials:

On the D:\ drive, you'll find two folders: D:\Walkthrough\ holds the triage we'll use in Tasks 4 and 5, and D:\Challenge\ holds the triage for the Investigation Challenge in Task 6. All forensic tools are pre-installed and live in the DFIR Tools folder under C:\Users\DFIRUser\.

Remote Desktop Protocol (RDP) is a built-in Windows feature that gives a connecting user a full graphical session on a remote host across the network. When an attacker has acquired valid credentials, this technique allows them to log on interactively to any reachable Windows machine without uploading a binary or running a specialized tool.

When a user double-clicks mstsc.exe and types a hostname into the Computer field, as shown in the screenshot, the client resolves the hostname and opens a connection directly to TCP 3389 (or UDP 3389) on the destination's Remote Desktop Services (TermService).

The flow that happens is:

1. The client opens TCP 3389 to the destination
2. NLA (Network Level Authentication) pre-authenticates the connection using CredSSP before any session resources are allocated
3. The destination validates the credentials (local SAM, or AD via Kerberos/NTLM)
4. The destination creates the session and starts the Windows shell (explorer.exe) under the user's context
5. Supporting processes start in the session: rdpclip.exe (clipboard sharing) and tstheme.exe (theme rendering)
6. The server streams bitmap data to the client and receives keyboard and mouse input back

Key Components

There's an important thing that we need to understand about RDP, which is that the connection runs a small set of processes and services, and knowing which runs where is one of the clearest ways to tell whether RDP was attempted. We'll cover this in more detail in the artifacts section, but here, generally what we need to understand is:

• The source host runs the client, mstsc.exe.
• After successful connection, the destination host runs Remote Desktop Services (TermService, hosted inside svchost.exe) and the session-support processes that start whenever a session is created, which are: rdpclip.exe (clipboard sharing) and tstheme.exe (theme rendering).

We can't recognize a malicious RDP session without first knowing what a normal one looks like. We'll start with what legitimate RDP looks like in a typical enterprise, then walk through why attackers reach for this technique and the real-world cases where they've used it.

Legitimate RDP Usage

A modern Windows enterprise has hundreds of legitimate RDP sessions per day, and most of them follow predictable patterns. Knowing the baseline is most of the work.

A legitimate RDP session looks the same every time the same person does it, with the same source workstation, the same destination, the same account, and the same time-of-day window. Every malicious session we'll investigate is going to deviate from this baseline in one or more specific ways.

Real-World Threat Actor Patterns

Below are real-world cases showing how threat actors abuse RDP in their operations.

RansomHub Password Spray and RDP Chaining (2025)

The DFIR Report's June 2025 RansomHub analysis (opens in new tab) documented operators password-spraying an internet-facing RDP server, then using RDP to chain through domain controllers, backup servers, and file servers before deploying ransomware roughly five days (about 118 hours) later.

The chaining pattern, where the same operator uses RDP to hop from each compromised host to the next, is a common pattern to see in modern ransomware operations. The operators never deploy a tool or use another known technique; they use built-in functionality to blend in with normal traffic, without revealing themselves, staying under the radar.

Volt Typhoon and BianLian

CISA AA24-038A on Volt Typhoon (opens in new tab) and CISA AA23-136A on BianLian (opens in new tab) both name RDP as a primary lateral movement method in their TTP profiles.

BianLian operators are also known to enable RDP on hosts where it was previously disabled (modifying RDP-related registry settings and adding firewall rules to allow inbound RDP) before pivoting.

We've covered why RDP is so useful for attackers and what makes a session suspicious in the first place. Now we need to understand the event-log artifacts this technique leaves behind, because that's where most of the investigation happens.

RDP is a built-in admin tool, so the presence of an RDP connection is never the finding by itself. What makes a session suspicious are the answers to the following questions:

• Whose account it was
• Which workstation it came from
• Whether the connection was expected
• What happened during the session

For this walkthrough we'll focus on a single source-to-destination RDP connection, so the artifact split between the two sides is easy to see. In the real world, you might find multi-hop RDP lateral movement, as you will in Task 6.

Now let's see what artifacts RDP leaves on the source and the destination hosts.

Make sure that you follow along with the VM open, so you can apply what you learn directly. You'll find the artifacts in D:\Walkthrough\, one folder per host (THM-MKT-WS, THM-SHR-SRV). There's also a Walkthrough shortcut on the Desktop that opens the same folder.

Source Host Artifacts

We'll start at the source side, the workstation where the operator initiated RDP from.

Sysmon Event ID 1 (mstsc.exe Process Creation)

When mstsc.exe runs on the source, Sysmon Event 1 captures the process creation with the full command line. This answers whose account it was (the User field on Sysmon Event 1) and confirms the RDP client launched on this workstation.

Sysmon Event ID 3 (Outbound TCP 3389)

Sysmon Event 3 records every outbound network connection. When mstsc.exe reaches out to the RDP server, the corresponding Event 3 shows mstsc.exe as the image, DestinationIp set to the RDP server, and DestinationPort=3389. The fact that this fires on the source is the source-side answer to which workstation it came from, and the DestinationIp tells us where the attempt landed.

This event fires on both the source and destination, showing both IPs and the port. The image is mstsc.exe, so we get the process that made the connection, not its parent.

TerminalServices-RDPClient Event IDs 1024/1025 (RDP Client Connection)

The TerminalServices-RDPClient Operational channel logs the client's view of each RDP connection:

• Event 1024 fires on attempt: "RDP ClientActiveX is trying to connect to the server (<server name>)"
• Event 1025 fires on success: "RDP ClientActiveX has connected to the server"

The <server name> field directly records the destination hostname mstsc.exe tried to reach, corroborating the source's view of where the operator was headed.

These come in handy when attackers attempt to clear logs as an anti-forensic technique and we want to trace RDP connections. Most of the time they would clear the main log sources such as Sysmon and Security logs, but not the TerminalServices-RDPClient channel.

Another benefit of this channel is that it's enabled by default, so these logs will exist without any extra configuration.

Destination Host Artifacts

Now let's move to the destination side, the host that accepted the RDP connection. Most of the evidence for RDP lateral movement exists on the destination.

Security Event ID 4624 (Type 10)

Event 4624 with LogonType 10 (RemoteInteractive) is a successful interactive RDP logon. The TargetUserName field answers whose account it was, IpAddress answers which workstation it came from, and comparing these against your normal baseline would be one way to determine whether the connection was expected.

It's important to mention that this isn't the only way to determine whether this session is malicious, but we can combine this with understanding further context about what happened during the session, which would give us a complete picture of this activity.

TS-RemoteConnectionManager Event ID 1149

TS-RemoteConnectionManager Event 1149 fires when the NLA handshake succeeds, recording the user and source network address. It confirms the network leg but not that a session was created, so it always pairs with the 4624 Type 10.

The fields to look at are the user and the source IP. The user corroborates whose account it was and the source IP corroborates which workstation it came from, the same two questions the 4624 Type 10 answers, now confirmed from a second channel.

TS-LocalSessionManager Event IDs 21, 22, 23, 24, 25

The TS-LocalSessionManager Operational channel records the session lifecycle on the destination:

• Event 21 is session logon succeeded
• Event 22 is shell start (the operator received an interactive desktop)
• Event 23 is logoff, session destroyed
• Event 24 is disconnect, session preserved on the server
• Event 25 is reconnect

These don't directly answer one of the four questions, but they confirm the session actually happened end-to-end (the operator got a shell, not just a network handshake) and bracket when the activity occurred.

Below is a diagram of events 21, 22, 23, and 24 from Event Viewer, showing the RDP lifecycle.

Event ID Reference

Below is a summary of source and destination artifacts in event logs that we've discussed in this task:

Use the events above to answer the following.

Same as the last task, let's follow along on the analyst VM. The triage is in D:\Walkthrough\, and the required tools are in the DFIR Tools folder under C:\Users\DFIRUser\.

Source Artifacts

Let's take a look at the source-side artifacts.

Registry MRU

Under Software\Microsoft\Terminal Server Client\Default in the user's NTUSER.DAT, MRU0 through MRU9 hold the recently RDP'd-to hosts (the "Recent" list inside mstsc.exe), MRU0 being the most recent. This is the source-side answer to which workstation the user RDP'd to, preserved on disk even after event logs are cleared.

UsernameHint

Each host the user connected to gets a Software\Microsoft\Terminal Server Client\Servers\<host>\ key, and its UsernameHint value is the username mstsc.exe saved for that host. This is the source-side answer to whose account was used against which target, a per-host record. If the saved username doesn't match the workstation's logged-in user, that's a stolen-credential tell, which also feeds into whether the connection was expected.

Bitmap Cache

The bitmap cache is a unique RDP artifact. It shows what the operator saw on the remote desktop during their session, the source-side answer to what happened during the session. To save bandwidth, the RDP client caches small tiles (typically 64x64 pixels) of the remote screen on the local machine, and those tiles stay on disk on the source host.

The cache exists at C:\Users\<user>\AppData\Local\Microsoft\Terminal Server Client\Cache\ (modern Windows uses Cache0000.bin, Cache0001.bin, etc.). Browsing the recovered tiles can reveal literal commands, file browsers, or open documents the operator had on screen during the session.

We can extract the tiles with bmc-tools (opens in new tab) (you'll find it in the DFIR Tools folder) using a command like the following one (make sure that the output directory, where the BMP tiles will be dropped, exists):

C:\Users\DFIRUser> mkdir "C:\Users\DFIRUser\Desktop\bmc-output"
C:\Users\DFIRUser> python "C:\Users\DFIRUser\DFIR Tools\bmc-tools\bmc-tools.py" -s "D:\Walkthrough\THM-MKT-WS\uploads\auto\C%3A\Users\<username>\AppData\Local\Microsoft\Terminal Server Client\Cache" -d "C:\Users\DFIRUser\Desktop\bmc-output"
[+++] Processing a directory...
[!!!] File '...\Terminal Server Client\Cache\bcache24.bmc' is zero bytes, skipping file.
[+++] Processing a file: '...\Terminal Server Client\Cache\Cache0000.bin'.
[===] <REDACTED> tiles successfully extracted in the end.
[===] Successfully exported <REDACTED> files.

This command writes one BMP per tile, often hundreds of them.

As seen in the output folder, the thumbnails have fragments that, if combined, can give us important context about the session and what happened in it.

For deeper analysis, we can use RdpCacheStitcher (opens in new tab), which stitches tiles into coherent screen reconstructions. All you need to do is select the output folder where the extracted BMP tiles are, and it'll give you the output that's shown in the screenshot below.

This can help us actually view what happened during the session in one image.

Prefetch

On the source, MSTSC.EXE-<hash>.pf in C:\Windows\Prefetch confirms the RDP client launched and gives a run count and the last few launch times. This is the source-side execution proof that ties back to which workstation it came from. We can parse Prefetch using a tool like Eric Zimmerman's PECmd using the following command:

C:\Users\DFIRUser\DFIR Tools\EZ Tools> .\PECmd.exe -d "D:\Walkthrough\THM-MKT-WS\uploads\auto\C%3A\Windows\Prefetch" --csv "C:\Users\DFIRUser\Desktop" --csvf THM-MKT-WS-prefetch.csv

As Prefetch is not enabled by default on Windows servers, we might need to rely on other evidence like Sysmon Event 1 for that execution evidence instead.

Generic Execution Artifacts (Corroborating Evidence)

Other artifacts can be valuable too: AmCache, ShimCache/AppCompatCache, UserAssist (in NTUSER.DAT), and Jump Lists each corroborate that mstsc.exe was executed on the workstation. They aren't RDP-specific, but they can be useful when other artifacts don't exist.

Destination Artifacts

Now let's pivot to the destination host artifacts, of which there are fewer.

Execution Evidence: rdpclip.exe and tstheme.exe

If we're trying to prove whether RDP was used on a host, we need to check for the processes that only run when an RDP session is created (as we mentioned in earlier tasks), which are rdpclip.exe (clipboard sharing) and tstheme.exe (theme rendering).

Finding them in execution artifacts on a host that's not supposed to receive RDP is itself evidence that an RDP session was accepted there, the destination-side anchor that the connection actually landed on this host. The evidence exists in:

• ShimCache/AppCompatCache entries found in the SYSTEM hive can show the presence of binaries such as rdpclip.exe and tstheme.exe, which may be useful as indicators of RDP activity. However, for those entries to appear correctly in the registry hive on disk, the system typically needs to go through a graceful shutdown or reboot, because ShimCache updates are generally committed from memory to the SYSTEM hive at shutdown time.
• Prefetch (C:\Windows\Prefetch\RDPCLIP.EXE-*.pf, TSTHEME.EXE-*.pf): This shows the execution timestamps and run counts as we've seen on the source side. It might not be reliable on servers though, as their SKUs have Prefetch disabled by default.

Use the artifacts above to answer the following questions.

We've completed our review of how attackers execute RDP lateral movement and how to detect it through event logs and forensic artifacts. Now we've prepared a hands-on practical exercise.

Scenario

Now that we've reconstructed an intrusion in the walkthrough and another in the challenge, we'll turn to the prevention layer that makes the next intrusion harder. Prevention for RDP lateral movement is hard because blanket blocking would break IT administration workflows nobody wants to give up, but there's a real list of things we can do, and the ordering matters.

Audit Policy Configuration

The highest-impact change is enabling the audit policies that produce the events we need. By default, several of them are off.

Configure these via GPO and not via auditpol at the host level, because Group Policy refresh will silently override any local auditpol /set changes. After any audit change, create a test RDP session and confirm the expected events actually fire before trusting the configuration.

The TerminalServices Operational Channel

The TS-LocalSessionManager and TS-RemoteConnectionManager Operational channels are on by default since Windows 7/Server 2008 R2. The TerminalServices-RDPClient Operational channel (the source-side workstation log) is also on by default, but it's the one most often disabled in production hardening profiles.

A disabled RDPClient channel means losing the source-side trail entirely when a destination's logs are cleared. Verify with:

C:\Users\DFIRUser> wevtutil gl Microsoft-Windows-TerminalServices-RDPClient/Operational

Then enable with:

C:\Users\DFIRUser> wevtutil sl Microsoft-Windows-TerminalServices-RDPClient/Operational /e:true

For persistence across feature updates, deploy the enablement via GPO or an endpoint management tool.

Log Forwarding and Retention

• Forward all three TS Operational channels to the SIEM (LSM + RCM + RDPClient), not just the Security log. The TS channels are the first-stop evidence source for this technique, and most SIEM deployments miss them.
• Forward source-side workstation logs, not just servers. Operators land on workstations first.
• The TS Operational channels rotate quickly by default. Increase size or forward aggressively.

Network Controls That Can Actually Be Deployed

• Deploy a Remote Desktop Gateway (RDG) as the only path for cross-subnet RDP, with MFA enforced at the gateway.
• Use Just-in-Time admin access (Microsoft PAM, Azure PIM, third-party PAM solutions) so admin RDP rights are time-bounded, not standing.
• Restrict TCP 3389 between user workstation VLANs and server VLANs at the network layer. A compromised endpoint on the user network shouldn't be able to RDP directly to a server.
• Block RDP from the internet entirely; never expose 3389 directly.
• Enforce NLA on every Windows host (Require user authentication for remote connections by using Network Level Authentication GPO setting) to disable non-NLA RDP and reduce brute-force exposure.

Privileged Account Hygiene

The two patterns that make RDP lateral movement harder are tiered administration and per-host random local admin passwords:

• Tiered Administration: Tier-0 (DC admins) cannot interactively log on to user workstations or servers; Tier-1 (server admins) cannot log on to workstations; Tier-2 (workstation admins) cannot log on to servers. This stops cross-tier credential reuse via RDP.
• LAPS (Local Administrator Password Solution): Randomized per-host local admin passwords mean a compromise on one workstation doesn't unlock every workstation.
• Restrict Remote Desktop Users group membership: Remove Domain Users from the default Remote Desktop Users group on every server.
• Session timeout policies: Auto-logoff disconnected sessions after a short window (e.g., 30 minutes). Disconnected sessions hold cached privileged credentials in memory on the server, which makes them a long-lived foothold for any operator with later access to the box.
• Remote Credential Guard: Prevents RDP from transmitting credentials to the remote host. Instead, it redirects Kerberos authentication requests back to the client. Even if the destination is compromised, the operator can't harvest RDP session credentials from LSASS. Configure on the remote host via GPO Computer Configuration > Administrative Templates > System > Credentials Delegation > Remote host allows delegation of nonexportable credentials, and on the client side via Restrict delegation of credentials to remote servers set to "Require Remote Credential Guard." Requires Kerberos, so it works only for domain-joined machines that can reach a DC.

Detection Rules Worth Deploying

MITRE Mitigation Mapping

For analysts mapping these controls into a defensive architecture, the table below ties each mitigation to its MITRE ATT&CK Mitigation ID and the specific RDP attack vector it neutralizes.

That's it for the RDP lateral movement technique, from explaining the protocol itself through the source-side and destination-side event-log artifacts, the on-disk forensic artifacts, and the multi-hop RDP chaining pattern that attackers use in real-world attacks.

Takeaways

• RDP is a built-in administration tool, so the presence of a session is never the finding by itself. What makes one suspicious is the context around it: whose account it used, which workstation it came from, whether it was expected, and what happened during the session.
• A legitimate RDP session looks the same every time the same person makes it, so malicious sessions stand out by deviating from that baseline. The same account showing up from a workstation it never normally uses is the most common deviation and the starting point for most RDP hunts.
• No single event confirms a malicious RDP session on its own. Correlating the connection and logon events on the destination with the session-lifecycle events is what gives us context and proves an operator reached an interactive desktop, not just a network handshake.
• When the destination logs are cleared, the source side is what saves the investigation, which is why an RDP investigation should never stop at the destination. Source-side event logs, the Terminal Server Client registry keys, and the bitmap cache survive clearing and can still show where the user connected, as whom, and what they had on screen.
• No single control stops RDP abuse without breaking the IT workflows that rely on it, but enabling the right auditing and layering controls like tiered administration, LAPS, and Just-in-Time admin access together make RDP lateral movement significantly harder to pull off and easier to spot.