> For the complete documentation index, see [llms.txt](https://walterdrake.gitbook.io/mysite/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://walterdrake.gitbook.io/mysite/rdp-lateral-movement-detection/rdp-lateral-movement-detection.md).

# RDP Lateral Movement Detection

## How RDP Works

RDP creates a real-time, interactive graphical desktop session via four main stages:

1. Connection Initiation: Client connects to the target server over TCP port 3389 (the default RDP listener port).
2. Security Negotiation: The endpoint pair negotiates encryption protocols and exchanges digital certificates to establish a secure channel.
3. Authentication: The client presents valid user credentials for identity verification on the target host.
4. Session Establishment: The server renders and streams GUI graphical data to the client while processing client keyboard and mouse inputs in real time.

Security Context: This architecture grants full interactive GUI control over the target machine, making it a prime vector for administrative tasks as well as attacker lateral movement.

## Event Logs

### Terminal Services Remote Connection

* On the **target system** at:

  `Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational`
* Forensic Utility: Captures incoming RDP connection attempts regardless of outcome (successful, failed, or reconnected), making it a crucial source for detecting connection attempts.
* Event ID **1149** (RDP Connection Attempt):
  * Logged whenever an RDP connection request reaches the host.
  * Critical Distinction: Indicates a connection attempt, *not* definitive proof of a successful interactive session.
  * NLA Nuance: The log text *"User authentication succeeded"* indicates Network Level Authentication (NLA) passed, not that the full desktop session logon completed.

### Successful Session Logon

* Windows Security Log: Event ID **4624**.
  * Key metadata includes **UTC Timestamp, User Account, Target Domain/Host, Source IP Address, Source Workstation Name, and Logon Type**.
* Key Windows Logon Types for RDP Analysis:
  * Logon Type 10 (RemoteInteractive): Recorded when a user initiates a new remote desktop session via RDP/Terminal Services and the target user is not currently logged in.
  * Logon Type 7 (Unlock): Recorded when connecting via RDP to a target machine where the specified user account is already logged in or locked, re-attaching/unlocking that active session.
  * Logon Type 3 (Network): Always generated just before a Type 7 or Type 10 event during network authentication.
  * Other Types Reference: Type 2 (Interactive/Physical local logon), Type 4 (Batch/Scheduled Tasks), Type 5 (Service Account background execution).
* Two-Stage RDP Logon Processing: Windows processes incoming RDP connections in two distinct stages:
  1. Network-Level Stage (Logon Type 3): The target system first authenticates the incoming connection over the network (e.g., via NLA/Kerberos/NTLM).
  2. Session Stage (Logon Type 10 or 7): Once authenticated over the network, the local target operating system takes over to initialize or unlock the user's interactive desktop environment as a local remote logon.

{% hint style="info" %}
This dual-stage processing is why every RDP interactive logon event (Type 10 or Type 7) is preceded by a network authentication event (Type 3), which provides crucial source IP and host attribution.
{% endhint %}

* Lateral Movement Tracing Rule:
  * New RDP session → Type 3 (Network) followed by Type 10 (RemoteInteractive).
  * Reconnecting to locked session → Type 3 (Network) followed by Type 7 (Unlock).
  * Forensic Utility: The accompanying Logon Type 3 event explicitly captures the Source Workstation Name and Source IP, allowing analysts to trace RDP lateral movement back to the initiating host.
* NLA Authentication Flow (Rule of Thumb):
  * When Network Level Authentication (NLA) is active, incoming connections always perform network pre-authentication first (Logon Type 3).
  * This is immediately followed by Logon Type 10 for new interactive sessions, or Logon Type 7 when reconnecting to an existing locked session.

#### LocalSessionManager

* On the target system at:

  `Microsoft-Windows-TerminalServices-LocalSessionManager/Operational`
* Session Identifier vs. Logon ID:
  * Session ID: Used by TerminalServices logs to uniquely identify an interactive user session.
  * Logon ID: Used by Windows Security logs (e.g., Event ID 4624).
* Key Event IDs:
  * Event ID **21** (*Session logon succeeded*): Confirms that the target system successfully authenticated and established the remote desktop session.
  * Event ID **22** (*Shell start notification received*): Confirms that the desktop GUI environment (e.g., `explorer.exe`) initialized for the remote user, verifying a fully interactive logon.

### Session Reconnect

* **Disconnect** vs. **Sign-Out** Mechanics: Closing the RDP client without explicitly signing out leaves the target session active in a locked background state rather than terminating it.
* Reconnection behavior:
  * Re-establishing a connection to an existing, locked session does not trigger a full new logon.
  * Logon Type 10 is NOT logged. Instead, Logon Type 7 (Unlock) is recorded, preceded as usual by Logon Type 3 (Network).
* Threat Hunting Signatures:
  * Adversaries often retain persistent access by reconnecting to existing compromised sessions rather than launching fresh sessions.
  * Key Indicator: A sequence of repeated Logon Type 7 events (rather than Type 10) on a target host signals continuous session reconnection activity.

#### LocalSessionManager

* Event ID **25** (*Session reconnection succeeded*): Recorded when an existing interactive RDP session (previously left in a locked/disconnected state) is successfully re-established. Correlates directly with Security Event ID 4624 (Logon Type 7).
* Event ID **40** (*Session disconnected*): Logged when an RDP session is severed or closed without a full account logoff (e.g., closing the `mstsc.exe` window), leaving the session active in the background.

### Session Disconnect

* Session Disconnect State: Ending an RDP connection without explicitly signing out leaves the user session suspended in memory in a locked state, preserving running processes and enabling fast reconnection (a pattern frequently exploited by attackers for persistence).

#### LocalSessionManager

* Event ID **24** (*Session disconnected*): Standard notification that an active session was disconnected without a full sign-out.
* Event ID **39** (*Session disconnected by another session*): Logged when an incoming session forcibly displaces an active session (e.g., an attacker taking over an active single-user session).
* Event ID **40** (*Session disconnected with reason code*): Provides detailed failure/disconnect reason codes (e.g., manual closure, network drop, idle timeout).

### RDP Session LogOff

* Session Termination Mechanics: Unlike a disconnect, an explicit sign-out destroys the interactive session and flushes the user context from memory.
* Target-Side Logoff Event Sequence:
  * LocalSessionManager Event ID **23** (*Session logoff succeeded*): Confirms the RDP session has been cleanly terminated.
  * Security Event ID **4647** (*User initiated logoff*): Logged on the target host when the user manually initiates sign-out (e.g., clicking *Start → Power → Sign Out*).
  * Security Event ID **4634** (*An account was logged off*): Fired by the Security subsystem confirming the logon session (`LUID`) has officially ended.

## Process Execution

### Source Computer

* Initiating an RDP session executes `mstsc.exe` (Microsoft Remote Desktop Client) on the source system to connect to a remote host or Remote Desktop Session Host (RDSH) server.
* RDP clients are typically launched via the GUI, artifact analysis relies on GUI-execution evidence (UserAssist, RecentApps) along with general execution logs (Prefetch, BAM).

Example:

* **UserAssist**: Located in the user's `NTUSER.DAT` hive under `Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist`.
  * Logs the program name (e.g., `Microsoft.Windows.RemoteDesktop`) rather than the raw `mstsc.exe` path.
  * Tracks Run Counter (execution count), Focus Time (GUI active duration), and Last Executed timestamp.
* **BAM** (Background Activity Moderator): Located in the `SYSTEM` hive under `SYSTEM\bam\State\UserSettings\<USER-SID>`.
  * Displays `mstsc.exe` along with a timestamp that correlates with the **UserAssist** data, validating client-side execution.

### Target System

* RDP connections spawn automated background processes rather than direct user-launched binaries:
  * `rdpclip.exe`: Manages clipboard sharing and file transfer redirection.
  * `tstheme.exe`: Handles RDP visual theme rendering.
* These are system-spawned background processes rather than GUI interactions, GUI artifacts (UserAssist, RecentDocs) will contain no evidence.
* System Execution Evidence:
  * **Prefetch**: The primary source for target-side process execution timestamps (which must align with the source machine's `mstsc.exe` execution time).
  * Fallback Artifacts: Windows Server OS often disables Prefetch by default. In these environments, rely on Shimcache or Amcache to confirm execution.

## Registry

* **MRU**: Stored on the **source system** within `NTUSER.DAT` at: `NTUSER\Software\Microsoft\Terminal Server Client\Servers`
* User Attribution & Scope:
  * It resides in `NTUSER.DAT`, it ties RDP activity directly to a specific user account.
  * Client Dependency: Populated only when using the native Windows Remote Desktop Client (`mstsc.exe` / RDC). Third-party RDP clients will not populate this key.
* **MRU** Keys & Order:
  * Entries are indexed chronologically using MRU# keys (e.g., `MRU0`, `MRU1`).
  * `MRU0` always represents the most recent connection; higher numbers indicate older sessions.
  * Each entry records the target system's IP address or hostname.
* Root Key Metadata: Reviewing the `Terminal Server Client` parent key provides aggregate context, including the target IP/hostname, the targeted user account, and the registry key's Last Write Timestamp.

## Bitmap Cache

* Mechanism & Purpose: To optimize network performance and reduce bandwidth during RDP sessions, RDP divides screen graphics into pixel "tiles" and caches frequently used visual elements locally on the client.
* Located on the source system at:

  `C:\Users\[Username]\AppData\Local\Microsoft\Terminal Server Client\Cache\`
* Cache Files (`.bmc` / `.bin`):
  * Files are stored with numerical suffixes (e.g., `bcache24.bmc`, `cache0000.bin`, or index suffixes like `00`, `01`, `02`).
  * Higher numerical suffixes generally correspond to more recent RDP session data.
* Forensic Value: Reconstructing these tiles allows investigators to visually recover what was displayed on the remote target screen during the attacker's session (e.g., open applications, documents, or terminal commands).

{% hint style="success" %}
This knowledge has been compiled from resources provided by [LetsDefend](https://letsdefend.io/).
{% endhint %}