1. You can obtain the service account's password, and the service account may be provisioned with more privileges than the user's account that you compromised. This allows for privilege escalation beyond simply accessing the service. For example, perhaps the service account has administrative access on other machines, or it is used for multiple services, or it is a Domain Admin in which case you can completely compromise the domain.
2. TGS tickets used to request access to a service are cryptographically signed with the password hash of the service account. Services use this to confirm ticket validity. In most cases, this means that if you can derive the service account password, you can forge TGS tickets that claim to be associated with arbitrary domain users. Instead of accessing the service as a low privilege user, you can now access the service as an Enterprise Admin or another high privilege account which could enable access to more resources or administrative access to the machine. This is called a Silver Ticket attack.
It's wild to me that this could happen just from solving the puzzle that allows the user's account to use the user's privileges (only) on the service... ?
> In most cases, this means that if you can derive the service account password, you can forge TGS tickets that claim to be associated with arbitrary domain users.
Since it's cryptographic signing, wouldn't this require reversing the hash? Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
Yes, it is an unfortunate design decision in the Microsoft implementation of the Kerberos protocol.
To interact with Active Directory and perform privileged actions, a service needs an Active Directory account that it can leverage for authenticated actions. This is colloquially referred to as a "service account", but it is not a special account type, it is just a regular Active Directory user or computer account designated for exclusive use by a service. Sometimes administrators will save time by registering a service under their own Domain Admin user account instead of creating a designated account for a service. This effectively makes their user account the service account. In other cases, extensive privileges may be required by a service (e.g. for network access control services, asset discovery services, vulnerability scanners, etc) and administrators find it easier to just create a Domain Admin (high privilege) account for that service than to do fine grained permissioning. This creates a dangerous situation where if an attacker can kerberoast the account associated with the service, they can immediately take possession of a high privilege account that can be used anywhere within the Active Directory environment.
> Since it's cryptographic signing, wouldn't this require reversing the hash?
Yes, you would need to brute-force it.
> Does any valid inverse of the hash work, or only the actual password that happened to get hashed?
Theoretically yes, any valid inverse of the hash would work, but to my knowledge there aren't any hash collisions for the NT hash algorithm. Practically speaking, this means that only the user's password would yield the correct hash.
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.
>Users with AD credentials can request tickets to any service account in AD.
I assume it means you can derive the service password to leapfrog up the chain to wherever you want to go.