Attacking RDP
Related Pages & Tools:
Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft which provides a user with a graphical interface to connect to another computer over a network connection. It is also one of the most popular administration tools, allowing system administrators to centrally control their remote systems with the same functionality as if they were on-site. In addition, managed service providers (MSPs) often use the tool to manage hundreds of customer networks and systems. Unfortunately, while RDP greatly facilitates remote administration of distributed IT systems, it also creates another gateway for attacks.
By default, RDP uses port TCP/3389. Using Nmap, we can identify the available RDP service on the target host:
nmap -Pn -p3389 192.168.2.143
Host discovery disabled (-Pn). All addresses will be marked 'up', and scan times will be slower.
Starting Nmap 7.91 ( https://nmap.org ) at 2021-08-25 04:20 BST
Nmap scan report for 192.168.2.143
Host is up (0.00037s latency).
PORT STATE SERVICE
3389/tcp open ms-wbt-serverMisconfigurations
Since RDP takes user credentials for authentication, one common attack vector against the RDP protocol is password guessing. Although it is not common, we could find an RDP service without a password if there is a misconfiguration.
One caveat on password guessing against Windows instances is that you should consider the client's password policy. In many cases, a user account will be locked or disabled after a certain number of failed login attempts. In this case, we can perform a specific password guessing technique called Password Spraying. This technique works by attempting a single password for many usernames before trying another password, being careful to avoid account lockout.
Using the Crowbar tool, we can perform a password spraying attack against the RDP service. As an example below, the password password123 will be tested against a list of usernames in the usernames.txt file. The attack found the valid credentials as administrator : password123 on the target RDP host.
Crowbar - RDP Password Spraying
Using Hydra
We can also use Hydra to perform an RDP password spray attack.
We can RDP into the target system using the rdesktop client or xfreerdp client with valid credentials.
Protocol Specific Attacks
Let's imagine we successfully gain access to a machine and have an account with local administrator privileges. If a user is connected via RDP to our compromised machine, we can hijack the user's remote desktop session to escalate our privileges and impersonate the account. In an Active Directory environment, this could result in us taking over a Domain Admin account or furthering our access within the domain.
RDP Session Hijacking
As shown in the example below, we are logged in as the user juurena (UserID = 2) who has Administrator privileges. Our goal is to hijack the user lewen (User ID = 4), who is also logged in via RDP.
To successfully impersonate a user without their password, we need to have SYSTEM privileges and use the Microsoft tscon.exe binary that enables users to connect to another desktop session. It works by specifying which SESSION ID (4 for the lewen session in our example) we would like to connect to which session name (rdp-tcp#13, which is our current session). So, for example, the following command will open a new console as the specified SESSION_ID within our current RDP session:
If we have local administrator privileges, we can use several methods to obtain SYSTEM privileges, such as PsExec or Mimikatz. A simple trick is to create a Windows service that, by default, will run as Local System and will execute any binary with SYSTEM privileges. We will use Microsoft sc.exe binary. First, we specify the service name (sessionhijack) and the binpath, which is the command we want to execute. Once we run the following command, a service named sessionhijack will be created.
To run the command, we can start the sessionhijack service :
Once the service is started, a new terminal with the lewen user session will appear. With this new account, we can attempt to discover what kind of privileges it has on the network, and maybe we'll get lucky, and the user is a member of the Help Desk group with admin rights to many hosts or even a Domain Admin.
RDP Pass-the-Hash (PtH)
We may want to access applications or software installed on a user's Windows system that is only available with GUI access during a penetration test. If we have plaintext credentials for the target user, it will be no problem to RDP into the system. However, what if we only have the NT hash of the user obtained from a credential dumping attack such as SAM database, and we could not crack the hash to reveal the plaintext password? In some instances, we can perform an RDP PtH attack to gain GUI access to the target system using tools like xfreerdp.
There are a few caveats to this attack:
Restricted Admin Mode, which is disabled by default, should be enabled on the target host; otherwise, we will be prompted with the following error:
This can be enabled by adding a new registry key DisableRestrictedAdmin (REG_DWORD) under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa. It can be done using the following command:
Adding the DisableRestrictedAdmin Registry Key
Once the registry key is added, we can use xfreerdp with the option /pth to gain RDP access:
xfreerdp: This is the command-line client for FreeRDP, an open-source implementation of the RDP protocol./v:192.168.220.152: This specifies the IP address of the remote computer you want to connect to. In this case, the IP address is192.168.220.152./u:lewen: This option specifies the username (lewen) for the remote session./pth:300FF5E89EF33F83A8146C10F5AB9BB9: This option provides a password hash instead of a plaintext password. The hash300FF5E89EF33F83A8146C10F5AB9BB9is used for authentication in scenarios where the password is not directly available or when using certain authentication methods like NTLM hash.
If it works, we'll now be logged in via RDP as the target user without knowing their cleartext password.
Keep in mind that this will not work against every Windows system we encounter, but it is always worth trying in a situation where we have an NTLM hash, know the user has RDP rights against a machine or set of machines, and GUI access would benefit us in some ways towards fulfilling the goal of our assessment.
Latest RDP Vulnerabilities
In 2019, a critical vulnerability was published in the RDP (TCP/3389) service that also led to remote code execution (RCE) with the identifier CVE-2019-0708. This vulnerability is known as BlueKeep. It does not require prior access to the system to exploit the service for our purposes. However, the exploitation of this vulnerability led and still leads to many malware or ransomware attacks. Large organizations such as hospitals, whose software is only designed for specific versions and libraries, are particularly vulnerable to such attacks, as infrastructure maintenance is costly. Here, too, we will not go into minute detail about this vulnerability but rather keep the focus on the concept.
The Concept of the Attack
The vulnerability is also based, as with SMB, on manipulated requests sent to the targeted service. However, the dangerous thing here is that the vulnerability does not require user authentication to be triggered. Instead, the vulnerability occurs after initializing the connection when basic settings are exchanged between client and server. This is known as a Use-After-Free (UAF) technique that uses freed memory to execute arbitrary code.
This attack involves many different steps in the kernel of the operating system, which are not of great importance here for the time being to understand the concept behind it. After the function has been exploited and the memory has been freed, data is written to the kernel, which allows us to overwrite the kernel memory. This memory is used to write our instructions into the freed memory and let the CPU execute them. If we want to look at the technical analysis of the BlueKeep vulnerability, this article provides a nice overview.
Initiation of the Attack
1.
Here, the source is the initialization request of the settings exchange between server and client that the attacker has manipulated.
Source
2.
The request leads to a function used to create a virtual channel containing the vulnerability.
Process
3.
Since this service is suitable for administering of the system, it is automatically run with the LocalSystem Account privileges of the system.
Privileges
4.
The manipulation of the function redirects us to a kernel process.
Destination
This is when the cycle starts all over again, but this time to gain remote access to the target system.
Trigger Remote Code Execution
5.
The source this time is the payload created by the attacker that is inserted into the process to free the memory in the kernel and place our instructions.
Source
6.
The process in the kernel is triggered to free the kernel memory and let the CPU point to our code.
Process
7.
Since the kernel also runs with the highest possible privileges, the instructions we put into the freed kernel memory here are also executed with LocalSystem Account privileges.
Privileges
8.
With the execution of our instructions from the kernel, a reverse shell is sent over the network to our host.
Destination
Not all newer Windows variants are vulnerable to Bluekeep, according to Microsoft. Security updates for current Windows versions are available, and Microsoft has also provided updates for many older Windows versions that are no longer supported. Nevertheless, 950,000 Windows systems were identified as vulnerable to Bluekeep attacks in an initial scan in May 2019, and even today, about a quarter of those hosts are still vulnerable.
Note: This is a flaw that we will likely run into during our penetration tests, but it can cause system instability, including a "blue screen of death (BSoD)," and we should be careful before using the associated exploit. If in doubt, it's best to first speak with our client so they understand the risks and then decide if they would like us to run the exploit or not.
Last updated