Is it safe to use Microsoft Remote Desktop?

What is RDP?

RDP [remote desktop protocol] is a technology that allows for a complete desktop experience, including remote sound, clipboard, printers, and file transfers with high resolution graphics [which can be scaled down based on bandwidth] for a remote user.

In 1998, Microsoft introduced Windows Terminal Server as an add-on to Windows NT Server 4.0 Operating System. This add-on capability enabled remote desktop access over a network using TCP/IP. Every Windows OS release to follow has also included this capability, which became mainstream with the release of Windows XP [circa October 2001]. Since the release of XP, RDP has been the de facto standard for remote session access for Windows Desktop and Server Operating Systems.

At 20 years old, RDP has seen multiple versions, with new capabilities added to mature it as a reliable remote access protocol. Over this time, RDP has also had its share of security issues.

However, with emergence of a new normal that entails more remote working, increased reliance on cloud computing, and ever more distributed environments, RDP is now commonly being stretched for use cases far beyond what it was intended. Numerous threat and breach research reports over the last 18+ months have indicated that this misuse of RDP is helping fuel the success and onslaught of ransomware and other cyberattacks.

Read on for an overview of RDP including, how it works, common use cases, RDP security risks, best practices for securing RDP, and alternatives to RDP to keep your organizations.

Best Practices for Addressing RDP Security Risks

In ideal and environmentally-controlled situations, the remote desktop protocol works great. However, securing RDP to prevent rogue sessions, hijacking, inappropriate access, exploits, privileged escalation, etc. requires a level of IT security maturity that goes far beyond default RDP settings.

RDPs default settings only provide a baseline for encryption and basic security. If these setting are solely relied on for security and used as is, they create a situation that presents an unacceptable risk to most organizations. With that said, how do you secure RDP for both internal and external operations?

First security rule of RDPit is absolutely unacceptable to leave RDP exposed on the Internet for accessno matter how much endpoint and systems hardening is performed. The risks of such exposure are far too high. RDP is meant to be used only across a local area network [LAN].

Since RDP hosts support a listening port awaiting inbound connections, even the most secure installations can be profiled as a Windows Operating System and its version. Once this is known, social engineering, missing security patches, zero day exploits, credentials on the dark web, insecure password management, etc. all could allow inappropriate access via RDP.

So, lets take securing RDP on external hosts off the table. It is just a bad idea. This even encompasses mobile devices like laptops used by employees at home or to support a mobile workforce. No devices that can have, or do have, a public TCP/IP address should have RDP enabled. This is why many organizations require VPN or modern remote access solutions to connect to external resourceseven if they are in the DMZ or cloudto mitigate these potential risks.

But whats involved with adequately securing RDP for internal use? We can start with what we know about the default configuration:

• Access lists: Enabling RDP on Windows Hosts, by default, only allows access by the local or domain administrators [depending on its current configuration]. While this prevents access by a standard user, it represents an unacceptable risk, since only administrators can authenticate via RDP into the asset. This does not follow the security best practice of least privilege. Therefore, access for administrators should be eliminated. Only the appropriate standard user accounts should be granted RDP access, and this should adhere to a just-in-time model, meaning access is for the briefest duration needed to complete a task. Moreover, session activity should be fully monitored to ensure it is appropriate. The necessary least privilege, just-in-time access, and session monitoring controls can be most thoroughly enforced via a privileged access management [PAM] solution.
• Default accounts: If the access lists recommendation above is not strictly followed, a threat actor can easily guess the administrator account for access into the resource. And, if the administrators default username is administrator, a breach, at least on some level, is almost foregone. So, my recommendation is that the administrator account for the local machine or domain be renamed to something different, unique, and not guessable. In addition, RDPing [yes, it commonly used as a verb too] as an administrator should only be performed in use cases where it is unavoidable, but not for daily remote access needs.
• Authentication: Network Level Authentication offers the strongest available method for authenticating RDP communications. If this not turned on, credentials are sent in clear text to a remote host or domain controller.
• Encryption: The High encryption level offers the strongest available encryption for RDP network communication. If this is not set, the maximum key strength supported by the target is negotiated [instead of the maximum key strength set by group policy options] through a domain controller.
• Clipboard redirection: RDP Servers offer clipboard redirection, so remote sessions can easily cut/copy and paste content from remote systems to the connecting device, and vice versa. This practice is ripe for abuse, such as by data extraction, or pasting of system information, like passwords.
• Network and LTP printer redirection: RDP Servers offer printer redirection for remote access sessions. This feature allows for the connection of network and LTP [Line Terminal Printer] printers from local devices and domain controllers to the remote asset. This can allow the printing of critical information and the introduction of malicious printer drivers into an environment. RDP should be configured without redirection for network and LTP printers.
• Session management: Windows Servers allow for multiple RDP sessions per user account. If a user is unintentionally disconnected, the results could be a loss of productivity or information, because a new session does not reconnect to the previous sessionit is orphaned. By restricting access, especially by limiting administrators to one session, this situation can be mitigated. This setting also acts as a rudimentary session management solution for malicious RDP since only one session can occur at a time, which makes tracking easy.

To implement these settings, organizations should configure them all in Group Policy Options and apply them via Active Directory. Resources that are not domain-joined must be individually set. Regardless, for both configuration scenarios, if one host is misconfigured, it could represent an enormous risk. Yet, this happens all the time.

While we keep security best practices for the configuration of RDP in mind, there are other risks that must be regularly monitored and managed:

• Vulnerabilities: Since the inception of RDP, various versions have had myriad vulnerabilities, including a few, such as BlueKeep and DejaBlue, that have allowed remote code execution and privilege escalation. For any environment using RDP, information technology administrators need to stay apprised of security updates and apply them in a timely manner. Without many of these security patches, few mitigating controls can prevent exploitation.
• Clients: The RDP protocol is well-documented. Many third-party products support acting as an RDP client. In addition, other operating systems, such as macOS and Linux, also contain native RDP clients based on open source and proprietary code. If a vulnerability is discovered in any of these clients, then the risk can be propagated back to an RDP host server. Therefore, controlling, limiting, and managing the RDP clients allowed in your environment [such as via application control] is critical to ensure the end users access does not become the attack vector.
• Licensing: Microsoft requires licensing of the RDP protocol for its use in an environment. Deploying a third-party solution or open source versions may violate your licensing agreements with Microsoft. As silly as this sounds, ensure any third-party solutions using RDP that you deploy have a proper license with Microsoft in order to instrument their technology.

Secure Alternatives to RDP for Remote Access

RDP security risks are unjustifiable for many organizations. Even the slightest incompliance, whether internally or externally when using RDP, is unacceptable. Such organizations require a strategic solution for remote access that is not dependent on native operating system functionality. This leaves a few choices for modern Microsoft Windows devices and other operating systems that support RDP as a client or server:

1. VNC [Virtual Network Computing]: VNC is an alternative remote access protocol that competes with RDP. It is a graphical desktop sharing solution that uses the remote frame buffer protocol to control the screen, keyboard, and mouse of another computer by relaying screen updates. The primary advantage of VNC over RDP is that it is platform-independent and has multiple server and client implementations from various sources on the same platform. With VNC, you can basically pick your vendor, open source, or style and implement it.

Unfortunately, VNC suffers many of the same security and hardening shortcomings as RDP, including potentially weak encryption, clear text transmissions, and limitations for hardening authentication. While some proprietary solutions have been built upon VNC to solve these issues, they are paid solutions just like any other proprietary implementation. And like RDP, assets using VNC should never be exposed directly to the Internet, and internal assets should be managed accordingly.

2. SSH [secure Shell]: Modern versions of Microsoft Windows allow almost every function to be executed via the command line. In 2018, Microsoft formally added native Secure Shell [SSH] to the operating system to facilitate this functionality remotely.

While not graphically-based, SSH allows a secure method to log in remotely to a Windows host and execute commands and scripts. Hardening of SSH entails similar steps to RDP. SSH needs to be properly configured for account access, encryption, and access control lists. To that end, it should only be used internallynever exposed directly on the Internet, if possible.

3. Third-Party Solutions: Proprietary implementations of remote access technology are typically architected in a vastly different manner than RDP, VNC, and SSH. In lieu of opening a listening TCP/IP port on a host, these technologies tend to use agent-based technology to call out to a manager or gateway technology and await an inbound connection request. Such implementations are ideal for placing on the Internet, since the exposure has been mitigated and authentication is performed at the remote access manager versus at the target itself. In addition, traffic is routed through the manager and gateway to secure the network path as opposed to point-to-point communication that may be blocked by firewalls.

Some vendors that supply proprietary implementations for remote access have solved all the challenges and deficiencies associated with RDP. However, these are enterprise solutions and not free. The underlying protocols used for these solutions are proprietary to the vendors.

The most advanced of these third-party secure remote access solutions may offer features like screen recording, multiscreen sharing, safe mode booting, and even remote registry accesswithout the need for a full session. However, account management can remain a challenge since every solution needs to grant authentication privileges based on a directory service or through a local role-based access model to each potential target. This needs to be set up regardless of whether the users and assets are grouped in Active Directory, LDAP, or Azure AD. Administrators need to set up who access to what, and when, in lieu of wide-open access that poses a huge risk to the business.

BeyondTrusts Secure Remote Access solution is comprised of the following two products:

• BeyondTrust Privleged Remote Access: Empowers IT teams to control, manage, and audit remote privileged access by authorized employees, contractors, and vendorswithout compromising on security. Enforces least privilege and exerts granular control and visibility over remote access for insiders and third parties, while enabling user productivity.
• BeyondTrust Remote Support: Empowers help desk teams to quickly and securely access and fix any remote device, on any platform, with a single solution. Organizations of all sizes can boost service desk productivity, efficiency, and security by consolidating and standardizing help desk support via a single, powerful solution.

Lets take a closer look at how BeyondTrust Secure Remote Access helps solve for the security shortfalls of native RDP.

Eliminates use of risky open ports and closes remote access backdoors: Typically, establishing remote desktop connections to computers on remote networks entails VPN tunneling, port-forwarding, and firewall configurations that create security holes [i.e. opening the default listening port, TCP 3389].

BeyondTrust Secure Remote Access enables organizations to eliminate these RDP security problems.

When you route remote desktop through our solution, you can still use native RDP to support systems on remote networks, but since BeyondTrust works through firewalls, you avoid exposing listening ports to the internet. With our solution, every remote connection is outbound through Port 443.

1. Centralized, identity-based controls: BeyondTrust integrates with LDAP, Active Directory, RADIUS and Kerberos. When you use RDP through BeyondTrust, your user access privileges and authentication methods cascade down to remote desktop sessions. This makes it easier both to require secure authentication before enabling remote access and manage remote access in an ongoing manner. For instance, if an employee departs the company, their RDP privileges are automatically removed from BeyondTrust once deleted from the AD or another identity-based directory, helping prevent backdoor access via an orphaned account.

2. Enforcement of least privilege: Unlike RDP, VPNs, and other remote access technologies, BeyondTrust Secure Remote Access can enforce granular privilege controls, ensuring users can only perform those specific activities for which they are authorized, and within the proper context.

With BeyondTrust, organizations can establish policies to control when the accounts are accessible [time of day, location, and other contextual parameters], and alert when specific access policies are invoked. Moreover, enterprises can extend these adaptive access controls to lock down access to resources [i.e. cloud control panes, web application consoles, etc.

Additionally, the solution enables a just-in-time access model, which helps minimize threat windows by ensuring duration of access is finite.

3. Password security for remote access session no matter the location: With BeyondTrust, you can ensure enterprise-class password security for remote sessionswhether initiated by an employee or vendor. A built-in vault manages credentials and injects them directly into sessionsnever exposing passwords to the end users. The vault can regularly rotate passwords, or even expire them after each use for the most sensitive accounts.

The solution also integrates easily with other privileged password management solutions, such as BeyondTrust Password Safe. Layering on enterprise password management controls immensely bolsters security and help ensure RDP sessions are not hijacked or leveraged for lateral movement.

4. Full visibility and pinpoint control over sessions: BeyondTrust enables organizations to overcome RDPs auditing and oversight shortcomings by providing centralized and tamper-proof logging and reporting features. Secure Remote Access pinpoints what took place, and by who, during any remote access session. The solution logs everything and also includes searchable video recordings of RDP sessions.

5. More robust encryption for remote sessions: BeyondTrust Secure Remote Access safeguards every remote desktop connection with 256-AES SSL encryption. This is much more robust than the 128-bit encryption RDP natively provides, and older versions of RDP may have even weaker encryption in place.

How BeyondTrust Secure Remote Access Technology Works with RDP

BeyondTrusts Remote Desktop integration leverages our Jumpoint technology, which can serve as the RDP broker. A Jumpoint is a connection to a remote host, which, in turn, can then connect to other hosts.

Once a Jumpoint has been installed on a remote network, an authorized user can leverage the Jumpoint to initiate sessions with computers on that same networkeven if those computers are unattended.

Enterprises commonly leverage BeyondTrust Jumpoint technology to securely initiate the follow types of sessions:

• Standard support
• Remote Desktop Protocol
• VNC
• Shell Jump to an SSH-enabled network device
• Shell Jump to a Telnet-enabled network device
• Intel® vPro Windows system

Support sessions, RDP sessions, and VNC sessions can also be started with systems on the same network segment.

The Jumpoint will only allow RDP access to the authorized users and teams, as established by your permissioning. Organizations can restrict installation and use of RDP clients in their environment, while configuring their RDP hosts to only accept connections from the Jumpoint. Once those settings are implemented, the solutions Windows, Mac, iOS, Android, or Linux Technician Console are the only applications that can be used for RDP access.

The BeyondTrust technology can also be used to address any other remote access use cases involving privileged access, ensuring every session is finely controlled, monitored, and audited.

Replace RDP or Better Secure It?

While Remote Desktop Protocol is a valid solution for some remote access use cases, there are manifold risks with regards to enforcing proper configuration, limiting Internet exposure, and maintaining security updates.

Today, cyber criminals wield automation and scanning tools to continuously seek out RDP exposed to the Internet and other remote access weakness that can be leveraged to gain a foothold into the environment. A single out-of-compliance asset, whether internally or externally, could jeopardize an entire organization. And, even if you use VPN to restrict access externally, the risks of VPN may actually amplify the problem.

Therefore, many organizations are choosing to discontinue use of RDP and replace it with a solution that provides more robust remote access security capabilities for the desired use cases. In those instances, the vast majority of risks can be mitigated.

Some modern solutions, such as BeyondTrust Secure Remote Access, even help enable zero trust security to better solve for the remote access problem.

Secure Remote Access can also be integrated with BeyondTrust other PAM solutions, such as Endpoint Privilege Management and Privileged Password Management to enforce least privilege and application control, and manage the entire enterprise universe of privileges. Combining these technologies will provide powerful, blended protection against remote access risks and all types of internal/external threats.

In parting, my advice is to identify where you have RDP exposed, assess that risk, and then make your own judgements. If you identify dangerous exposures, but an alternative solution is not immediately feasible to implement, at minimum, follow the hardening and security guidelines covered in this blog. It could help prevent, or at least minimize, the fallout due to an attack on your enterprise.