Using & Securing Remote Desktop Protocol (RDP)

Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft, allowing users to remotely connect to Windows workstations and servers. RDP is included in most versions of Windows, going as far back as Windows NT 4.0, and doesn’t come with additional costs or licensing requirements.

In Windows networks, this means organizations don’t need to pay for third-party software like TeamViewer, LogMeIn, or AnyDesk in order to enable their users with remote access capabilities. As a comparison, RDP is similar to the VNC protocol found in Linux and macOS.

How to Connect to an RDP Server

In order to establish an RDP connection to a destination Windows host (known as an RDP server), the connecting system needs to have RDP client software installed. On Windows, this is included as the Remote Desktop Connection program.

Microsoft also makes a Mac version of this software, available in the Apple App Store as Microsoft Remote Desktop. For Linux, there’s third-party software such as Remmina that supports being an RDP client in addition to the more Linux-friendly VNC protocol.

Once you’re running an RDP client, simply enter the IP address or hostname of the RDP server, assuming the RDP client can already communicate with the destination IP and DNS can resolve the hostname and communicate with it.

If your client can ping the RDP server but can’t connect using your RDP client software of choice, then RDP may not be enabled on the destination host. On Windows 10 and recent Windows Server OS’, you can search the Start Menu for “remote desktop settings” and enable the protocol in the resulting menu.

Pictured in the previous screenshot, your organization’s Group Policy settings may prevent you from enabling RDP access, which is a security best practice for hosts that should never allow remote connections.

Another thing to check in the event of a failed connection is the Windows Firewall on the RDP server, which should be open for TCP and UDP on the default RDP port of 3389 (unless this has been changed on hosts in your network).

Finally, you should also specify which user credentials can be used to log-in via RDP by managing the Remote Desktop Users group in Computer Management.

It’s also important to note that Administrators have RDP rights by default, per the “Allow log on through Remote Desktop Services” in Group Policy (Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment).

If the connection is successful, the RDP client software will prompt for log-in credentials for the RDP server.

If the log-in is authenticated, you’ll be able to view and control the remote host’s desktop environment as if you were physically at that system.

Securing RDP Servers

Due to the ease of use and popularity of RDP, it’s essential that organizations take steps to secure all hosts that can act as an RDP server (including non-server workstations). Furthermore, RDP has been subject to many vulnerabilities over the years, some of which allow attackers to connect without valid credentials (such as CVE-2019-0708 aka BlueKeep).

Some general tips for securing Remote Desktop Protocol:

• NEVER expose RDP servers to the public internet. Due to the number of vulnerabilities discovered in the RDP protocol over the years, there’s no reliably secure way to leave them open to connections over the public internet.Every day, attackers are scanning for internet-facing RDP servers (port 3389 open), and will try every attack in their arsenal to break in.

Let’s reiterate this one more time, because it’s the most important RDP best practice: Never expose RDP servers to the public internet!

However, access is still possible when your client isn’t in the same LAN as the RDP server. Instead of connecting across the public internet, consider a VPN or Windows’ built-in Remote Desktop Gateway.

• Disable RDP where it’s not needed. If a workstations or server should never be accessed remotely, then RDP should be disabled in that host’s OS (typically via Group Policy, Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely using Remote Desktop Services).

• Restrict which user credentials can connect. You can control which users and groups are able to connect to a host with RDP via the “Remote Desktop Users” group in Computer Management.

• Use strong passwords. Preventing passwords from being easily guessed or brute-forced is an essential security best practice, and we took a deeper dive into that subject in our Preventing Bad Passwords blog.

• Restrict which IPs can connect via the Windows Firewall. In addition to restricting which credentials can be used to log-in to an RDP server, the Windows Firewall also allows you to specify which IPs RDP connections should come from. If configured properly, RDP connections from IPs not on that list will be rejected before the prompt for log-in credentials.

• Enable Network Level Authentication (NLA). Introduced in RDP 6.0 (in Windows Vista), NLA requires RDP clients to authenticate before establishing a session. Prior to NLA, the legacy connection method used RDP server resources to authenticate the session, which could result in “denial of service” attacks if legacy RDP connection requests were spammed. NLA also protects against intercepted credentials (“man in the middle” attacks).

To quote Microsoft directly:

“There is partial mitigation on affected systems that have Network Level Authentication (NLA) enabled. The affected systems are mitigated against ‘wormable’ malware or advanced malware threats that could exploit the vulnerability, as NLA requires authentication before the vulnerability can be triggered. However, affected systems are still vulnerable to Remote Code Execution (RCE) exploitation if the attacker has valid credentials that can be used to successfully authenticate.”

Source: Patch new wormable vulnerabilities in Remote Desktop Services (CVE-2019-1181/1182)

If your organization has Network Level Authentication enabled, you may be familiar with this RDP error message when trying to connect via the legacy method:

“The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA. If you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System Properties dialog box.”

This is not an exhaustive list, rather a solid jumping off point if RDP security hasn’t been addressed in your network. Additional safeguards include multi-factor authentication, enabling stronger encryption methods, and locking out users after a certain number of failed log-in attempts.

There’s one more security measure worth discussing, although its pros and cons need to be weighed before deciding if it’s the right solution for your organization. There’s a mode in Windows called “Restricted Admin Mode”, which prevents credentials used in RDP connections from being stored on the RDP server in memory (which attackers can harvest using programs like Mimikatz). However, Restricted Admin Mode changes RDP logins to be of type “network” rather than the traditional “interactive”. This means hashes or tickets are used for authentication rather than prompted credentials, which opens the RDP server up to “pass-the-hash” attacks (using user NTLM hashes harvested elsewhere).

This may not be as big an issue as it seems, however. Restricted Admin Mode certainly exposes RDP servers to pass-the-hash attacks, however if attackers have already harvested privileged user NTLM hashes then they can potentially access SMB via pass-the-hash anyways. In this scenario, protecting RDP servers against NTLM hash harvesting may be more valuable then preventing RDP pass-the-hash attacks. Ultimately it comes down to each organization’s current security needs, compliance regulations, and general approach to network security.

How Stealthbits Technologies Helps

Stealthbits’ Privileged Activity Manager enables secure, task-based administrative access delivered just-in-time and with just-enough privilege, including tasks performed via Remote Desktop Protocol. SbPAM provides admins the exact level of privileges needed, exactly when they’re needed, for only as long as they’re needed, and returns the environment to a no-access-by-default state, immediately upon completion.

Stealthbits also offers real-time threat detection and response with StealthDEFEND. Including advanced attack detection, response playbooks, user behavior analytics, and more, StealthDEFEND allows organizations to detect and respond to abnormal behavior and advanced attacks with unprecedented accuracy and speed.

Learn more about how Stealthbits Technologies can protect your organization here.