Kerberos Authentication

A collection of my notes regarding how Kerberos authentication works on Windows networks.

Kerberos Process

Key Terms

Kerberos authentication is very complicated, here is a list of terms and definitions to refer back to.

• KDC - Key Distribution Centre - A service which handles the distribution of Kerberos tickets on a network. This service is usually installed on the DC
• TGT - Ticket granting ticket - like a security badge, allows a user to request tickets from the KDC without having to authenticate every time.
• Session Key - A session key (believe it or not!) used by the user to generate further requests to send to the KDC
• krbtgt - The default account for the Kerberos service
• TGS - Ticket granting service - Tickets that allow connection to a specific service, and only that service.
• SPN - Service Principle Name - An object which indicates the service and server name a user intends to access
• Service Session Key - A session key, but for communication with a service rather than the KDC
• Service Owner Hash - The password hash of the service owner, which is the account / machine under which a service runs
• PAC - Privilege Attribute Certificate - holds all of the user’s information, it is sent along with the TGT to the KDC to be signed and to validate the user

Step 1

• The user sends their username and a timestamp, encrypted using a key derived from their password, to the KDC (Key Distribution Centre), a service usually installed on the domain controller, which is in charge of creating Kerberos tickets on a network.

• Kerberos Ticket - A certificate of authentication issued by the KDC.

• The KDC will send back a TGT (Ticket granting ticket), allowing the user to request tickets to access specific services without passing their credentials to the KDC again
  • You can think of the TGT like a security badge, once you have it, the KDC will not ask to see any identification or try and authenticate you. Along with the TGT, a session key will be given to the user, which must be used to generate the requests that follow.
• Note: the TGT is encrypted using the krbtgt account’s password hash, so the user can’t access its contents. The encrypted TGT contains the session key so the KDC does not need to track all sessions, as it can decrypt the TGT and retrieve the session key if needed.
  • krbtgt - the account for the Kerberos service on the domain controller

Step 2

• When users want to connect to a network service (such as a share, website or database), they will use their TGT to ask the KDC for a TGS (ticket granting service). TGS are tickets that allow connection only to the specific service for which they are created. To request a TGS, the user once again send their username and timestamp, but encrypted using the session key this time, along with their TGT and a SPN (Service principle name)
  • SPN - Indicates the service and server name you intend to access
• The KDC responds with a TGS and a service session key, which will be needed to authenticate to the service that is to be accessed. The TGS is encrypted using the service owner hash. The service owner is the user / account under which the service runs. The TGS contains a copy of the service session key on its encrypted contents so that the service owner can access it by decrypting the TGS

Step 3

• The user can then send the TGS to the service they want to access. The service will use its configured account’s password hash to decrypt the TGS and validate the service session key

Kerberos Delegation

A legitimate and practical use of Kerberos delegation would be, for example, giving a web server access to a SQL databased hosted on the database server. Without delegation, you would probably use an AD service account and provide it with direct access to the DB.

Constrained vs Unconstrained

Unconstrained is the outdated, least secure method of Kerberos delegation. It is insecure because any user with the TRUSTED_FOR_DELEGATION flag set is able to request a TGT (ticket granting ticket) from the host with unconstrained delegation configured.

In 2003 Microsoft remedied this insecurity with Constrained Delegation . This restricts what service an account can be delegated to and thus limits exposure. Below are some examples of services that can be configured for delegation:

• HTTP (used for web apps to allow pass-through using AD creds)
• CIFS (common internet file system)
• LDAP (delegate actions such as resetting a user’s password)
• MSSQL (pass-through authentication to databases)

Exploiting constrained delegation is more complex, since the delegated account can’t just be used for everything.

Resource-Based Constrained Delegation

Introduced in 2012, Resource-Based Constrained Delegation (RBCD) completely changed the delegation model. Instead of specifying which object can delegate to which service, the service onw specified which object can delegate to it. This allows the service owner to control who can access it. As an example, Instead of specifying which object can delegate to which service, the service now specifies which objects can delegate to it. This allows the service owner to control who can access it. In our web application example, this means that instead of specifying that the web service account can delegate to the database service to access the database, we can now specify that on the database service that the web service account is allowed to delegate access to it.

Examples

To enumerate available delegations:

PS C:\\>Import-Module PowerView.ps1
PS C:\\>Get-NetUser -TrustedToAuth
...
msds-allowedtodelegateto : {WSMAN/THMSERVER1.za.tryhackme.loc,
                           WSMAN/THMSERVER1, http/THMSERVER1.za.tryhackme.loc,  
                           http/THMSERVER1}
...