RDP: protocol weaknesses and honeypot deployment experiment

Today RDP is one of the most popular protocols for remotely connecting to Windows machines. But if not properly configured, it can become the Achilles heel of any infrastructure.

At the time of the transfer of employees to remote control, many companies chose RDP because of the simplicity of its configuration and use. At the same time, due to the emergency transition, not everyone was able to pay due attention to ensuring security. As a result, many organizations were targeted by cybercriminals.

In this article, we decided to analyze the weaknesses of the RDP protocol and tell you how to secure the company’s infrastructure. We also conducted an experiment by deploying an RDP honeypot on several servers and described forensic artifacts that can be detected in case of unauthorized connection of intruders.

▍ Weaknesses of RDP

Almost 4 million RDP servers around the world are accessible from the external network today. No less of them, most likely, are available only from internal networks.

Attackers often specifically look for weaknesses in RDP servers in order to exploit them for their own purposes. For example, RDP is often subject to brute-force attacks. In addition, over the past two years, experts have discovered serious RCE vulnerabilities related to RDP.

Brute force attacks

The most common attacks on RDP are brute force attacks. They can be roughly divided into several groups.

1. The simplest attacks, which consist in guessing elementary passwords without using any automation tools.
2. Dictionary attacks, during which brute-forcing of all possible passwords for the assumed username is started.
3. Hybrid attackswhich involve the use of dictionaries, but each password is verified not only in dictionary form, but also after a series of simple modifications.
4. Password spraying, which iterates over millions of usernames for a known password until a match is found.
5. Credential stuffingin which the attackers use a list of compromised user credentials to brute force.

Having picked up a pair of login and password, the attackers gain full access to the compromised system.

The simplest and dictionary attacks are usually given due consideration and protection by organizations. For example, it is often planned to lock an account after several unsuccessful login attempts.

At the same time, password spraying and credential stuffing attacks are often forgotten. However, such attacks are now not uncommon, but, on the contrary, have rather become commonplace. Blocking IP addresses from which multiple unsuccessful RDP login attempts are made helps to combat them. Also, prohibiting the reuse of passwords will not be superfluous. Also, you shouldn’t use the same password on multiple resources.

Vulnerabilities

Since 2019, several serious RCE-related vulnerabilities have been discovered with respect to RDP. Their exploitation leads to remote code execution on the target system.

Vulnerability CVE-2019-0708, dubbed BlueKeep, was discovered not in the RDP protocol itself, but in the implementation of the Remote Desktop Service. This vulnerability allows an unauthenticated user to remotely execute arbitrary code on the target system. The vulnerabilities affect older versions of Windows: from Windows XP (Windows Server 2003) to Windows 7 (Windows Server 2008 R2). For its successful operation, you only need network access to a computer with a vulnerable version of Windows and a running RDP service. To do this, the attacker sends a specially crafted RDP request to the service, which allows the attacker to remotely execute arbitrary code on the target system. Information about BlueKeep was published in May 2019, but more than 289 thousand RDP servers are still vulnerable.

Vulnerabilities CVE-2019-1181 / 1182/1222/1226 are almost identical to BlueKeep. However, while the previous vulnerability only affected older versions of Windows, now all new versions of the OS are at risk. To exploit vulnerabilities, an attacker also needs to send a specially crafted request to the Remote Desktop Service of the target systems using the RDP protocol, which would allow arbitrary code to be executed. These vulnerabilities were published in August 2019.

Another vulnerability – BlueGate (CVE-2020-0609 / 0610) – was found in the Windows Remote Desktop Gateway component in Windows Server (2012, 2012 R2, 2016 and 2019). It also allows attackers to remotely execute code on the target system via RDP and specially crafted requests. BlueGate was published in early 2020.

▍Malware and RDP

The weaknesses of RDP do not remain out of sight of malware operators. It is not uncommon for cybercriminals to use the publicized RDP credentials in targeted attacks.

After gaining RDP access to the target system, the attackers manually disable anti-virus protection and launch malware. Such attacks often run ransomware such as Dharma (aka Crysis) on an infected system.

▍ Bait for intruders, or how we deployed honeypot

We decided to conduct an experiment and check what will happen with an RDP server accessible from an external network. For this, two honeypots were deployed. We used the Python implementation of the RDP protocol – RDPY, which can be found in open access…

One honeypot was deployed on the DigitalOcean public server, the other on a server in our organization’s network. Three ports were available from the Internet:

• the standard port is 3389;
• two non-standard ports – 36 and 25300.

The window displayed when connecting is shown in the screenshot below.

The standard port 3389 attracted the maximum attention on the network. During the month and a half that honeypots worked, a total of 15 brute force attempts and 237 attempts to write invalid data to a socket on a public server were recorded; and, respectively, 16 and 135 attempts – on a server in the organization’s network.

Also, as you would expect, the standard port 3389 was subjected to numerous scans from the network. At the same time, the public server was scanned on average 2.5 times more often than the server in the organization’s network.

The scan rate can be seen in the graph below. The vertical lines here indicate Saturdays and Sundays, which fell during the honeypot period. In most cases, there was a decline in network scans at the end of the working week.

Horizontally – days of honeypots, vertically – the number of connections.
The blue curve is the public north, the orange curve is the server in the organization’s network.
Vertical lines – Sat and Sun…

There were practically no attempts to scan non-standard ports. Therefore, porting RDP to a non-standard port will help protect against most attacks.

▍Security

Summarizing all of the above, you can deduce several rules that will help secure the infrastructure when connecting remotely via RDP.

1. Choose a custom port to provide an RDP connection. As practice shows, the standard port is more often than others subjected to scans and attempts to log in from unwanted users. However, a non-standard port alone cannot fully protect against attacks.
2. Establish a remote connection to corporate resources via VPN. This will provide an additional layer of protection, since brute force attacks will not be possible without access to the VPN.
3. Apply strong password policies which impose restrictions on the length of the password, its content, reuse, as well as the number of unsuccessful login attempts, after which the account is locked. This will help protect against brute-force attacks. Prohibiting password reuse will reduce the risk of password spraying and credential stuffing attacks.
4. Block IP addresses from which multiple failed RDP login attempts are made. This will protect against password spraying and credential stuffing attacks.
5. Use two-factor authentication. This will minimize the implementation of all types of brute-force attacks.
6. Configure auditing of RDP events and review connection logs regularly, in order to register suspicious activity in time.

---

▏Where to look for traces of RDP connection▕

If you have any suspicions about compromising your system via RDP, you can try several steps yourself.

1. Logs. First of all, you should immediately check the event logs:
   • % SystemRoot% System32 Winevt Logs Microsoft-Windows-TerminalServices-RemoteConnectionManager% 4Operational.evtx

     Event 1149 for successful connection before authentication using login and password, but after authentication of the IP address of the connection source. It is important to look for connections from unusual IP addresses; brute-force passwords can also get here.

   • % SystemRoot% System32 Winevt Logs Security.evtx

     Event 4624 for successful login, 4625 for failed login, 4778 for reconnection, 4634 for disconnect. Pay attention to the “LogonType”. For remote connections, it will be 3, 10 or 7. Here you need to look for successful login events from unusual IP addresses, pay attention to unsuccessful login events – this could be a brute-force attack.

   • % SystemRoot% System32 Winevt Logs Microsoft-Windows-TerminalServices-LocalSessionManager% 4Operational.evtx

     Events 21, 22 and 25 – for successful login or reconnection, 23 – for disconnection. Look for events from unusual IP addresses.

     Even if connections are allowed exclusively from internal IP addresses, it still makes sense to periodically check the logs described above for a sudden connection from the external network. This will allow you to timely find configuration errors made by administrators through inattention (for example, when setting up port forwarding, etc.).

   Often, attackers clean the logs. In this case, most often only Security.evtx is cleaned, a little less often – Security.evtx and Microsoft-Windows-TerminalServices-RemoteConnectionManager% 4Operational.evtx immediately. For this reason, it is highly desirable to view all three logs, and it is better to configure the forwarding of events to the SIEM system in advance.

2. Sessions of legitimate users. Almost always, cybercriminals who distribute ransomware begin to examine their victim’s internal network almost immediately after penetration. Sometimes they manage to reconnect to existing RDP server sessions accessible from the internal network. This can happen when the connection of a legitimate user has already been established, but at the TCP level it is broken (for example, the RDP window was closed). In this case, upon reconnection, the session is restored and the attacker enters the server. This means that in the log you can see that the connection was initiated by a legitimate user on day X, and on day X + N the attacker will reconnect from the same machine. Therefore, you should look not only at connection setup events, but also at reconnection and disconnection events.

If traces are found

If you find traces of successful penetration through RDP, you must first of all:

• try to isolate the attacker (or completely disconnect the infrastructure from the Internet, or disconnect critical servers from the local network);
• check the domain controller for signs of hacking, as well as check file dumps and other possible targets of the attacker.

There is a significant chance that the infection has already spread through internal resources. If this happens, you need to check for PowerShell startup events, antivirus triggers, and others. And the best thing is to immediately contact a computer forensics specialist.