Background

Kerberoasting is an extremely common attack in active directory environments which targets Active Directory accounts with the SPN value set.

When we authenticate we perform an AS-REQ request to request use of a TGT ticket, and we receive back a TGT ticket. Next we perform a TGS-REQ to request information about the service we are attempting to authenticate to (it could be a host or a service, such as a fileserver), this service is known as SPN (Service Principal Name), and they are a field in the user or computer account attributes .

We can use are new TGT ticket to request a TGS (TGS-REQ) by encrypting it using the service password and the timestamp, the KDC (=DC) received the TGS-REQ and decrypt it using the service password which is saved on the KDC, the KDC doesn't check if you are allowed to have access to the service, it's not the KDC role, the access is part of the PAC which is inside the TGS-REP and the services check the PAC to see if you're allowed access.

Worth Noting

Encryption type

The TGS ticket could be encrypted using different type of encryptions (RC4, AES, PBKDF2 and more)

• Service ticket with HMAC-MD5-RC4 encryption are faster to crack, but possibly non-standard (it is the default minimum supported encryption type)
• Default encryption type is PBKDF2 with 4096 rounds aes256-cts-hmac-sha1-96 (very slow, but looks more normal)
• With Kerberoasting, we really want RC4 encrypted service ticket replies, as these are orders of magnitude faster to crack than their AES equivalents (But that may not be OPSEC safe)

Be aware the following encryption types:

• type 17 - AES128
• type 18 - AES256
• type 23 - RC4_hmac

We can identify the protocol for the hash:

$krb5tgs$23$*SVC_SQLServices$eth.lab$WIN-EU4DLP9KRRC/SVC_SQLServices.eth.lab*$F

Machine accounts

Most of the accounts that run services are machine accounts (MACHINENAME$) and their passwords are very long, complex and completely random, so they’re not really vulnerable to this type of attack.

Bottom line