One of the new security features in the latest Windows release (Windows 8.1) is the “Restricted Admin mode for Remote Desktop Connection”. This measure is meant to enhance Windows credential protection against attacks such as Pass-the-Hash and Pass-the-Ticket. However, it appears that cure might be worse than the disease as the new “Restricted Admin mode” opens a new attack surface for the very same attacks it was meant to protect against. Ultimately, this feature enables attackers to perform Pass-the-Hash and Pass-the-Ticket attacks by connecting to targeted machines via a Remote Desktop Protocol (RDP) connection.

Using RDP Restricted Admin with Pass-the-Hash attack

The fact that the “Restricted Admin mode” is ironically vulnerable to the very same attacks it was supposed to mitigate against had already been published a few months ago. However, our analysis provides insights on the technical details that allowed this vulnerability, and more importantly, explains why it is not a mere “software glitch” that can be solved with a patch, but rather a security tradeoff inherent to Windows’ authentication model.

What is 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. On the one end, the user employs RDP client software, while the other end must run RDP server software. Both the RDP client and server software are included in Windows distributions, so no additional installation step is required.

RDP aims to provide the remote user the same “look and feel” of a local user on the console but over a network connection. Therefore, an RDP session starts exactly like a local session – with a logon process. Before we delve into the details of the RDP’s logon process, it’s important to be familiar with the two main types of logons on a Windows based domain: Interactive and Network logon.

Interactive vs Network Logon: The Inherent Security Tradeoff

As its name implies, the Interactive Domain Logon works in an interactive mode between the user and the device, in the following manner:

1. The user inputs their credentials to the intended machine, for example by typing their username and password in the machine’s User Interface.
2. The machine checks the validity of the credentials against the Domain Controller using one of Windows supported protocols (Kerberos by default, or NTLM when Kerberos is not available).
3. In the case that the Domain Controller approves the user’s identity, and the user is authorized to access the machine, then the user is granted access to the machine. Consequently, a Single Sign On (SSO) token is stored on that machine.

The exact nature of the SSO token depends on the authentication protocol, thus it can be either a Kerberos TGT ticket or an NTLM hash. The SSO token enables the user to gain access to all authorized network resources without additional authentication. In fact, the SSO token then rides on top of the Network Domain Logon process.

The Network Domain Logon works in the following manner:

1. An SSO token derivative (a Kerberos TGS ticket or a challenge encrypted with the NTLM hash) is used to prove the user’s identity to the target machine.
2. The target machine uses the Domain Controller to validate the authenticity of the SSO derivative and to receive authorization data for the user.  It’s important to note that the SSO token itself does not leave the user’s machine and specifically, it is not sent to the target machine.

The first logon to the machine must be an Interactive Logon. For various other tasks, either of the logon processes can be used. For example, in order to view a picture stored on a remote machine, the user can either perform a Network Logon and connect to a network file share; or physically walk over to the target machine, perform an Interactive Logon and view the picture locally.

Since some tasks can be done with either of the mentioned logon processes, it makes sense to find out which one is better from the security perspective.

• From the client’s security perspective, Network Logon is preferred. The reason is that when the user logons with an Interactive Logon their password and the generated SSO token is exposed to the target machine. Thus, if that target machine is compromised, then that attacker is able to use the SSO token to steal the user’s identity and propagate throughout the network by abusing the user’s privileges. Therefore, Network Logon reduces the user’s exposure to Pass-the-Hash and Pass-the-Ticket attacks.
• From the server’s security perspective, Interactive Logon is better. The reason is that it provides a stronger proof of the user’s identity since the user’s credentials are used – not some derivative of its token. Taking it to the extreme, a server that only allows Interactive Logons is not exposed to access by stolen SSO tokens, thus making it invulnerable to Pass-the-Hash and Pass-the-Ticket attacks.

As shown, enabling Network Login for a service is a double edged sword. On the one hand it protects the connected user identity from a compromised service, but on the other hand, it exposes the very same service to the abuse of compromised users’ identities.

Remote Desktop Authentication and “Restricted Admin”

Let’s return now to RDP’s logon. Prior to Windows 8.1, the only way to authenticate to the RDP service was with the Remote Interactive Logon Process. This “old” process works accordingly:

1. The user submits their credentials to the RDP client.
2. The RDP client performs a Network Logon to the target machine to ensure that the user is permitted to access the target machine.
3. Once the user is authorized, the RDP client securely relays the credentials to the target machine over an encrypted channel.
4. The target machine uses these credentials to perform an Interactive Logon on behalf of the remote user.

Just over half a year ago, the “Restricted Admin mode for Remote Desktop Connection” security enhancement for Windows Server 2012 R2 and Windows 8.1 was announced: “new credential protection and domain authentication controls have been added to address credential theft. The Remote Desktop Services (RDS) client can connect in Restricted Admin mode. Using this mode with administrator credentials, RDS attempts to interactively logon to a host that also supports this mode without sending credentials… Restricted Admin mode does not at any point send plain text or other re-usable forms of credentials to remote computers.”

In other words, this enhancement is enabled only when the user explicitly specifies “Restricted Admin” mode in their RDP command to prevent their credentials from being sent to the target machine during an Interactive Logon. Using this mode, the credentials are sent only in the Network Logon scenario.

Remember the inherent tradeoff of enabling Network Logon? It is now clear that although this enhancement may help users that are aware of this feature to protect their identity when they connect to a potentially infected machine over RDP, it now enables Pass-the-Hash and Pass-the-Ticket attacks in order to RDP to various machines across the network.

While this tradeoff seems to have escaped the eye of Windows programmers, it was not missed by the security community (and probably malicious hackers…). The picture in the introduction to this blog post depicts the reproduction in Aorato’s lab for the utilization of a stolen NTLM hash to achieve RDP access to another machine (10.0.0.4) with the Mimikatz pen test tool.

To add insult to injury, RDP’s Restricted Admin “Security enhancement/setback” is supported by default and Windows does not provide a simple way to remove it. It seems that currently “Restricted Admin” is more useful for attackers – after all, they are aware of it. Unfortunately, since less security-savvy individuals are not aware of this mode, they ultimately cannot benefit from its security advantages. 

Update (July 13, 2014): Following the security community’s criticism, a recent (July 8, 2014) Windows update disables RDP Restricted Admin feature by default and it can be enabled with a registry flag:  ”The default behavior for Restricted Admin mode changed in Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1. By default, Restricted Admin mode is now turned off, and you have to enable it again after you install update 2973351 or 2975625 if it is required. Previously, Restricted Admin mode was turned on by default. ”