Delegating Kerberos To Bypass Kerberos Delegation Limitation by Charlie Bromberg

Summary

Charlie Bromberg delivers a comprehensive talk on Kerberos delegation, focusing on how attackers can exploit these mechanisms to bypass intended security limitations. He begins by providing an overview of Kerberos and Active Directory, and then discusses various types of delegations and their properties. Bromberg vividly elucidates the intricacies of unconstrained delegation, constrained delegation, and resource-based constrained delegation, highlighting their potential abuses. He explains methods like s4u2proxy and s4u2self and demonstrates abuses such as privilege escalation techniques, while also discussing potential mitigations.

Highlights

• Charlie emphasizes the need to understand the intricacies of Kerberos delegation 🔍
• Delegation mechanisms like s4u2proxy and s4u2self are key exploitation points 🎯
• Bromberg showcases various vulnerabilities in common network setups 🕵️‍♂️
• Insight into resource-based and unconstrained delegation abuses 💥
• Discussion on defending against these security loopholes 🛡️

Key Takeaways

• Charlie Bromberg explores Kerberos delegation intricacies and how they can be exploited 🎤
• Kerberos has both constrained and unconstrained delegation with distinct security implications 🔓
• Understanding s4u2proxy and s4u2self is crucial for exploiting or defending against abuses 🔍
• Microsoft's RBAC and machine account quota settings can be leveraged for attacks 🛠️
• Mitigating these vulnerabilities requires careful service configuration and privilege management 🛡️

Overview

Charlie Bromberg, known as 'shutdown' on Twitter, navigates the complex world of Kerberos delegation, shedding light on potential abuses inherent in these security mechanisms. As an expert in cybersecurity, he explains how Kerberos' unconstrained and constrained delegation work, and how attackers might exploit them.

Throughout the talk, Bromberg explains the technical aspects of Kerberos, including TGTs, service tickets, and the various delegation models like s4u2self and s4u2proxy. He outlines how these mechanisms, while designed to facilitate legitimate interactions, can be manipulated by attackers to escalate privileges or impersonate users.

Finally, Charlie discusses various mitigations and defenses against these potential threats, such as configuring services responsibly and managing machine account quotas. He also taps into the broader realm of maintaining secure Active Directory configurations. With a keen sense of humor, he engages his audience with practical examples and insightful strategies for both attack and defense.

Chapters

• 00:00 - 00:30: Introduction In the 'Introduction' chapter, the host begins by greeting everyone and thanking the organizers and attendees of the Insomniac event. The chapter sets the scene for a discussion that will focus on Kerberos security issues, specifically highlighting abuses rather than bugs, taking inspiration from the words of Waldo.
• 00:30 - 05:00: Overview of Kerberos and Active Directory The chapter introduces Kerberos delegations and the ways to exploit its mechanisms. It covers how to use service for user extensions to bypass Kerberos limitations. Additional resources and links are provided for further reference.
• 05:00 - 10:00: Kerberos Authentication Mechanisms This chapter provides an overview of Kerberos authentication mechanisms and their integration with Active Directory. It begins with a brief introduction to Active Directory and Kerberos, serving as a reminder of foundational concepts. The chapter then explores different types of Kerberos delegations, identifying three to five main types commonly encountered. Detailed explanations follow, illustrating the functioning of these delegation types and the underlying mechanisms and extensions that enable Kerberos delegations. The focus is on understanding the logic and technical specifics of these authentication processes.
• 10:00 - 15:00: Types of Kerberos Delegations In this chapter, the speaker, Charlie Bromberg, introduces himself and the topic of Kerberos delegations. He works at Capgemini and plans to discuss the abuses of S4U (Service for User) to Proxy and S4U2Self, concluding with a Q&A session and providing resources and tools for further understanding.
• 15:00 - 20:00: Service for User (S4U) Extensions The chapter titled 'Service for User (S4U) Extensions' seems to be a part of a larger work, possibly related to computer security or pen testing. The transcript reveals the speaker's gratitude for the opportunity to conduct research in the field and apply their findings during penetration test engagements. The speaker is also identified as someone engaged in 'night jobs,' known for creating 'hacker recipes,' which are theoretical and practical methodologies. These methodologies are intended to convey the kind of information the speaker wishes they had at their disposal from the start of their career. Additionally, the speaker is mentioned as a co-creator of other tools, likely related to cybersecurity.
• 20:00 - 30:00: Testing S4U Extensions The chapter titled "Testing S4U Extensions" begins with a discussion on hexagonal pi whisker and kaby ross, among other topics. It then shifts focus to Active Directory and Kerberos, highlighting that Active Directory is a well-known set of services. A show of hands in the audience indicates that the majority are familiar with and have experience working with Active Directory.
• 30:00 - 40:00: Abuses of S4U This chapter discusses the presence of various services, particularly domain services within Active Directory, which have been around for decades. It highlights the potential for abuse in these services, acknowledging that some abuse mechanisms are already known while others are yet to be discovered. The chapter also touches on authentication mechanisms within Active Directory.
• 40:00 - 45:00: Security Considerations and Tools The chapter discusses two primary authentication protocols used in Active Directory Domain Services: NTLM and Kerberos. While both serve the same purpose, they operate in significantly different ways. NTLM relies on a three-way handshake process involving a negotiate message, a challenge message, and an authentication message. The operation of Kerberos, though not detailed in the transcript, is implied to differ from this method.
• 45:00 - 53:00: Q&A In the chapter titled 'Q&A,' the discussion revolves around the NTLM (NT LAN Manager) authentication scheme. It explains how the NTLM response, referred to as the NTLM hash or NET NTLM hash, is derived from the actual user's password hash, though it is not truly a hash in the context of this protocol. Typically, the domain controller determines whether a user is authorized to authenticate to a remote resource. However, exceptions exist when the user is a local user on the server as opposed to being authenticated through the domain.

Delegating Kerberos To Bypass Kerberos Delegation Limitation by Charlie Bromberg Transcription

• 00:00 - 00:30 [Music] so bonjour atus hello everyone thank you for coming to insomniac and thanks for the organizers for this great event thank you for hosting me for the next hour i will be talking about kerberos shenanigans and to take the words from waldo i will be talking about abuses and not bugs so
• 00:30 - 01:00 let's hope they just stay stay there in the long run i just took his id on the first slide you will have the link to the deck so if you need to take pictures or something feel free to do so but know this you have the deck somewhere on the internet so the talk is about kerberos delegations and how to abuse the mechanisms of kerberos delegations and service for user extension to bypass the limitation of kerberos
• 01:00 - 01:30 delegation so this is all just quite some logic here the contents of the talk will be as follows firstly i will briefly introduce everyone to what is active directory in kerberos just a quick reminder then we will talk a bit about quebros delegations the the three or five main types of delegation you will find and then i will uh make some detailed explanations of how these work and how the extensions and delegations work what are the mechanisms behind those
• 01:30 - 02:00 and then i will talk about the abuses of s4u to proxy as for yourself and we'll wrap things up in the end by forcing some of the questions you may have linking some resources and tools and doing the conclusion so without further ado let's let's just break the eyes together my name is charlie bromberg also known on twitter as shutdown written written on the reverse for the handle i work at capgemini which i truly thank
• 02:00 - 02:30 for the about opportunity to come here they allow me to do this research or at least take the time to uh try all this and give me the context to to try this during pen test engagements um you may also know me from some night jobs uh which is the hacker recipes which is a set of theoretical and practical methodologies uh again just to take the words from waldo i just write what i wish i had read from the beginning you also have other tools i'm co-creator
• 02:30 - 03:00 of hexagonal pi whisker targeted kaby ross and many other things so let's start with active directory and kerabros active directory is a set of services that you probably all know by a show of hands who knows active directory and has worked with active directory in the past yes so that's a huge majority here uh that's a good thing in active directory
• 03:00 - 03:30 we find a lot of services we just talked about azure ad before but one type set of services that we find usually is domain services this one will stick this one is here for decades and it has some abuse capabilities some are norm some are known sorry and some are left to discover in active directory we have authentication mechanisms uh to uh to to
• 03:30 - 04:00 say the least we have ntlm and kerbros which are the two main curb uh authentication protocols we we find in active directory domain services ntlm and kerberos serves the same purpose but they work in a really really different different way ntlm works in a three-way handshake first with a challenge message then with a negotiate message uh first with a negotiate message site then the challenge then the authentication authentication message and it works in a
• 04:00 - 04:30 scheme based on the challenge response where the response also called the ntlm hash or net ntlm hash is in fact derivated from the actual user's password hash it's not really a hash in this protocol the domain controller usually decides if the user has the right or not to authenticate to the to the remote resource i say usually because there are cases where the user is a local user on the server and the domain
• 04:30 - 05:00 controller doesn't have his saying in if the user has the right or not kerbros works a bit differently it works based on tickets these tickets called tgts and service tickets are obtained through a first step that is called the pre-authentication step which is optional but i won't deep dive in this it's out of the scope but just to remind uh it's based on tickets yes but
• 05:00 - 05:30 at the beginning it's also based on the long term key which is also derivative from the user's password so it makes kerberos nntlm vulnerable to lots of things lots of abuses lots of bugs also here is a a quick list of those the aim of that list is not to say that kerberos is more dangerous that ntlm this this would be wrong this would be false this slide just shows that
• 05:30 - 06:00 there are a lot of paths to discover to explore when attacking kerberos there are a lot of paths too for mtlm but i mean ntlm is really dangerous it's really old it's badly constructed but kerberos has its flows too and since this protocol is far less known than ntlm it's far more subject to some abuses and attacks if you want more information on when do these attacks occur when are
• 06:00 - 06:30 these abuses taking place during the authentication mechanism you have a mind map on the left on the right on this of the slide which is accessible on the hacker recipes if you want to understand it clearly so let's do some quick reminder of how kerberos authentication actually works well as i said earlier you have a first step with which is the pre-authentication step and this one while it's optional it it really um
• 06:30 - 07:00 is the first step to grant a tgt for user i say it's optional because there is a an abuse case called as rep roast where you can disable the pre-authentication for user but in fact this step is usually taking place and allows the user to make a request to the authentication service the as that is located on the kdc the key distribution center and it allows him to obtain a tgt tgt stands for ticket granting ticket
• 07:00 - 07:30 it's a ticket but what does it do it grants ticket and it grants what types of ticket well service tickets so bear with me here usually you see on the internet that the acronym for service ticket is tgs well it's not quite true the tgs usually stands for the ticket granting service it's a service it's not a ticket the ticket the acronym for service ticket would be st and this is the acronym i will be using
• 07:30 - 08:00 in this deck but if you see tgs somewhere referring to tickets uh this is uh this is quite normal people you'll usually tend to mix a few things and with microsoft parlance it's quite common so the service ticket what is it what's its purpose the service ticket's purpose is to allow the user to access a resource in this ticket you will find information about the service the
• 08:00 - 08:30 service class the service name the service realm and you will find information about the user as well you will also find in that ticket and in the tgt as well the pack the pac stands for privilege attribute certificate and it's all the information regarding the user that the remote resource will unpack and check and verify to see if the user really has uh the authority and the privileges necessary to access the said resource so now that it's perfectly understood
• 08:30 - 09:00 how kebros works i really believe it now let's talk a bit about delegation so kerberos delegations there are let's say two families the first one is the unconstrained family and the second one is the constrained family well you can guess it from the name unconstrained means no limit the kerberos delegation is a mechanism allowing a service to access another service on behalf of a user this is a legitimate behavior
• 09:00 - 09:30 by microsoft there is no issue with this but we will see the different abuse scenarios later on the end constraint is no limit the service configured for unconstrained delegation can act on behalf of another identity on a remote service on any other remote service the constrained one well it's limited the first service configured for kcd for constraint delegation can act on a set of services and rbcd resource based on
• 09:30 - 10:00 strain delegation is quite similar but the other way around and then on the constrain delegation there are there is a setting called protocol transition when configuring an account for constraint delegation you have the choice between using kerberos only which is without vertical transition and use any authentication protocol which is without vertical transition so here is uh some here are some diagrams to better understand what are the uh behaviors and mechanisms behind
• 10:00 - 10:30 kerberos delegation so as i said the unconstrained delegation allows the service that is configured for it to act on behalf of another identity on any other service there is no limit here it's really dangerous if this service gets pawned the attacker will be able to act on any other user on let's say the domain controller services when i say any other user there is a limit here the limit is the protected users and the users set sensitive for
• 10:30 - 11:00 delegation we will talk a bit later on deep dive on this matter constrain delegation is the exact same thing but instead of having the right to act on anyone's behavior on any service it's only on the list of services and then the rbcd when i said it's the other way around it's because instead of configuring the service that we'll delegate we configure the service that is the target of the delegation instead of having an outgoing delegation with unconstrained and constrained delegation
• 11:00 - 11:30 we have an incoming delegation with rbcd the difference here resides in the fact that unconstrained and constrained delegation require really really high privileges on the domain it's the se enable uh delegation privileges on the domain which is uh close to domain admin rights and the rbcd doesn't require those ultra high privileges it only requires control over the service that we will configure
• 11:30 - 12:00 for rbcd and for example computer accounts on the domain have the right to edit their own rbcd attribute that is called the msds allowed to act on behalf of other identity thanks microsoft for that um now i have to drink a bit sorry for that yeah so it doesn't require all that power on the domain to configure rbcd so now that you have perfectly understood i'm sure of it the
• 12:00 - 12:30 differences between unconstrained constrained protocol transition with or without resource based on screen delegation let's see how these work really this is um just again to uh to uh quote waldo from the the talk before uh we have to deep dive and go beyond the documentation to really understand what are the mechanisms of those protocols once we understand that we should be able to find some abuses just a quick disclaimer here the abuses that i will be talking about are not
• 12:30 - 13:00 abuses that i will i had have discovered myself i'm just quoting a few other things that i found on on the internet and put it all in a in a nice red and orange diagram for the theme the unconstrained delegation works like this a user first needs to obtain a tgt and later on when using that tgt to obtain a service ticket for a service when the kdc will see that the service target for these the uh the
• 13:00 - 13:30 service ticket is configured for kerberos unconstrained delegation which i will refer to as kud it does something really special it adds it delegates the tgt in the service ticket so the user that sends his service ticket to the service configured for kud has in fact its tgt delegated included in the service ticket what this allows it allows the service configured for kud to actually extract
• 13:30 - 14:00 the tgt from the user and act on behalf of the user with his tgt to access any other resource while this works for any user it doesn't work for the users set sensitive for delegation or put in the protected users group that's the only limitation here so let's do a quick swat analysis strength weaknesses opportunities and threats what this allows is that you can in fact act as as any other user with the limits
• 14:00 - 14:30 i explained before but the limit here is that actually if the attacker gets obtains control full control over the kud he won't be able to impersonate users out of thin air he will require the requirement here is to obtain an incoming authentication from a user because without that authentication the service will not receive the service ticket and hence will not receive the tgt of the user so he won't be able to
• 14:30 - 15:00 act as that user there are workarounds to force coerce the authentication you the core the authentication of users sorry for that for example uh rpc abuses based on msrp iran the printer blog ms efsr ms office rvp there are a lot of abuses the attacker can also just sit and wait and see for users to access that resource because usually this service is not configured for kud for no reason at all
• 15:00 - 15:30 usually users connect to that service constraint delegation is a bit similar in the way that it requires an incoming authentication from the user but here the tgt is not delegated in the service ticket here we will begin to talk about service for user extensions which are extensions in the kerberos mechanisms here we've constrained delegation without protocol transition so when it's
• 15:30 - 16:00 configured for kerb ross only the user when he obtains a ticket to access the resource the ticket is a standard one but when the service obtains that ticket the service configured for kcd obtains that ticket he includes that ticket in a tgs request in a tgs rack a request for obtaining a service ticket and in that request he will include an additional ticket and evidence that the user has in fact authenticated to the service
• 16:00 - 16:30 and this is called s for you to proxy service for user to proxy it's a request that allows the service configured for delegation to obtain a service ticket on behalf of another user to another service while this allows the exact same thing it allows the service to access another resource on behalf of another user here the list of resource of target resources like app02 are limited it's configured on the account
• 16:30 - 17:00 and the requirement of having you need you need the incoming authentication from the the user is still here with constraint delegation without protocol with protocol transition sorry for that uh it's a bit different so while i'm sipping a bit of water i'll let you find the differences find waldo which is my name the differences between the diagrams of without and with protocol transition
• 17:00 - 17:30 okay this was just an excuse because i was really thirsty okay so the constraint delegation with protocol transition as you can see probably guess if you are too far away in the room um there is something missing here it's the user the user is not part anymore of the diagram with vertical transition you have i mean the service configured for kcd with protocol transition has the ability to impersonate users out of thin
• 17:30 - 18:00 air he doesn't need the incoming authentication from the user and how does he do that he does that by calling by requesting an s for you to self now we talked earlier about the s4u2 proxy which is a request allowing the service to obtain a ticket on behalf of another other user to a remote service as for yourself is quite similar it allows the service to ask a service ticket to itself on behalf of another user so as for yourself in fact is the only
• 18:00 - 18:30 difference here in the mechanisms between with and without protocol transition for kcd and then we have rbcd i won't go into too much details here what we have to uh understand and remind is uh keep in mind sorry is that the our obesity mechanisms are quite similar to the kcd one instead of having an outgoing delegation we have an incoming delegation uh when we uh
• 18:30 - 19:00 take place from the o2 which is the one now configured for rbcd but the process is the same you can either the service that wants to delegate can either wait for a service ticket from a user or get one with as for yourself now i'm sure it's perfectly understood you have all understood really 100 how delegation work so let's now deep dive and something you wish you wouldn't have heard service for user extensions
• 19:00 - 19:30 these extensions are in fact the mechanisms behind delegation if you followed the the explanations before kcd is based on s4u extensions and rbcd as well so let's now find the differences between s for yourself and it's for you to proxy and understand how these work and i promise this is one of the last explanations of this talk and we will do some tastes tests later on so as for yourself as i said earlier
• 19:30 - 20:00 allows a service to obtain a service ticket for oneself for itself on behalf of a user but while this concept is quite easy to understand there are a few variables to take into consideration the service ticket that is produced after the s for yourself that is sent by the kdc by the key distribution center has one thing that is essential for us for you to proxy it's the affordable
• 20:00 - 20:30 flag if the impersonated user is protected by any means like it's set for sensitive for delegation it's uh put in the protected users group then the service ticket produced by the s4u itself will exist it will produce a ticket however the forwardable flag will not be included in the ticket and what this does is that the s4udo proxy will fail because the requirement of the s4u to
• 20:30 - 21:00 proxy is to use an additional ticket in the request that was either produced by the svu self or received to bring the incoming authentication from the user and if that forwardable flag is not present in the ticket then the s4u proxy will fail and the kdc will will say something like come on man you don't have the permissions to do this shut up just no but there is another thing if the affordable flag is not set there is a specific scenario based on rbcd which i
• 21:00 - 21:30 will be explaining later on another thing is that the service ticket produced by the s4u proxy always have the affordable flag set and some of you might guess where i'm coming if you manage to do a nest for the proxy and include in the additional ticket a ticket produced by an s4u proxy you know as video proxy produces its ticket used then bias for your proxy then it will work because the flag will
• 21:30 - 22:00 be present in the ticket but we will see that that later on everything stated here is just taken from the awesome and extensive blog post from eli shamir which you can see on the right walking the dog all the links will be in the deck link is already here um but do we really trust a random blog post on the internet you shouldn't well this is a this is far from being a random blog post i can assure you this takes months to digest but let's say that for the sake of this talk
• 22:00 - 22:30 we will do the tests ourselves so let's begin with the tests for sv yourself let's say that our our service is not configured for delegation for any kind of delegation will the s4u itself work well the answer to that is yes it works but is the affordable flag present in the ticket the answer is no so let's move on to the second part what happens when the service that asks for the uh as for yourself is configured
• 22:30 - 23:00 for kerberos constrained delegation without protocol transition um by a show of hands who can really read that slide no one okay awesome from the front rows i can assume that either the one the ones on the fourth on the four first rows don't really have uh you need vinyl glasses you need glasses okay so the affordable flag is not present in
• 23:00 - 23:30 the ticket because here the service is not configured for uh protocol transition it doesn't have it it has constrained navigation without critical transition so the ticket issued by the service doesn't have the affordable flex set and for the ones for the majority who cannot read these slides but they will be they really are available online you should see that in the ticket somewhere right here but you cannot see my mouse um you have the username domain admin stated in the ticket it's the user i'm trying to impersonate to act on
• 23:30 - 24:00 behalf of and then you have the target service which is the service that asked the s for yourself because that's where the self is obtaining a ticket for itself now what happens if we switch from no protocol transition to with protocol transition if you fall out you should have receive a service ticket after the s for you yourself with the affordable flag set and this is what happens exactly on the first command of the slide i used
• 24:00 - 24:30 find delegation pi which is a script of in packet i'm not so fond of powershell myself so i'm using python here um but you can see that i mean you can guess trust me that the service configured for delegation is configured with protocol transition and what this does is that when calling the s for yourself extension the ticket obtained is configured with the affordable flag but then what happens if we keep the
• 24:30 - 25:00 same configuration but instead of asking as for yourself to obtain a ticket as any other user let's say that we want to impersonate a protected user a user that should be protected uh against the legation well it's the same behavior for users set as members of the protected users group or users that are set sensitive for delegation it doesn't work i mean the s word itself works but the affordable flag said
• 25:00 - 25:30 the affordable flag is not set in the ticket now what is the impact of all these tests i'm sure you found very boring on his food or proxy well with no delegation we obtained a ticket that didn't have the affordable flag set so it fails uh the last line of the s42 proxy command shows that actually the service doesn't have the delegation right because the ticket in fact doesn't have the affordable flex set second use case what happens with kcd
• 25:30 - 26:00 but the pro the ticket issued by the s4 itself didn't have the affordable flag set well this happens because the kcd was was configured without vertical transition well as we do proxy fails again but now what happens if the service was configured for a kcd with protocol transition the forwardable flag was set in the service ticket which means that when late when used later on with the s4 your proxy the s40 proxy succeeds and we see that the ticket obtained with us for you to proxy
• 26:00 - 26:30 is actually targeting another resource resource stated in the list of delegation of the accounts acting as another user and then there is another use case i told you earlier that i would deep dive in rbcd you probably are fearing that moment that moment is coming winter is coming it's here the story of s for your proxy and rbcd so we have a service configured for rbcd and another service that is in in in
• 26:30 - 27:00 this list is trying to obtain a ticket so he's trying to obtain that ticket using this for you to self because that service is not configured for kcd with protocol transition that s for your proxy 60 as for yourself sorry it succeeds but the ticket doesn't have the affordable flag set so if you followed the previous tests it should fail right the s42 proxy should reject the request and say come on man the additional ticket didn't have the affordable flex set so it doesn't work but in fact it does
• 27:00 - 27:30 and why that well let's say let's see what microsoft has to say about this because here in fact the documentation is quite correct we just have to read it and then understand it and digest it what it says is that actually in order to accept ns4u proxy request you either have to have the affordable flag set on the service ticket used in the additional uh
• 27:30 - 28:00 used in the request or you have to have the rbcd bit set in the request this bit is set by the client by the client who's doing the request so i was like come on man if you have affordable flag that is not set in the ticket can you with your client set the arbisity bit and then bypass all of this well the answer is no the kdc chooses that and if the obesity bit is set in the uh request he will double check that the service does indeed
• 28:00 - 28:30 have is listed somewhere in the rbcd list of the target service so i was wondering then okay uh but are we sure about that uh do the tools that we use uh really include that well the answer is yes here is how rubios works with this which is the c-sharp toolset to manipulate and work with tickets and here is how impact works i won't go into the details because i think i don't have the time but i trust you to do that homework later on
• 28:30 - 29:00 so now that you have all perfectly understood how the authentication works how the delegation works how the with or without protocol transition affects the mechanisms and how the s service for user extensions work let's talk a bit about abuses i'll let you some time to digest that meme which is i think of the highest quality
• 29:00 - 29:30 ever okay so all right listen to this since s voodoo proxy produces affordable ticket why not use s for your proxy to obtain a ticket that meets the requirements of espio proxy that is genius i mean for the people that understood that because i took it took hours for me to understand and to digest but let's see this together we have three kind of scenarios we can we can tackle with the first one is the obesity trick
• 29:30 - 30:00 let's say that the app o2 is configured for kcd without protocol transition meaning that yes for you to self will produce an unaffordable ticket and let's say that we have controlled we have control over that service this means that we can configure rbcd on this machine because computers have this right themselves and let's say we have control over another service let's say app01 this is possible thanks to the great mission account quota domain level setting that
• 30:00 - 30:30 is set to 10 by default that allows any authenticating authenticated user on the domain to create and join up to 10 mission accounts awesome i don't know why this this exists and it's not limited to admins but okay let's use that and abuse that so the scenario is you have control over app02 which is configured for kcd you configure rbcd on that you have control over app01 you use app01 with the specific rbcd mechanisms
• 30:30 - 31:00 to obtain a ticket with this for you to proxy on behalf of another user for app02 and what will happen here is that from app02 perspective you will receive something that really looks like a ticket produced by as for yourself but this ticket since it's produced by our bcd's as we do proxy will be for audible so you will be able to use this
• 31:00 - 31:30 with this with us for your proxies for the kkcd part and it bypasses the whole i need the user authenticating to me requirement so i had planned or at least hoped to make a demo but there are a lot of concepts and i think you are starting to be hungry so let's uh jump right to the backup slides the uh first slide here you cannot see it trust me
• 31:30 - 32:00 you have the service that is configured for kcd uh kerberos constraint delegation without protocol transition that is trying to do ns4 yourself it succeeds but the ticket obtained is not affordable so the kcd service cannot impersonate users out of thin air i mean right now but what happens if we create with add computer the first command we create a computer account called croissant and then use that computer account to do rbcd
• 32:00 - 32:30 well the first step is to obtain an s for yourself ticket and you can see in the flags i mean guess i mean trust me that the flags here do not include the affordable flag but it doesn't matter because as you've seen from wolf wiggum uh this is special this is we are talking here about rbcd and rbcd doesn't really care about if the affordable flag is set on the ticket produced by us for yourself so here it's not affordable but it's forwarded anyway thanks to rbcd
• 32:30 - 33:00 what happens is that we now have a second ticket which is a ticket aimed at the service configured for kcd as another user with affordable flex set on and it really mimics the mechanisms of this for yourself we now have a ticket that would be produced by us for yourself with protocol transition however the service is not configured for protocol transition is configured without it would require an incoming user authentication but now it doesn't
• 33:00 - 33:30 and we can impersonate users out of thin air we can use that ticket in the additional ticket part of the yes for your proxy request and now say i want to act on the behalf of dominion domain admin on svo1 which is the actual target of this whole scenario and then i used that ticket and showed that in fact it's usable with a with a secret stump sam remote salmon lsa dump so the first scenario is really possible
• 33:30 - 34:00 but it requires the creation of another mission account it requires the machine account quota set to 10 which usually is the fact when it's your client's first pen test engagement but on the second try you will not find that so let's just do self obesity we don't we do not need another computer account let's just say that app o2 is configured for rbcd for itself we can delegate to itself
• 34:00 - 34:30 and with this we actually bypass the limitation of this for you to self which produces an unaffordable ticket that is that cannot be used with us for you to proxy with this mechanism you can chain the first test for yourself then an s4u proxy to self and then use that ticket to do the real estate proxy to sv1 and on the left i just did the test and it works and then you have the third scenario which is double kcd this is exactly the same
• 34:30 - 35:00 thing as the rbcd trick uh just here let's say we have an app01 that is under our control and apple 2 which we control also let's say up a1 is configured for this for kcd with protocol transition yes the s4u2 proxy will work and will allow like our bcd trick to obtain a ticket that mimics this for yourself on the apple 2 and this will bypass the limitation of this for you to proxy now we have seen the abuses case of uh of us
• 35:00 - 35:30 figure proxy awesome are there any kind of scenarios and abuses we can do with us for yourself i'll let you guess the answer the answer is yes i wouldn't be talking about that if if it weren't the case so before talking about the abuses and the scenarios let's just remind or understand a few things two i mean uh the first thing is airs for yourself
• 35:30 - 36:00 doesn't really take the delegation protection into consideration i mean it does because it doesn't include affordable flag in the ticket but it still produces a ticket right so wouldn't that ticket be usable and allow for local privilege escalation let's say you obtain a service ticket you act as the service and you obtain a service for yourself as a domain admin or local admin i mean this would be an lp right well the answer is yes but no
• 36:00 - 36:30 because the ticket is issued for a service that is not valid the service is actually the name of the account that did the request but there is another thing the service name is not protected in the ticket and you can change it and will there be a check about that the answer is no you will be you should be able to modify the service name the s9 the spn included in the ticket and make that ticket valid and usable
• 36:30 - 37:00 and this is what i did here again you cannot read it trust me in the first ticket the service name is if i remember correctly self dash pc dash kcd dollar which is not valid but let's say that we want to use that ticket well let's just you know substitute that spn and change it because it's not protected and it works so
• 37:00 - 37:30 we have two scenarios the first one is an lpe primitive and the other one is the stealthier silver ticket this is not really a lateral movement thing it's only a persistent thing but if you like to stay stealthy um i mean you'll like that one in order for the lpe primitive to work the first step is the tgt delegation trick this relies on the fact that microsoft virtual accounts like default app pool or the network service accounts on a
• 37:30 - 38:00 windows machine can indeed on the network perspective acts on behalf of the machine so if you use ruby use which has a tgt delegation trick included in its features you can indeed obtain a tgt for the machine account and the machine account doesn't have admins privilege to itself but what it does it it actually handles the authentications and the access to the services that it handles so you can you
• 38:00 - 38:30 know when you have knowledge about the service key the long-term key of a service you should be able to do a silver ticket and access that service with a forge pack and say you are let's say a local admin well this works a bit similarly you obtain a tgt use that tgt to make an s for yourself and say okay i want a ticket to myself as another user let's say a domain admin well this works the affordable flag is not set in the
• 38:30 - 39:00 ticket but but we don't care really in fact because we don't use as we do proxy what we want to have access to is not a remote resource it's a resource itself that did the we we want local privilege escalation so it works but what happens when you try to do this with a user sensitive for delegation or a protected user against the legation as for yourself is if i remember correctly a delegation extension i mean an extension linked to the legation so it would it shouldn't work but it does
• 39:00 - 39:30 if you request an s for yourself with a sensitive admin protective admin or or something like this and let's say in the same command you do the spn substitution the tgs sub well you will obtain a ticket that is valid that doesn't have the affordable flex set on but we really don't care and that is usable so we do use it and in the last command you see that i escalated from default app pool
• 39:30 - 40:00 with a web server installed on the surface to local admin and i dumped the sam and lsa hashes and this is not a bug this is an abuse so just again this will stay in the long run there is another scenario it's stealth year silver ticket if you know the long term key of a service you should be able to construct and forge a ticket with a pack uh stating that let's say your user
• 40:00 - 40:30 is part of all the groups of the domain admins and it has the 500 air id or something like this the only thing is that it's not really stealthy because it's not stealth or stealthy i don't know the thing is that primitive that primitive is quite known and it's monitored all the way usually but what about as for yourself as food itself is far less known not monitored as much and it has a legitimate pack in the
• 40:30 - 41:00 ticket it's a real ticket issued by the kdc so why not use it instead of a silver ticket well the answer is yes use it okay so let's wrap things up i'm sure i mean i hope some of you have questions um but i don't like to be surprised so i try to guess a bit of those questions i guessed three of those the first one is okay charlie you explained to us that the spn is not protected in the ticket and we
• 41:00 - 41:30 can change it but how about the affordable flag the affordable flag is the requirement for us for your proxy work right so if we take a ticket edit that affordable flag which is not in the encrypted part of the ticket it should work and the answer is yes i mean no it worked for a while because that cve was disclosed in 2021 and now this is patched so it doesn't work anymore now the kdc makes additional checks to check that indeed you should have affordable flag set okay now
• 41:30 - 42:00 you should have a second question how to mitigate all this how to protect against this well don't take my word for it just take microsoft's one you just have to understand that as for yourself and as for your proxy extensions are really dangerous and you just only have to protect all your services that use those like you would protect your kdc your domain controller of course why didn't i think about that uh yeah yeah yeah that is um that is rich okay so last questions usually this question is
• 42:00 - 42:30 turned the other way around people like waldo infuriate me because they always use powershell which i don't really like because i don't understand it so how can we use this from linux well that would be petty of you because i showed you how to exploit it from linux not from windows i assume this would be your question so i made a quick equivalence table between the tools available from uh rubios and the tools available from impact so now you have this and uh
• 42:30 - 43:00 you have also this i did the effort here i did the homework uh i tackled a bit with rubios i never do so that that is probably why it's not readable because i don't want you to see what i did you will see in the online slides i just did the double kcd scenario with rubios it works it's just too small for you to read and it is great for me so uh this is the end of the foreseeing
• 43:00 - 43:30 questions we can now get to the acknowledgements part really again if you are interested by this and if you are not asleep yet just wake up and now you can see all the links and resources i used and the ones i quotes uh i quoted like illachamir that wrote again an extensive and undigestable blog post about this everything is written here there with reviews so if you want to see what it's used how we can abuse this with linux uh go back to my slides
• 43:30 - 44:00 and then we have uh articles about uh s4u about kerberos uh did uh that will schroeder uh jorgen uh charlie clark snow crash and pixies wrote and these are awesome articles if you want the links here they are um i also included my own links you know shameless self plug you have the links from the hacker recipes which is the blog post and website i hope i had found when i started my journey into active directory
• 44:00 - 44:30 you will also find an and you will not be unable to understand these mind maps because i'm not able to understand them myself even if i made them myself but here they are and if one day you find yourself tackling against delegation you have these those mind maps that tell you step by step what to do in each scenario also i included a glossary because when people call an nt hash and ntlm hash and
• 44:30 - 45:00 call an ntlm response an end net ntlm hash i mean everyone is just fed up with this don't call a service ticket atgs this is the service well the glossary is here i mean my glossary at least for the tooling you have all the list of the tools i used and want to highlight in these slides you have find delegation get together get a c describe ticket ticket converter and so on which are script examples you can find on impact if you want to do these tests yourself
• 45:00 - 45:30 just keep in mind that there are still some of my pull requests that are pending everything is not merged yet but you can do those merges yourself and use those uh those um those tools if you do not want are too lazy to uh do those merges yourself you can use exigal which is my docker container multi-container i mean it's perfect it replaces completely kali linux which i find really really great
• 45:30 - 46:00 and you also have a rubio's bloodhound and the hacker recipes in the list are there any questions left for you to ask me please do not corner me i don't know a thing i think we'll start by thanking you for the talk that's very good [Applause] [Music] [Applause] hey hi thank you for the talk nice talk so i've
• 46:00 - 46:30 i have a question which regards like this privilege escalation so do you think with the data and information you leak it would be possible to make a ransomware out of this vulnerability should i answer that question i'm not really sure um first of all bonjourno i guess so i think if you have access to the service if you know the key the only limit here is that for the lpe trick you
• 46:30 - 47:00 really do need to have access to the machine for the tgt delegation trick but if you know the service key the machine account key you should be able to generate silver tickets i mean equivalence to silver tickets you should do the yes where you do self yourself but if you do not know that key and need the tgt for the s4 yourself you would need an access to the machine which is not really that convenient for ransomware perspective
• 47:00 - 47:30 okay well a little bit of work to do but answer me for who [Music] yeah um do you know if it's possible to make a use case based uh in order to detect those attack based on the microsoft event logs i guess so but my experience and knowledge about
• 47:30 - 48:00 this is close to the ground so i have no answer for you but i guess so okay i guess you could maybe tr uh put some triggers on the calls for extensions for yourself as for your proxy i guess hi thanks a lot for your talk i had a question about whether this applies only to kerberos for microsoft or would it apply like would these extensions exist elsewhere
• 48:00 - 48:30 [Music] if i remember correctly but i'm not really sure about that i think those extensions are are microsoft products but i'm not really sure this is a great question because i wonder what would happen in environments that implement kerberos without having the microsoft ecosystem it's a really great question and i don't have a particular answer to that but i will do the research it's yeah i didn't think about that
• 48:30 - 49:00 [Music] uh thanks for the great talk i have two questions uh the first one is uh do you know why as for yourself works kinda for the accounts that are protected why is the tickets returned in the first place is there any legitimate cause for that
• 49:00 - 49:30 if you're talking about um the point that waldo made earlier that is understanding the intent i do not know i don't know i don't know why the s for yourself still produces a ticket that is not affordable i have really no uh if i remember correctly it's a feature by microsoft because it allows the microsoft virtual account to react on behalf of other services but that's my guess i'm not sure i don't know if there's anyone from ms here
• 49:30 - 50:00 thanks and the second question is i do know of any way to remove remove the user has to authenticate to the service requirement for the unconstrained delegation as you did for constraint is there any way that you know yep i wondered that myself because since unconstrained delegation is like its name implies unconstrained and you can target any service it's a very good question let me
• 50:00 - 50:30 get back to the slide yep so um the answer is no because unconstrained delegation doesn't um rely on s4u extensions it relies on a tgt delegation when the user wants to access the service that is set for unconstrained allegation there is no ways for yourself there is no aspirated proxy the tgt of the user is in fact
• 50:30 - 51:00 packed and put into the service ticket for the service and when the kud service will receive that ticket he will unpack it take the tgt and use that tgt as if it was his own so in a way and constrained delegation is safer in this regard kinda i didn't no no no no no mean in a sense yes because you wouldn't need another requirement which is the coercion the authentication
• 51:00 - 51:30 conversion of the user you want to impersonate but i mean this exists you have printerbug which relies on an abuse of msrprn you have msc fsr us you have ms fsrvp to coerce uh machine authentications and then you have lots of other mechanisms to poison and spoof in the network like llmr adidns the hcp v6 you have lots of those so usually obtaining an authentication is not really the
• 51:30 - 52:00 biggest issue there don't use unconstrained delegation [Music] uh thank you for the great talk uh do you have any recommendations on how to defend against this other than just protect your
• 52:00 - 52:30 services wait a bit here you go yes do you have any other than the big redness i'm just messing with you man i have no idea i like to abuse things i don't like to protect them other yeah let me think about that remove the uh 10 value of the machine account quota
• 52:30 - 53:00 to prevent users from creating machine accounts uh set a trigger an event log when uh unauthenticated i mean authenticated users with standard privilege create a computer account uh and maybe do some behavioral analysis when rbcd is chained with kcd right after when when there are two delegations implied with the same service there should be something wrong here but that's my take i'm not the one who defends
• 53:00 - 53:30 all right great thanks again charlie thank you for listening [Applause]