How to avoid using RDP on Windows

Several new vulnerability disclosures in Windows Remote Desktop Protocol suggest it’s time to stop using it where possible. Here’s how.

The recent discovery of several security vulnerabilities targeting Remote Desktop Protocol (RDP) has led to warnings that we should immediately patch Windows. CVE-2019-0708 (BlueKeep), CVE-2019-1181 (BlueKeep II), and CVE-2019-1182 (BlueKeep III) all rely on the fact that many admins still set up servers and leave them open to remote access over the internet.

Reviewing what or who is accessing your Remote Desktop Services (RDS) can be a difficult process. The log files and artifacts left by remote desktop are not the easiest to track. For years the way that many attackers would gain access to a server hosted in a data center was to use the tool TSgrinder to brute-force guess a system password.

Why do we still use Remote Desktop to connect to servers when we know that it’s less than ideal? Why are we still using it to connect to Azure virtual machines as well? Let’s face it, it’s familiar. It uses tools and techniques that we’ve used for years. It provides us with a resulting desktop that we’re familiar with. That familiarity means that attackers are familiar with it, too.

Recommendations for minimizing RDP risk

The first recommendation is only one step away from direct exposure of port 3389, over which Remote Desktop runs, but it’s a key step: By using the native Windows firewall, you can set up a rule to limit access of a machine to specific IP addresses. While this won’t protect machines from the latest RDP vulnerabilities, it does protect machines from brute-force password attacks.

The next recommendation will protect machines from these latest RDP vulnerabilities: Tuck them behind RDgateway or ensure that Network Level Authentication (NLA) is set and not allowing systems to accept RDP from lower level clients.

Ways to perform remote tasks without RDP

Using Remote Desktop at all is opening yourself up to old-school attacks. So what other ways can you perform tasks on remote computers without exposing them directly to the web over port 3389? Plenty. By now you are probably already using remote PowerShell commands. Have you thought about how you are securing remote PowerShell? Let’s review if you’ve set it up as securely as you can.

First have you deployed PowerShell 5 to enable PowerShell logging? Even on older platforms you can enable logging in PowerShell, which ensures that you can track and review what PowerShell scripts have been run on systems. Next, ensure that you’ve enabled transcription logging and choose a central file share location to keep the logs files for later review.

You’ll want to enable transcription logging via Group Policy or using Intune or registry keys. If you are using Group Policy, go to “Computer Configuration”, and then go to “Administrative Templates”, then to “Windows Components”, then to “Windows PowerShell” and double-click on “Turn on PowerShell Transcription”.

When you click on Enable, ensure that you choose a preferred Output Directory. Set the permissions for this central share location so that users and computers can write but not delete logging. Remember, you can do this with NTFS file permissions.

Grant permissions for what you want users to do. For example, you’ll want them to read, write and modify. To block the user or computer from deleting files, click on the advanced button for special permissions and advanced settings. On the advanced settings menu, select “Change permissions”, highlight the user and select “Edit”. In the edit window, you can see the granular permissions that are set. Check the box to remove the delete function from the share.

Susan Bradley

Permission settings

You’ll want to also enable script block logging, which can be done using Group Policy or via registry keys. You may want to evaluate the use of module logging, but keep in mind that this generates a large volume of log files, so determine if this can be done in your organization.

If you have not done so already, enable a certificate infrastructure for your domain. If your current certificate authority (CA) is on an older server, move your CA to a newer platform before Server 2008 R2 reaches its end of life. You’ll also want to disable the use of port TCP 5985, which uses HTTP, and instead use port TCP 5986. This uses HTTPS or TLS to secure the transmission of the commands and information. Step-by-step information on setting up Remote PowerShell over TLS can be found on this blog.

Next, limit via Group Policy objects that can initiate PowerShell connections. First, limit who has administrator access to any computer in the network. Limit the use of local administrator and limit who in your domain is a member of the Remote Management Users group. If you still need local administrators, ensure you deploy LAPS toolkit.

If your servers have multiple network connections, you can limit using one NIC as the remote management connection. In Group Policy, go to “Computer Configuration”, then to “Policies”, then to “Administrative Templates: Policy Definitions “, then to “Windows Components,” then to “Windows Remote Management (WinRM)”, then to “WinRM Service”. Choose “Allow remote server management through WinRM” and limit the IP address to the NIC that you will use for remote management.

Susan Bradley

Limit WinRM

These steps will ensure that when you use Remote PowerShell you are doing it in a secure manner that will keep the attackers away as well.

My challenge to you: The next time you feel the urge to launch Remote Desktop and log into another server. Stop. Ask yourself what exactly you are doing and review if there is a script already built to let you do what you need to do using PowerShell. Get out of the habit of using Remote Desktop. Block port 3389 on internet-facing servers as soon as you can. Consider doing the same inside the network to keep attackers from being able to easily gain access.