Attack Paths in Active Directory: RDP Hijacking
This post describes an attack vector known as RDP Hijacking and documented in the MITRE ATT&CK framework as technique T1563.002 [1]. This attack vector can be used by attackers to perform privilege elevation and move laterally within an Active Directory environment. It involves the abuse of abandoned-disconnected - or in other words dangling - RDP sessions that may be running on hosts in which the RDP service is enabled. At the very bottom, it allows attackers connect to other users’ RDP sessions without knowing the password of the targeted user.
To bring this technique closer to real life, we will use an example. A ransomware operator that has compromised the internal network of a business, has access to an account. The access has been achieved using Kerberoasting [2]. The account grants access to a number of critical servers within the compromised network, such as RDP jumphosts. Leveraging the dangling RDP sessions that the attacker identified additional accounts are compromised. With the hijacked RDP sessions, attacker elevates their priviliges in the domain and install ransomware on critical infrastructure.
Public reporting indicates that this technique is leveraged by multiple threat actors [4] such as the Daixin Team - a ransomware and data extortion group [3].
The impact of this technique remains subject to the privileges the compromised accounts have and additional factors.
The post is divided in the following sections:
Concurrent RDP Sessions
The following image shows the output of the native command query user that is used to list active sessions on a host - effectively who (user) and how (RDP, console) is connected on the host. This command is the Windows equivalent of the Linux command who.
More specifically, it shows that the users john.doe and jack.jones have logged into the host with RDP.
Further on this, sessions can be enumerated on remote hosts with the command: query user /server:<server_name>. However, beginning with Windows 10, version 1607 and Windows Server 2016 Microsoft implemented configuration [7] to restrict access to that information from low-privileges users.
Nothing of concern thus far. The next section though, shows which condition can be exploited by attackers.
Dangling RDP Session
For the sake of this post, user jack.jones is a member of the group “Domain Admins”. This membership gives jack.jones full administrator privileges on the domain. Therefore, this account is a high value target from an attacker’s perspective.
The exploitation condition begins when a user closes the RDP window without logging off. This action leaves the RDP session in a dangling state, opening the door to session hijacking if additional requirements are met.
Observe the Disc status on the column STATE in the following image:
When closing the RDP window and logging off the operating system shows the following warning, that indicates the session is kept running:
The dangling state of this RDP session, allows users with sufficient privileges to connect to that session.
It is important to note that dangilng RDP sessions may be running for days or even months in production environments where RDP session timeouts have not been configured. Restarting the RDP server would be a way to remove dangling RDP sessions, however the availability of critical for business operations systems may be a significant reason that prevents restarting of servers.
Exploitation Requirements
To perform RDP hijacking an attacker would need to meet both requirements:
- Administrator level privileges on the host
- SYSTEM level privileges on the host
The second requirement is actually a byproduct of the first and can be easily achieved provide the first is established. For example, an attacker that has been connected with an account that has Administrator privileges on the host, can switch to SYSTEM permissions using a tool such as PsExec from Sysinternals. Another way would be to set up a service to run tscon and connect to the dangling session.
Next step is to connect to the dangling RDP session. This can be done with the native Windows command tscon. In line with the images provided above, an attacker would run the command list below to connect to the Administrator’s session:
tscon 2 /DEST:rdp-tcp#3
The tool tscon also accepts the password of the targeted user (/PASSWORD:). Therefore, an attacker can connect to a dangling session assuming the requirement number 1. is met and without escalating to SYSTEM privileges.
The elevation of privileges through service creation could be performed with the following command:
sc create binpath= “cmd.exe /k tscon <session_id> /dest:<session_name>”
Additional tools that offer the functionality to perform RDP session hijacking are Mimikatz [6] and SharpRDPHijack [5].
Recommendations
Is there anything administrators and users can do to mitigate this risk?
There are indeed steps in the form of both configuration settings and good practices that can mitigate this risk:
- User education. Users should be made aware of the risks and be educated to close the RDP sessions by signing out or logging off instead of disconnecting or quitting. Disconnecting or quitting the session leaves a dangling-disconnected session, to which attackers can connect to.
- Apply group policy across the domain to set appropriate session limits (session time-out). The relevant configuration is located at Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits. It is good security practice to enforce expiry of inactive RDP sessions. This will reduce the number of dangling RDP sessions across the domain.
- Monitor and investigate the usage of tscon in the environment. Although a native and legitimate Windows tool system administrators may be using, attackers that want to cloak their activities and stay low, may resort to native tools. Additionally, if malicious activity is confirmed, the use of tscon would indicate attackers have already established foothold within the environment and posses account with administrative privileges. This could be a useful thread for the security team to pull and further investigate.
References
[1] https://attack.mitre.org/techniques/T1563/002/
[2] https://stmxcsr.com/tutorials/kerberoasting.html
[3] https://www.cisa.gov/uscert/ncas/alerts/aa22-294a
[4] https://www.cisa.gov/uscert/ncas/alerts/aa20-259a
[5] https://github.com/bohops/SharpRDPHijack
[6] https://github.com/gentilkiwi/mimikatz
[7] https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls
#ransomware
tags: #active directory