# Kerberos 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. ## Terminology - **Ticket Granting Ticket (TGT):** An authentication ticket that can be used to request service tickets for specific domain services from the ticket granting service. - **Key Distribution Center (KDC):** A domain service that issues tickets; typically composed of the ticket granting service and the authentication service. - **Authentication Service (AS):** Issues ticket granting tickets. (Presumably in charge of *authenticating* users and automations.) - **Ticket Granting Service (TGS):** Issues tickets for domain services (and machines?) when presented with a ticket granting ticket. (Presumably in charge of *authorizing* users and automations.) - **Service Principal Name (SPN):** A service identifier. On Windows, SPNs associates a particular service instance with a domain account. All services must have a domain service account. (But it sounds like services might be associated with *multiple* accounts via multiple principal names assigned to multiple running instances?) - **KDC Long Term Secret Key (KDC LT Key):** A secret key used to encrypt ticket granting tickets and sign privilege attribute certificates. This is the NT hash of the KRBTGT service account. - **Service Long Term Secret Key (Service LT Key):** A secret key associated with a particular service. Used to encrypt the service portion of a service ticket and sign privilege attribute certificates. Held by individual domain service accounts. - **Session Key:** Issued with a ticket to identify a particular user session. Services expects *both* a ticket and a session key to be present before acting on a user's behalf. - **Privilege Attribute Certificate (PAC):** A bundle of the user's identifying information, which is provided along with the tickets. Importantly, this contains the user's username and (on Windows) SID. 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](https://en.wikipedia.org/wiki/Kerberos_%28protocol%29), 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: - Message A: *Client/TGS Session Key* encrypted using the NT hash of the client/user. - Message B: *Ticket Granting Ticket* (including the privilege attribute certificate, client network address, ticket validity period, and the *Client/TGS Session Key*) encrypted using the KDC long term secret key. 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. > [!important] > 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: - Message C: Composed of the ticket granting ticket and the service principal name of the requested service. - Message D: Authenticator (which is composed of the client ID and the timestamp), encrypted using the *Client/TGS Session Key*. 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: - Message E: *Service ticket* (which includes the privilege attribute certificate, client network address, validity period, and *Client/Server Session Key*) encrypted using the service's long term secret key. - Message F: *Client/Server Session Key* encrypted with the *Client/TGS Session Key*. ## 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: - Message E: The *service ticket* (as provided by the ticket granting service; see above). - Message G: A new Authenticator, which includes the client ID, timestamp and is encrypted using *Client/Server Session Key*. 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: - Message H: The timestamp found in client's Authenticator (sometimes modified, depending upon the version of Kerberos being used), encrypted using the *Client/Server Session Key*. 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. ## Exploitation ### .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). ### Kerberoasting ![[Kerberoasting]] ### AS-REP roasting ![[AS-REP roasting]] ### 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 ![[Golden and silver ticket attacks]]