If you have the user's credentials then you can indeed connect to the service as you normally would. The advantages of performing this attack are:

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.

▲

zahlman 6 days ago | parent [-]

> 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.

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?

▲

harmon 6 days ago | parent [-]

> 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... ?

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.

	▲	zahlman 5 days ago \| parent [-]
		Thanks, I think I get it now. Everything to do with cryptography always seems to struggle to stick in my head, though, even when I understand the math in principle.