RDP hijacking attacks explained, and how to mitigate them

RDP hijacking definition

One means of compromising systems cherished by malware authors is Remote Desktop Protocol (RDP). It provides a convenient way for system administrators to manage Windows systems and help users with troubleshooting an issue. 

RDP hijacking attacks often exploit legitimate features of the RDP service rather than purely relying on a vulnerability or password phishing. In fact, the WannaCry ransomware is known to enumerate remote desktop sessions in an attempt to hijack RDP sessions and execute malware on each session.

RDP hijacking attacks involve the attacker “resuming” a previously disconnected RDP session. This allows the attacker to get into a privileged system without having to steal the user’s credentials. For example, if an administrator remoted into a Windows Server machine a few days ago, it is much easier for the attacker to “resume” this very session, rather than attempting to obtain the administrator account’s password via social engineering.

Once in the system, the attacker can gain lateral movement across the enterprise network while remaining undetected, because to an event monitor, they are effectively acting as the authorized user whose session they have hijacked.

Why RDP hijacking attacks are dangerous

RDP hijacking is nothing novel. Rather than being a vulnerability, it is a decades-old “technique” that exploits a legitimate feature of the Windows RDP service. Given how a vast majority of enterprise networks connect Windows and Windows Server systems, with sysadmins using RDP, it is vital to be aware of the risks and behavior of the RDP service.

Moreover, increasing work-from-home arrangements have meant a greater reliance on remote administration and management tools like RDP, which now form a part of the attack surface for malicious actors.

RDP hijacking proof-of-concept

There are multiple ways to resume an RDP session. The technique was originally discovered in 2011 by Benjamin Delpy, the author of the pen-testing utility mimikatz. In 2017, Alexander Korznikov demonstrated how the same technique can be used for privilege escalation on later versions of Windows machines. 

Passwordless hijacking

Let’s focus on the RDP hijacking technique leveraging the Tscon.exe utility, which comes with Windows. It enables a user to connect to a different remote desktop session on a system or switch between different sessions.

The syntax for the command is simple, with the Microsoft Knowledge Base explaining in detail what each parameter entails:

tscon { | } [/dest:] [/password: | /password:*] [/v]

The simplest example would be tscon 2. Running such a command on a server hosting the remote desktop session would connect the user to session with ID 2 and disconnect any existing sessions they are on. 

The Microsoft Knowledge Base warns though, “If a remotely owned console session is sent to the physical console of the computer by the use of Tscon.exe, the session is left unlocked. Because of this behavior, you have to be careful when you use Tscon.exe so that you do not leave a previously locked server in an unlocked state.”

CSO / IDG

To exploit hijacking another session, the attacker needs to be connected to the RDP host. Therefore, this trick requires some prior level of access. While an attacker could be an insider (unless they are using a compromised account of an employee), the seriousness of this technique lies in the fact it can form a part of a sophisticated, chained advanced persistent threat (APT) attack.

Compromising one system, such as via malware, can enable an attacker to exploit this RDP technique to reach into other users’ sessions and environments, without requiring a password. Suppose the attacker at client 3 logs into the RDP server and is able to see all connected RDP users by simply running the command: query user. The attacker can then execute the following commands in the command prompt:

sc create hijackedsession binpath= “cmd.exe /k tscon 1 /dest:rdp-tcp#2”

net start hijackedsession This will disconnect the current session of the attacker (ID 2) and “resume” the previously disconnected session 1 between the attacker and the RDP server without asking for a password (that was used by client 2) or leaving much of a forensic trace.

This is because while the user previously present at client 2 may have disconnected their RDP session, they did not explicitly log off from the server.

To automate the process, Rishabh Sharma of Network Intelligence has provided a simple batch script pen-testers can incorporate in their toolkits, along with explaining the above steps in detail. In a real-world scenario it could be the attacker incorporating such automated scripts in their malware programs, like the group behind WannaCry did.

The common denominator between all the accounts is the user “SYSTEM.” If Tscon.exe can be run as SYSTEM, it can switch between different user sessions in a credential-less manner.

“Now, you might be saying, ‘If you’re SYSTEM, you’re already root… You can already do anything.’ Yes, you can. You could, for example, dump out the server memory and get user passwords. That’s a long process compared to just running Tscon.exe with a session number, and instantly [getting] the desktop of said user — with no obvious trace, or external tools. This isn’t about SYSTEM — this is about what you can do with it very quickly, and quietly,” explained cybersecurity expert Kevin Beaumont in a blog post.

“Attackers aren’t interested in playing, they’re interested in what they can do with techniques. This is a very valid technique. So, you have full blown RDP session hijacking, with a single command,” Beaumont continued.

Recently, a security researcher and pen-tester who prefers to go by the pseudonym Bohops also released his own open-source .NET implementation of a RDP hijacking utility called SharpRDPHijack. He has tested the tool on Windows Server 2019 machines for achieving credential-less hijacking.

“Has anyone tried to test disconnected RDP session hijacking in Windows Server Server 2019? When connecting to a session that is redirected back to an active RDP session, there is now a prompt for the target [credentials]. If redirected to the console session, there is no additional [authentication required],” said Bohops in a tweet. 

When asked as to what was his motivation behind creating yet another RDP Hijacking tool, the researcher stated, “All things considered, this is just (yet) another implementation. I wanted to make it easier to switch between sessions without the noise of mimikatz and tscon.”

The researcher further explained, “The credential-less part is achievable when impersonating the NT AUTHORITYSYSTEM context, [such as having SharpRDPHijack or Mimikatz do this] or launching a command (tscon.exe) as NT AUTHORITYSYSTEM with another program such as PSexec, a service, or a scheduled task. To successfully switch to another RDP session, effectively, the tester must have positive control over a highly privileged account on a machine, and there must be multiple sessions connected to the machine.” 

How to detect and prevent RDP hijacking

Due to the nature of RDP protocol and the behavior exploited by this technique, monitoring for an RDP hijacking attack is difficult because, to forensic tools, the activity looks as if a legitimate, authorized remote user was accessing the system. The decades-old technique continues to impact almost every Windows Server version, so advice to upgrade to a different Windows OS version isn’t quite reassuring. The recommended prevention techniques aimed at preventing RDP Hijacking are: 

1. Enforce Group Policy: Instead of leaving “disconnected” remote desktop sessions in dormant state for long, Group Policy settings should be changed to log off users either instantly or shortly after they have disconnected an RDP session. This will prevent an attacker from simply “resuming” a session in a credential-less manner.
2. Mind the exposure: It doesn’t make sense to blatantly expose RDP services and ports to the internet. However, restricting RDP heavily hampers its very purpose: remote administration. Beaumont suggests using Microsoft Remote Desktop Gateway or Azure Multi-Factor Authentication Server, should access over the internet be desired. Ignoring such advice can lead to devastating consequences, according to the researcher. “You can use things like Microsoft RD Gateway or Azure Multi-Factor Authentication Server to get very low-cost multi-factor authentication. If you’re exposing RDP directly to the internet and somebody creates a local user or your domain users have easy to guess or reused credentials, things will go downhill fast. Trust me — I’ve seen hospitals and others be ransomware’d [sic] by RDS servers,” stated Beaumont on his blog. 

Preventing the possibility of rogue RDP sessions and hijacking remains a challenge in many Windows-centric IT environments, but it is a step not to be taken lightly. Stealthy malware creators exploit these fundamental techniques to evade detection across corporate environments.