Kerberos Delegation Attacks

Delegation is a feature of the Kerberos protocol that allows a user or computer account to impersonate other users. Microsoft have developed extensions to the Kerberos protocol to provide further functionality over the base protocol.

A common example of delegation in use occurs when a web server has delegation enabled, allowing it to pass credentials sent to it through to a backend database server. You need delegation to overcome the Kerberos double hop problem.

In this article, we are going to be looking at exploiting three types of delegation;

• Unconstrained Delegation
• Constrained Delegation
• Resource Based Constrained Delegation

We will be using Windows Server 2022 across the target network.

---

Unconstrained Delegation

Using Active Directory users and computers, we can configure a computer account to use unconstrained delegation by selecting the second checkbox:

An attacker with a an Active Directory user account can determine which machines have unconstrained delegation enabled by reviewing the useraccountcontrol field. This can be queried using PowerView.

In the above output we can see SERVER1 has unconstrained delegation enabled, as designated by the TRUSTED_FOR_DELEGATION attribute. If an attacker can gain local administrator access to the host, this condition can be exploited. Note, that domain controllers always have unconstrained delegation enabled.

In this scenario user Bob is a local administrator on SERVER1, but is not a Domain Administrator. They are unable to access the Domain Controllers C$ share:

Bob can use Rubeus on the host to monitor for Kerberos Ticket Granting Tickets (TGT).

As soon as user Alice creates a remote desktop session to the server, her TGT ticket is captured.

Reviewing her group membership, we can see she is a member of the domain group, “Administrators” so she will have Administrative access to domain controllers.

Importing Alice’s ticket into our session allows us to access the domain controllers C$ share:

---

Constrained Delegation

Unconstrained Delegation allows a user’s TGT to be used anywhere within an Active Directory domain. Since this is not desirable from a security perspective, Microsoft released two Kerberos extensions to allow limiting where captured TGT’s could be used; S4U2Self and S4U2Proxy.

To configure constrained delegation, create a user account within the domain, and provide it using a Service Principal Name using SetSPN.

With the SPN in place, the Delegation tab then appears on the users properties in Active Directory users and computers. We can configure the account to provide delegation for a specific computer and target service. In this instance, our service account (svc_bordergate) can impersonate users on the domain to access the fax service on the domain controller.

The issue with constrained delegation is an attacker who gains access to this service account can request a TGT for any user in the domain including domain administrators, and then access any service on the target host (irrespective of the service type configured in AD users & computers).

We can identify accounts with constrained delegation enabled using PowerView.

TRUSTED_TO_AUTH_FOR_DELEGATION indicates the account has constrained delegation enabled.

Let’s assume an attacker gains access to the password of this service account, either through Kerberoasting or dumping credentials from memory.

First generate the NTLM hash for the accounts password:

Next, generate a TGT for the account:

We can then use the alternative service parameter to provide us with a CIFS service ticket, allowing us to access the systems C$ share:

The alternative service can be set to “http” to provide WinRM/PSRemoting access;

---

Resource Based Constrained Delegation

This form of delegation has been available since Windows Server 2012. Unlike the other forms of delegation, the destination resource is configured to state which systems and accounts can perform delegation of it’s services.

Specifically, the ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity Active Directory attribute defines this behavior. There are a couple ways this can be exploited;

• Compromise an account or system specified in another systems ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute, and perform delegation attacks against the system as previously described.

• If an attacker has GenericWrite capabilities over a target machine account, they can add or manipulate the ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute, and add their system to the record. They can then perform delegation for any user in the domain to that system.

Let’s look at option 2.

User Bob aims to access resources on SERVER2 as an administrative user. There is a write DACL in place to allow Bob to modify SERVER2.

Bob can determine they have GenericWrite access to SERVER2 using PowerView.

Active Directory accounts can create up to ten machine accounts by default. Bob uses Powermad.Ps1 to create a new machine account that will be the delegation source and grab it’s SID.

Next Bob creates a security descriptor based on the SID of our newly created phantom machine account, and applies the ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute to the SERVER2 target machine.

Finally, Bob uses Rubeus to create a TGT for the Domain Administrator, inject it into their session and access the C$ share of SERVER2.

---

Preventing Delegation Attacks

Some things that can help lessen the impact of delegation attacks;

• Limit usage of delegation where possible.

• Use Resource Based Constrained Delegation where possible.

• Enable the option “Account is sensitive and cannot be delegated” on administrative accounts to prevent them from being used in delegation attacks.