Readit News logoReadit News
timmedin commented on Kerberoasting   blog.cryptographyengineer... · Posted by u/feross
amluto · 5 months ago
> To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.

I have a vague understanding of Kerberos, and this is where I’m mystified. Why is the KDC or anything else willing to issue a TGS ticket encryption against a service password before the requesting user authorizes themselves? Or is the issue that authentication and authorization are split and the KDC has no idea whether the requesting user is authorized.

timmedin · 5 months ago
The reason that the KDC doesn't decide if the user should get a ticket is that then the power requirements of the DC would be enormous. It should have to know if a user is supposed to have access to every single service in the environment. It would be a massive database. That massive database would also have to sync to all the other DCs. To alleviate this, Kerberos let's the server decide if the user has access, and if so, how much
timmedin commented on Kerberoasting   blog.cryptographyengineer... · Posted by u/feross
cybergreg · 5 months ago
Good overview of Kerberoasting, still a common attack chain. A couple things though: To obtain access to a service, you actually need to get a service ticket (TGS) from the KDC (Domain Controller) to authenticate to the service, not a TGT. The TGT is the first ticket acquired during authentication to the domain. In addition, the "salt" is not a true salt but a concatenation of the domain and principal name, so even worse. Active Directory (invented at MIT) supports RC4, AES128, and AES256 encryption types, however you can effectively disable RC4 via Group Policy. The reason RC4 is still supported is to support legacy systems. Many organizations use old software that only supports RC4. For example, I've run into many manufacturing and small businesses that have no choice but to use it and can't upgrade the software due to $$$. Anyway, good stuff! Shout out to Tim Medin, who published this back in 2014.
timmedin · 5 months ago
Just to add to this, the salt (domain [realm] and username) is only used to generate the AES keys, not the RC4. The RC4 key is simply the NT hash.

And thanks for the shout out!

timmedin commented on Kerberoasting   blog.cryptographyengineer... · Posted by u/feross
moomin · 5 months ago
Padme: AD uses salts in its protocol, right?
timmedin · 5 months ago
In Kerberos, the answer is effectively no. To generate the NT hash, the password is hashed using a single round of MD4. This is what is used to encrypt (and sign) tickets.

The attack is, guess a password, hash it, and attempt to decrypt.

With AES Kerberos keys there is a salt... but not a good one. It is just the domain (realm) and the username.

timmedin commented on Kerberoasting   blog.cryptographyengineer... · Posted by u/feross
Hilift · 5 months ago
You're missing the forest for the trees. A regular user account should never have a service principal name (SPN), for the simple reason that it can be attacked in the way described. That is why service accounts have really long complex passwords.

Kerberoasting nearly always occurs due to an installation process that assigns an SPN to an account that is performing an installation, or inappropriately selected by the installer. That is the first problem. The second problem is there isn't anyone auditing this stuff because they are incompetent.

If you reported an issue of an account that had an SPN but should not, nearly everyone would either not know what you are talking about, or disagree that it is a security problem without any knowledge or basis.

timmedin · 5 months ago
> That is why service accounts have really long complex passwords.

The sad thing is, they don't always have long complex passwords. They SHOULD, but they don't. Many orgs are scared of changing service account passwords due to the possibility of an outage.

I don't often see a day to day user with an SPN. I do see plenty of SPNs tied to service accounts where the service account password is crackable/Kerberoastable.

u/timmedin

KarmaCake day2September 11, 2025View Original