I'm learning about how Kerberos and it's common exploits work and I'm a little confused. In this video explaining the process we see that at one of the earlier points the user is provided with two packets, one of them being a TGT: http://www.youtube.com/watch?v=2WqZSZ5t0qk&t=6m0s

Now from what I understand people can use the python script GetNPUsers.py to crack the hash of the users password by brute forcing the hashed TGT. However this doesn't seem technically correct: What we would really want to hash (according to the video) is the blue packet since once that is cracked that will provide the user's password, and so then we can pose as the user.

With this in mind, with pre-authentication disabled (which shouldn't ever happen in a real world setting as far as I know), how would we ever get the user password simply from cracking the hash of the TGT? Would we have to provide a valid user id and (since pre-auth is disabled) kerberos would happily provide the blue and red packets?

Ultimately I'm not sure what we're cracking: A user account or a TGS account?


You wouldn't ever try and brute force the TGS session keys, as they are almost certainly going to be randomly generated in any implementation out in the wild. This isn't strictly true with older versions of Kerberos (v4), but there aren't, or shouldn't, be any production systems still running older versions.

The only attack that's practically possible is attacking the AS-REP, that is, the response that contains the TGT, because the response is encrypted using the users long term credential, which is their password. If you can bruteforce the key and decrypt the response you now either know the password, or the derivation of the password, which is just as useful. You aren't breaking the krbtgt secret in any way.

In principle this also applies to attacking the tickets in TGS-REPs to get the service principals secret, but you're not going after the session keys. Instead you're going after the tickets themselves. It's basically the same bruteforce attack. Find the key that decrypts the ticket and you've found the service principals long term credential, which is their password. This is however impossible without already knowing the user credential since you need the long term credential to get the session key to decrypt the response.

Certain service principals like krbtgt have long randomly generated passwords so the likelihood of bruteforcing that key is nil.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.