Resource-based constrained delegation is a dangerous Kerberos extension in Active Directory, which opens a path to a variety of attacks that we discovered in our latest research on the subject. We reported our findings to Microsoft, but Microsoft's engineering team determined that they would not address this issue via a security update.
Kerberos is a network authentication protocol, commonly used in directory environments, including Microsoft’s Active Directory. One of the security advantages of Kerberos is that when a user sends authentication data to a service, no material that can be used to crack the user’s credentials is transmitted, unlike other common network authentication protocols, such as NetNTLM.
Kerberos has mechanisms that allow users to “delegate” their identity to services, to allow the services to impersonate the user to other services. For example, these mechanisms allow an application to access a database as the user, which helps to enforce the access control model more robustly.
The first delegation mechanism that was introduced to the protocol is “unconstrained delegation”, which allows the service to impersonate the user to any other server, hence “unconstrained”. Later on, Microsoft introduced “constrained delegation”, which allows services to impersonate the user only to a predefined list of services. Constrained delegation is considered more secure than unconstrained delegation because if the service is compromised, the attacker can only abuse it to move laterally to that predefined list of services.
Microsoft also introduced to Kerberos a feature called “protocol transition”, which allows services to impersonate users out of thin air. This feature is useful when users authenticate to a service over a different protocol, such as NetNTLM, and the service is required to impersonate the users to other services over Kerberos. This feature is obviously very dangerous, and only services that have the TrustedToAuthForDelegation flag set are allowed to invoke it.
These delegation features pose a security risk, and so only users with very high privileges are permitted to configure them; by default only Domain Admins. In contradiction to the last statement, to make delegation more accessible to sysadmins, Microsoft introduced in Windows 2012 another flavour of Kerberos delegation, called “resource-based constrained delegation” or RBCD in short. RBCD allows anyone with delegated control of an object in Active Directory to configure delegation from other objects. Even the objects can configure RBCD for themselves, e.g. a computer can configure RBCD for itself to determine which services can delegate to it.
For many years, RBCD seemed to have been a best-kept secret, at least within cyber security circles. However, in the past few months, we have been researching this feature and found that it poses a major security risk, due to the following:
- RBCD does not require the TrustedToAuthForDelegation flag to be set to impersonate users out of thin air, unlike “classic” constrained delegation
- If an attacker can control a computer object in Active Directory, the attacker can abuse RBCD to compromise the corresponding host
- Chained with RBCD, “classic” constrained delegation allows impersonating users out of thin air without having the TrustedToAuthForDelegation flag set
- Once a domain is compromised, RBCD can be configured to allow the attacker to persist in the environment
- We were able to put together several attack chains that abuse RBCD to gain remote code execution or local privilege escalation on affected domain-joined hosts, including a local privilege escalation attack that affects all domain-joined Windows 10 hosts by default.
We reported our findings to Microsoft’s Response Centre; however, their response stated that:
"The engineering team has determined this is not an issue which will be addressed via a security update but rather we need to update our documentation to highlight service configuration best practices and using a number of features such as group managed service accounts, resource-based constrained delegation, dynamic access control, authentication policies, and ensuring unconstrained delegation is not enabled."
Until Microsoft reconsiders and issues a patch, as per our research, we recommend the following configuration changes to mitigate RBCD attacks:
- If resource-based constrained delegation is not used in your organisation, block it by denying everyone from configuring it throughout the domain
- Add all privileged users to the “Protected Users” group in Active Directory
- Set all computer accounts as “sensitive for delegation”
- Enforce LDAP signing with channel binding on the domain controllers
- Do not enable unconstrained delegation on any service, except for the domain controllers
RBCD attacks can be detected if the right audit policy is configured, and an appropriate detection logic is implemented. More details about detection can be found in the Detection section of our paper.
For the full details of the research, including proof of concept and demos, please read my paper https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html.
If you need assistance, in configuring mitigating these controls in your organisation, please reach out to us.
If you would like to have our red team challenge your security posture to identify gaps in your defences through a penetration test or an adversary simulation, please contact us at The Missing Link.
