Modification of the TrustedToAuthForDelegation and ms-DS-Allowed-To-Delegate-To properties used to configure constrained delegation requires the SeEnableDelegationPrivilege. This privilege is granted only to domain administrators by default, but it could be manually granted to other users. However, services can configure their own ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute to accept resource-based constrained delegation from other services.
Weaknesses
While there are many avenues for escalating access using constrained delegation and resource-based constrained delegation, three weaknesses in particular are exposed across multiple attack types.
First, in constrained delegation, the service ticket received from S4U2proxy by service A can be modified to access any target service run by the same user as service B because there is no integrity check for the field specifying the target service. Second, in resource-based constrained delegation, any account can request a service ticket on behalf of another user with S4U2self that can be used to access a different target service as the user with S4U2proxy. Third, services can begin accepting resource-based constrained delegation by altering their own ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute.
Following are descriptions of two different attacks and how resource-based constrained delegation and constrained delegation can be compromised. These attacks can be accomplished using Impacket, mitm6, and an Abstract Syntax Notation One (ASN.1) editor. While variations of these attacks can be performed using other tools, such as Rubeus, the attacks presented here have an advantage because they can be run from an attacker’s machine within a target network. They do not require executing tools locally on legitimate machines within the target network, which might increase the likelihood of detection by endpoint detection and response (EDR) or other security technologies.
Attack 1: Gain a foothold with resource-based constrained delegation
Unauthenticated attackers can use resource-based constrained delegation to establish an initial foothold within a target environment where Windows New Technology LAN Manager (NTLM) is used for network authentication. Internet Protocol version 6 (IPv6) and Web Proxy Auto-Discovery (WPAD) are used in the following attack, but any means of coercing NTLM authentication over the Hypertext Transfer Protocol (HTTP) or Lightweight Directory Access Protocol (LDAP) is sufficient.
Prerequisites
- IPv6 and WPAD are allowed on the target network but not used. In general, this is the default configuration.
- NTLM authentication is allowed on the target network.
- The MS-DS-Machine-Account-Quota attribute, which allows accounts to join additional computers to the domain, is set to a non-zero value, the default.
- There exists at least one LDAP endpoint where LDAP signing is not required or LDAP over SSL (LDAPS) endpoint where Extended Protection for Authentication (EPA) is not required. LDAP signing and LDAPS EPA are not required by default.
Steps
- Leverage IPv6 to become the domain name system (DNS) server of any target machine (machine T) and coerce NTLM authentication from the machine’s computer account by serving it a malicious WPAD configuration.
- Relay the coerced authentication to a vulnerable LDAP or LDAPS endpoint.
- Using the relayed authentication, create an attacker-controlled computer account (account A) and configure machine T to accept delegated access from account A.
- Use account A to request a service ticket for itself as a domain administrator with S4U2self. The ticket returned will not be forwardable, but it can still be used with S4U2proxy for resource-based constrained delegation.
- Use the first service ticket to request a second service ticket to access machine T as a domain administrator using S4U2proxy.
Results
The service ticket grants the attacker access to machine T as a privileged user. Additionally, the attacker has established persistent, privileged access to machine T by repeating steps 4 and 5 at any time.
Attack 2: Compromise a target host with constrained delegation
After performing the previous resource-based constrained delegation attack or another attack that grants access to an authenticated user, an attacker can use constrained delegation to gain access to a high-value target machine. The following attack targets a service run by the computer account for a target machine; however, the attack can be performed by targeting any service run by a user with elevated access to the target machine that also meets the following prerequisites.
Prerequisites
- Access is available to any low-privilege account (account A).
- There exists an account (account B) with a service principal name (SPN) that can delegate access using constrained delegation to a target service run by the computer account on a machine that is a high-value target (machine T).
Steps
- Use account A to perform an LDAP query to identify an account B that can delegate access to any service run by the computer account for machine T.
- Gain access to account B using the previous resource-based constrained delegation attack or another attack providing account compromise.
- Use account B to request a service ticket for B as a domain administrator with S4U2self. The returned ticket must be forwardable for constrained delegation.
- Use the first ticket to request a second service ticket to access the service on machine T that is configured for constrained delegation as a domain administrator with S4U2proxy.
- If necessary, alter the service field of the second ticket with an ASN.1 editor to gain access to any service on machine T.
Results
As in the first attack, the service ticket grants the attacker access to any service on machine T as a privileged user. Additionally, the attacker has established persistent, privileged access to machine T by repeating steps 4 and 5 at any time.
Remediation
Attackers can exploit constrained delegation and resource-based constrained delegation to establish initial, elevated, and persistent access within an Active Directory environment. However, resource-based constrained delegation is the most secure variety of delegation available in Active Directory, and delegation is a useful feature in many environments.
The following remediation steps provide a reasonable, but not impenetrable, defense against attacks on constrained delegation and resource-based constrained delegation:
- Identify and audit existing delegation configurations using Impacket or the Microsoft PowerShell™ Active Directory module.
- Assign SeEnableDelegationPrivilege only to users that require the ability to configure delegation for services, such as domain administrators.
- Configure discretionary access control lists (DACLs) according to the principle of least privilege. Any user that can modify the ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute of a computer object can allow themselves to impersonate users on that computer object with resource-based constrained delegation.
- Use resource-based constrained delegation in place of constrained delegation where possible. This creates a one-to-one mapping of a service allowed to impersonate users to another target service. Constrained delegation creates a less restrictive one-to-many relationship.
- Mark accounts with elevated access as sensitive for delegation, including computer accounts for domain controllers, to prevent services from requesting service tickets for the relevant accounts using S4U2proxy, but not S4U2self.
- Add sensitive accounts to the Protected Users security group to prevent services from requesting service tickets for the relevant accounts using S4U2proxy, but not S4U2self. Computer and service accounts should not be added to this group due to adverse effects on their functionality.
- If resource-based constrained delegation is not used, add an access control entry (ACE) to the DACL to explicitly permit only necessary accounts to write to the ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity and TrustedToAuthForDelegation attributes.
- If constrained delegation is not used, add an ACE to explicitly permit only necessary accounts to write to the ms-DS-Allowed-To-Delegate-To attribute.
- Apply NTLM relay mitigations to prevent attackers from using NTLM relay attacks to set up vulnerable resource-based constrained delegation configurations.
- Monitor S4U2self and S4U2proxy calls as part of requests for service tickets (Event ID 4769) from devices that are not configured by IT for delegation, because unexpected delegation from such devices might indicate compromise.
- Add an ACE to the system access control list to generate an event (ID 5136) when changes are made to directory service objects, including changes to the ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity or ms-DS-Allowed-To-Delegate-To attributes.
Hardening networks
Constrained delegation and resource-based constrained delegation are more secure alternatives to unconstrained delegation. Resource-based constrained delegation offers the most security and granular control over permissions for delegation, and it should be used for new configurations of delegation. However, any implementation of delegation increases the attack surface of a network and might allow attackers to elevate access and establish persistence. Organizations should implement delegation only when necessary for business functions, prefer resource-based constrained delegation over other varieties, and harden delegation configurations to mitigate the risk of attacks.
