Attacking Constrained Delegation

Kerberos Delegation

Kerberos Delegation is a feature that allows the application to request end-user credentials to access resources on behalf of the user. For e.g: A user authenticates to a web server and the web server makes a request to the SQL server to access resources as a user (depending on the type of delegation).

Types of Delegation

There are three types of delegation,

1. Constrained Delegation

2. Unconstrained Delegation

3. Resource-based Constrained Delegation

In this blog, we’ll focus on Constrained Delegation.

Constrained Delegation

If the constrained delegation is enabled on the user or computer (machine) account, it is possible to impersonate any domain user and authenticate to a service that the user account is trusted to delegate to. Constrained entities can be abused if one of their delegation entries is sensitive.

1. Service for User to Self (S4U2Self) — an extension that allows a service to obtain a forwardable TGT on behalf of a user with just the user’s principal name without supplying a
   password. The service account must have the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION attribute.
2. Service for User to Proxy (S4U2Proxy) — extension allows the service to obtain a TGS of a second service on behalf of a user. This second service is controlled by the msDS-AllowedToDelegateTo attribute. This attribute contains a list of SPNs to which the user’s ticket can be forwarded.

Note: If a user is marked as ‘Account is sensitive and cannot be delegated’, you will not be able to impersonate them.

Constrained Delegation — Authentication Flow:

To understand the authentication flow, let’s use the example of a user authenticating to a Constrained delegated account like a web service account that only permits delegation to SQL services.

1. A user John authenticates to the web service (web svc) using a non-Kerberos authentication mechanism.
2. The web service account requests a ticket from the KDC (Key Distribution Center) for John’s account without supplying a password as the web svc account.
3. KDC checks whether the web service account is allowed for delegation (TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION attribute) and whether the user is active or not blocked. If everything is verified accordingly, the KDC sends the TGT ticket to the web service (S4U2Self).

This step uses the Service for User To Self (S4U2self) extension that allows a service to obtain a forwardable TGT on behalf of a user.

5. The web service passes the TGT back to KDC and requests a TGS (service ticket) for a SQL service.

6. The KDC checks the *msDS-AllowedToDelegateTo* field on the web svc account. If the service is listed, the KDC will grant the SQL TGS ticket (S4U2Proxy).

This step uses the Service for User to Proxy (S4U2proxy) extension allows the service to obtain a TGS of a second service on behalf of a user.

7. Once the web server gets the ticket, it will send it to the SQL server to request access to its data and retrieve the information needed for the user.

8. Once the KDC grants the TGS, the web server will use the ticket to access the resource in the SQL server.

Figure 1: The web service account requests a forwardable TGT ticket from the KDC

Figure 2: Web server receives Forwardable TGT and requests for TGS (SQL service)

Figure 3: Webserver accessing the SQL servers and retrieving the data back to the user

Attack Requirement

To abuse the constrained delegation, we need to have access to the web svc account. If we have access to that account, it is possible to access the services listed in msDS-AllowedToDelegateTo of the web svc account as any user.

Attack Demo

This Post assumes that the attacker already has access to the delegated machine with admin privileges.

To identify the constrained delegation user or machine accounts, we can look into the msDS-AllowedToDelegateTo attribute in the accounts details. These accounts can be enumerated with the Powerview script or Active Directory Module.

PowerView makes it very easy to find the constrained delegation user or computer accounts.

Abusing User Account Configured with Constrained Delegation:

To get Users that have Delegation Option enabled, we can use the below commands,

Get-DomainUser -TrustedToAuth

Get-DomainComputer -TrustedToAuth

Figure 4: web_svc user has constrained delegation feature enabled for CIFS only.

We can also use the AD module to get the same result,

Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

The above results show that two accounts allow delegation to specific services. One is a user account, “web svc” which enables the delegation to the CIFS services on the MSSQL server, and the other is a computer account, “dcorp-adminsrv” allowing the delegation for the Time service on the domain controller.

The first step is to request Forwardable TGTs from KDC for delegated accounts. We can use either Rubeus or Kekeo. For this post, we going to use Rubeus.

We can request the TGT ticket for the “web svc” user and “dcorp-adminsrv” account with which we can get access to the SPN Machine. We are requesting a TGT and TGS in a single command.

.\Rubeus.exe s4u /ticket:TGT_Ticket /msdsspn:"service/HOST" /impersonateuser:Administrator /ptt

Figure 5: It shows obtaining the TGT and TGS ticket for the DCORP-ADMINSRV$ account

Figure 6: Directory contents for the dcorp-mssql

As seen, we have the ticket and we have successfully listed the directories on the server with that ticket. We could also alternate the allowed services with other services and perform additional attacks like remotely dumping the machine’s credentials.

Abusing Computer Account Configured with Constrained Delegation:

To get computers that have Delegation Option enabled, we can use the below commands:

Get-DomainComputer -TrustedToAuth

Figure 7: DCORP-ADMINSRV$ user has a constrained delegation feature enabled for TIME.

The above result shows that “dcorp-adminsrv” allows the delegation for the Time service on the domain controller.

With Rubeus, we can request the TGT ticket for the current user with which we can get access over the SPN Machine. We are requesting a TGT and TGS in a single command.

Rubeus.exe s4u /user:username /aes256:HASH /impersonateuser:Administrator
/msdsspn:"service/HOST" /altservice:ldap /ptt

Figure 8: It shows obtaining the TGT and TGS ticket for the DCORP-ADMINSRV$ account

Figure 9: Directory contents of the dcorp-dc

As seen, we have the ticket and we have successfully listed the directories on the DC with that ticket.

Mitigation

1. Disable Kerberos delegation where possible.
2. Limit DA/Admin logins to specific services.
3. Set “Account is sensitive and cannot be delegated” for privileged accounts.
4. Ensure the delegated accounts use strong passwords to protect them against attacks like Kerberoasting.

Thanks for reading! Happy Hacking !!!

Reference:

Kerberos Constrained Delegation Overview

What Is Kerberos Delegation? An Overview of Kerberos Delegation