Over the last several months, TrustedSec has noticed a common thread in the root cause of incidents we’ve investigated: Microsoft Remote Desktop Protocol (RDP) open to the Internet. RDP on the Internet is a very bad idea. Attackers are constantly searching for, and breaking into, systems set up in this way. Once in, they can pivot throughout your enterprise, wreaking havoc in the process.

This blog series will be split into three (3) parts. This first post will detail ways to protect RDP installations and some pitfalls when configuring these protections. To get hard data on how often RDP is attacked on the Internet, and what happens when the bad guys get in, I set up an RDP honeypot. The second post of this series will discuss the data I gathered from the honeypot and what the attackers did once they got into the system. The final post will discuss how I set up the honeypot and the issues I had, as requested by my Internet peers.

Remote Desktop

Microsoft RDP is a protocol that allows users to remotely connect to Windows systems and act as if they were sitting in front of their computer. It’s a wonderful, and free, way to remotely administer Windows systems or access your desktop from home. Since it already comes with Windows, and provides a great way to remotely access systems, many organizations allow RDP on one or more internal systems to be accessible from the Internet. This is a bad idea.

First, it’s extremely easy to find RDP systems online. Not only can you scan for RDP’s default port (TCP/3389), but Shodan has already done it for you.

With over 3 million potential victims in their database, attackers are sure to find a few to attack (including any you have).

Second, once an open RDP server is found, there are multiple free tools that let attackers brute force credentials. My honeypot was online for nine (9) days and I had over 58,000 logon attempts, with the first starting only a few minutes after it was put online.

Once an attacker brute-forces valid credentials, they can log in as if they were sitting in front of the computer. This means that if you expose the RDP of an internal system to the Internet, and an attacker breaks in, they are on your internal network. In the cases we’ve worked, we’ve seen attackers pivot across the domain installing crypto-miners and ransomware, or even gaining Windows domain admin privileges—and all of it starting because they were able to log in through RDP.

Securing Remote Desktop

What can you do if you need to put RDP on the Internet? First off, don’t.

Seriously, don’t.

There is absolutely no reason to put RDP directly on the Internet. Most business-level firewalls come with built-in VPNs with multi-factor authentication (MFA) and provide a secure way for external users to access internal resources.

Regardless, for every RDP instance you have—including those on your internal network—there are some things you should do to secure it.

Network Level Authentication (NLA) should be configured. By default, RDP allows a client to connect to the RDP service and then requests authentication. When configured, NLA requires the user to authenticate before gaining access to the remote desktop connection. This is a more secure method of authentication and helps protect RDP from potential exploits, should they exist. However, it does not prevent or slow down brute-force or man-in-the-middle (MitM) attacks.

Forensically, NLA might also change the way RDP logs authentications. Without NLA, both failed and successful authentication attempts generate logon type 10 Windows security events. When NLA is enabled, and depending on the OS version, successful and failed authentication attempts become logon type 3 events, which are also used when someone attempts to connect to network shares.

Additionally, turning on NLA might also mean you lose the IP source of the authentication attempt in the event logs. (Again, this depends on the OS version and your configuration.) In order to determine if the logon was for RDP rather than access to a file share, you need to correlate the Windows “TerminalServices” Operational logs to logon attempts. Ponder the Bits has an amazing article that describes how to do this.

Organizations should also limit who can log in through RDP. Group Policy contains a setting “Deny log on through Remote Desktop Services,” which designates a list of users or groups that are not allowed to access to the system through RDP. By default, this is empty. It is recommended to add “Local account and member of Administrators group” to the setting. This will ensure that the most commonly used accounts in brute-force attacks, including the local administrator, are not able to log on through RDP.

A Remote Desktop Gateway server can also be set up to better secure RDP connections. RDP Gateways allow organizations to tunnel RDP traffic over HTTPS and restrict which systems users can RDP to through the gateway. Combining this with MFA, this greatly increases the security of RDP instances. However, a VPN should still be used; using a gateway server does not magically fix all the issues with putting RDP on the Internet.

Finally, following good security practices—including having a good password policy, setting an account lockout policy, and having a robust logging policy—also helps protect RDP instances. If an attacker were to get into your organization, these practices would help slow them down and enable faster detection.

Conclusion

RDP is a great technology that allows us to easily remotely access systems and increase productivity. However, care must be taken to prevent opening your organization up to unneeded risk. Organizations should never put RDP directly on the Internet, as doing so means it’s only a matter of time before a bad password is guessed and the system is compromised.

Of course, all organizations must weigh their own risk and may decide the benefits of an Internet RDP system outweigh the enormous risk. However, if you do decide to do this, make sure you have an Incident Response retainer on hand, as you’ll need it.

In the next part of the series I’ll discuss what happened when I put an RDP honeypot online. Spoiler: bad things.