I’ve seen blog posts and forum threads bad mouthing Microsoft and Remote Desktop Protocol (RDP). Usually it’s in conjunction with someone complaining that a ransomware or cryptominer variant had successfully compromised their environment through RDP. The rants are often followed by calls for everyone to dump Microsoft Windows and how “Microsoft security sucks!”
It’s not only boring and pedantic. It’s a case of blaming the wrong culprit.
Let me be clear. If you are compromised because of RDP, the problem is you or your organization. It isn’t a problem with Microsoft or RDP. You don’t need to put a VPN around RDP to protect it. You don’t need to change default network ports or some other black magic. Just use the default security settings or implement the myriad other security defenses you should have already been using. If you’re getting hacked because of RDP, you’re not doing a bunch of things that any good computer security defender should be doing.
Ransomware and RDP
There are many ransomware programs, like SamSam, and cryptominers, like CrySis, that attempt brute-force guessing attacks against accessible RDP services. So many companies have had their RDP services compromised that the FBI and Department of Homeland Security (DHS) have issued warnings.
The warning should be, “Your security sucks!” It isn’t like the malware programs are conducting a zero-day attack against some unpatched vulnerability. They are simply making a bare minimum of attempts to find easy-to-guess passwords on remote access accounts, most of which appear to have admin-level access.
If all you did was take the defaults that Microsoft puts in place, you would be very safe. That’s because by default, Microsoft only enables RDP for members of the built-in administrators group (RID 501), which requires a password that would be sufficiently long and complex enough to stop simple password guessing RDP attacks, especially when paired with an account lockout policy that only allows a few wrong guesses before locking the account. When RDP malware breaks into a computer you manage, that means you allowed the RDP-accessible account to have a very weak password and didn’t have account lockout enabled.
I’m pretty sure that’s not Microsoft’s fault.
Best practices to secure RDP
If you follow any of Microsoft’s decades-long touted best practices for security RDP you would be doubly protected. For instance, Microsoft has long recommended that the default administrator name be renamed and provides a group policy option to allow that. It also recommends enabling the Interactive Logon: Do Not Display the Last User Name option. If enabled, the password-guessing malware program would have no clue what username to start with to begin successful guessing, and even if it did, it would be easily stopped from guessing by account lockout.
Further, Microsoft recommends enforcing the distribution and use of trusted digital certificates to any computer trying to logon to use RDP. If the remote device doesn’t have the trusted digital certificate installed, it can’t even begin to guess at the logon password. The best computer security practitioners even require multi-factor authentication (MFA), which RDP supports, as authentication credentials. Microsoft has been recommending and supporting these best practices for over a decade.
When RDP might really be a problem
There are times when having a remote access service can truly add vulnerabilities to your system that you could not defend against using the defaults or best practices. A great example of this would be when RDP (or a service depending on it) has a known unpatched vulnerability. This happens, but it’s fairly rare. In fact, as best as I know, it’s only happened two or three times in the multi-decade existence of RDP, which first appeared in Windows NT 4.0.
The last critical vulnerability in RDP was back in 2012. It was the real deal. It was remotely exploitable, and one malicious connection could take over the remote logon without any successful authentication. Admins patched this one pretty fast--faster than the bad guys and malware could take advantage of it. Since then, there has not been not a single critical vulnerability that could take advantage of RDP.
Let’s compare that to OpenSSH (basically the open source competitor of RDP). It’s had 93 vulnerabilities since 1999, including nine in the last two years. I don’t hear anyone telling everyone to dump Linux and BSD because of OpenSSH vulnerabilities.
Should you do more to protect RDP?
It can't hurt to protect your publicly accessible RDP connections with additional VPNs, changing default TCP/IP ports, and other protection methods. Microsoft’s best practice recommendation of requiring digital certificates is to set up a precursor VPN, but you don’t need to do it.
If you ensure that you have basic, acceptable password policies along with account lockout enabled (even with a high number, like 100, of bad logons accepted), you won’t need the additional protections. There’s a lot to worry about and fix in the computer world, and you don’t need to add mitigations when you’ve already fixed the problem they solve twice over.
I used to be a big believer in using alternate ports, or even cooler, using port knocking (where you ping a predetermined series of ports, like a combination lock, before the firewall opens up the port you want to connect to), and other one-off defenses. You absolutely don't need to do them. They just add unneeded complexity to an already secured system.
If ransomware or a hacker successfully exploits your system or network because of RDP, you are doing many insecure, risky things that are indictive of problems far beyond just RDP. The last thing I'm going to do is blame Microsoft and RDP for a problem they aren't even close to creating--no more than I would blame Linux and OpenSSL for password guessing issues.