When accessing a remote server, there is always a risk that it could be compromised. For users with administrative privileges, it is especially important to establish a secure connection to the Remote Desktop Protocol (RDP) service to avoid becoming a victim of credential theft or impersonation. There are several ways to do this in Windows. In this blog post, we’ll look at some of them, their advantages, and their disadvantages.

What’s the big deal?

If a server is compromised, there are several security issues related to Remote Desktop Protocol (RDP) sessions:

Credential Dumping: By default, LSASS stores remote user credentials in the server’s memory. These credentials can be extracted and used in pass-the-hash attacks or cracking attempts.

Token/ticket impersonation: Remote users have open sessions with the server. Session tokens or Kerberos tickets can be (mis)used to impersonate the logged-in user and access network resources in their name.

Session hijacking: Existing RDP sessions can be taken over completely by an attacker. By hijacking the session, the attacker can effectively control the user’s desktop environment, access sensitive information and perform malicious activities.

Pass the Hash: PtH against the RDP service is disabled by default. If enabled, acquired hashes can be reused to connect to (other) RDP services. To use Remote Credential Guard or Restricted Admin Mode, the possibility for PtH against the RDP service must be enabled. More on this later.

About Session Hijacking

Has anyone tried to test disconnected RDP session hijacking in Windows Server Server 2019? When connecting to a session that is redirected back to an active RDP session, there is now a prompt for the target cred. If redirected to the console session, there is no additional auth.

— bohops (@bohops) July 6, 2020

In Windows 2019+ environments, RDP session hijacking from non-“console” sessions is no longer effective. Hijacking a session now requires the user’s password. However, if an attacker has access to the “console” session, hijacking is still possible. It’s worth noting that gaining a “console” session via RDP has not been possible since Windows 2008+.

Although there are some tweets suggesting a potential workaround for Windows 2019, the validity of these claims remains unproven at this time.

Microsoft’s solutions

Microsoft provides several tools to mitigate or at least reduce the possibility for lateral movement when using RDP:

• Restricted Admin Mode
• Remote Credential Guard
• Local Admin Password Solution (LAPS)
• Protected Users group

Restricted Admin Mode and Remote Credential Guard

Restricted Admin Mode is a security feature introduced in Windows Server 2012 and Windows 8.1. When using restricted admin mode, the administrator’s credentials are not passed to the remote system. Although the logon session is associated with the administrator’s user account, the cached credentials and stored TGTs belong to the machine account of the connected system. Therefore, an attacker with system privileges cannot obtain additional credentials.

Introduced in Windows 10, version 1607, Windows Defender Remote Credential Guard protects credentials over a Remote Desktop connection by redirecting Kerberos requests back to the device that initiated the RDP session. This enables SSO functionality while the remote desktop connection is alive. SSO in this context means that a user can connect to network resources without having to re-enter their credentials. For example, accessing a file share.

How to enable Restricted Admin Mode and Remote Credential Guard?

A GPO exist to enable these features on the server. It can be found under:

Administrative Templates (Computers) > System > Credentials Delegation > Remote host allows delegation of non-exportable credentials

Note that this GPO changes the AllowProtectedCreds key under Software\Policiess\Microsoft\Windows\CredentialsDelegation. There exist another key DisableRestrictedAdmin under HKLM\System\CurrentControlSet\Control\Lsa that takes precedence over the former.

How to enforce Restricted Admin Mode or Remote Credential Guard?

As we assume the server to be compromised, it makes only sense to enforce these security features on the clients. To this end, the following GPO should be configured on every workstation which is used for RDP connections:

Administrative Templates (Computers) > System > Credentials Delegation > Restrict delegation of credentials to remote servers

It can be configured to allow only Restricted Admin Mode (1), only Remote Credential Guard (2) or both (3).

How to use

Once enabled, both features are very easy to use. If you enforce it on the client you are good to go. If you want to try it without enforcement on the client simply use the appropriate flag when running the Remote Desktop client.

mstsc.exe /restrictedadmin

mstsc.exe /remoteguard

Caveats

Allowing for PtH against the RDP Service

By default, pass-the-hash attacks are not possible against the RDP service:

As mentioned above, in order to use Restricted Admin Mode or Remote Credential Guard, some registry keys are needed to be set on the server (manually or by GPO). Unfortunately, this allows for pass-the-hash attacks against the RDP service. That is, an attacker who obtains an NTLM hash of an authorized RDP user, can connect to the RDP session without knowing the actual password.

Restricted Admin Mode

As the name implies, Restricted Admin Mode is available only to users with local Admin access to the server. Since all cached credentials and TGTs belong to the machine account, it is not possible to use any SSO features to connect to other resources on the network as the user.

Remote Credential Guard

Remote Credential Guard uses the established RDP session from the workstation to request new Kerberos service tickets. This means that no new Kerberos service tickets can be requested if the RDP session is terminated. However, as long as the RDP session is active, an attacker on the same server can request new Kerberos service tickets on behalf of the user. In addition, service tickets requested by the user remain in memory and can be extracted and used by the attacker. By default, these service tickets are valid for 10 hours. Thus, even if the window of opportunity is small, an attacker can still gain access to the user’s resources. For this reason, it is recommended that you also set a short time limit for idle sessions to further reduce the window of opportunity.

Local Admin Password Solution (LAPS)

LAPS helps manage the local administrator account passwords on Windows computers. It automatically generates and manages unique passwords for the local administrator account on each computer in a domain.

If an administrator uses the server’s local administrator account to connect to the server via RDP, an attacker can extract the local administrator’s credentials, but because the password is unique to that system, no further lateral movement or privilege escalation is possible.

How to enable it?

Depending on your setup, you may want to use the old Microsoft LAPS or the new Windows LAPS. As there are a lot of good resource on the internet on how to set this up, we won’t go into details here.

Caveats

LAPS implies local admin access to the server, this cannot be given to standard users. This feature also does prevent any SSO feature since the administrator is logged on to the system as the local admin, similar to the Restricted Admin Mode. In addition, permissions must be set to retrieve such LAPS-managed passwords. A clear concept is therefore required beforehand.

Protected Users Group

The Protected Users group is a security group introduced in Windows Server 2012 R2 and Windows 8.1.

When users are added to this group, the following restrictions apply:

• NTLM authentication is disallowed 🎉
• Strong Kerberos encryption is enforced (no DES or RC4)
• Users cannot be delegated in unconstrained or constrained delegation scenarios
• Kerberos TGTs cannot be renewed beyond the initial four-hour lifetime
• Credential delegation (CredSSP) will not cache the user’s plain text credentials

By adding the user to the Protected Users group, credentials are no longer cached when the user connects to an RDP service.

How to enable it?

This is a default feature of the Active Directory. User simply needs to be added to this group.

Caveats

The Protected Users group takes care of the cached credentials and NTLM, but unfortunately it does not protect against any form of impersonation attack. An attacker on the server could gain access to and use the stored TGT and TGS of the user. Therefore it is additionally important to set short time limits for idle and disconnected sessions so that Windows has the possibility to cleanup the no longer needed tickets.

Comparison

Which of these security features should you use? That’s a tough question. It depends on your use case.

• Are only Admin required to do remote desktop sessions?
• Do you need NTLM in your environment?
• Is SSO important for remote desktop users?
• Can you enforce policies on servers and workstations?

The table below gives an overview of some protections and drawbacks of the method mentioned above.

Additional Hardening

Additional hardening on remote desktop servers can also increase the security level:

• Configure trustworthy certificates for the RDP service
• Ensure that network level authentication (NLA) is enforced
• Set short time limits for idle and disconnected sessions
• Allow logon to RDP based on the least privilege principle
• Consider implementing a second factor of authentication
• Consider disabling NTLM

Conclusion

The default configuration of Remote Desktop connection on Microsoft Windows is suboptimal. It is best to combine security features and apply hardening to achieve a good level of security. This is not easy, but hopefully, our summary table will help you make informed decisions!