Delegation to KRBTGT
Last updated
Was this helpful?
Last updated
Was this helpful?
The idea behind this technique is to configure on the krbtgt account to generate TGTs on-demand as a persistence technique. The requirements for the technique are to have enough privileges (i.e. domain admin rights) to edit the krbtgt account's "rbcd" attribute (i.e. ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity) and to control an account that has an SPN (, or do ).
Once the delegation is configured, an attacker can later on obtain a service ticket for the krbtgt on behalf of any user.
Since a TGT is just a Service Ticket for the KRBTGT service, it means the attacker has a persistence technique allowing him to obtain a TGT for almost any user in the domain. The only limitations are the "Protected Users" group, or the "Account is sensitive and cannot be delegated" parameter. Those settings can protect users from delegation and will prevent attackers from obtaining a ticket that looks like a TGT on their behalf through a delegation trick.
An example of the abuse goes as follows :
Configure RBCD delegation on the krbtgt account to allow a controlled account to delegate to it. The controlled account should have at least one SPN (i.e. ServicePrincipalName) for the delegation to work (or, see ). This controlled account will be called "ControlledAccountWithSPN".
Perform a full attack to obtain a Service Ticket for the krbtgt service, on behalf of another privileged user. Let's call this chosen user "TargetedAccount". The ticket obtained through this process is for the KRBTGT service, which basically means the ticket can be used as a TGT for the TargetedAccount.
to use the Service-Ticket-that-is-in-fact-a-TGT, act as the target -privileged- user, and authenticate to remote resources.
Every step of this attack can be achieved using one of the following scripts from (Python), such as rbcd.py and getST.py.
