Windows
View all Worklets
WindowsWindows

Disable Remote Desktop Protocol on Windows Machines

Disable Remote Desktop Protocol on Windows endpoints to remove the ransomware-favorite initial access vector

Worklet Details

What the RDP disabler does

This Automox Worklet™ disables inbound Remote Desktop Protocol connections on Windows endpoints. It reads and writes a single Terminal Server registry value: fDenyTSConnections under HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server. When that value is 1, the operating system refuses every new RDP session at the protocol layer, regardless of which user accounts exist on the host or which firewall rules are in place.

The Worklet ships as a paired PowerShell evaluation and remediation. The evaluation script calls Get-ItemProperty against the Terminal Server key and exits 0 when fDenyTSConnections already equals 1. The remediation script wraps Set-ItemProperty in a try/catch, writes the desired value, and on failure emits "Unable to update fDenyTSConnections" via Write-Output before exiting 1. Both scripts run as the Automox agent, which already runs with SYSTEM privileges on managed Windows endpoints.

The change is effective the moment the registry write completes. No reboot is required, and the Terminal Services and Remote Desktop Services services do not need to be restarted for the deny flag to take effect on subsequent connection attempts. Sessions that are already established remain connected until the user disconnects, which gives an administrator a graceful window to confirm no production session is being severed.

Why disable RDP on endpoints that do not need it

RDP on port 3389 is the most heavily attacked remote-access protocol on the internet, and it appears in the initial-access stage of nearly every major ransomware playbook tracked over the last five years. Conti, Ryuk, LockBit, BlackCat, and Royal affiliates all relied on exposed or weakly authenticated RDP at scale. The threat is not just brute force against the listener: BlueKeep (CVE-2019-0708), DejaBlue (CVE-2019-1181, CVE-2019-1182), and BlueGate (CVE-2020-0609, CVE-2020-0610) are pre-authentication remote code execution flaws that turned the RDP listener itself into a wormable foothold. Disabling RDP closes that listener on endpoints that do not need it, which is the most direct mitigation Microsoft and CISA recommend.

The fDenyTSConnections flag is also the control behind CIS Microsoft Windows 10 Benchmark 18.10.56.3.2.1 ("Do not allow users to connect remotely using Remote Desktop Services") and the corresponding Server 2019/2022 benchmark items, and it maps to NIST 800-53 AC-17 (Remote Access) and SC-7 (Boundary Protection). Auditors expect to see this flag enforced on workstations and on any server that does not have a documented remote-management need.

This Worklet writes fDenyTSConnections=1 to HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server on every Windows endpoint in scope, which collapses port 3389 inbound at the kernel level rather than relying on a firewall rule that a user can toggle off. The same value holds across rebuilds, group policy resets, and well-meaning end user toggles in the System Properties dialog, because the next Automox evaluation re-asserts it. Pre-authentication RDP listener flaws such as BlueKeep (CVE-2019-0708) and the DejaBlue pair (CVE-2019-1181, CVE-2019-1182) are unreachable on an endpoint where the registry key is set, because the host never completes the RDP handshake.

How RDP enforcement works

  1. Evaluation phase: The Worklet reads fDenyTSConnections from HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server using Get-ItemProperty. When the value equals 1 the endpoint is compliant and the script exits 0. When the value is 0, missing, or the property cannot be read, the endpoint is flagged non-compliant with exit code 1 and remediation is scheduled by the policy.

  2. Remediation phase: The Worklet calls Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 1 inside a try/catch block. On success the script exits 0. On failure it writes "Unable to update fDenyTSConnections" via Write-Output and exits 1, so a permission failure or a registry-tampered host surfaces in the Automox activity log instead of going silent.

RDP disable requirements

  • Windows 7, Windows 8, Windows 10, Windows 11, or Windows Server 2008 R2 and later (the same coverage the underlying Terminal Server registry key supports)

  • PowerShell 2.0 or later (already present on every supported Windows version)

  • Administrative or SYSTEM context for writes to HKLM (the Automox agent default already meets this)

  • A documented alternative for inbound remote access where it is genuinely needed, such as the Automox console for patch and configuration work, a privileged-access workstation, or a vendor-managed jump host

  • Optional, recommended companion Worklet to close TCP 3389 inbound at the host firewall with netsh advfirewall firewall set rule group="remote desktop" new enable=No, for defense in depth

Expected endpoint state after remediation

After remediation, the endpoint refuses every new RDP connection at the protocol layer. A user attempting mstsc.exe against the host receives "The remote computer that you are trying to connect to has refused the connection" or a similar protocol-level error, rather than a credential prompt. The Remote Desktop Services service can remain running without exposing the endpoint, because the deny flag is read before any session is brokered. Active sessions are not killed, so the change is safe to push during business hours when the policy targets workstations that are not currently in active remote use.

Validate from PowerShell with Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections and confirm the returned value is 1. Validate from the network side with Test-NetConnection -ComputerName <hostname> -Port 3389 from a remote host: the TCP handshake may still succeed because the listener remains bound, but the RDP negotiation will not complete and the session will not open. For audit evidence, capture the registry value and the mstsc.exe error screen with the policy run identifier, then cross-reference CIS Benchmark 18.10.56.3.2.1 and NIST 800-53 AC-17 in the audit workbook. Run a daily evaluation against the workstation policy so any drift caused by a Group Policy refresh, a System Properties toggle, or a tampered registry hive is corrected on the next remediation pass.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklets deploy named-CVE mitigations within hours of disclosure, perform configuration, remediation, and install or remove applications and settings across Windows, macOS, and Linux.

do more with worklets