Remote Credential Guard was recently introduced by Microsoft to mitigate the risk of credential theft from machines that are accessed through RDP. In essence, this feature enables RDP connections without leaving credentials on target servers. Instead, the credentials remain on the source machine and the target requests Service Tickets from the source as needed.
While a useful control, an attacker can still reside on a target machine, wait for an incoming connection, and instead of hijacking the credentials, simply request the tickets he wants from the source. Thus, even without having the credentials, as long as the session is open, the adversary can impersonate the privileged user (ex: by stealing the generated service tickets or hijacking the victim’s access token).
This blog will explore some of the ways this attack vector can be executed.
The Remote Credential Guard
Last year, Microsoft introduced the Credential Guard – a security feature in Windows 10 Enterprise and Windows Server 2016. Credential Guard uses virtualization technology to mitigate the risk of derived domain credentials theft after compromise, thus reducing the effectiveness of Kerberos attacks such as Overpass-the-Hash and Pass-the-Ticket. Recently, Microsoft released the Anniversary update and, with it, the Remote Credential Guard, a security feature that aims to protect credentials over Remote Desktop (RDP) connections by generating the necessary service tickets from the source machine instead of by copying the credentials (hashes and TGTs) to the target machine.
Source: https://technet.microsoft.com/en-us/itpro/windows/keep-secure/remote-credential-guard
This feature is designed to allow administrators to safely connect to untrusted remote servers (“assume breach“) without leaving privileged credentials on those servers. It seems to be replacing the Restricted Admin mode, a feature introduced in Windows 8.1 / 2012 R2 and then “back-ported” to Windows 7 / 8 / 2008 R2 / 2012. Restricted Admin mode aimed to secure privileged credentials by “switching” the RDP session to a local admin session, thus preventing the theft of privileged domain credentials. The key advantage of the Remote Credential Guard in comparison to the Restricted Admin mode is that the RDP connection is fully interactive (instead of network logon), allowing access to remote services from the credentials-free RDP session.
When a user logs in via RDP to a machine that has Remote Credential Guard enabled, none of the Security Support Providers (SSP) in memory store the user’s clear-text password or password hash. Thus, if an attacker has compromised the target machine and tries to dump the hashes, there will be no hashes there to dump.
This eliminates an attacker’s ability to execute Pass-the-Hash or Overpass-the-Hash (aka Pass-the-Key) attacks to impersonate the remote user. So, is this the end of credential theft attacks?
Service Tickets are still there
Note that Kerberos tickets still remain in memory to allow interactive (and SSO) experiences from the target (RDPed) server. Dumping the cached Kerberos tickets from memory shows that the session key of the Ticket Granting Ticket (TGT), which has been delegated from the client machine’s Credential Guard, is encrypted making it unusable for a Pass-the-Ticket attack.
However, because service tickets (Ticket Granting Service) are not encrypted, it is still possible to pass them to gain access to specific services (SPN). The scope of access and the escalation opportunities here depends on the service tickets that can be extracted.
The target server will withdraw any service ticket requested by the user through the source (RDPing) machine. If the RDP session involves execution of administrative tasks or access to sensitive assets, it will probably cache juicy service tickets that could be abused for remote execution and data exfiltration. So, while it is true that password hashes and TGTs have broader exposure, and thus are more sensitive than service tickets, those service tickets can be quite valuable in their own right.
Nevertheless, service tickets are limited. What if the attacker is not satisfied with what he got and wants to access to other, more lucrative targets? After all, while the account of the victim may have the adequate permissions for escalation, relying on the user to request the service tickets that enable effective elevation may not work.
Borrow the Access Token
Well, despite the fact that the victim’s credentials are isolated by Credential Guard on the source machine, the victim account’s access token still exists on the compromised server as long as the RDP session is live. Hijacking this access token allows an attacker on a compromised server to run code in the context of the victim’s account. Even though the victim’s TGT is protected, the Remote Credential Guard will redirect any Kerberos requests back to the source machine, and the source machine will be tricked into granting service tickets.
Service tickets will be generated and permissions will be granted for both the RDP client’s token and the malicious duplicated token based on the authenticated account privileges. Even if the attack window is narrow, it is possible to quickly request arbitrary tickets on behalf of the victim and use them later on another machine. By default, the lifetime of service tickets is 10 hours, leaving enough time for the attacker to plan the next move.
Timing or skills
The mentioned attack vector requires two pre-requisites: a machine with administrative access and a user who is logged on (or logged on recently) to that compromised server. The former could be achieved by exploiting a vulnerability or abusing a misconfiguration, while the latter will demand social engineering or a bit of luck. The first thing to do after compromising a server is to check whether an active terminal session or cached Kerberos tickets exist. If there are no credentials and time is not an issue, it’s possible to reside on the machine and wait for incoming connections. Or perhaps use the old fashioned trick and encourage such a connection by luring an admin to RDP to the machine by creating an issue that requires higher privileges to resolve.
Summing it all up
The Remote Credential Guard is designed to protect privileged domain credentials from being exposed when connecting to a remote server with RDP, yet derived credentials are not limited to NTLM hashes and Kerberos TGTs. From the attacker’s perspective, the quantity of compromised credential derivatives are irrelevant if one of them allows the sufficient level of access. While limiting the potential exposure of credentials to some extent, the Remote Credential Guard does not fully mitigate the risk of credentials theft by a determined adversary that has already compromised the target machine and is just waiting for a privileged session to fall under the fishing rod.
Recommendations
Given the limitations of Remote Credential Guard, what else can be done to protect derived credentials from theft? Here are a few steps you can take and policies you can enforce to close some of the gaps that are left open by Remote Credential Guard:
- Establish remote connections using network logon instead of interactive logon when possible
- Set up and restrict administrative access by tiers (Tier Model), i.e Forest/Domain Admin are only used to administer the Active Directory
- Reduce credentials exposure to the least privilege required for the specific task
- Enforce credential removal after logoff
