Belief this person/laptop for delegation to specified providers solely
Delegation is the act of giving somebody authority or accountability to do one thing on behalf of another person. Within the Energetic Listing, delegation is a function that allows particular accounts (person or laptop) to impersonate different accounts to entry specific providers on the community.
There are three (3) recognized kinds of delegations allowed with Kerberos: Unconstrained, Constrained, and Useful resource-based constrained delegations. For this text, we are going to concentrate on the Constrained delegation. We are going to study to abuse such a delegation throughout a penetration testing engagement and chain it with different assaults equivalent to DCSync to acquire the area controller hashes.
The assault demonstration steps will likely be on the Pentester Academy Energetic Listing Lab by Nikhil Mittal related to the CRTP course. Beneath is the breakdown of the important thing ideas we are going to talk about on this article.
Constrained delegation permits the account with the “Belief this person/laptop for delegation to specified providers solely” enabled to impersonate ANY person to entry particular providers listed within the allowable delegation record.
As seen under in Figures 1 and a pair of, delegation properties are set for particular service varieties and hosts (Service Principal Names – SPNs) for person or laptop accounts.
This sort of delegation offers an enormous accountability to the front-end providers to authenticate the person. On this case, the person doesn’t authenticate to the Kerberos area controller (KDC) instantly. As an alternative, it should authenticate to the service first, then the service impersonates the person to entry the requested useful resource.
Kerberos Protocol does such a delegation with two (2) extensions:
- Service for Person to Self (S4U2Self) — Kerberos protocol transition extension.
- Service for Person to Proxy (S4U2Proxy) — Kerberos Constrained Delegation extension.
To grasp the authentication movement, let’s take an instance of a person authenticating to a constrained delegated account like an internet service account that solely permits delegation to SQL providers. The authentication movement would encompass six (6) major steps.
- A person authenticates to the online service with username solely (no password wanted).
2. The online service sends a request to the KDC impersonating the person to request a Forwardable TGT — (Determine 3).
3. The KDC checks whether or not the online service account is allowed for delegation and whether or not the person is energetic and never blocked. Then, the KDC sends the TGT ticket to the online service if the whole lot is verified accordingly — (Determine 3).
📍This step makes use of the Service for Person To Self (S4U2self) extension that enables a service to acquire a forwardable TGT on behalf of a person.
4- The online service caches the Forwardable TGT regionally and sends it again to the KDC to request a service ticket (TGS) for a SQL service — (Determine 4).
5- If the SQL service is allowed within the delegation record of SPNs, the KDC will grant the SQL TGS ticket — (Determine 4).
📍This step makes use of the Service for Person to Proxy (S4U2proxy) extension permits the service to acquire a TGS of a second service on behalf of a person.
6- As soon as the online server will get the ticket, it should ship it to the SQL server to request entry to its knowledge and retrieve the data wanted for the person — (Determine 5).
- A person or laptop account with the delegation possibility enabled — “Belief This person/laptop for delegation to specified providers solely”.
- Native admin privileges on the delegated compromised host. If you happen to compromised the server as a daily person, you would wish to escalate to admin to abuse this delegation function.
This assault assumes that the attacker already has entry to the delegated machine with admin privileges. Entry is normally obtained by service account Kerberoasting or OverPass the hash with dumped hashes compromised from different machines. Right here is the breakdown of the wanted steps:
◼️ Figuring out the delegated hosts.
◼️ Requesting forwardable TGT tickets from the area controller with the delegated account.
◼️ Requesting service tickets with the obtained forwardable TGT tickets.
◼️ Accessing the requested providers.
We begin in search of the constrained delegation accounts by checking the msDS-AllowedToDelegateTo attribute within the accounts particulars. The attribute lists the providers allowed for delegation. These accounts may be enumerated with the PowerView Dev script or Energetic Listing module.
With PowerView Dev, we are able to run Get-DomainUser –TrustedToAuth 2>$null to get the constrained person accounts and Get-DomainComputer –TrustedToAuth 2>$null to get the pc accounts.
We will obtain the identical output with the AD module by working the Get-ADObject cmdlet and filtering for the msds-allowtodelegate property.
Get-ADObject -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo
The above outputs present that two (2) accounts permit delegation to particular providers. One is a person account, “websvc,” which permits the delegation to the CIFS providers on the MSSQL server, and the opposite is a pc account, “dcorp-adminsrv,” permitting the delegation for the Time service on the area controller.
The hazard right here is that if an attacker beneficial properties management of those delegated accounts, they will request alternate providers to what’s allowed and carry out extra assaults. In our case, we are able to alternate the CIFS and TIME providers with LDAP or WMI and dump credentials remotely, as we are going to within the later steps.
The subsequent step is to request Forwardable TGTs from KDC for our delegated accounts, we are able to use both Rubeus or Kekeo for this step. I’m going to make use of Rubeus for this text.
For Rubeus, we use the asktgt module to request the TGT tickets for the “websvc” and “dcorp-adminsrv” accounts. This step makes use of the S4U2self extension that enables a service to acquire a forwardable TGT on behalf of a person.
rubeus.exe asktgt /person:userName /area:DomainName /ntlm:Hash /outfile:FileName.tgt
After acquiring the TGT tickets from the area controller, we are able to now request service tickets for the allowed providers, i.e., CIFS and TIME, or alternate providers like LDAP or WMI.
To request service tickets (TGS) for the allowed providers, we are going to use the s4u module in Rubeus and the obtained TGT tickets within the earlier step. The msdsspn worth is the worth of the msDS-AllowedToDelegateTo attribute we discovered earlier within the enumeration steps.
The SPN for the websvc account is “CIFS/dcorp-mssql”, and for the dcorp-adminsrv is “TIME/dcorp-DC ‘’. The impersonated person is Administrator.
.Rubeus.exe s4u /ticket:TGT_Ticket /msdsspn:"service/HOST" /impersonateuser:Administrator /ptt
To confirm our entry to the service, let’s strive accessing the directories on the MSSQL service and see if we are able to record them. As seen, we have now efficiently listed the directories on the server with the obtained TGS ticket.
We talked about earlier that we might additionally alternate the allowed providers with different providers and carry out extra assaults like remotely dumping machine’s credentials.
To try this, we are able to use the s4u module in Rubeus, cross it the delegated SPN “msdsspn,” and the service we wish to alternate to “altservice.” In our case, we are able to alternate the time service on the area controller with LDAP to carry out the DCSync assault.
.Rubeus.exe s4u /ticket:adminsrv.tgt /msdsspn:"TIME/dcorp-DC" /impersonateuser:Administrator /altservice:LDAP /ptt
Working Klist exhibits us the LDAP ticket created for the impersonated person “Administrator,” and with that, we are able to carry out the DCsync assault and acquire the krbtgt hash.
As seen above, we efficiently retrieved the krbtgt hash; no extra permissions had been required to carry out this assault apart from the LDAP service ticket.
- To mitigate towards the abuse of delegated accounts, we are able to be sure that the privileged accounts are configured to “Account is delicate and can’t be delegated” inside the Energetic Listing or added to the Protected Person group to forestall delegation.
- If delegation is required for particular accounts, they need to be secured with firewall guidelines that solely serve the aim and delegation to the required service and restrict some other privileged entry that may not be crucial.
- Additionally, make sure the delegated accounts use sturdy passwords to guard them towards assaults like Kerberoasting.
That’s all for this text; we realized about constrained delegation and easy methods to abuse it in an Energetic Listing surroundings to realize entry to different providers than the allowed ones and leverage that entry to carry out totally different assaults.
Thanks for studying !!
🔔 All the used instructions may be discovered at R3d-Buck3T — (Energetic Listing — Privilege Escalation — Kerberos Delegations)
