Remote Desktop: You're Opening the Floodgates for Hackers

This blog post was originally created by Jeremy Rasmussen, Chief Technology Officer at Abacode.

Read the original blog here.

Once is a fluke. Twice a pattern. But when you see something dozens of times, it’s a bona fide trend. Abacode has seen Remote Desktop Protocol (RDP, IANA port 3389) used in dozens of successful attacks against businesses. When we get called in to perform Digital Forensics and Incident Response (DFIR), there’s a good chance RDP was the initial entry point for the attackers – ranking up there with phishing and Business Email Compromise (BEC). In fact, Abacode partner Coveware says that RDP was a factor in nearly two-thirds of targeted ransomware campaigns last year.

What is RDP?

RDP is the Microsoft proprietary client-server protocol that allows users to connect to remote systems over the network. RDP client software is available for most flavors of Windows (including Windows Mobile), Linux, Unix, macOS, iOS, Android, and other operating systems. RDP servers are built into Windows operating systems to listen for incoming connections on port 3389 by default.

RDP is great for allowing quick access to files, opening applications, troubleshooting problems, or just working from home on your office workstation. But if not configured properly, RDP can serve as a gateway for cybercriminal gangs to gain entry to your enterprise, move laterally, steal sensitive data, and launch malicious code such as ransomware.

I should mention that this problem is not inherent only to Windows RDP, but also to other third-party software allowing remote access – such as LogMeIn, TeamViewer, RemotePC, Zoho Assist, ConnectWise Control, and others.

How are they attacking it?

Believe it or not, a lot of RDP abuse comes from simple brute-force password guessing on the Internet-exposed service. An improperly configured service will allow unlimited attempts, starting with no password, password=username, password=password, etc. According to Malwarebytes, these rather unsophisticated attacks continue to be on the rise.

Credential stuffing is a related attack in which the cybercriminals have a set of valid username and password combinations – usually stolen from other breaches – and then try out all these combinations on different systems (this is a good reason never to reuse your passwords across different accounts).

Another method used to bypass firewall restrictions is creating a tunnel out from a compromised PC. Firewalls typically block inbound traffic but allow outbound to pass. If attackers are able to gain a foothold through phishing or tricking a user into launching an app, they can then use a tool such as PuTTY to establish a secure shell (SSH) network connection out to other systems. This gives them an encrypted tunnel by which to establish RDP connections with a remote command and control (C&C) server – and the firewall won’t stop them.

What should you do?

Since RDP is a prime entryway for attackers to come into your system, ideally you should disable it as follows:

• Disable the Remote Desktop Service on all workstations and servers for which the service is not required for remote connectivity.
• Enable host-based firewall rules that explicitly deny inbound RDP connections.
• Prevent the use of RDP using local accounts on endpoints by enabling the “Deny log on through Remote Desktop Services” security setting in the system security profile.

But being realistic and seeing security as a continuum somewhere between wide-open usability and a completely disconnected, locked-down fortress – we understand that RDP services are often required to accomplish the business mission. So, if you are going to utilize RDP, make sure you have all of the following in place:

• Access Control. Organizations should configure their firewalls not to expose RDP listening ports, e.g., TCP 3389, to the public Internet. Using an RDP gateway with additional controls – say, solely via Virtual Private Networks (VPN) utilizing Multi-Factor Authentication (MFA) – is also a best practice for restricting RDP access to desktops and servers.
• MFA/Password Security. Set up long and strong passwords (say, 24 characters) on all accounts with access to Remote Desktop before enabling RDP. Also, ensure there is another factor required – e.g., an Authenticator app on a mobile phone or receiving an SMS text message and having to answer a challenge/response. If you think users will struggle with long passwords, you can implement this for them automatically with an Identity & Access Management solution, such Okta or Duo, that provides Single Sign-On/MFA/Role-based Access Control provisioning, and so forth.
• Limited Administrative Access. This is part of the larger issue of account management. By limiting the number of accounts with Administrator rights, as well as disabling local admin accounts (or ensuring there is not a common password across local admin accounts on all systems), this can help limit the ability of attackers to move laterally, harvest other credentials, and escalate privileges.
• Vulnerability Management. Implement a formal program that regularly researches vulnerabilities, and tests and installs security patches in a timely manner across all servers and workstations – this is absolutely critical to RDP security.
• Enable Network Level Authentication (NLA). Per Microsoft, NLA is “an authentication method that can be used to enhance Remote Desktop Session Host server security by requiring that the user be authenticated to the RD Session Host server before a session is created.” This can also help prevent denial-of-service (DoS) attacks that result from brute-force password guessing.
• User Awareness Training. Empower your users to be the first line of defense by training them to be aware of phishing scams. Users can undermine other security protocols in place if they’re not aware that clicking on links, opening email attachments, or following instructions from people over the phone (vishing), etc. can lead to launching malware.
• Network Segmentation. Isolate public-facing servers in a DMZ network segment and only expose hardened Web services to the Internet – not RDP. Likewise, isolate domain controllers, app servers, and database servers from workstations and other devices in your network and limit RDP access to these servers to an administration subnet.  Furthermore, configure a bastion server in which only whitelisted administration workstations can log on and only allow RDP sessions from the bastion server to any server in your environment.

If you do not have the resources (personnel, expertise, tools, etc.) required to perform these steps in your environment, consider reaching out to Abacode for a fully managed program to address RDP risk.

Let me be clear: Abacode does not get DFIR calls from clients that we have under-managed services. That’s because we have visibility into their environments and can immediately detect and contain any security incidents as they occur.

I’ll conclude with a recent success story:

Abacode deployed a Proof-of-Value (PoV) of our Cyber Lorica™ managed Security Information and Event Management (SIEM) and virtual Security Operations Center (vSOC) services for a client. Within hours of deployment, we saw foreign adversaries pounding on a system that had RDP port 3389 improperly exposed to the Internet. We were able to advise the client on the proper configuration to address and eliminate the problem. This speaks to the deeper value of Cyber Lorica™. We do not just report the security alerts from the SIEM and say, “Something’s happening.” We take it a step further and ask the difficult architecture questions to ensure that the issue is addressed and completely closed out.