BlueTeam, Information Security, RDP, TLS

Hardening Microsoft Remote Desktop Services (RDS)

As systems administrators we are often tasked with implementing countermeasures to mitigate risks that we can’t completely address. The intent of this post is to cover methods of reducing the risk presented by having Remote Desktop Services (formerly Terminal Services) available on the network.

The risks that I will cover are:

  • Man in the Middle attacks
  • Sniffing / Traffic capture
  • Brute Force Attacks
  • Information Disclosure


Man in the Middle (MitM) attacks

The essential premise here is that an attacker, via a couple methods, can cause RDP traffic to flow through a host he controls. This allows the attacker to view the traffic [1]  and in some cases manipulate it to reduce the security level negotiated between the server and client.

Sniffing / Traffic capture

An attacker does not necessarily need to be a part of client/server communications in order to see traffic. There are a variety of techniques that allow an attacker to record the network traffic at the client, server, or on the network. Even if this traffic is encrypted with TLS there are methods of leveraging compromised TLS (x.509) certificates to perform offline attacks against the packet capture [2].

Brute Force Attacks

There are multiple tools such as Hydra [3] and ncrack that will attempt to try combinations of usernames and passwords in an effort to determine valid credentials. These attacks, while typically very noisy, can be very fast and effective. They have the downside of potentially causing a denial of service as well. This is due to the target RDS server allocating resources for the user before they log in.  It is not unusual to see a poorly crafted brute force attack consume 100% of the target’s CPU by trying to attempt too many connections simultaneously.

Information Disclosure

Unauthenticated RDP connections to servers can expose sensitive information about the target environment. Usernames, domain names, and potentially other hosts of interest to the attacker can be displayed after the connection.  The screen shot on the right below ( click to enlarge) shows that the user logged in as Administrator is connected from WinServer01.   Management servers and workstations are often a treasure trove of credentials and typically have more access to bypass firewalls than most other hosts.

Rdesktop_userlist Rdesktop_AdminMachine



The good news is that mitigating these risks can be done by changing 3 settings. The changes are compatible with every supported Microsoft operating system and many 3rd party RDP clients.  The settings can be changed via GUI, PowerShell, and Group Policy.

Set the Security Layer to SSL (TLS 1.0)

This setting requires the use of TLS 1.0 or higher encryption to protect the session as opposed to the legacy RDP encryption.  In addition to increasing the strength of the encryption, it also enables the detection of MitM attacks by requiring the server to present a TLS (x.509) certificate as proof of identity.  Ideally every server would have a certificate issued from a trusted authority but even when using self-signed certificates this can allow observant users to detect MitM after the first connection.  If both the client and the server support and require the use of TLS cipher suites that provide Forward Secrecy (ECDHE, DHE) then sniffed RDP sessions cannot be decrypted after the fact even if the RDP Server’s TLS certificate is compromised.   Further, any efforts spent hardening the TLS configuration of the server or client will result in better security for their RDP sessions.

In the right environment, this setting will completely mitigate MitM and sniffing risks.  It also provides the benefit of being able to assure stake holders and interested 3rd parties such as customers and auditors that their traffic is being protected using well known and widely accepted encryption.

Enable Network Level Authentication (NLA)

Network Level Authentication requires a user connecting via RDP to authenticate before a session is allowed to be established to a server. It can leverage Kerberos, NTLM, and PKI for authentication when those technologies are available.  Additionally, due to its use of the Microsoft CredSSP protocol, all of the traffic during the session is sent over TLS 1.0 or higher.  This effectively enforces the Security Layer setting discussed above and all that it entails.

The  use of NLA completely mitigates the Information Disclosure issue as described above, and currently breaks all of the popular RDP brute force tools.

NLA is enabled by default in Windows 2012 R2.

Set the Encryption Level to High

By default, Windows allows the server and client to negotiate the encryption level.  Setting Encryption Level to ‘High’  requires that at least 128 bit encryption is used or the server will not allow the client to connect.  Depending on the requirements of the environment, Encryption Level can be set to FIPS instead.  This setting doesn’t directly address one of the risks above but may make it more resilient to unforeseen downgrade attacks against the deployed cryptography.


The settings can be deployed to the environment in a couple of ways.


On Windows 2008  and 2008 R2 the values can be change via the GUI by going to Start,  Administrative Tools, Remote Desktop Services, and then clicking Remote Desktop Session Host Configuration.  Under Connections, right click on RDP-tcp and click Properties. All of the settings covered above can be configured on the General tab of the resulting window. Once the desired settings are in place, click Apply.  This change takes effect immediately but does not affect any sessions currently connected.  This will allow the new settings to be reverted easily if testing shows that they cause problems.


On Windows 2012 Microsoft has changed the GUI so as to not provide this level of control.  As NLA is enabled  by default on 2012 this is less of an issue than it would be on 2008 R2.


The PowerShell code snippet below will configure all three settings discussed above.  It requires local Administrative rights and is known to work on Windows 2008 R2 and 2012 R2. Information on the values can be found in References [5] [6] and [7] at the bottom of this blog entry.

# Remote Desktop Services: Enable NLA Requirement
(Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").UserAuthenticationRequired
(Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").SetUserAuthenticationRequired(1)

# Remote Desktop Services: Require 'High' level of encryption
(Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").SetEncryptionLevel(3)

# Remote Desktop Services: Set Security Layer to SSL
(Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").SetSecurityLayer(2)

# References
# .SetUserAuthenticationRequired(1) -
# .SetEncryptionLevel(3) -
# .SetSecurityLayer(2) -

Group Policy

The previous two options are good for testing and non-Active Directory joined systems but will not scale usefully.   Deployment in Active Directory environments can be performed using Group Policy.  I recommend creating a GPO just for these settings so that they can be deployed for testing or in stages.  All of the relevant settings can be found under Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security.



Potential Issues

There are a couple of concerns to be aware of.  First, for those in the unfortunate position to still have to support Windows XP clients there are some steps you need to take.

  1. Upgrade to Service Pack 3
  2. Enable CredSSP on Windows XP Service Pack 3 [8]
  3. Install Remote Desktop Client 7.0 (last to support Windows XP) [9]

Second, always be aware that the risks in any environment are dynamic even if there are no changes to the configuration or software.  NLA defeats brute force attempts today, but this may change tomorrow if Hydra is updated to support CredSSP.  Like any other control, implement it if it is appropriate, test it to make sure it’s working,  assume it will be insufficient without warning at some future date, and layer it with other controls and detection mechanisms.

Further Reading

There are quite a few resources that cover this topic and I will link to many of them in the references section below.  For those of you wishing to implement these settings in conjunction with an internal PKI I strongly recommend Carlos Perez’s blog post from 2012 titled Configuring Network Level Authentication for RDP and a post from 2015 titled RDP TLS Certificate Deployment Using GPO. I wish that I had been aware of them when I was implementing this in my environments.  Also, the Microsoft Remote Desktop Services Blog has an article from 2008 titled Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks that discusses NLA in conjunction with Kerberos and NTLM.

– Tom



1. Portcullis Labs – SSL “Man-In-The-Middle” attacks on RDP example:

2. Portcullis Labs – Retrospective decryption of SSL-encrypted RDP sessions:

3. THC Hydra:

4. TechNet – Configure Security Settings for Remote Desktop Services Connections :

5.  Developer Network: SetEncryptionLevel method of the Win32_TSGeneralSetting class:

6. Developer Network: SetSecurityLayer method of the Win32_TSGeneralSetting class:

7. Developer Network:  SetUserAuthenticationRequired method of the Win32_TSGeneralSetting class:

8.  Microsoft Support – Enabling CredSSP on Windows XP SP 3 –

9. - Remote Desktop Client 7.0 (last to support Windows XP SP3 ):

9. TechNet – Configure Network Level Authentication for Remote Desktop Services Connections:

10. TechNet – Secure RDS (Remote Desktop Services) Connections with SSL:

11. Developer Network – [MS-RDPBCGR]: Remote Desktop Protocol: Basic Connectivity and Graphics Remoting:

12. Developer Network – [MS-CSSP]: Credential Security Support Provider (CredSSP) Protocol:

13. Remote Desktop Service Blog – Configuring Terminal Servers for Server Authentication to Prevent “Man in the Middle” Attacks:

14.  Carlos Perez ( DarkOperator) – Configuring Network Level Authentication for RDP:

15.  Carlos Perez ( DarkOperator) – RDP TLS Certificate Deployment Using GPO:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s