And thanks for the shout out!
And thanks for the shout out!
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.
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.
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.
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.