Overview

Remote Desktop Protocol (RDP) lateral movement occurs when an adversary uses valid credentials to interactively log into a remote Windows system via port 3389, gaining a full graphical desktop session as the compromised user. This gives attackers hands-on-keyboard access to the target system — they can browse files, execute tools, harvest additional credentials, and pivot further into the network, all while blending in with legitimate administrative traffic.

RDP is one of the most commonly abused lateral movement techniques observed in ransomware deployments, hands-on-keyboard intrusions, and nation-state operations. Because RDP is a native Windows feature used daily by IT staff, malicious sessions are easy to hide in normal operational noise — making deliberate detection engineering essential for every security team.

Attacker Perspective

After obtaining credentials through phishing, credential dumping, or brute force, attackers leverage RDP to move interactively between systems as though they were a legitimate administrator.

• Manual lateral movement with mstsc.exe: Attackers launch mstsc.exe /v:192.168.1.50 from a compromised workstation to hop to a domain controller or file server, often using Pass-the-Hash or stolen plaintext credentials.
• Automated spreading with Impacket or CrackMapExec: Tools like crackmapexec rdp 192.168.1.0/24 -u administrator -p Password123 allow rapid scanning and authentication testing across entire subnets to identify accessible RDP targets.
• RDP hijacking of existing sessions: Using tscon.exe [session_id] /dest:[target_session], attackers take over disconnected but authenticated RDP sessions without needing the original user’s password — a technique that requires no credential re-entry and leaves minimal traces.
• Persistence via Accessibility Feature backdoors: Attackers replace sethc.exe or utilman.exe with cmd.exe on the RDP login screen, enabling SYSTEM-level command execution before authentication by pressing Shift five times or clicking the accessibility icon.

RDP is attractive to attackers precisely because it is a trusted, built-in Windows feature — it requires no custom tooling to exploit, sessions look identical to legitimate admin activity, and interactive access dramatically accelerates the pace of a breach.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Logon Events: Enable Audit Logon (Success and Failure) via GPO: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Logon/Logoff → Audit Logon. This generates Event ID 4624 (successful logon) and Event ID 4625 (failed logon). For RDP, look for LogonType = 10 (RemoteInteractive) in 4624.
• Windows Security Event Log — Logoff Events: Enable Audit Logon (same policy as above). Generates Event ID 4634 and Event ID 4647 (user-initiated logoff). These help you calculate session durations and identify unusually short or off-hours sessions.
• Windows Security Event Log — Special Logon: Enable Audit Special Logon via GPO: Logon/Logoff → Audit Special Logon. Generates Event ID 4672 when a privileged account logs on. Correlating this with a LogonType 10 event on the same host within seconds identifies privileged RDP sessions.
• Windows Security Event Log — Account Logon (Kerberos/NTLM): Enable Audit Credential Validation and Audit Kerberos Authentication Service via GPO: Account Logon → Audit Credential Validation. Generates Event ID 4776 (NTLM credential validation) and Event ID 4768/4769 (Kerberos TGT/service ticket requests). These fire on the authenticating domain controller and help you trace the originating account.
• Windows System Event Log — Remote Desktop Services: No additional GPO required — these are logged by default. Event ID 21 (session logon), Event ID 22 (shell start), Event ID 24 (session disconnect), and Event ID 25 (session reconnect) are written to Microsoft-Windows-TerminalServices-LocalSessionManager/Operational. These provide the most direct evidence of RDP session activity.
• Windows Security Event Log — Object Access (RDP-specific): Event ID 4778 (session reconnected) and Event ID 4779 (session disconnected) in the Security log provide the client IP address, client hostname, and session name — critical for attribution.
• Network/Firewall Logs: Ensure your perimeter and internal firewalls log all TCP connections to port 3389. If you have east-west visibility via an NDR tool (Zeek, Darktrace, ExtraHop), enable RDP protocol parsing to capture handshake metadata, negotiation flags, and client hostnames from the RDP cookie in the initial connection packet.
• Windows Sysmon (Event ID 1, 3, 7): Deploy Sysmon with a configuration that captures Event ID 1 (process creation) for mstsc.exe launches, Event ID 3 (network connection) for outbound connections to port 3389, and Event ID 7 (image load) to detect DLL hijacking in Terminal Services. Install Sysmon via sysmon.exe -accepteula -i sysmonconfig.xml and deploy config via GPO startup script.
• Windows Security Event Log — Process Creation: Enable Audit Process Creation and command-line auditing: GPO at Computer Configuration → Administrative Templates → System → Audit Process Creation → Include command line in process creation events = Enabled. Generates Event ID 4688 with full command-line arguments. Required to detect tscon.exe abuse and post-RDP tool execution.

Key Indicators

• Successful RDP logon from unexpected source: In the Security log, Event ID 4624 where LogonType = 10 and IpAddress is a workstation, server, or external IP that does not normally initiate RDP sessions. Pay special attention when TargetUserName is a service account, built-in Administrator, or any account ending in $.
• RDP logon outside business hours: Event ID 4624 with LogonType = 10 where the event TimeCreated falls outside defined business hours (e.g., before 07:00 or after 20:00 local time, or on weekends). Correlate with the user’s normal login pattern baseline if your SIEM supports it.
• Privileged account RDP session: Event ID 4624 (LogonType = 10) followed within 5 seconds by Event ID 4672 on the same host for the same TargetLogonId. Indicates a privileged (admin, domain admin, backup operator) account opened an interactive RDP session.
• RDP from non-jump-host source: In TerminalServices-LocalSessionManager operational log, Event ID 21 where the Source Network Address does not belong to the approved jump server or VPN subnet. Legitimate RDP administration should originate from a known bastion host — anything else is suspicious.
• mstsc.exe launched from unexpected parent: Sysmon Event ID 1 where Image contains mstsc.exe and ParentImage is not explorer.exe or a known admin tool. Seeing mstsc.exe spawned by cmd.exe, powershell.exe, or a script interpreter is a strong indicator of scripted lateral movement.
• tscon.exe execution (session hijacking): Event ID 4688 or Sysmon Event ID 1 where CommandLine matches tscon.exe [0-9]+ /dest:. This is the canonical RDP session hijacking command and has virtually no legitimate use case outside of explicit TSAdmin workflows.
• Accessibility feature binary replacement: Sysmon Event ID 11 (file creation) or Event ID 7 where TargetFilename matches sethc.exe, utilman.exe, osk.exe, narrator.exe, or magnify.exe, and the writing process is not TrustedInstaller or a known patch management system. Also look for Event ID 4688 showing these binaries executing from the RDP login screen context (spawned by winlogon.exe).
• High volume of failed RDP logons (brute force): Multiple Event ID 4625 events with LogonType = 10 targeting the same or multiple TargetUserName values from a single IpAddress within a short window. Threshold: more than 10 failures in 5 minutes from a single source warrants investigation.
• Outbound RDP connection from server: Sysmon Event ID 3 where DestinationPort = 3389 and the source Image is mstsc.exe, originating from a host that is classified as a server (not a workstation or jump host). Servers initiating outbound RDP is rare and high-fidelity.

Detection Logic

Rule 1 — Broad: Any RDP Logon (LogonType 10) Baseline Sweep
IF EventID = 4624 AND LogonType = 10 AND TargetUserName NOT IN [known_service_accounts] AND IpAddress NOT IN [approved_jump_hosts] THEN alert(severity=LOW)

This broad rule captures every interactive RDP logon that does not originate from an approved jump host. Expected volume will be high in environments without strict RDP controls — use this rule to build a baseline and populate a dashboard before tuning it down. It is most valuable in the first 30 days of deployment to identify all RDP pathways in use.

Rule 2 — Medium: RDP Logon by Privileged Account
IF EventID = 4624 AND LogonType = 10 AND TargetUserName IN [domain_admins, local_admins, built_in_administrator] AND IpAddress NOT IN [approved_jump_hosts] THEN alert(severity=HIGH)

This rule fires when a privileged account authenticates over RDP from an unapproved source. Domain admin accounts should never be used for interactive RDP from workstations or uncontrolled servers. Expected volume should be very low (near zero) in well-managed environments — each alert deserves investigation.

Rule 3 — High Precision: RDP Session Hijacking via tscon.exe
IF (EventID = 4688 OR SysmonEventID = 1) AND (CommandLine CONTAINS "tscon.exe" AND CommandLine MATCHES "[0-9]+ /dest:") AND ParentImage NOT IN ["mmc.exe", "tsadmin.exe"] THEN alert(severity=CRITICAL)

This rule detects the specific command pattern used to hijack an existing RDP session. Legitimate use of tscon.exe is extremely rare and almost always scripted by an attacker. Expected volume is near zero — treat every alert as a confirmed attack until proven otherwise.

Rule 4 — High Precision: Accessibility Feature Backdoor on RDP Login Screen
IF (EventID = 4688 OR SysmonEventID = 1) AND Image IN ["sethc.exe", "utilman.exe", "osk.exe", "narrator.exe"] AND ParentImage = "winlogon.exe" AND CommandLine NOT CONTAINS "/winlogon" THEN alert(severity=CRITICAL)

This rule catches the moment an accessibility feature backdoor is triggered at the Windows login screen over RDP. The process will execute with SYSTEM privileges before any user authenticates. There are essentially no legitimate triggers for this pattern — treat as a confirmed incident immediately.

Tuning Guidance

• IT helpdesk and system administrator RDP: Admins legitimately RDP into servers and workstations daily. Create a named list of approved jump hosts or bastion servers and exclude their source IPs: IpAddress IN [jump_host_subnet]. Additionally, exclude known admin accounts that are expected to use RDP if they always connect from approved hosts: TargetUserName IN [approved_rdp_admins] AND IpAddress IN [jump_host_subnet].
• Vendor and contractor remote access: Third-party vendors may connect via RDP through a VPN or approved remote access solution. Document their source IP ranges and designated target systems, then add exclusions: IpAddress IN [vendor_vpn_range] AND TargetHostname IN [vendor_allowed_targets]. Flag any deviation from the approved source/target pair.
• Automated backup and monitoring agents: Some backup tools (e.g., Veeam, Commvault) use service accounts that trigger RDP-like logon events internally. Identify these accounts and exclude them from logon-based rules: TargetUserName IN [backup_service_accounts]. Verify that these accounts are restricted to the expected source IPs.
• Scheduled remote management scripts: Scripts that invoke mstsc.exe for automated session management will trigger Rule 1 and Sysmon-based mstsc rules. Identify the parent processes used by these scripts (e.g., schtasks.exe, a specific RMM tool) and exclude: ParentImage IN ["rmm_agent.exe", "scheduledtask_host.exe"] only after verifying the script’s purpose and scope.
• VDI and Citrix environments: Virtual desktop infrastructure generates a very high volume of LogonType 10 events as users connect to their virtual desktops. Identify your VDI broker server IPs and create a blanket exclusion for logons sourced from them: IpAddress IN [vdi_broker_ips]. Monitor the VDI brokers themselves separately with a stricter ruleset since they are high-value targets.

When the Alert Fires: Investigation Steps

1. Verify the alert is real — confirm the raw event exists in the source log. Query your SIEM for the exact Event ID 4624 with LogonType = 10 that triggered the alert, and confirm the event exists in the raw Windows Security log on the target host (use Event Viewer or a remote log query). Verify the IpAddress, TargetUserName, TargetDomainName, and LogonID fields are populated and make sense — malformed or empty fields can indicate log injection or parsing errors.
2. Identify the affected host and user — flag if privileged. Note the target hostname from the 4624 event and determine its role (domain controller, file server, workstation, jump host) by checking your asset inventory or CMDB. Look up TargetUserName in Active Directory to confirm whether the account belongs to a privileged group (Domain Admins, Enterprise Admins, Backup Operators) — if so, escalate severity immediately.
3. Determine the originating source and correlate with authentication logs. Extract the IpAddress from the 4624 event and identify the machine it belongs to using DHCP logs, DNS reverse lookup, or your CMDB. On the domain controller, query for Event ID 4776 or 4768/4769 matching the same TargetUserName and timestamp to confirm whether the credential was validated via NTLM or Kerberos — NTLM from a non-domain-joined host is a red flag.
4. Pull the full session timeline and any processes executed during the session. On the target host, query the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational log for Event IDs 21, 22, 24, 25 matching the session to determine when it started, whether it was disconnected/reconnected, and how long it lasted. Then use Sysmon Event ID 1 (process creation) filtered by the logon session ID or time window to enumerate every process the attacker ran during the session — look for cmd.exe, powershell.exe, credential dumping tools (mimikatz.exe, procdump.exe, lsass access), and reconnaissance commands.
5. Check for network connections and files written to disk during the session. Query Sysmon Event ID 3 (network connections) on the target host for the session time window, looking for outbound connections to new internal hosts (further lateral movement) or external IPs (C2 exfiltration). Also review Sysmon Event ID 11 (file creation) and Event ID 15 (file stream creation) for any executables, scripts, or archive files dropped in %TEMP%, C:\Users\Public, C:\Windows\Temp, or C:\PerfLogs.
6. Search for lateral movement originating from this host after the RDP session began. Using the target host’s IP as the new source, search your SIEM and firewall logs for outbound RDP connections (port 3389), SMB connections (port 445), WMI, WinRM (port 5985/5986), or PsExec patterns within 2 hours of the session start time. Look for Event ID 4624 on other hosts showing logons originating from this compromised system — map the full movement chain.
7. Search for persistence mechanisms and make the escalation decision. Query Sysmon Event ID 13 (registry value set) for changes to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and HKLM\SYSTEM\CurrentControlSet\Services during the session window, and check Windows Security Event ID 4698 for new scheduled task creation. If you find any of the following, treat it as a confirmed incident requiring full IR engagement: dropped executables on disk, new scheduled tasks or services, accessibility feature modifications, evidence of credential dumping (lsass access via Sysmon Event ID 10), or lateral movement to additional hosts — if none of these are present and the user confirms the session, it may be unauthorized but benign access.

Response Playbook

Containment

• Isolate the compromised host from the network while preserving it for forensics: Do not power it off — memory may contain decrypted credentials, active process information, or malware artifacts. If your EDR supports it (CrowdStrike Network Contain, Defender for Endpoint Isolate), trigger network isolation from the console. Alternatively, place the host in an isolated VLAN or apply an emergency firewall ACL blocking all traffic to/from the host except for your forensic collection IP.
• Disable the compromised user account immediately: In Active Directory Users and Computers or via PowerShell (Disable-ADAccount -Identity [username]), disable the account used in the malicious RDP session. If the account is a service account, coordinate with the application owner before disabling — but do not delay more than 30 minutes if active malicious activity is confirmed.
• Terminate all active RDP sessions for the compromised account: On the target host, run query session to list active sessions, then logoff [session_id] to terminate any active sessions. On the domain controller, check for additional active logons using Get-ADUser [username] -Properties * | Select-Object LastLogonDate and query other hosts for live sessions using your EDR or SIEM.
• Block the source IP of the malicious RDP connection: Add the originating IP address identified from the Event ID 4624 IpAddress field to your perimeter firewall and internal core switch ACLs. If the source is an internal host, isolate that host as well — it is likely a prior lateral movement target. If the source is external, also add a DNS sinkhole or proxy block for any associated domains.
• Revoke Kerberos tickets and cached credentials for the compromised account: Run klist purge on any hosts where the account had active sessions. If the account is a domain admin or high-privilege account, consider running Invoke-ADSISearcher or using your PAM solution to rotate all associated secrets immediately. Force a password reset that invalidates existing Kerberos TGTs.

Eradication

• Remove identified persistence mechanisms: Based on investigation findings, delete any malicious scheduled tasks identified via Event ID 4698 using schtasks /delete /tn [task_name] /f. Remove malicious registry run keys identified via Sysmon Event ID 13 using reg delete [key_path] /v [value_name] /f. Disable or delete any new services created during the session via sc.exe stop [service_name] followed by sc.exe delete [service_name].
• Search for and remove all dropped tools and payloads: Based on the file paths identified in Sysmon Event ID 11, delete all identified malicious files. Run a full AV/EDR scan on the compromised host and all hosts it connected to laterally. Use your EDR’s threat hunting capability to search for matching file hashes across the entire fleet — attackers frequently reuse the same tools on multiple systems.
• Restore accessibility feature binaries if they were replaced: Verify the integrity of C:\Windows\System32\sethc.exe, utilman.exe, osk.exe, narrator.exe, and magnify.exe by comparing their hashes against known-good values from a clean reference system or Microsoft’s MSRC hash database. Restore any modified files from the Windows component store using sfc /scannow or directly from a trusted source.
• Reset credentials for all accounts that were used or potentially exposed: Reset the password for the compromised account and any accounts whose credentials were stored on the compromised host (check Credential Manager, browser-saved passwords, and any password vaults accessible during the session). If Mimikatz or a similar tool was detected, assume all credentials cached on the host (including machine account credentials) are compromised and reset them.
• Check all lateral movement targets for additional backdoors: For every host the attacker touched (identified in investigation step 6), run the same persistence checks — review scheduled tasks, services, run keys, and accessibility feature binary integrity. Do not assume the attacker only established persistence on the first compromised host.

Recovery

• Verify the host is clean before reconnecting to the network: Before removing network isolation, obtain sign-off from your IR lead that all identified persistence mechanisms have been removed and a full EDR scan returned clean. If confidence in the integrity of the OS is low — particularly if the attacker had SYSTEM-level access or the session lasted more than an hour — re-image the host from a known-good baseline rather than attempting cleanup. A re-image is always faster than an undiscovered backdoor.
• Re-enable the user account only after confirming no persistence remains: Before re-enabling the disabled account in Active Directory, confirm the password has been reset, MFA has been re-enrolled (reset any existing MFA tokens if your platform supports TOTP or FIDO2 re-registration), and the user has been briefed on the incident. Communicate the re-enablement time to the user’s manager to avoid confusion.
• Implement or validate RDP access controls before returning to normal operations: Confirm that RDP on all non-jump hosts is either disabled via GPO (Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Allow users to connect remotely = Disabled) or restricted by firewall rules to only permit connections from approved jump host IPs. Verify Network Level Authentication (NLA) is enforced on all RDP-enabled hosts.
• Monitor the previously affected host, user account, and lateral movement targets for 72 hours post-remediation: Create a temporary high-sensitivity watchlist rule in your SIEM that alerts on any logon (all logon types), process creation, network connection, or file write activity involving the previously compromised account or originating from the re-imaged host. Review the watchlist alerts manually at least twice per shift for the first 72 hours.
• Document the full incident timeline and conduct a lessons-learned review: Record every event timestamp, affected host, action taken, and decision point in your ticketing system or IR platform. Within 5 business days, hold a lessons-learned meeting covering: how the initial credential was compromised, how long the attacker had access before detection, which detection rules fired (and which did not), and what process or control gap allowed RDP to be accessible from an unapproved source. Update your detection rules with any new IOCs (file hashes, IPs, command-line patterns) discovered during the investigation and share them with your threat intelligence team.