Delegations
ATTL4S's amazing Kerberos presentations for all things related to Kerberos
Double Hop Issue
Kerberos Delegation is a mechanism designed to address the Kerberos double hop issue, which arises when an authenticated user accesses a remote service (first hop), and that service must then access another resource on a different system (second hop) on behalf of the same user.
This issue stems from the fact that both access tokens and credentials are tied to a user’s logon session. The access token defines the user’s local security context which is used by the operating system to control what the user can do on the local machine. Credentials, such as NTLM hashes or Kerberos tickets, represent the user’s network security context and are used to authenticate to remote systems. Therefore, unless delegation is configured, a service that receives an access token cannot leverage that token to authenticate as the user to another system.
To overcome the Kerberos double hop issue, two primary approaches exist:
CredSSP: Stores user credentials in cleartext on the first hop, allowing the second hop to reuse them. While effective, this method introduces significant security concerns due to plaintext credential exposure.
Kerberos Delegation: Enables services to reuse a user's Kerberos-based authentication to access other resources across the network. This allows impersonation beyond the local system without exposing credentials directly, and it can be configured with varying levels of control and restriction depending on the delegation type.
There are three main types of Kerberos delegation:
Unconstrained
Grants a service unrestricted ability to impersonate a user to any service in the domain.
Constrained
Limits impersonation to specific services on specific hosts. If a user authenticates using a method other than Kerberos (e.g., NTLM), the service can still delegate using Protocol Transition, converting the authentication method into a Kerberos ticket to perform delegation.
Resource-Based Constrained
Defined on the resource server rather than the delegating service. This allows the target server to specify which principals are allowed to delegate to it.
Unconstrained
To set the
TRUSTED_FOR_DELEGATIONUAC flag on an account, theSeEnableDelegationPrivilegeis required. This is typically restricted to DAs.
When a user authenticates to a service configured for Unconstrained Delegation (UD), the KDC includes the user’s TGT inside the TGS response. The service decrypts this TGS, extracts the TGT, and stores it in LSASS. With this TGT available, the service can now request additional TGSs on behalf of the user for any service in the domain, allowing the server to fully impersonate the user over the network. It should be noted, that a service account cannot modify itself to add this option.
OPSEC: Performing a DCSyc with DC$ will typically fly under the radar.
This behavior introduces a critical security risk: if a host configured for UD is compromised, any user who authenticates to it exposes their TGT to the attacker. The host becomes a passive collection point for TGTs. The attacker can wait for privileged users to connect naturally or to actively force a connection from a privileged account (e.g. DC01$) to the compromised host.
User requests TGS for a server configured with UD.
KDC embeds the user's TGT into the issued TGS.
Server stores the user's TGT into memory.
Server gets compromised and a DA logs in.
Attacker captures DA's TGT and can now access the DC's services, eg. CIFS.
Passive TGT Collection
Coercive Connection
Some Windows services make this coercion possible.
When leveraging WSP or DFS, use the netBIOS name, not the FQDN as with RPRN.
Enumerate hosts which have UD configured.
Launch Rubeus and coerce a connection.
Inject the compromised TGT.
If the ticket is from DC01$ perform DCSync; otherwise, use request a TGS via S4U2Self as any user.
For more information on coercive connections, see here.
User Accounts
User accounts can also be configured for UD. If such an account is compromised, the attacker must also have the ability to modify its SPN set, which typically requires GenericWrite (or equivalent) permissions over the account object. The general process is outlined below:
Create a malicious DNS record using a valid domain account. This record resolves to an attacker-controlled host and effectively introduces a rogue service endpoint within the AD environment.
Register a suitable SPN (for example,
CIFS/<dns_record>) on the compromised user account. This enables the account to act as a Kerberos service capable of receiving delegated tickets.Trigger Kerberos authentication to the rogue service. When a privileged user authenticates to the attacker-controlled endpoint, their TGT is forwarded to the UD account. The attacker can then extract and reuse this TGT to impersonate the victim and escalate privileges within the domain.
This attack can be performed using the krbrelayx tools (dementor.py is an alterntive for triggering the Printer Bug). In the example below:
x7331devis a user account configured with UDx7331hasGenericWriteoverx7331dev
Constrained
Constrained Delegation (CD) enables a service to impersonate users to access specific services on specific hosts. The list of allowed services is stored in the msDS-AllowedToDelegateTo attribute. As in UD, a service account cannot modify itself to add this option either.
The service account makes a special TGS-REQ (S4U2Proxy) to KDC by modifying two of its fields:
additional tickets→ contain a TGS copy the user sent to the service accountcname-in-addl-tkt→ indicates to KDC to use the ticket information withinadditional_ticketsinstead of the server information
The KDC will check that the account has the rights to delegate to the requested service and that the TGS copy is forwardable. If everything checks out, it will return a TGS.
With Protocol Transition
S4U2Self and S4U2Proxy are Kerberos extensions in AD that enable delegation. They are commonly used in CD scenarios.
S4U2Self addresses the situation where a user authenticates to a service without using Kerberos (for example, via NTLM or another method) and therefore does not present a TGS. In this step, the service requests a forwardable TGS to itself on behalf of a specified user. The user’s password is not required. The DC verifies that the service is trusted for delegation and that the user is not marked as sensitive for delegation. If these checks pass, the TGS is issued.
With this ticket, the service can then perform S4U2Proxy. In this step, the service requests a second TGS to access a downstream service on behalf of the user. The request is limited to the target services listed in the service account’s msDS-AllowedToDelegateTo attribute. The KDC validates that the target SPN is permitted and, if so, issues a new TGS. The service can then use this ticket to authenticate to the downstream resource as the user.
S4U2Self→ Service requests a ticket to itself as the user.S4U2Proxy→ Service requets a ticket for another service as the user.
This setup, however, introduces two key risks if the delegating account is compromised.
First, with S4U2Self, the service can obtain a forwardable ticket for any domain user, including highly privileged ones such as DAs. As a result, any downstream service listed in msDS-AllowedToDelegateTo becomes reachable as a privileged identity. A compromised service account essentially becomes a powerful pivot point to lateral movement.
S4U2Self step.This attack path, i.e., leveraging S4U2Self, can be performed as shown below.
Second, the SPN in an S4U2Proxy request is sent in plaintext, which means it can be modified. While the msDS-AllowedToDelegateTo attribute is intended to restrict which services a ticket can be requested for, this control applies only to the target host and not always to the specific service class.
As a result, if delegation is configured for a low-risk service, such as TIME/dcorp-dc, the service portion of the SPN (for example, TIME) can potentially be changed to a more sensitive one, such as LDAP, while keeping the same host. This can allow access to higher-privilege services than originally intended, increasing the risk of abuse.
S4U2Proxy step.This attack path, i.e., leveraging S4U2Proxy, can be performed as shown below.
Services are case-sensitive → LDAP not ldap!
A list of what each SPN provides can be found below.
WSMAN is the protocol the underlies PowerShell Remoting, so SP
HTTP
WinRM (Windows Remote Management)
CIFS
File system (SMB shares)
HOST
Scheduled tasks, remote service control, WMI (partial, combined with RPCSS)
RPCSS
WMI (combined with HOST), DCOM/RPC endpoint mapper
LDAP
DCSync (requires elevated permissions)
TERMSRV
RDP (Remote Desktop Protocol)
Without Protocol Transition
CD without Protocol Transition requires the client to authenticate with Kerberos directly. The user must first obtain a TGS and present it to the front-end service. This ticket serves as the “evidence” required for the subsequent S4U2Proxy request.
To abuse this setup, only a valid TGS and an account with at least one SPN are required. A machine account can be created for this purpose using tools such as PowerMad. By default, AD allows authenticated users to create up to 10 machine accounts (the machineAccountQuota attribute), which makes this approach practical in many environments.
Additionally, any account with an SPN can configure RBCD on a resource it controls. For example, if web01 is configured to trust attl4s via RBCD, then attl4s can impersonate any user when accessing web01.
Resource-based
Resource-Based Constrained Delegation (RBCD) transfers control of delegation from DAs to the owners of the specific resource or service being accessed. Instead of being centrally managed, delegation is defined on the target resource through the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. This attribute, configured on the resource account itself, contains a list of trusted principals that are permitted to act on behalf of other users when accessing that resource.
The msDS-AllowedToActOnBehalfOfOtherIdentity attribute can be displayed as PrincipalsAllowedToDelegateToAccount on various tools.
This approach allows the administrator of a service, such as a database or application, to grant delegation rights to trusted systems without requiring elevated domain privileges like SeEnableDelegation. As a result, delegation can be managed in a more granular and decentralized manner.
The TGS request process in RBCD is similar to traditional CD. The key distinction is that the resource controls its own trust configuration by modifying the relevant attribute. Consequently, any service account with sufficient permissions over its own object can allow one or more accounts to delegate to it, enabling flexible and fine-grained delegation scenarios.
To exploit RBCD successfully, two primary conditions must be satisfied:
The attacker must have control over an account or group that has permission to modify the target object’s delegation attribute,
msDS-AllowedToActOnBehalfOfOtherIdentity.The attacker must control an account that has a SPN assigned. This can be accomplished either by compromising an existing account with an SPN or by creating a new account capable of obtaining one. The latter approach is viable due to the default
MachineAccountQuotaconfiguration in AD. By default, this setting permits standard domain users to join up to ten machines to the domain. When a new computer account is created, it automatically receives an SPN, thereby providing the attacker with a suitable account to use in the RBCD attack chain.
Enumerate which accounts can modify the target attribute on which hosts. In this example, the user x7331 can modify DC01.
Create a machine account with an SPN (RBCD).
Set RBCD on the target host (DC01). Although this can be achieved with a one-line command using different tools, all methods ultimately perform the same underlying steps.
A binary security descriptor is written to the msDS‑AllowedToActOnBehalfOfOtherIdentity attribute. The security descriptor is an access control structure that contains an Access Control Entry (ACE) for the attacker‑controlled account. The ACE includes the account’s SID and permissions that allow it to act on behalf of other users.
Tools such as Standln and PowerView automate the creation of the security descriptor and the LDAP modification.
Extract the credentials of the machine account in order to request and inject the TGS impersonating the Administrator.
Additional services within the TGS: /altservice:host,RPCSS,wsman,http,ldap,krbtgt,winrm
The above attack can also be performed from a Linux host using Impacket.
If the MachineAccountQuota attribute is set to 0, standard users cannot create new computer accounts. This prevents the common RBCD abuse path that relies on creating a machine account, which automatically has SPNs and naturally behaves as a service.
RBCD can still be abused by using a normal user account, but the account must have at least one SPN assigned (Exploiting RBCD Using a Normal User Account). This is required because S4U2Self and S4U2Proxy operations can only be performed by service accounts. Without an SPN, the KDC will not treat the account as a service and delegation will fail. Unlike machine accounts, normal user accounts are not typically used for delegation workflows. As a result, additional Kerberos key handling is required to ensure successful S4U operations.
In the example below, the compromised user x7331 is used to perform delegation. The NT hash allows requesting Kerberos tickets by triggering the S4U2Self operation.
The session key is embedded in the TGT and will be used during S4U operations. When abusing RBCD with a normal user account, Kerberos validation during S4U requires consistency between:
The account’s current long‑term key (derived from its password)
The key material used in the delegation workflow
The attacker changes the user’s password (SamrChangePasswordUser method) so that subsequent S4U2Self and S4U2Proxy requests succeed by aligning the account’s current key with the session key already in use.
Services
CD & CIFS
In scenarios where a machine account is configured with CD to a target server's CIFS, it is possible to impersonate privileged users and access the target via SMB by abusing the delegation trust.
In certain execution methods (like those involving service control manager RPC calls, e.g., PsExec) a valid HOST SPN ticket may be also required. This is because behind the scenes, PsExec uses the Service Control Manager (SCM), which may demand authentication tied to the HOST SPN. If CIFS-only ticket injection fails to enable RCE, request and inject an additional TGS for the HOST/target service.
In the below example, the machine account CLIENT1$ is trusted for CD to the CIFS service on server.internal.corp. This means the delegation rights are set on the delegator account (CLIENT1$) through the msDS-AllowedToDelegateTo attribute, indicating classic CD.
With the AES-256 key for CLIENT1$ extracted, forged Kerberos tickets can be created using Rubeus’s /s4u module to impersonate a privileged user such as Administrator. Injecting these tickets allows access to the CIFS service on the target.
Last updated