[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?
Kerberos Resource-Based Constrained Delegations

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Shutdown (Charlie BROMBERG)

Shutdown (Charlie BROMBERG) Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @_nwodtuhs

29 Oct
[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.
Read 11 tweets
29 Oct
[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).
Read 20 tweets
29 Oct
[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
Read 11 tweets
22 Oct
[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
Read 23 tweets
21 Oct
[thread 🧵] ⚠️ nothing technical here, just sharing about my life

Since 2018, I’ve been creating or contributing to open-source projects, and I was wondering how many hours I spent of my personal time on this.

TL; DR: In 3 years, I squeezed in 1 year of additional free work.
Usually working from 7pm to 9pm almost every day, and from 1pm to 7pm almost every Saturday. This equals to, roughly, 2000+ hours.

I wasn’t very consistent and there were times I was doing 2h/week, some times 20h/week w/o lunch break.
There were also times I switched personal and professional work slots in order to optimise both, but the number of hours is ~ the same

ADHD signals here? Dunno 🤷‍♂️
Read 14 tweets
19 Oct
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?
Pass-the-Certificate is useful for the following attacks
- AD CS ESC8 NTLM relay cc/ @harmj0y @tifkin_ @ExAndroidDev
- Shadow Credentials (ACE abuse on accounts' msDs-KeyCredentialLink attribute) cc/ @MGrafnetter @elad_shamir
- UnPAC-the-hash cc/ @_dirkjan @elad_shamir
It can be operated when obtaining a certificate with Rubeus or @_dirkjan's PKINITtools (gettgtpkinit).
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(