Unconstrained Delegation
Last updated
Last updated
Application and data access configurations often require fine-grained permissions, which can create design issues and security misconfigurations. One classic example of this lies in the Kerberos protocol and its authentication mechanism.
For example, consider an internal web server application that is only available to company employees. This web application uses Windows Authentication and retrieves data from a backend database. In this scenario, the web application should only be able to access data from the database server if the user accessing the web application has appropriate access according to Active Directory group membership.
Kerberos does not directly provide a way to accomplish this. When the web application uses Kerberos authentication, it is only presented with the user’s service ticket. This service ticket contains access permissions for the web application, but the web server service account can not use it to access the backend database.
This is known as the Kerberos double-hop issue. Microsoft’s Kerberos delegation solves this design issue and provides a way for the web server to authenticate to the backend database on behalf of the user.
When a user successfully logs in to a computer, a Ticket Granting Ticket (TGT) is returned. Once the user requests access to a service that uses Kerberos authentication, a Ticket Granting Service ticket (TGS) is generated by the Key Distribution Center (KDC) based on the TGT and returned to the user.
This TGS is then sent to the service, which validates the access. Note that this TGS only allows that specific user to access that specific service. Since the service cannot reuse the TGS to authenticate to a backend service, any Kerberos authentication stops here. Unconstrained delegation solves this with a forwardable TGT.
We begin with an overview of Kerberos authentication
In this case, when a user request access to a service that uses unconstrained delegation, the request also include the forwardable TGT.
Next we are able to send the TGT and the session key into TGS and sends it to the server. Now the frontend service is able to impersonate as us to the backend services.
seems cool solve the double hopping problem.
Frontend service stores all the tickets into LSASS(Local security Authority Subsystem Service). So it can impersonate authentication to ANY service(Its unconstrained delegation, if its constrained delegation it will only able to access for specific service).
In the event when this frontend is being compromised, attacker is able to dump the memory to retrieve the hashes and impersonate the users and authentication to any services.
We can enumerate using the PowerView and search in AD which of the workstation has the attribute useraccountcontrol set as "TRUSTED_FOR_DELEGATION"
In this screenshot we found the station web.cyberrange.com have the attribute TRUSTED_FOR_DELEGATION
This will dump all the ticket out the memoies and pick one of the desied TGT and inject into memory usingkerberos::ptt
Its normal that domain controller wont visit the web service(Why would he?).
We could trick a Print server to automatically login against it saving a TGT in the memory of the server. Then, the attacker could perform a Pass the Ticket attack to impersonate the user Print server computer account.
To make a print server login against any machine you can use SpoolSample
In order to receive the tickets once it force authenticated to us, directly setup a Rebeus monitor session listening for the tickets. Since we are forcing the DC, we should indicate the machine name of the DC(AD1$ in this case)
Now we using spoolSample to perform force authentication.
now switch back to the Rubeus windows, we should receive a ticket from AD1$ with flags forwardable
Use the same ways as above, either use rubeus or use mimikatz to inject the ticket into memory.
and dumping the krbtgt hash out from DC.
Ik0nw
1) Explain the Kerberos double-hop issue and how unconstrained delegation solves it.
2) How to configure unconstrained delegation in AD ?
3) What are the security risks associated with unconstrained delegation?
4) If we are using powerview, what command you can issue to find potential unconstrained delegation?
5) Why domain controller have "TRUSTED_FOR_DELEGATION" attribute set?
6) Any mitigations?
