Remote Desktop (RDP) Security Guide: Exposure, NLA and Gateways

Remote Desktop Protocol gives whoever holds a valid password a full interactive desktop, which is why exposed RDP, weak RDP logon controls and abused sessions keep turning up in intrusions. RDP is built into every Windows edition that admins and users rely on, so it cannot simply be removed; it has to be exposed carefully, authenticated strongly and watched. This guide covers RDP exposure and scanning, Network Level Authentication, RD Gateway and brokered access, RDP MFA, credential protection with Restricted Admin mode and Remote Credential Guard, session abuse such as hijacking, shadowing and redirection, malicious RDP files and unsanctioned remote desktop tools, and RDP logon monitoring. It is written for Windows administrators, endpoint engineers and SOC analysts.

Key takeaways

• Never expose RDP directly to the internet. TCP and UDP 3389 are scanned constantly; publish remote desktop access only through an RD Gateway, VPN or broker that enforces MFA, and block 3389 at the perimeter.
• Require NLA everywhere. Network Level Authentication makes the client authenticate before a session and logon screen are created, which shrinks the pre-authentication attack surface that BlueKeep (CVE-2019-0708) exploited.
• Keep admin credentials off the target. Remote Credential Guard or Restricted Admin mode stops reusable credentials being left on a server an attacker may already control.
• Treat sessions as assets to protect. Time limits on disconnected sessions, restricted drive and clipboard redirection and a shadowing policy that requires consent close the common session abuse routes.
• Log the whole session lifecycle. Event 4624 type 10, 4625, 4778 and 4779 plus the TerminalServices operational logs show who connected, from where, and when a session was reconnected or taken over.

How RDP and Remote Desktop Services fit together

RDP listens on TCP 3389, and on UDP 3389 for the UDP transport. Microsoft calls its implementation Remote Desktop Services (RDS). On Windows clients, Windows Remote Desktop allows one interactive session at a time; on servers, the Remote Desktop Session Host role allows many, with the RD Connection Broker distributing users, RD Web Access publishing resources and RD Gateway tunnelling RDP over HTTPS from outside. MITRE ATT&CK tracks RDP use with valid accounts as T1021.001 Remote Services: Remote Desktop Protocol, and notes that attackers usually obtain the credentials first. That is why RDP security is mostly about who can reach the listener and how they authenticate.

For identity-centred remote access design across VPN, ZTNA and gateways, see the Remote Access Identity Guide.

RDP exposure, scanning and brute force

Internet-wide RDP scanning finds new listeners quickly, and an exposed host then faces RDP brute force and password spraying (ATT&CK lists RDP on 3389/TCP among the services sprayed under T1110). Changing the port only delays discovery. ATT&CK mitigation M1030 is plain: do not leave RDP accessible from the internet, and block RDP between network security zones with firewall rules. See the Network Ports and Protocols Security Guide for the wider port exposure picture.

• Find exposure from outside: scan public ranges for 3389 on a schedule and check cloud security groups and NAT rules; a test VM with a public IP is the usual leak.
• Find exposure from inside: workstation-to-workstation RDP is rarely needed. Block inbound 3389 on workstations with host firewall rules, and allow it on servers only from management subnets or the gateway.
• Disable it where unused: ATT&CK M1042 says to disable the RDP service if it is unnecessary.

BlueKeep, CVE-2019-0708

BlueKeep is a remote code execution flaw in Remote Desktop Services that CERT-EU described as "pre-authentication and requires no user interaction", making it wormable. It affected Windows 7, Windows Server 2008 and 2008 R2, plus out-of-support Windows XP and Server 2003; Windows 8 and Windows 10 were not affected. The guidance was to patch, enable NLA (a partial mitigation, because the attacker then needs a valid account first) and block TCP 3389 at the perimeter. NLA plus no exposure is the pattern that limits the next pre-authentication RDP flaw.

Hardening the RDP host

Most settings live under Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host, and in Intune's Settings Catalog under the same names. Group Policy takes precedence over the setting on the System Properties Remote tab.

Patch RDS promptly, keep local administrator passwords unique per host, and use the Windows Endpoint Hardening Guide for the wider baseline.

Protecting credentials: Restricted Admin mode and Remote Credential Guard

A normal RDP logon sends the user's credentials to the remote host, so an attacker with SYSTEM on that host can harvest them. Two features prevent that, and Microsoft documents how they differ.

• Remote Credential Guard: redirects Kerberos requests back to the client, so "credential and credential derivatives are never passed over the network to the target device". Single sign-on and multi-hop still work. It is Kerberos only with no NTLM fallback, works only to Active Directory joined targets, and is not supported through RD Connection Broker or RD Gateway.
• Restricted Admin mode: the session runs without the user's identity being usable on the target, so there is no single sign-on onwards, and it requires membership of the remote host's Administrators group. Microsoft suggests it for help desk scenarios. Because it authenticates without sending a password, it has been abused to open RDP sessions with a stolen NTLM hash, so enable it on targets only where it is needed and monitor its use; event 4624 records a Restricted Admin Mode field.
• Enforcing them: the policy Restrict delegation of credentials to remote servers (Administrative Templates, System, Credentials Delegation) offers Require Restricted Admin, Require Remote Credential Guard, or Restrict credential delegation, which prefers Remote Credential Guard and falls back to Restricted Admin.

Choose Remote Credential Guard for administrators connecting directly to domain-joined servers, Restricted Admin for help desk access to machines they should not carry identity into, and a broker or privileged access workstation where neither fits. The Credential Dumping Guide covers what attackers do with credentials left behind.

RD Gateway, RDP MFA and brokered access

RD Gateway is the standard way to publish RDP. Access requires matching one RD Connection Authorization Policy (RD CAP, who may connect) and one RD Resource Authorization Policy (RD RAP, which hosts they may reach). Scope RD RAPs to specific server groups rather than all computers, otherwise the gateway becomes an open door to the internal network.

• RDP MFA through the gateway: the Entra MFA NPS extension adds a second factor through RADIUS. Install it on a separate NPS server, not on the gateway itself. Microsoft notes the gateway flow cannot accept typed verification codes, so users need push approval or phone verification, and SMS does not work. Raise the RADIUS timeout to 30 to 60 seconds so users can respond. Use number matching for push approvals to limit fatigue prompts; see the MFA Fatigue and Bypass Guide.
• MFA at the host: where a gateway is not used, Windows sign-in with Windows Hello for Business or smart cards gives stronger RDP authentication than a password, but the network path must still be restricted.
• Brokered RDP: a bastion or privileged access gateway removes inbound exposure entirely and ties each session to an identity and approval. Azure Bastion Premium can record graphical RDP and SSH sessions to a storage account (not through the native client), and privileged session management platforms add approval and keystroke or video recording.

RDP session abuse and how to limit it

Remote desktop session abuse matters as much as stolen credentials. The Lateral Movement Guide covers RDP as a lateral movement channel; below are the controls the RDP host provides.

• RDP session hijacking (T1563.002): with SYSTEM rights, an attacker can attach to another user's active or disconnected session through the Terminal Services console tool without credentials or a prompt. Short disconnected-session limits, logging off admin sessions rather than disconnecting, and alerting on session reassignment without a matching logon reduce the window.
• RDP shadowing: a legitimate support feature that lets one user view or control another's session. If policy allows control "without user's permission", anyone holding the right permissions can watch or drive sessions silently. Enforce a consent-required policy and alert on changes to it.
• RDP drive redirection and RDP clipboard redirection: mapped drives and the shared clipboard move files and data both ways; disable them where not needed.
• Malicious RDP files: in October 2024 Microsoft reported Midnight Blizzard emailing signed .rdp files that connected victims to attacker-controlled servers and redirected drives, clipboard, printers, peripherals and smart cards, exposing local data and allowing malware to be placed on the victim's drives. Microsoft's mitigation is to use Windows Firewall to prevent or restrict outbound RDP to external or public networks; consider blocking .rdp attachments at the mail gateway as well.
• Reverse RDP and tunnelling: when inbound 3389 is blocked, attackers carry RDP outbound, for example through a reverse SSH tunnel or a web shell, as ATT&CK procedure examples describe, or expose a local RDP port through a relay. A host making long-lived outbound connections that carry interactive sessions, or a 4624 type 10 logon whose source address is the loopback address, deserves investigation.
• RDP Wrapper and Terminal Services DLL changes (T1505.005): attackers patch termsrv.dll or change the ServiceDll value under HKLM\System\CurrentControlSet\services\TermService\Parameters, for example with the RDP Wrapper library, to allow concurrent sessions on client Windows and keep hidden access. Monitor that registry value and unexpected modules loaded by the svchost process hosting TermService.

Unsanctioned remote desktop tools

Remote support agents and services such as Chrome Remote Desktop connect outbound to cloud relays, so blocking 3389 does nothing against them. Approve one tool per use case, manage it with MFA and logging, and block the rest. For Chrome Remote Desktop, Google states that blocking remotedesktop-pa.googleapis.com prevents all its functionality, and the RemoteAccessHostFirewallTraversal policy can restrict it to LAN or VPN use. Application control on endpoints is the backstop for other tools; see the Endpoint Security Guide.

RDP logon monitoring and detection

• Brute force pattern: bursts of 4625 against many accounts from one source on an RDP host or gateway, followed by a 4624 type 10 from the same source.
• Unusual source: RDP logons from workstations rather than management hosts, from outside approved ranges, or by accounts never seen using RDP before. ATT&CK detection strategy DET0327 looks for RDP logon followed by unusual process execution, file access or lateral movement.
• Hijacking pattern: a session reassigned to another user (4778, LocalSessionManager 25) with no matching authentication (1149 or 4624) beforehand, which is how ATT&CK detection strategy DET0588 frames it.

The Windows Event Log Guide covers enabling Audit Logon and Audit Other Logon/Logoff Events, and forwarding the TerminalServices operational channels.

Metrics

• Internet-exposed RDP listeners: target zero, measured by external scans.
• NLA coverage: percentage of RDP-enabled hosts enforcing NLA.
• Remote Desktop Users sprawl: accounts with RDP logon rights per server tier, trending down.
• MFA coverage: share of remote desktop sessions passing through an MFA-enforcing gateway or broker.
• Unapproved remote desktop tools: endpoints with unsanctioned tools installed.

Rolling out RDP controls in phases

1. Inventory (weeks 1 to 2): hosts with RDP enabled, external 3389 exposure, Remote Desktop Users and local Administrators membership, installed remote desktop tools.
2. Close exposure (weeks 2 to 4): remove direct internet RDP, put remote access behind a gateway, VPN or broker with MFA, and block 3389 at the perimeter and on workstations. Test with a pilot group before cutting public listeners.
3. Harden hosts (weeks 3 to 8): enforce NLA, the TLS security layer, session limits and redirection restrictions through a GPO or Intune profile, piloted on one server tier first. Expect breakage from old thin clients that lack CredSSP.
4. Protect credentials: enforce Restrict delegation of credentials to remote servers on admin workstations, starting with Restrict credential delegation so connections still succeed where Remote Credential Guard cannot be used.
5. Detect and record: collect the events above, build the brute force and unusual-source rules, and enable session recording for privileged access.

Rollback: each setting is a single policy value; unlink or set the GPO or Intune profile to Not Configured to revert. Keep an out-of-band console path (hypervisor or cloud serial console) before tightening RDP on servers you cannot reach otherwise.

Choosing the right approach

• Small organisations: no public RDP, a VPN or cloud broker with MFA, NLA everywhere and unique local admin passwords.
• Large or regulated estates: RD Gateway or brokered RDP with narrow RD RAPs, tiered administration, Remote Credential Guard for admins and RDP session recording for privileged sessions.
• Cloud VMs: no public IPs on management ports; use the provider's bastion or just-in-time access.
• Help desk support: Restricted Admin or a managed support tool with consent prompts.

Where identity fits

Accounts with RDP logon rights, shared local administrator passwords and standing privilege decide how far one stolen password goes. Remove RDP logon rights from service accounts and alert on their type 10 logons, rotate local administrator passwords per host, and give administrators just-in-time access through a broker. See the Privileged Session Management Guide.

Common failure patterns

• The forgotten exposed host: a test VM or vendor server with 3389 open bypasses every gateway. Scan continuously, not annually.
• Remote access without MFA: remote desktop and virtual app portals protected only by a password are the same weakness as exposed RDP; the Change Healthcare breach started with a Citrix remote access login without MFA.
• Gateway with an open RD RAP: MFA at the gateway, then access to every internal machine.
• Disconnected admin sessions left for days: ready-made targets for session hijacking and credential theft.
• Outbound RDP allowed: malicious RDP files and reverse tunnels work because nothing stops 3389 leaving the network.
• Shadow tools: remote desktop agents installed by users or suppliers that nobody monitors.

Framework mapping

Practitioner checklist

• Confirm by external scan that no host exposes TCP or UDP 3389 to the internet, including cloud VMs.
• Publish remote desktop access only through an RD Gateway, VPN or broker that enforces MFA, with RD RAPs scoped to named server groups.
• Enforce NLA and the TLS security layer on every RDP-enabled host through GPO or Intune.
• Restrict Allow log on through Remote Desktop Services to named groups and remove service accounts and broad Administrators membership.
• Set disconnected and idle session limits and require consent for shadowing.
• Disable drive, clipboard and device redirection on servers that do not need them.
• Enforce Restrict delegation of credentials to remote servers on administrator workstations.
• Block outbound RDP to public networks and .rdp attachments at the mail gateway.
• Collect 4624 type 10, 4625, 4778, 4779, 1149 and LocalSessionManager events, and alert on brute force, unusual sources and TermService registry changes.
• Approve one remote support tool, block the rest, including Chrome Remote Desktop where not sanctioned.

Standards and references

• MITRE ATT&CK: T1021.001 Remote Services: Remote Desktop Protocol
• MITRE ATT&CK: T1563.002 Remote Service Session Hijacking: RDP Hijacking
• Microsoft Learn: Remote Credential Guard
• Microsoft Learn: Integrate Remote Desktop Gateway with the NPS extension and Microsoft Entra ID
• Microsoft Learn: Configure Network Level Authentication for Remote Desktop connections
• CERT-EU: Security Advisory 2019-013, Remote Desktop Services Remote Code Execution Vulnerability
• Microsoft Threat Intelligence: Midnight Blizzard spear-phishing campaign using RDP files
• Microsoft Learn: Event 4778, session reconnected to a Window Station

Related NHI Mgmt Group resources: Network Ports and Protocols Security Guide · Lateral Movement Guide · Remote Access Identity Guide · Privileged Session Management Guide · Windows Endpoint Hardening Guide