Kerberos: Trust Your Delegations, Don’t Just Delegate Your Trusts

Trust your delegations. Don't just delegate your trusts. My name is Darryl Baker. I am a security consultant with Trimarc Security. I am the creator of Active Directory Hacking Village, also known as Identity Security Village. And I'm a purple teamer. Today, we're going to talk about Kerberos authentication and delegation, different types of Kerberos delegation, trending Kerberos delegation attacks, including KrbRelayUp; some delegation behavior across AD trusts, as well as delegation behavior across your Cloud Infrastructure, such as Azure AD or Azure VMs when using Hybrid Active Directory join; specific attack vectors for delegation in Hybrid AD, as well as mitigations for all of this. So to start off, what is Kerberos? Kerberos is a network authentication protocol. It is based on a ticket paradigm, and it allows for two trusted hosts to authenticate securely over an insecure network using a trusted third party. So this allows for communication across intranets, internets, and other types of networks, even if you don't have any other infrastructure in place aside from a domain controller and then these two trusted hosts. It is the preferred authentication method for Windows domains, although it is not the only authentication method. NTLM is also commonly used in Windows domains, though there's a lot of attacks that are targeted around NTLM. But NTLM is always used with Windows machines if either a server or the client is not domain joined. So NTLM, very active still in the environment, but Kerberos is definitely more secure and preferred. To start off, before we can dig too deep into delegation and what Kerberos delegation looks like, we first have to talk about Kerberos authentication. So Kerberos authentication consists of about six different steps. And we'll go through those briefly. So step one is known as the authentication service request, and there's actually a piece of authentication that happens here. The client will take a timestamp, and then encrypt that timestamp using the hash of its password, and send that over to the domain controller. The domain controller knows the client's password, so it uses the hash of the client's password. In order to decrypt that, it checks the timestamp, and it makes sure that time is within five minutes. If all of that checks out, then the domain controller replies with a authentication service reply. And in this reply, there is a ticket granting ticket known as a TGT. This TGT is good for 10 hours by default, and it's used for all subsequent service ticket requests after that. The main purpose of a TGT is to prove that that client is that client whenever requesting service tickets to any other target resource. So with step three, the client will then use the TGT and present that to the domain controller and say, I would like a service ticket for some target resource. The domain controller will check out the TGT, make sure the client is who they are, and then replies back with the service ticket, also known as a TGS. Once the client has the service ticket for the resource server, it will present that service ticket to the target resource. This is known as an application request. And the target resource will look at the service ticket, make sure the information inside of the service ticket is good to go. Everything checks out and that this client does indeed have permissions to access the service or this resource. Off to the right-hand side, you can see that we have a 5.1 and a 5.2 step. Basically, what this is-- this is known as a PAC verify request and then a PAC verify response. The reason why it's in yellow, and we've got the dot 1 and the dot 2 is because this step does not always happen. Let's dig in a little bit deeper into that. So what the PAC actually is is a privileged attribute certificate, and it is used to hold some security information about that client. So when that first ticket granting ticket is sent to the client from the domain controller, a PAC is sent with it. And some of the data that's inside of this PAC structure include the username, SAM account name, and, importantly, group membership. So when a target resource receives the service ticket, decrypts it, and looks at the PAC, if a user is part of, let's say, the domain admins group, once they receive a token for the service-- so let's say, a log on token-- they will receive the token as a domain administrator for that service or for that resource. Now, in 2014, the algorithm used to encrypt the PAC was accidentally disclosed by Microsoft. And so Microsoft completely revamped what the PAC data structure looks like and pushed out updates. This was back in 2014, so all subsequent versions of Windows Server also include this new updated PAC structure. So what happens is there's a new registry key that you can see right here on the screen. By default, this registry key is set to 1. And what this means is, if a target resource receives a PAC that does not meet the new PAC structure, this is when we go back to that 5.1 step. The target resource will send the bad PAC to the domain controller and say, I need for you to verify that this PAC is legitimate. If everything checks out, Kerberos authentication continues as usual. Now, you can change this registry key value if you'd like. By setting it to 0, it basically reverts the update. And no matter what the PAC structure in place is, authentication will always continue on. Now, that is not to say that the client will always get authenticated, but the authenticating-- the authentication process will continue. If you set it to 2, this enforces the new PAC structure. It's the most strict, but it's not necessarily the recommended. But with enforcement, if the PAC meets the new data structure, authentication continues. If the