Remote Desktop Services Shadowing – Beyond the Shadowed Session

From time to time in certain situations one needs to have a possibility to view a customer’s user screen to make some proofed screenshots or to get access to an open GUI application window which contains secrets for lateral movement while the legitimate user is connected via RDP and you don’t want to kick them out of the session.

There is a number of third-party software such as VNC, radmin, TeamViewer, etc. on the market to achieve it, but it involves additional actions such as binary delivery, its installation and so on. Moreover, these actions are too noisy and leave a lot of garbage on a remote host.

Luckily, Windows-based systems have an awesome built-in feature (as part of Remote Desktop Protocol) that is unfairly ignored or forgotten. It is called Remote Desktop Services Shadowing.

There are two versions of the feature. Since the legacy version of Remote Desktop Services Shadowing is incompatible with the latest one and there are several articles on system administrator’s websites and forums about it, I’m not going to describe the former one widely, just a few words as a historical note.

In earlier versions of Windows, the shadow.exe file lets a user connect to a remote host using Remote Desktop Services Shadowing technique. Shortly, this is a predecessor to mstsc utility and its /shadow parameter. It was introduced in Windows Server 2003 and it is available on many versions of Windows.

In addition, there are two GUI applications and they do the same stuff: Terminal Services Manage (TSAdmin) which has been present since Windows Server 2003 and Remote Desktop Service Manager (RDSM) which is a part of Remote Server Administration Tools (RSAT) and replaces TSAdmin on Windows Server 2012.

The key difference between the versions of RDS Shadowing is that with the legacy one you must establish an RDP connection first to get a session on a remote host before you are able to shadow anybody else’s session on that host. With the latest version you can shadow a user’s session on the remote host from the console of your own host.

Now let’s get down to the latest version. Any modern Microsoft Windows version, starting from Windows 7, can be used to connect to a remote host with the session shadowing feature, but some of them require additional steps to be done and can be used only with several restrictions in cases mentioned below.

Requirements

There are three main requirements that a Windows-based system must meet to allow you to use the feature.

The first and the most essential part is Remote Desktop Protocol version. It must be 8.1 or higher. The following versions of Microsoft Windows can be used on a server side and as a client as they have RDP 8.1 out of the box:

• Windows 8.1 and later;
• Windows Server 2012 R2 and later.

Windows 7, Windows Server 2008, Windows 8, Windows Server 2012 versions don’t support this feature on the server side.

If you want to use these versions as client the first thing you do is install additional updates to update Remote Desktop Protocol version up to 8.1. After that you are able to connect to any Windows version on a remote host that supports the RDS Shadowing feature. For details see https://support.microsoft.com/en-us/help/2830477/update-for-remoteapp-and-desktop-connections-feature-is-available-for.

The next but not less important thing is that a remote host must have RDP services running.

Thirdly, besides software and service requirements, some additional changes must be made to firewall rules. The Remote Desktop Services Shadowing feature doesn’t use 3389/TCP port (RDP), it uses 445/TCP port (SMB), instead, and ephemeral ports, also known as dynamic port range (RPC).

These changes can be done by adding new custom rules or by enabling the following built-in ones:

• The first rule is called File and Printer Sharing (SMB-In), which allows to connect to port 445/TCP;
• The second one is Remote Desktop - Shadow (TCP-In). It only allows the %SystemRoot%\system32\RdpSa.exe binary to handle inbound connections on any local TCP port.

Note: the dynamic port range on Windows usually includes TCP ports from 49152 to 65535. The current value can be determined by issuing the following command:

netsh int ipv4 show dynamicport tcp

Commands qwinsta and quser described further also require the port 445/TCP to be open, otherwise you get the following error:

C:\>qwinsta /server:{ADDRESS}
Error 1722 getting sessionnames
Error [1722]:The RPC server is unavailable.

Note: in the situation when the shadowing connection seems to be successful, but a window with a shadowed session doesn’t pop up, check the firewall rules (dynamic ports must be open or Shadow rule is enabled).

Establishing a Shadowing Connection

The simplest command line string to shadow a session with a functionality built into the Remote Desktop Connection Client (mstsc) utility looks as follows:

mstsc /v:{ADDRESS} /shadow:{SESSION_ID}

where

• /v parameter lets specify the {ADDRESS} value that could be an IP address or a hostname of a remote host;
• /shadow parameter is used to specify the {SESSION_ID} value that is a shadowee’s session ID.

Note: for details on all available parameters of mstsc utility issue the command

mstsc /?

So, based on the parameters of the command above you have to know remote user’s session ID to establish a shadowing connection.

To list the existing sessions on a remote host you could use qwinsta command as follows:

qwinsta /server:{ADDRESS}

or quser command which is equivalent to the one above

quser session /server:{ADDRESS}

One interesting thing is that if a user locks their screen (Win+L) or switches to another user’s account (from a lock screen only, for details see section 5) or the UAC prompt pops up, then a window with a shadowed session automatically switches to a pause state (two parallel stripes on the screen) until the user comes back. When the user is back, the window with the shadowed session is unpaused automatically.

It should also be noted that the latest version of RDS Shadowing supports multi-monitor setup on a remote host pretty well even with a different resolution on each monitor out of the box.

Abusing the Shadow Registry Key and the NoConsentPrompt Parameter

I haven’t mentioned the Shadow registry key yet, because it doesn’t exist by default.

In this case the behavior is the same as when the key value is set to 1 (described below). In other words, a shadowee must explicitly give permission to allow their session to be shadowed.

To be able to shadow it without permission, you must intentionally override this with a group policy, for example, using GUI application called Local Group Policy Editor (gpedit.msc) set the Set rules for remote control of Remote Desktop Services user sessions policy value to allow session shadowing without user permission. It is located at Local Computer Policy → Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections.

It can also be set manually with a command line interpreter by issuing the following command:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 4

where the value of the /d parameter is one of the following:

• 0 – No remote control allowed;
• 1 – Full Control with user’s permission;
• 2 – Full Control without user’s permission;
• 3 – View Session with user’s permission;
• 4 – View Session without user’s permission.

Selecting the Not Configured value or the Disabled value deletes the Shadow registry key.

Full Control also allows to connect in the View Session mode, but to avoid a situation with the mistakenly specified /control parameter it is safer to set the Shadow value to 4.

Note: to get the current value of the Shadow key issue the following:

reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow

to remove the Shadow key type

reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /f

Defining the Shadow parameter on the remote host, it is possible to shadow a session without a user’s consent as follows:

mstsc /v:{ADDRESS} /shadow:{SESSION_ID} /noconsentprompt /prompt

where

• /v parameter lets specify the {ADDRESS} value that is an IP address or a hostname of a remote host;
• /shadow parameter is used to specify the {SESSION_ID} value that is a shadowee’s session ID;
• /noconsentprompt parameter allows to bypass a shadowee’s permission and shadow their session without their consent;
• /prompt parameter is used to specify a user’s credentials to connect to a remote host.

Another way to specify user’s credentials without having to constantly type them in the pop-up window is to use the runas command as follows:

runas /netonly /noprofile /user:{USERNAME} cmd

and in the new command line interpetator window run the mstsc utility

mstsc /v:{ADDRESS} /shadow:{SESSION_ID} /noconsentprompt

The same works for qwinsta and quser.

Sometimes you can face the following general error:

which can mean anything, but in some cases it may mean that

• the user in whose context the current command is issued doesn’t exist on a remote host;
• the specified user credentials are incorrect;
• you are trying to shadow a session to which you don’t have permissions.

This behavior is pretty much the same for qwinsta:

C:\>qwinsta /server:{ADDRESS}
Error 5 getting sessionnames
Error [5]:Access is denied.

In a workgroup environment you can use any of the local accounts if this account is also present on a remote host.

Moreover, if you are trying to shadow a session (or list sessions using qwinsta or quser) with an unprivileged user account on a remote host, then you are able to connect only to the session (to list only information about a session) related to this user.

You will get the same behavior if you’re using a non-RID 500 administrator account, but UAC remote restrictions are enabled on the remote host, more precisely it means that the LocalAccountTokenFilterPolicy registry key is set to 0 or the key doesn’t exist (by default).

In the first screenshot UAC remote restrictions are enabled and in the second one they are disabled

This is a well-known security mechanism that strips out the administrator access token when a user is connected remotely. More details are at https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction.

To disable it change the value to 1 with the following command:

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Note: to get the current value of the LocalAccountTokenFilterPolicy key, issue the following:

reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy

to remove the LocalAccountTokenFilterPolicy key type

reg delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /f

It’s important that if you are lucky and the built-in RID 500 administrator account is enabled (by default it is disabled) on the remote host you are able to shadow a session using it since the LocalAccountTokenFilterPolicy key doesn’t affect it. There is another FilterAdministratorToken registry key that might restrict this account if it is set to 1, but by default it is set to 0.

So, in a workgroup (as well as in a domain) environment a local administrator is the only local user that can access other local user’s sessions (if the LocalAccountTokenFilterPolicy and the FilterAdministratorToken registry keys are set to the appropriate values).

In a domain environment any domain administrator is able to shadow sessions of both local and domain users.

I don’t know when it might be useful, but it is possible to enumerate the existence of a session using mstsc itself by simply incrementing the {SESSION_ID} value

mstsc /v:{ADDRESS} /shadow:{SESSION_ID}

If there is no such session, then the following error occurs:

Alternatively, if a session exists, but nobody is connected to it or you have no necessary permissions you get one of the following errors:

Otherwise, you are granted permissions and a viewer’s window is opened

Abusing the StartRCM and the fDenyChildConnections Registry Keys

It’s been mentioned in the Requirements section, to successfully shadow a session the remote desktop services must be run, otherwise, the following error occurs:

The simplest way to start them all is to use a graphical user interface as follows:

or to switch the fDenyTSConnections registry key from 1 (by default) to 0 manually

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

These actions trigger some magic that does all the necessary things.

Note: to query the current value use the following command:

reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Running these services like that will start a listener on the 3389/TCP port which can be found in netstat output

Seems good, right? It is interesting that you can simply switch the fDenyTSConnections registry key back to 1

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 1 /f

then the listener is shut down and the 3389/TCP port disappears from the netstat output, but due to the fact that all the services are still running and the necessary ports (139/TCP, 445/TCP and dynamic port range) are open, you are able to shadow any user’s session.

I went a bit deeper and discovered which services were still running after I’d switched the fDenyTSConnections key from 1 to 0. Here is the list:

• Remote Desktop Services (TermService),
• Remote Desktop Configuration (SessionEnv),
• Remote Desktop Services UserMode Port Redirector (UmRdpService),
• Certificate Propagation (CertPropSvc).

but only two of them are really necessary to get RDS Shadowing working:

• Remote Desktop Services (TermService),
• Remote Desktop Configuration (SessionEnv).

Also, I figured out that the RDS Shadowing won’t work if you are trying to start these services manually and some registry keys aren’t set to the appropriate values as listed below in section 5.

Let’s see who is watching the changes to fDenyTSConnections key. The key thought here is that if there is another way to start those services we will probably be able to shadow a session independently of the fDenyTSConnections key and running the listener on 3389/TCP port.

To accomplish it, start Process Monitor and set up a filter to fDenyTSConnections and switch the key fDenyTSConnections from 1 to 0.

There are several unique stack traces of the processes that access the fDenyTSConnections key value. Two of them are the following:

In the first stack the interesting thing is that there is the CPolicyMonitor class in the lsm.dll (Local Session Manager Service) and it has two methods PolicyMonitorWorker and IsDenyTSConnectionsPolicy that monitor the changes to the fDenyTSConnections key.

The existing CRemoteConnectionManager::Start call in the second stack trace suggests that it runs Remote Connection Manager. As you can see on the following screenshot there is the StartRCM registry key which name is too similar to “Start Remote Connection Manager”.

Additionally, I found a little information about another registry key called fDenyChildConnections that is somehow related to RDP connections at https://www.guardicore.com/2017/05/the-bondnet-army/. This key doesn’t exist by default.

The fDenyChildConnections key is also present in the output of Process Monitor.

As you can see the key is monitored by the same functions we have seen in the first stack trace above, so there are some validation checks related to this key in lsm.dll.

I examined each of these registry keys and found out that both of them work as expected. Issuing the following commands independently of each other (and reverting the previous one to the default value) I successfully got shadowed connections without setting the IsDenyTSConnections to 0 and running a listener on 3389/TCP port:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v StartRCM /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyChildConnections /t REG_DWORD /d 0 /f

Persistence

It is possible to get a kind of persistence for RDS Shadowing technique.

No matter how the Remote Desktop Services (TermService) service is started, it cannot be stopped while one of the following is true:

• fDenyChildConnections is 0,
• IsDenyTSConnections is set to 0,
• StartRCM is 1.

While this is true, you get the following error every time you try to stop it:

The bad thing is that the Remote Desktop Configuration (SessionEnv) service can be stopped and if so, you will receive the following error while trying to shadow a session:

On the other hand, once the host restarts, the Remote Desktop Configuration (SessionEnv) service starts again (under the condition that one of the keys is set to an appropriate value as mentioned above). Of course, it can be started manually at any time if you have privileged access.

Moreover, as I’ve already written in section 4, only some part of RDP services must be running, thereby you might be able to stop and disable the rest of them without getting any impact on RDP functioning (in case someone decides to turn it on later) and keep RDS Shadowing working. The services are:

• Remote Desktop Services UserMode Port Redirector (UmRdpService),
• Certificate Propagation (CertPropSvc).

I didn’t do any tests with smart cards, so I have no idea how disabling the Certificate Propagation service will affect users or an operating system.

Here are several screenshots demonstrating this. What I did is that I disabled the services, turned the RDP on using GUI and successfully got an RDP connection. After that I disconnected and established a shadowing connection (the last screenshot).

In section 2 I’ve mentioned that a shadowed session will be paused if a user locks their session, but it doesn’t work if a user uses the Fast User Switching feature to switch to another account from their own session directly while it is unlocked. In this case a shadowing connection is closed and you receive the following error:

There is a way to deprive a user of this opportunity and hide the Fast User Switching interface from them by adding the following registry key (by default it doesn’t exist):

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v HideFastUserSwitching /t REG_DWORD /d 1

The negative side of this is that the feature also disappears from a lock screen, hence a user won’t be able to switch to another account until the user signs out.

RDS Shadowing on *nix

As in each and every imbalanced world there is terrible news for *nix users. This is expressed in the fact that well-known utilities, like FreeRDP and rdesktop, don’t support Remote Desktop Services Shadowing feature.

More information can be found at corresponding issue pages of these projects on GitHub:

• FreeRDP
  • Support /shadow
  • Unable to shadow a Windows 10 console user session
• rdesktop
  • Feature Request: rdesktop 1.8.4 support shadow existing RDP session