The updated slides (from the WoS talk) can be found here: http://www.slideshare.net/gentilkiwi/abusing-microsoft-kerberos-sorry-you-guys-dont-get-it
Quick Oversimplified Kerberos Refresher
IF you read all the links on Kerberos there's talks about TGTs, service tickets, principals, etc... I want to present just a simple way to quickly visualize what's going on with Kerberos.
Imagine yourself as a kid. Mom needs to pick up a gallon of milk and the dry cleaning but needs to wait in the car for whatever reason. Fortunately, the cleaners and 7-11 are right next door to each other. She hands you her credit card and tells you to go get the milk and then the dry cleaning and get back to the car.
You walk into the 7-11, grab the milk, hand the credit card to the cashier and he lets you leave with the milk. You then walk into the dry cleaners, tell them you're there for the pickup, hand them the credit card and you walk out with some shirts as well.
In this highly oversimplified example, the credit card is how you gain access to the services of the convenience store (the milk) and the dry cleaners. You don't understand how the card works, only that you show it to the cashiers and they allow you to leave with the items.
TGT (Ticket Granting Tickets) operate in much the same way. When a kerberos principal (somebody who wants to access a service protected by kerberos) authenticates to the KDC, they provide their username and password and get a TGT in return. This TGT operates in much the same way the credit card does. Whenever the principal wants to access a service, they submit their request along with the TGT and based on the privileges contained in the TGT, the request will either be granted or denied.
The nice thing about this TGT is that it is valid for a period of time. This means that the user doesn't have to get prompted for their password for a period of time. The TGT can simply be passed on and reused until the ticket expires.
Why Does the Domain Trust the TGT?
So what grants the TGT its mystical powers? It's because part of it is encrypted using the NT hash of the KRBTGT account and the other part is encrypted by the NTLM hash of the principal requesting it.
This means that in order for it to be legit, 2 different principals have to agree that it's legit. In essence, each side of the conversation has some assurance that the other side is who they claim to be since "in theory" the only way the TGT could be valid is that both sides can read their part.
This is where Mimikatz comes into play.
So How Old is the KRBTGT on Your Network?
If we have a complete hashdump of the domain, then we have the password hash for the KRBTGT account. Additionally, this account seemingly never changes its password. The only instances where folks have reported that it changes is when the domain functional level changes during an upgrade, a point I will touch on in a sec.
So, for example, this is from my demo domain from 2012 that is still up and running that I use to test PTH tools against:
Note that the password for the KRBTGT hasn't changed since March of 2012. This is about the time I set the domain up to begin with.
So that means that regardless of the password policy in place on the network, this account has NOT changed its password in over 2 years. Just in case you're wondering what your network looks like, try running "net user krbtgt /domain" from a command prompt on your local network.
So, when does this hash / password change? There is only one circumstance where this password automatically changes. The password for the KRBTGT account only changes when the domain functional level is upgraded from a NT5 version (2000/2003) to a NT6 version (2008/2012). If you move from 2008 -> 2012R2 domain functional level, this hash won't change.
This hash can also be manually changed in a working AD, but this will cause all sorts of "Bad Things(tm)" to happen to your network, namely all Kerberos tickets will simultaneously die and in all likelihood demons will be summoned and a lot of puppies and kittens will be killed. Not to mention Sysads.
Seriously though, this process is as of right now unsupported by Microsoft and there has not been any official documentation regarding how this should take place and what the effects will be. This will be forthcoming in the "Not Too Distant Future(tm)" as well, so keep an eye out for that.
So, the net result is that your KRBTGT account is only as old as your transition from a NT5 domain funtional level to NT6. If that happened back in 2008, then you hash is at least 6 years old. If you are still on a 2003 domain, then it is even older.
Assume that "N" is the amount of time since the KRBTGT account has changed. Ultimately, if you have a password hash dump somewhere on your network from something less than N years ago, then the KRBTGT account could have been compromised. (Of course, said password dump could also be on pastebin too and archived by Google...) If you have a poorly configured backup of a domain controller on your network from less than N years ago, the KRBTGT account could have been compromised. If there's an old domain controller that has been decommissioned but is still in your virtual machine library, ditto. If there was a poorly redacted pentest report showing the first few lines of a hashdump, ditto... and the list goes on....
So, this is definitely a Big Fscking Deal.
Well touch more on this in the next post.
So, for example, this is from my demo domain from 2012 that is still up and running that I use to test PTH tools against:
Note that the password for the KRBTGT hasn't changed since March of 2012. This is about the time I set the domain up to begin with.
So that means that regardless of the password policy in place on the network, this account has NOT changed its password in over 2 years. Just in case you're wondering what your network looks like, try running "net user krbtgt /domain" from a command prompt on your local network.
So, when does this hash / password change? There is only one circumstance where this password automatically changes. The password for the KRBTGT account only changes when the domain functional level is upgraded from a NT5 version (2000/2003) to a NT6 version (2008/2012). If you move from 2008 -> 2012R2 domain functional level, this hash won't change.
This hash can also be manually changed in a working AD, but this will cause all sorts of "Bad Things(tm)" to happen to your network, namely all Kerberos tickets will simultaneously die and in all likelihood demons will be summoned and a lot of puppies and kittens will be killed. Not to mention Sysads.
Seriously though, this process is as of right now unsupported by Microsoft and there has not been any official documentation regarding how this should take place and what the effects will be. This will be forthcoming in the "Not Too Distant Future(tm)" as well, so keep an eye out for that.
So, the net result is that your KRBTGT account is only as old as your transition from a NT5 domain funtional level to NT6. If that happened back in 2008, then you hash is at least 6 years old. If you are still on a 2003 domain, then it is even older.
Assume that "N" is the amount of time since the KRBTGT account has changed. Ultimately, if you have a password hash dump somewhere on your network from something less than N years ago, then the KRBTGT account could have been compromised. (Of course, said password dump could also be on pastebin too and archived by Google...) If you have a poorly configured backup of a domain controller on your network from less than N years ago, the KRBTGT account could have been compromised. If there's an old domain controller that has been decommissioned but is still in your virtual machine library, ditto. If there was a poorly redacted pentest report showing the first few lines of a hashdump, ditto... and the list goes on....
So, what's the BFD with this account?
The bottom line is this : If somebody has compromised the KRBTGT account and they have the domain SID (Security Identifier) for your domain, they can generate a ticket that can impersonate any user and put them into any group. The users do not need to be enabled or even exist in the domain and they can still be put into the highly privileged groups in the domain, such as the domain or enterprise admins.So, this is definitely a Big Fscking Deal.
Well touch more on this in the next post.
