Skip to main content

88 - Pentesting Kerberos

Definition and History​

Kerberos is an authentication protocol between two trusted devices in an Active Directory. It has been present since Windows 2000, and first appeared in RFC 4120.

Kerberos Entities and Realm​

Kerberos relies on 3 entities:

  1. The client, otherwise known as the requesting entity for access (user or service)

This can be a user, in the form "[email protected]". In this case, the user is "Thomas" and the "realm" is "domain.local". (We will return to the notion of realm later)

But it can also be a service, in the form "SMB\[email protected]". Here the concerned service is "SMB", the instance of the SMB service (otherwise the FQDN of the host of this service) is "file_server.domain.local" and the realm is "domain.local".

  1. The resource, which can be a service, server, file, etc.
  2. The KDC (Key Distribution Center), which is the key distribution center that authenticates clients and delivers tickets

The realm quant to it, is a way to logically group resources and Kerberos identities. It is represented by a domain name, and is often the domain name of the Active Directory.

KDC (Key Distribution Center)​

The KDC is responsible for distributing encryption keys between entities. It consists of 2 parts:

  1. The AS (Authentication Service), which is the authentication service. It is:
  • Responsible for authenticating clients and distributing TGT (Ticket Granting Ticket)
  • Contains the database of principals (users and services)
  • Uses the krbtgt account to encrypt communications. This account is created when the domain is created and is unique for each domain.
  1. The TGS (Ticket Granting Server), which is the ticket granting service. It is:
  • Uses the TGT presented by the client and the associated session key
  • Verifies that the client has the right to access the requested resource
  • Issues temporary service tickets for accessing resources (here we will talk about ST, or Service ticket)

Explanatory diagram of how kerberos works​

Step 1: Authentication​

First, the client must authenticate to the AS. This is done as follows:

The client first sends a cleartext message to the AS specifying its Username, IP and the service it requests.

In this message, the client specifies a TGT lifetime, but it is the AS that will define it

The AS responds with 2 messages:

  1. The first is encrypted with the client account key (retrieved from the KDC database). It contains the Name/ID of the TGS (Ticket Granting Server), a timestamp, the TGT lifetime, and the TGS session key
  2. The second is encrypted with the TGS key. It contains the Name/ID of the TGS, a timestamp, the client IP, the TGT lifetime, and the TGS session key.

The 2nd message is called the TGT or Ticket Granting Ticket.

This mechanism allows both:

  • Authenticating the client to the AS (if the client was able to decrypt message 2 on the diagram)
  • Securely distributing the TGS session key to the client. This key will be useful later to communicate securely with the TGS
Client account key

The client account key corresponds to the hash of the account password, salted with the user name + domain, i.e. user@domain.

This therefore allows, if no pre-authentication is enabled, an attacker to crack the password of a user account.

The client now has the TGS session key in its possession and can start communicating with it to obtain its ST (Service Ticket)

Step 2: Communication with the TGS​

The client then sends 3 different messages to the TGS:

  1. This one is sent in cleartext, specifying the name of the user wishing to access the service, as well as the desired ST lifetime
  2. This one is encrypted with the TGS session key (obtained previously) and contains the username/id of the client and a timestamp
  3. Finally, this one is encrypted with the TGS key, and it is a copy of message 3 (with the following attributes: Username/Id of client, Name/Id of TGS, Timestamp, Client IP, TGT lifetime and TGS session key)

The TGS will therefore:

  • Decrypt message 6 with the TGS key, and retrieve the TGS session key
  • Decrypt message 5 with the TGS session key, and verify that the timestamp is valid (to prevent replays). It will also verify that the username is valid and matches an entry in the KDC database
  • Verify that the requested service name in message 4 is valid and actually exists in the KDC database
  • Store the decrypted message 5 in the cache to prevent replays

The TGS has therefore authenticated the client (if the client was able to use the TGS session key), and the client has authenticated the TGS (if the TGS was able to decrypt message 6)

Step 3: Obtaining the ST​

The TGS then sends 2 messages to the client:

  1. This message is encrypted with the TGS session key and contains the Name/Id of the service, a timestamp, the ST lifetime and the service session key
  2. This message is encrypted with the service key and contains the username/id of the client, the name/id of the service, a timestamp, the client IP, the ST lifetime and the service session key

This mechanism securely distributes the service session key to the client. This key will be used later to communicate with the service.

The 8th message is then called the Service Ticket (ST).

Step 4: Communication with the service​

To communicate with the service, the client sends 2 messages to the service:

  1. This message is encrypted with the service key and contains the username/id of the client, the name/id of the service, a timestamp, the client IP, the ST lifetime and the service session key. This message is a copy of the previously mentioned ST

  2. This message is encrypted with the service session key and contains the username/id of the client and a timestamp

The service will therefore:

  • Decrypt message 9 with the service key, and verify that the timestamp is valid (to prevent replays). It will also verify that the username is valid and matches an entry in the KDC database
  • Decrypt message 10 using the session key obtained in message 9, and verify that the username matches message 9
  • Store the decrypted message 10 in the cache to prevent replays
  • Send a message (11) to the client, encrypted with the service session key, containing the name/id of the service and a timestamp

The client will be able to authenticate the service by decrypting message 11 with the service session key. It will also store the decrypted message 11 in the cache to prevent replays

The service has therefore authenticated the client (if the client was able to use the service session key), and the client has authenticated the service (if the service was able to decrypt message 10)

Communication between the two entities can now be done with the service session key transmitted previously by the TGS.

Complete diagram​