RDP Event Logs

When an attacker moves laterally across a Windows network, Remote Desktop Protocol is the tool of choice in the vast majority of intrusions. Windows records every RDP session across multiple independent event log channels — from the initial authentication in Security.evtx to the session lifecycle in TerminalServices logs. Cross-correlating these channels reconstructs the complete lateral movement path, including source IPs, usernames, session durations, and disconnection patterns.

What Are RDP Event Logs?

Remote Desktop Protocol (RDP) event logs are a collection of Windows Event Log channels that collectively record every phase of a remote desktop session. Unlike a single monolithic log, RDP telemetry is distributed across at least four distinct EVTX files, each capturing a different aspect of the connection lifecycle. The TerminalServices-LocalSessionManager/Operational log records session creation, reconnection, and disconnection on the destination host. The TerminalServices-RDPClient/Operational log records outbound connection attempts on the source host, including the target hostname. The Security.evtx log records the authentication event (Event ID 4624, Logon Type 10) with the source IP address. The TerminalServices-RemoteConnectionManager/Operational log records the initial connection attempt before authentication completes.

This distribution means that a single RDP session produces evidence on both the source and destination machines. An investigator who collects logs from only one endpoint will recover a partial picture. Collecting from both endpoints — and cross-correlating timestamps — produces a complete timeline showing who connected from where, when the session started, how long it lasted, and whether the session was cleanly closed or abnormally terminated.

RDP has been the dominant lateral movement technique in enterprise intrusions since at least 2015. It is used by ransomware operators (Conti, LockBit, BlackSuit), nation-state actors (APT29, APT41), and insider threats. The protocol is enabled by default on Windows Server and is frequently enabled on workstations for IT administration. Because RDP uses legitimate Windows authentication, it blends with normal administrative traffic — making log analysis the primary detection and forensic reconstruction method.

Location & Format

Event Log File Paths

Log Format

All Windows Event Logs use the EVTX (Event Log XML) binary format introduced in Windows Vista. Each event is stored as a binary XML record with a standard header containing the event ID, timestamp (UTC, 100-nanosecond precision), provider name, and channel. The event-specific data is stored in structured XML fields that vary by provider. EVTX files have a configurable maximum size (default: 1 MB for operational logs, 20 MB for Security.evtx) and use a circular buffer — when the file reaches capacity, the oldest events are overwritten.

Key Event IDs

Destination Host — TerminalServices-LocalSessionManager/Operational

Destination Host — TerminalServices-RemoteConnectionManager/Operational

Source Host — TerminalServices-RDPClient/Operational

Destination Host — Security.evtx

What It Reveals

Cross-correlating RDP event logs across all four channels answers the following investigative questions:

• Which user accounts were used for lateral movement? — Event 4624 (Type 10) records the TargetUserName and TargetDomainName on every destination host, building a map of which credentials were used at each hop.
• What was the source IP of each RDP connection? — The IpAddress field in Security.evtx 4624 and the Source Network Address in LocalSessionManager Event 21 both record the connecting host’s IP. Discrepancies between these two fields may indicate NAT or proxy traversal.
• What was the complete lateral movement path? — By collecting RDPClient/Operational (Event 1024) from each compromised host, the investigator can chain outbound connections: Host A connected to Host B, Host B connected to Host C, Host C connected to the domain controller.
• How long did each session last? — Subtracting the 4624 timestamp from the 4634/4647 timestamp gives the total session duration. For disconnected sessions, Event 24 provides the disconnect time.
• Were there failed authentication attempts before success? — Event 4625 (Type 10) records failed RDP logon attempts. A cluster of 4625 events followed by a 4624 indicates credential guessing. The Status and SubStatus fields distinguish between wrong password (0xC000006A), nonexistent account (0xC0000064), and account locked out (0xC0000234).
• Did the attacker reconnect to existing sessions? — Event 25 (LocalSessionManager) and Event 4778 (Security) record session reconnections. A reconnection from a different source IP than the original logon may indicate session hijacking or attacker infrastructure rotation.
• Was RDP used during off-hours? — Timestamp analysis of 4624 Type 10 events against the organization’s working hours identifies anomalous access patterns. An RDP session from an external IP at 03:00 local time on a Saturday warrants investigation.
• Which systems were targeted but not compromised? — Event 1024 on the source host records attempted connections. If a 1024 event has no corresponding 4624 on the target, the connection was attempted but authentication failed or the target was unreachable.

Forensic Use Cases

1. Ransomware Lateral Movement Reconstruction

A ransomware operator compromises an external-facing RDP server via brute force (Event 4625 x 3,400 followed by Event 4624 Type 10). From the initial foothold, they use the same compromised credentials to RDP into internal hosts. Event 1024 on the initial server records connections to 14 internal systems. Event 4624 Type 10 on each internal host confirms successful authentication. Event 4634 timestamps show sessions lasting 3–15 minutes each — consistent with manual reconnaissance. The final hop to the domain controller shows a 2-hour session during which Group Policy was modified to deploy ransomware. The complete chain is reconstructed from event logs alone, even after the attacker wiped their tools.

2. Insider Threat Session Analysis

An employee under investigation for data theft RDPs from their home IP to their office workstation at 23:47 on a Saturday. Security.evtx Event 4624 Type 10 records the home IP address. LocalSessionManager Event 21 confirms the session start. The session remains active for 4 hours and 12 minutes (calculated from Event 21 to Event 24). During this window, file access logs (Event 4663) on the file server show 2,300 files opened from the same user account. Event 4779 records the final disconnection at 03:59. The RDP timestamps bracket the entire data access window.

3. Credential Sharing Detection

Security Event 4624 Type 10 shows the same service account authenticating via RDP from three different source IPs within a 20-minute window. LocalSessionManager Event 39 records that each new session disconnected the previous one. This pattern proves that multiple individuals are sharing a single credential — a policy violation and a security risk. The three source IPs resolve to workstations assigned to three different employees, identifying all participants.

4. External Brute-Force Attack Analysis

Security.evtx contains 47,000 Event 4625 (Type 10) entries from 230 unique source IPs over 72 hours, all targeting the local Administrator account. The SubStatus field shows 0xC000006A (wrong password) for all attempts. On the third day, a single 4624 Type 10 succeeds from a new IP not seen in the brute-force cluster — the attacker rotated infrastructure after obtaining the correct password through credential stuffing from a separate breach dataset. The 4624 timestamp establishes the exact moment of initial access.

5. Session Hijacking via Disconnected Sessions

An administrator RDPs to a server and disconnects (Event 24) rather than logging off. The session remains active on the server. Two hours later, Event 25 records a reconnection from a completely different source IP. Security.evtx Event 4778 confirms the reconnection with the new client address. This pattern indicates session hijacking — an attacker with local administrator access on the server used tscon.exe to attach to the disconnected session without needing the original user’s credentials.

Acquisition Methods

Live System — wevtutil Export

:: Export all four RDP-related logs from the destination host
wevtutil epl Microsoft-Windows-TerminalServices-LocalSessionManager/Operational C:\Evidence\TSLocalSM.evtx
wevtutil epl Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational C:\Evidence\TSRemoteCM.evtx
wevtutil epl Security C:\Evidence\Security.evtx
wevtutil epl System C:\Evidence\System.evtx

:: Export the RDPClient log from the source host
wevtutil epl Microsoft-Windows-TerminalServices-RDPClient/Operational C:\Evidence\TSRDPClient.evtx

Live System — PowerShell Targeted Export

# Export only RDP-relevant events from Security log (faster than full export)
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4624,4625,4634,4647,4778,4779} |
    Where-Object { $_.Properties[8].Value -eq 10 -or $_.Id -in @(4778,4779) } |
    Export-Csv C:\Evidence\RDP_Security_Events.csv -NoTypeInformation

# Export LocalSessionManager events
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational';ID=21,22,23,24,25,39,40} |
    Export-Csv C:\Evidence\RDP_LocalSM_Events.csv -NoTypeInformation

KAPE Collection

:: KAPE target for event logs collects all relevant channels
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target EventLogs

:: For targeted RDP analysis, also collect from source hosts:
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Source --target EventLogs,RemoteDesktopCache

Parsing Tools & Analysis

Parsing with EvtxECmd

:: Parse all EVTX files in the evidence directory
EvtxECmd.exe -d C:\Evidence\ --csv C:\Analysis\RDP_Events --csvf RDP_Timeline.csv

:: Parse only the LocalSessionManager log
EvtxECmd.exe -f C:\Evidence\TSLocalSM.evtx --csv C:\Analysis\ --csvf TSLocalSM_Parsed.csv

Analysis Script — RDP Session Reconstruction

# Reconstruct RDP sessions from Security.evtx parsed output
import pandas as pd

df = pd.read_csv('/analysis/rdp/Security_Parsed.csv')

# Filter for RDP logon events (Type 10 = RemoteInteractive)
logons = df[(df['EventId'] == 4624) & (df['LogonType'] == 10)].copy()
logoffs = df[df['EventId'].isin([4634, 4647])].copy()

# Match logon to logoff by TargetLogonId
sessions = logons.merge(
    logoffs[['TargetLogonId', 'TimeCreated']],
    on='TargetLogonId', suffixes=('_start', '_end'), how='left'
)

# Calculate session duration
sessions['Duration'] = pd.to_datetime(sessions['TimeCreated_end']) - pd.to_datetime(sessions['TimeCreated_start'])

# Display sessions sorted by start time
print(sessions[['TimeCreated_start', 'TargetUserName', 'IpAddress',
               'Duration', 'TargetLogonId']].sort_values('TimeCreated_start').to_string())

Sample Output — Lateral Movement Timeline

TimeCreated_start        TargetUserName    IpAddress        Duration          TargetLogonId
2026-02-14 02:17:33      svc_backup        185.220.101.42   0 days 06:42:15   0x1A3F7C2
2026-02-14 02:31:08      svc_backup        10.10.5.20       0 days 00:08:44   0x1B22A01
2026-02-14 02:40:22      svc_backup        10.10.5.20       0 days 00:12:33   0x1C18F30
2026-02-14 02:53:41      administrator     10.10.5.22       0 days 00:03:17   0x1D09E44
2026-02-14 02:57:19      administrator     10.10.5.22       0 days 02:14:08   0x1E42B10

Session Duration Reconstruction

Calculating RDP session duration requires correlating events across multiple logs because no single event records both start and end times. The most reliable method uses the TargetLogonId field, which is a unique identifier assigned to each logon session and recorded in both the 4624 (logon) and 4634/4647 (logoff) events.

Anti-Forensics Resilience

Event logs are a common target for attackers who want to cover their tracks. Understanding which cleanup methods affect RDP evidence — and which do not — is essential for assessing evidence integrity.

MITRE ATT&CK Detection Mapping

RDP event log analysis provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & References

Corroborating Artifacts

References

1. 13Cubed, “RDP Event Log Analysis for DFIR” — https://www.13cubed.com
2. SANS Institute, “Tracking Lateral Movement with RDP Event Logs” — https://www.sans.org/blog/
3. Eric Zimmerman, “EvtxECmd — EVTX Parser” — https://ericzimmerman.github.io/
4. Yamato Security, “Hayabusa — Windows Event Log Analyzer” — https://github.com/Yamato-Security/hayabusa
5. WithSecure, “Chainsaw — Rapid Event Log Triage” — https://github.com/WithSecureLabs/chainsaw
6. Microsoft, “Remote Desktop Services Event Logs” — https://learn.microsoft.com
7. JPCERT/CC, “Detecting Lateral Movement through Tracking Event Logs” — https://www.jpcert.or.jp/english/
8. MITRE ATT&CK, “T1021.001 — Remote Desktop Protocol” — https://attack.mitre.org/techniques/T1021/001/