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 to other systems within an Active Directory environment. It involves the abuse of RDP sessions. More sophisticated threat actors target disconnected/abandoned - or in other words dangling - RDP sessions that may be running on hosts. Bottom line is that it allows attackers connect to other users’ RDP sessions without attackers knowing the password of the target 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 can be compromised. With the hijacked RDP sessions, the attacker elevates their priviliges in the domain and install ransomware on critical infrastructure at scale.

Public reporting indicates that this technique has been 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 as well as additional factors.

The post is divided in the following sections:

• Concurrent RDP Sessions
• Dangling RDP Session Example
• Exploitation Requirements
• Threat Hunting Opportunities
  • Monitor tscon Process Events
  • Services
  • Scheduled Tasks
• Mitigation Recommendations
  • User Education
  • RDP Session Lifetime
  • Separate Administrative Workstations
• References

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.

Alternatively, the Windows task manager as well as the native Windows utility quser can be used to list user sessions on a host locally.

Nothing of concern thus far. The next section though, shows which condition can be exploited by attackers.

Dangling RDP Session Example

For the sake of this post, user jack.jones is a member of the group “Domain Admins”. This membership provides 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 a user closes the RDP window and disconnects, 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(also known as hijack) 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:

1. Administrator level privileges on the host
2. SYSTEM level privileges on the host

The second requirement is actually a byproduct of the first and can be easily achieved, provided the first is met.

To connect to a dangling RDP session an attacker could use the native Windows utility tscon. This utility allows a user to attach a session to a remote desktop session. Since the utility is a native tool, it allows attackers to use living-off-the-land techniques, blending in with normal system administration and thereby avoid external, signature-detectable tooling.

Once an attacker has connected using an account with Administrator privileges, they can escalate to SYSTEM privileges using a tool such as PsExec from Sysinternals. They could also configure a service to run tscon with SYSTEM privileges or create a scheduled task to execute tscon with the highest privileges under the target user’s context.

In line with the images provided above, an attacker would need to run the command listed below to connect to the Administrator’s session:

tscon 2 /DEST:rdp-tcp#3

tscon also accepts the password of a user (/PASSWORD:), which removes the requirement of SYSTEM privileges. 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>"

The elevation of privileges through scheduled task creation could be performed by registering a scheduled task to run with the highest privileges, under the context of the user account whose RDP session the attacker wants to hijack. The scheduled task would then need to be configured to run the following action:

tscon <SESSION_ID> /dest:<SESSION_NAME>

Additional tools that offer the functionality to perform RDP session hijacking are Mimikatz [6] and SharpRDPHijack [5].

To summarize, an attacker with local Administrator privileges on a host that has dangling RDP sessions, can hijack these sessions in many different ways including:

• PsExec to escalate privileges locally and run tscon
• Service configuration to run tscon
• Scheduled Task configuration to run with highest permissions under the context of the target user tscon

Threat Hunting Opportunities

Monitor tscon Process Events

Monitor and investigate the usage of tscon in the environment, especially when it is running with SYSTEM privileges. Although tscon is a native and legitimate Windows tool that system administrators may be using, attackers that want to cloak their activities and stay under the radar, may resort to native tools.

Furthermore, if malicious activity is confirmed, the use of tscon would indicate that attackers have already established foothold within the environment and posses account(s) with administrative privileges. This could be a useful thread for the security team to pull and further investigate.

Services

Perform searches across Windows hosts for services configured to execute the binary tscon.exe.

Scheduled Tasks

Perform searches across Windows hosts for scheduled tasks configured to execute the binary tscon.exe.

Mitigation Recommendations

Is there anything administrators and users can do to mitigate this risk?

There are indeed steps in the form of both configuration settings (hardening) 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.

RDP Session Lifetime

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 reduces the number of dangling RDP sessions across the domain.

Separate Administrative Workstations

Privileged accounts, such as Domain Administrators, must use dedicated administrative hosts - Privileged Access Workstations - for all administrative tasks. These hosts must not be accessible to standard users via RDP or other remote access methods. Overall, privileged accounts must not log on to systems used by standard or non domain-administrative users.

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

[8] https://doublepulsar.com/rdp-hijacking-how-to-hijack-rds-and-remoteapp-sessions-transparently-to-move-through-an-da2a1e73a5f6

#ransomware