Remote Desktop Session Shadowing Mode in Windows 10

Besides Remote Assistance, you can use Remote Desktop Session Shadowing to remotely connect to the Windows 10 user’s desktop. Most administrators are using this feature to connect to user sessions on the RDS servers running Windows Server 2012 R2 / Server 2016. However, a few of them know that session shadowing can be used to remotely view and manage a user desktop console session in Windows 10 as well. Let’s see how it works.

As you remember, if you try to connect to a Windows 10 computer using RDP, the session of a user working locally is knocked out (even if you enable multiple concurrent RDP sessions in Windows 10). However, you can connect to a console user session directly without locking it.

Suppose, you want to connect from a server running Windows Server 2012 R2 to the desktop of a user working locally on a workstation running Windows 10 Pro.

In order to establish shadow connection to a user session, you must use the standard RDP tool mstsc.exe. The command looks like this:

Mstsc.exe /shadow: /v:

You can also use one of the following options:

• /prompt – request a user credentials to connect (if not specified, you will be connected with the current user credentials);
• /control – the mode that allows to interact with the user session. If the parameter is not set, you will be connected to a user session in a view mode, i. e. you won’t be able to control a user’s mouse or enter data from the keyboard;
• /noConsentPrompt – allows not to prompt the user for confirmation to connect to a session.

Remote shadowing setting is configured using a Group Policy or by registry modification. You can configure whether you need to request the user confirmation to connect, and whether view or control is allowed in the shadow session.

The policy is located in the GPO editor section Computer Configuration -> Policies -> Administrative Templates -> Windows components -> Remote Desktop Services -> Remote Session Host -> Connections and called Set rules for remote control of Remote Desktop Services user sessions.

Instead of enabling the policy, you can set the necessary value in the DWORD registry parameter Shadow in the HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services registry key. The allowed values are:

0 – disable remote control;
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.

By default, this registry parameter is not set and the shadow connection is performed in full control mode with user permissions.

To connect to a user session remotely using shadowing, the connecting account must have the administrator permissions and Remote Desktop (RDP) enabled on the Windows 10 computer (in the System Properties).

Let’s remotely request the list of sessions on Windows 10 workstation using this command:

As you can see, there is one console user session with the on this computer.

Let’s try to remotely connect to the user session 1 via a shadow connection. Run the command:

Mstsc /shadow:1 /v:10.10.11.60

The Windows 10 user will see the following request on the screen:
Remote connection request
PC\admin is requesting to view your session remotely. Do you accept the request?

If the user accepts the connection, you’ll connect to the Windows 10 console session and see the users’ desktop. You will see all user actions, but won’t be able to control this session.

If you check the network connections using TCPView, you can see that it is the RemoteRPC connection (not an RDP one using port TCP/3389). It means that a random TCP port from high RPC range is used for shadow connection. Mstsc.exe establishes the connection on the side of a connecting computer, and rdpsa.exe or rdpsaproxy.exe (depending on the Windows 10 build) processes the connection on the client side. So RemoteRPC must be enabled on the client:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server
“AllowRemoteRPC”=dword:00000001

Remote Desktop Shadowing is available in Windows 10 / 8.1 and Windows Server 2012 R2 / 2016 / 2019. To allow shadowing on Windows 7 SP1 (Windows Server 2008 R2) clients, you will need to install the RDP client version 8.1 – KB2830477 (requires installation of the following updates – KB2574819 and KB2857650).

Thus, Remote Desktop Shadowing can be used as the substitute of Remote Assistance or TeamViewer in a local or corporate network.

RDS Shadow – теневое подключение к RDP сессиям пользователей в Windows Server 2016 / 2012 R2

Mstsc.exe [/shadow:sessionID [/v:Servername] [/control] [/noConsentPrompt]]

/shadow:ID – подключится к RDP сессии с указанным ID.

/v:servername – имяRDP/RDS терминального сервера (если не задано, используется текущий).

/control – возможность взаимодействия с сеансом пользователя (если не указано, используется режим просмотра сессии пользователя).

/noConsentPrompt – не запрашивать у пользователя подтверждение на подключение к сессии.

/prompt –используется для подключения под другими учетными данными. Запрашивается имя и пароль пользователя для подключения к удаленному компьютеру.

Ограничения теневых сеансов RDS в Windows 2012 R2

• Подключаться к чужим сессиям может только администратор сервера. Делегировать эти права обычным пользователем нельзя
• RDSShadowне будет работать в сетях на базе рабочих групп

Использование Remote Desktop Shadow из графического GUI

Подключиться к сессии пользователя можно с помощью утилиты mstsc.exe или непосредственно из консоли Server Manager. Для этого в консоли Server Manager откройте коллекцию QuickSessionCollection

Щелкнув по сессии интересующего пользователя, выберите в контекстном меню Shadow (Теневая копия).

Появится окно параметров теневого подключения. Возможен просмотр (View) и управление (Control) сессией. Кроме того, можно включить опцию Prompt for user consent (Запрашивать согласие пользователя на подключение к сессии).

Если выбрана опция «Запрашивать согласие пользователя», в сессии у пользователя появится запрос:Запрос на удаленное наблюдение

Winitpro\administrator запрашивает удаленный просмотр вашего сеанса. Вы принимаете этот запрос.Winitpro\administrator is requesting to view your session remotely. Do you accept the request?

Если пользователь подтвердит, подключение, в режиме просмотра администратор увидит его рабочий стол, но не сможет взаимодействовать с ним.Совет. Для отключения от сессии пользователя и выхода из shadow-режима нужно нажать ALT+* на рабочей станции или Ctrl+* на терминальном сервере (если не заданы альтернативные комбинации).

Если же пользователь отклонит подключение, появится окно:Shadow Error: The operator or administrator has refused the request

Если попытаться подключиться к сессии пользователя без запроса подтверждения, появится ошибка, сообщающая, что такое это запрещено групповой политикой:Shadow Error: The Group Policy setting is configured to require the user’s consent. Verify the configuration of the policy settings.

Параметры удаленного управлениями RDS сессиями пользователя настраиваются политикой Set rules for remote control of Remote Desktop Services user sessions (Установить правила удаленного управления для пользовательских сеансов служб удаленных рабочих столов), которая находится в разделе Policies -> Administrative Templates -> Windows components -> Remote Desktop Services -> Remote Session Host -> Connections (Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Подключения) в пользовательской и «компьютерной» секциях GPO. Данной политике соответствует dword параметр реестра Shadow в ветке HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.

Этой политикой можно настроить следующие варианты теневого подключения через теневое подключение RD Shadow::

• No remote contol allowed — удаленное управление не разрешено (значение ключа реестра Shadow = 0);
• Full Control with users’s permission — полный контроль с разрешения пользователя (1);
• Full Control without users’s permission — полный контроль без разрешения пользователя (2);
• View Session with users’s permission – наблюдение за сеансом с разрешением пользователя (3);
• View Session without users’s permission – наблюдение за сеансом без разрешения пользователя (4).

Теневое подключение RDS Shadow из PowerShell

Воспользоваться функционалом теневого подключения к сессии пользователя через теневое подключение Remote Desktop Services можно и из Powershell.

В первую очередь покажем, как получить список сессий на терминальном сервере (сессии пользователей будут сгруппированы в группы в зависимости от их статуса):

На данном сервере мы обнаружили три активных терминальных сессии. Подключимся к сессии пользователя с ID сессии 3:
Mstsc /shadow:3 /control
Также для получения списка всех сессии на сервере можно выполнить команду

На экране отобразится список RDP сессий, их ID и статус: активная сесиия (Active) или отключенная (Disconnected).

Для получения списка сессий на удалённом сервере выполните команду:

query session /server:servername

Для более удобного теневого подключения к сессиям можно использовать следующий скрипт. Скрипт предложит ввести имя удаленного компьютера и выведет список всех сеансов и предложит указать сеанс, к которому нужно подключится:

shadow.bat

@echo off
set /P rcomp=»Enter name or IP of a Remote PC: «
query session /server:%rcomp%
set /P rid=»Enter RDP user ID: «
start mstsc /shadow:%rid% /v:%rcomp% /control

Можно поместить данный файл в каталог %Windir%\System32, в результате для теневого подключения достаточно выполнить команду shadow.

Для подключения к консольной сессии можно использовать такой скрипт:

@echo off
set /P rcomp=»Enter name or IP of a Remote PC: «
for /f «tokens=3 delims= » %%G in (‘query session console /server:%rcomp%’) do set rid=%%G
start mstsc /shadow:%rid% /v:%rcomp% /control

Как разрешить обычном пользователям использовать теневое подключение

В рассмотренных выше примерах для использования теневого подключения к терминальным сессиям необходимы права локального администратора на RDS сервере. Однако можно разрешить использовать теневое (shadow) подключение для подключения к сессиям пользователей и простым пользователям (не давая им прав локального администратора на сервере).

К примеру, вы хотите разрешить членам группы AllowRDSShadow использовать теневое подключение к сессиям пользователей, выполните команду:

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName=’RDP-Tcp’) CALL AddAccount ‘corp\AllowRDSShadow’,2

В январе 2018 года после установки обновления KB4056898 (патч Windows против Meltdown и Spectre) пользователи столкнулись, что в Windows Server 2012 R2 перестал работать теневой доступ. При попытке выполнить теневое подключение к чужой сессии появляется сообщение «Неопознанная ошибка» (в логах присутствует ошибка STATUS_BAD_IMPERSONATION_LEVEL). Аналогичная проблема возникала и на RDS ферме на базе Windows Server 2016.

Для решения проблемы нужно установить отдельные обновления:

• для Windows Server 2016 — KB4057142 (от 17 января 2018)
• для Windows Server 2012 R2 — KB4057401 (от 17 января 2018)

Remote Desktop Services Shadowing – Beyond the Shadowed Session

Author

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:

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

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:

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

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

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:

or quser command which is equivalent to the one above

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.

A shadowed session is in a pause state

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.

A multiple monitor support

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.

The Shadow key 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.

The policy setting window of the Local Group Policy Editor management console

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

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:

to remove the Shadow key type

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

• /v parameter lets specify the
  value that is an IP address or a hostname of a remote host;
• /shadow parameter is used to specify the 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:

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

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 :

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

The qwinsta command output while UAC remote restrictions are enabled The qwinsta command output while UAC remote restrictions 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:

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

to remove the LocalAccountTokenFilterPolicy key type

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 value

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

The session you’re trying to connect to doesn’t exist

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

The session exists, but nobody is connected to it Not enough permissions to shadow a session

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

A successfully established shadowing connection

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 version of Windows running on this server does not support user shadowing

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

Allowing remote connections from a GUI window

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

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

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

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

A listener on the 3389/TCP port

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

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.

An established shadowed connection

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.

The list of processes that access the fDenyTSConnections key value

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

The first stack trace of the svchost process that reads the fDenyTSConnections key value The second stack trace of the svchost process that reads the fDenyTSConnections key value

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.

Information related to the fDenyChildConnections key

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:

An established shadowing connection while the StartRCM key is set to 1 An established shadowing connection while the fDenyChildConnections key is set to 0 The netstat command output without a listener on the 3389/TCP port

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:

The interface is unknown

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).

The Remote Desktop Services and the Remote Desktop Configuration services status Establishing an RDP connection A successfully established RDP connection A successfully established shadowing connection

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):

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: