There is an attack on Active Directory named "Kerberoasting": https://attack.mitre.org/techniques/T1558/003/

  • I ask TGS for ticket to access some SPN
  • Part of this ticket is encrypted with SPN's password hash (something that only TGS/KDC and SPN may know)
  • I brute force this hash offline to obtain service password

My question is why use password hash as key at all? Can't some kind of temporary session key (changed every several hours) be used here?

In other words, every regular user in Windows network may know every service account password's hash. Is not it bad?

1 Answer 1


How exactly would that session key be kept in sync between the KDC and the target service?

The KDC encrypts the ticket to a key the server knows. That therefore means both the KDC and the target server need to know the password, and that has to be set up, somehow.

Windows handles this sync through the domain join process, which allows the computer account to periodically rotate its own password. The password is 127 randomly generated characters, so bruteforcing that will never succeed. This leaves administrator-created service accounts, which fall into two buckets: unmanaged and managed.

Unmanaged service accounts are where the administrator generates a password, and attacks against this are at the whim of the strength of the generated password. Short, less-random passwords are vulnerable to bruteforcing. Longer, more random passwords are not/less vulnerable to bruteforcing.

Managed service accounts work in a fundamentally different way where the computer using the account knows how to periodically rotate the password on an admin-defined schedule. This works by having the host computer periodically poll the domain controller and ask if it can get a copy of the new password.

There is yet another mechanism by which this can occur, called encrypt-in-session-key or user-to-user mode, where the target server can return their own public portion of their TGT to the calling client, and the client forwards that to the KDC, and the KDC encrypts the ticket to the session key in the server's TGT. The TGT portion is public on the wire so it's safe, and the ticket is no encrypted in a random session key and this is most closely resembling what you're asking.

However, the reason these work the way they do is because everyone has line of sight to a domain controller at all times. Everyone needs to poll the domain controller to get password updates or to refresh their own TGT. This is a problem because there are untold numbers of applications out there that can't speak to the DC for any number of reasons, so they must be told ahead of time what their long-term secrets are, often through the use of a keytab.

Sticking to a long, randomly generated password will mitigate any bruteforcing concerns. If you're in a position to do so, use managed accounts. Otherwise enforce a password change policy on your service accounts and rotate them regularly. Or run as NETWORK SERVICE, so the computer takes care of it.

  • Thank you! Service and DC may generate some random key when service logins first time and change it periodically like it is done in many protocols, some kind of session key. This was my idea. I didn't think about those keytab-based services that cant talk to DC. Could you please give examples? I am aware of msa and never set service passwords manually, my question was theoretical.
    – user996142
    Jan 12, 2022 at 18:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .