There isn’t a soul within IT who is going to deny that Microsoft’s Remote Desktop Protocol (RDP) client, that’s built into their Windows desktop and server operating systems, has helped organizations remain productive. What started out as Terminal Services, part of Windows NT 4.0 Server, back in 1998, has enabled users to remotely interact with a Windows desktop environment for more than two decades. But back in 1998 none of us was even thinking about the possibility that someone would (GASP!) misuse the functionality for their own malicious purposes; the idea of a hacker was someone targeting government networks, infrastructure, etc. – nothing even remotely close to the average business.
Fast forward to 2022. Remote Desktop Protocol, in its current iteration, is still very much used by organizations today. And that’s because it still meets the simple need of remotely connecting to a Windows machine. But also, fast forward to a current day that includes the need to secure a network from any external cyber risk that may exist – and the first thing that should come to mind is RDP.
Remote Desktop Protocol is a Security Risk
RDP is just minding its own business, helping users be productive. So, why put so much focus on it? When considering the service from a cybersecurity perspective, we must use the risk lens to determine RDP’s fate. The reality is that using RDP (without proper compensating controls) creates risk for an organization. There are a few issues with Remote Desktop Protocol that create this risk:
- It’s a readily available platform – It’s a built-in service on the “server” side (whether that is a Windows desktop or server OS), with every Windows machine having a built-in client. I mean, c’mon – we’re not even making this difficult for the threat actor!
- It’s directly accessible from the Internet – unlike more advanced services like Zero Trust Network Access that scrutinize the connection request before connecting the requesting user to the remote desktop, RDP is directly exposed to the Internet.
- The used port is irrelevant – I can’t tell you how many times I’ve heard “I changed the port”. It doesn’t matter. Threat actors use port scanners to look for active ports, testing them to determine what service is exposed based on the response. So, move the port from 3389 to whatever you want, the bad guys will find it anyway.
- It uses a single authentication factor – by default, RDP relies on AD’s scrutiny of a username and password combination to provide access. This is the very same username and password that could be collected via a credential harvesting phishing scam that collects Microsoft 365 logons.
- It may enable a brute force attack – if the system hosting the RDP session is Windows 10 or earlier, there’s a possibility that it’s using a specific default account lockout policy that won’t lock out the credential, despite repeated unsuccessful attempts to log on using the same account.
- There’s limited visibility – unless you implement Microsoft’s Remote Desktop Services (the current iteration of Terminal Services), organizations lack an understanding of which systems may have RDP enabled, which are exposed externally (especially if the systems in question are sitting in, say, a DMZ outside the firewall), and – most importantly – which ones are being used.
- It can provide internal access to a compromised remote endpoint – there’s no consideration given to whether the externally-remote client that wishes to access an internal Windows desktop is secure when establishing the connection. The assumption is that the user of a credential afforded remote desktop privileges is the owner of that credential.
- (Simple) VPNs don’t add any security to RDP – Many organizations believe “RDP + VPN = Security”. But that’s not always – if rarely ever – true. Assuming the VPN used merely facilitates a secure channel between the externally remote endpoint and the internal system running RDP, while the connection’s privacy is certainly maintained, there is no additional security in this scenario. Many modern VPN services augment the security of the connection using features like multi-factor authentication, the use of certificates present on the remote endpoint, or IP restrictions (to name just a few), the overall connection is more secure – but no thanks to RDP itself.
The simple truth is that for an organization today that wants to stop the misuse of Internet-facing remote access by threat actors of any nature, all of the risks above must be eliminated. The threat actor who wants to take advantage of the remote access that is in place in your organization should be met with some (if not an extremely high) degree of difficulty along the way:
- When they scan your ports, it’s not super obvious “oh, that’s RDP!”.
- The remote client isn’t a Run command away.
- They can’t log on as many times as they want without locking the account.
- They need to provide additional authentication factors at logon.
- And you know which systems are externally accessible and when they are utilized.
So, let’s answer the question posed in the title of this article by saying that RDP – on its own – definitely isn’t a secure way to remotely connect over the Internet.
Depending on your organization’s remote access needs, there are plenty of other remote access solutions that exist (keeping in mind that you’d need to wrap Remote Desktop Protocl in a number of third-party solutions anyway to eliminate the risk it natively creates anyway) to provide your remote users with secure access to internal systems that don’t inherently bring with them the same risks as RDP.
