Adventures of an RDP Honeypot – Part One: RDP Security

Adventures of an RDP Honeypot – Part One: RDP Security

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.

Author: Tyler Hudak

Tyler has over 20 years of real-world experience in incident handling, malware analysis, computer forensics, and information security for multiple organizations. He has spoken and taught at a number of security conferences about topics ranging from incident response to penetration testing techniques.