[thread 🧵] Kerberos delegations. This meta-thread gathers three sub-threads, one for each delegation type. I’ll talk about Unconstrained, Constrained, Resource-Based Constrained (RBCD), S4U2self, S4U2proxy and abuse scenarios.
Kerberos delegations is a set of features included in the Kerberos authentication protocol. It allows services to access other services on behalf of domain users.
3 types of delegations exist
- Unconstrained: service can access any other service on behalf of any user
- Constrained: service can access a set of services on bhalf of any user
- Resource-Based Constrained (RBCD): service grants that « impersonating access » to a set of services
Nota bene: « any user » is not 100% true. There are limitations that I will cover later on. But TL;DR: some users are secured and cannot be delegated. Services cannot act on their behalf.
What purpose do delegations serve? They allow services to access remote resources and limit what the service account has access to. This is nice! Users have specific access that some service accounts configured for delegation can temporarily profit from by acting on their behalf
Now, let’s dive in the different types of delegations and how to abuse those shall we?
[thread 🧵] This is a sub-thread on Kerberos Unconstrained Delegations (KUD) and abuse scenarios
User granted with the SeEnableDelegationPrivilege right in the domain (really high priv ⚠️) can configure service accounts for delegation (unconstrained or constrained).
If an attacker owns a service account configured for Unconstrained Delegation, escalation to domain ad rights is almost guaranteed. The service account can act on behalf of any* other AD principal on any service.
[thread 🧵] this is a sub-thread about Kerberos Constrained Delegation (KCD) and abuse scenarios.
Similarly to Unconstrained Delegations, service account configured for KCD can act on behalf of other principals on other services. The difference is that with KUD, it’s possible to delegate to any service whereas with KCD it’s possible to delegate to a specific set of services
User granted with the SeEnableDelegationPrivilege right in the domain (really high priv ⚠️) can configure service accounts for delegation (unconstrained or constrained).
[thread 🧵] this is a sub-thread about Kerberos Resource-Based Constrained (RBCD) and abuse scenarios.
While configuring accounts for Unconstrained and Constrained delegations requires high privileges in the domain, configuring RBCD is simpler. RBCD is configured on the service others delegate to.
This can be done by filling the service’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute with other services SIDs. This allows other services to delegate to it.
Abusing high-priv users to edit that attribute on another account is an Access Control abuse and is another topic
[thread 🧵] Kerberos basics & (ab)use of Certificates within Active Directory (i.e. AD CS and PKINIT)
- Kerberos 101
- Pass-the-Certificate
- UnPAC-the-Hash
- Shadow Credentials
- AD CS escalation (ESC1 to ESC8)
(Links and credits at the end)
[Kerberos 101 ⬇️]
AD-DS offer two main auth protocols: NTLM and Kerberos. Kerberos works with tickets in order to authenticate a user.
A TGT (Ticket Granting Ticket) can be used to obtain a Service Ticket. A Service Ticket can be used to access a service. This is how it works.
1. User requests a TGT (Ticket Granting Ticket) 2. Domain Controller requires pre-authentication 3. User pre-auths and receives a TGT 4. User requests a Service Ticket and gives his TGT 5. DC sends the Service Ticket 6. User can now use the ST and access a service
Shouldn't we all agree that using a certificate to go through a PKINIT Kerberos pre-auth to obtain a TGT should be called Pass-the-Certificate? Or is there a reason we should avoid using that term?