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.
Hello,
ReplyDeletePassword change "Not supported?" Then why does Microsoft recommend that you change the krbtgt password in their support KBs under various circumstances?
http://technet.microsoft.com/en-us/library/cc734032(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc733991(WS.10).aspx
http://support.microsoft.com/kb/2549833
http://technet.microsoft.com/en-us/library/bb727066.aspx
To reiterate, the *official Microsoft guidance* after a domain controller breach or forest recovery is to reset the krbtgt password yourself, and purge its password history by resetting it twice.
To avoid exactly the kind of problem you describe, where changing krbtgt's password once invalidates all TGTs, TGTs can also be validated against krbtgt's first previous password.
I think people have been going nuts lately over the PtH stuff because it makes good blog fodder, but in many cases, "security researchers" are attacking a straw man because they're unclear of how Active Directory actually works in the first place.
That "official Microsoft guidance" was from the Windows 2000 section of the Technet website. I'm not saying it's bad advice, I'm saying that I've got several different folks from various Microsoft groups including MSRC, the Windows product team, and consulting services that are telling me that their official guidance is to burn it down and start over in the event of a breach because it's potentially less painful than changing the KRBTGT.
DeleteYour explanation of what *SHOULD* happen with the KRBTGT account is correct. However, once again I've got a bunch of folks at Microsoft who are telling me that they are currently investigating whether or not everything actually works that way. As in they are going back to the source code to audit Kerberos.
Microsoft wants to make sure that the guidance they issue makes sense for large and complicated networks. (Translated big multi-million to billion dollar clients)
Hi,
ReplyDeletein your screenshot the krbgtg account looks as inactive.
Does your method still work despite of it?
Thanks
Sorry I didn't see this comment earlier. That account always looks like it's disabled, however it is actively being used internally by AD. You just can't log in with it.
ReplyDeleteThis attack applies in NT 6 version also ?
ReplyDeleteYes, this attack works for NT6 versions as well
Delete