Kerberos

author: Nathan Acks
date: 2022-03-13

Kerberos: The default authentication method for Windows domains. Intended to be the successor to NTLM.

The built-in Windows command klist will show you the current Kerberos tickets in memory.

Definitions

Note that Active Directory bundles the authentication service, ticket granting service, and KDC into a single “domain controller” role. Non-Windows Kerberos implementations are more likely to separate these roles between different servers.

Authentication Process

The below steps are cut-and-pasted from Wikipedia’s walk-through, but with language adapted to match the Windows-specific environment Kerberos is most commonly deployed in. (A close reading of these steps will also explain why it’s sometimes said that “a hash is as good as a password” for a Window’s domain.)

Client Authentication to the KDC (a.k.a. “Pre-Authentication”)

(1) AS-REQ: The client sends the client/user ID + the current timestamp (the timestamp is used to prevent replay attacks) encrypted with the NT hash of the user’s password + a cleartext message of the user ID to the authentication server to request services on behalf of the user.

(2) AS-REP: The authentication server checks to see if the client/user ID is in its database and if it can decrypt the timestamp using the NT hash of the password stored there. If it can, then the authentication server sends back the following two messages to the client:

(3) Once the client receives messages A and B, it attempts to decrypt message A with the NT hash generated from the password entered by the user. If the user entered password does not match the password in the authentication service database then decryption of message A will fail. Once message A is decrypted, the client obtains the Client/TGS Session Key. This session key is used for further communications with the ticket granting service. (Note: The client cannot decrypt Message B, as it is encrypted using the KDC long term secret key.)

Client Service Authorization

(1) TGS-REQ: When requesting services, the client sends the following messages to the ticket granting service:

(2) TGS-REP: Upon receiving messages C and D, the ticket granting service retrieves the ticket granting ticket out of message C and decrypts it using the KDC long term secret key. This gives it the Client/TGS Session Key and the client ID (the client ID is part of the privilege attribute certificate). Using the Client/TGS Session Key, the ticket granting service decrypts message D (Authenticator) and compares the client IDs from the ticket granting ticket and message D; if they match, the server sends the following two messages to the client:

Client Service Access

(1) AP-REQ: Upon receiving messages E and F from ticket granting service, the client has enough information to authenticate itself to the service server. The client connects to the service server and sends the following two messages:

(2) AP-REP: The service server decrypts the service ticket (message E) using its long term secret key to retrieve the Client/Server Session Key. Using the sessions key, it then decrypts the Authenticator and compares client ID from the service ticket and message G. If they match the server sends the following message to the client to confirm its true identity and willingness to serve the client:

(3) The client decrypts the confirmation (message H) using the Client/Server Session Key and checks whether the timestamp is correct. If so, then the client can trust the server and can start issuing service requests to the server.

(4) The server provides the requested services to the client.

.kirbi Files

There’s a bit of terminology creep when discussing Kerberos tickets. Mimikatz and Rubeus are actually dumping Kerberos data structures (as .kirbi files), which contain both a ticket and the corresponding session key. People tend to call these .kirbi files “tickets”, but it’s worth keeping in mind that they contain both pieces of data (as a “ticket” in the Kerberos sense, not the hacker’s sense, isn’t useful without the corresponding session key).

Atacking Kerberos

Kerberoasting

Kerberoasting is where a service ticket is used to brute force a service password. This password can then be used to either move laterally or (if the service runs with elevated privileges) to elevate your privileges.

Note that not every account is kerberoastable, though it’s not 100% obvious from this walk-through why that is. The Kali Linux tool bloodhound can be used to identify potentially kerberoastable accounts.

The Invoke-Kerberoast PowerShell module can be used to create a dump of service tickets that can then be attacked offline using Hashcat of John the Ripper. (Note that calling Out-File with the -Width 8000 option is important in the below example, as otherwise the ticket can be truncated!)

Invoke-Kerberoast -OutputFormat Hashcat |
	Select-Object Hash |
	Out-File -filepath "$FILE_PATH" -Width 8000

The main defenses against kerberoasting are (1) strong passwords and (2) making sure you’re not running any services as domain admin (which you shouldn’t need to do in this day and age anyway).

AS-REP Roasting

AES-REP roasting is basically kerberoasting for regular user accounts. The only requirement to roast a user account is that Kerberos pre-authentication is disable.

(When pre-authentication is disabled, the authentication server will supply a ticket granting ticket and a session key automatically when requested, without first verifying the user. This data is then stored offline by the Windows machine for later decryption when the user with pre-authentication disabled logs in. But this means that all we need to do is to break the user’s NT hash!)

Basically the only mitigation for this attack is to keep pre-authentication enabled, though strong password policies can help.

Pass the Ticket Attacks

The only real way to defend against this attack is to only allow domain admins to log into domain controllers, not lower privileged machines!

Golden/Silver Ticket Attacks

The idea with gold and silver tickets is that, since the KDC and service long term secret keys are just the NT hashes of the corresponding service account’s passwords, then if you can dump the password (or even its hash), you can forge a kerberos ticket without ever needing to contact the KDC.

Silver tickets are forged using a service account’s NT hash, and can be used to grant any user access to that service. This works because Kerberos implicitly assumes that only the KDC and the service account know the service account’s long term secret key.

Golden tickets take things a step further - if you can get the krbtgt user’s NT hash, then you can forge a ticket granting ticket for any user, and then use that to get the KDC to provide a valid service ticket for any service that user has access to. This works because Kerberos trusts the encrypted ticket granting ticket blob and doesn’t reauthenticate the user before granting further access.

Golden tickets are powerful (since you can be anyone, it’s trivial to gain control of the domain), but also noisier - because you’re running through the KDC infrastructure, golden ticket still generate (almost) all of the normal logging, while silver tickets allow you to bypass the KDC completely and only generate logs on the service server (if that).