How Kerberos Protocol Works for Penetration Testing: Simple About the Complex (Part 1)

13 January 2025 21 minutes Author: Lady Liberty

This article examines the theoretical basis of the Kerberos protocol, which is used for authentication in computer networks. You will learn how this protocol works, what are the main stages of its functioning, as well as the specifics of its application in the Active Directory environment. In addition, the article reveals possible Kerberos vulnerabilities and explains how penetration testers can use them when assessing the security of systems.

  • Disclaimer: We are aware that some photos or articles may contain Russian language captions. But isn’t it great to use their own language against them?

Introduction

For penetration testers of Active Directory-based infrastructure, it is important to have a clear understanding of the principles of the Kerberos protocol. This is necessary for several key reasons.

First, knowledge of how Kerberos works helps to understand the essence of many classic attacks. Second, new attack methods are constantly emerging, and in order to assess their possible consequences and effectiveness, you need to be well-versed in the principles of the protocol. Without such knowledge, it can be difficult or even impossible to correctly assess threats.

In addition, a deep understanding of the topic distinguishes a true specialist from a person who simply knows the name of the tool or knows how to press the right buttons. This allows you to not only perform your work more efficiently, but also to identify non-standard vulnerabilities that may be missed by less knowledgeable specialists.

Although a lot of materials have already been written about Kerberos and attacks on it, many of them are designed for narrow specialists – mathematicians, network engineers or penetration testers. Often, the information is presented in a fragmented or overly specific way, which makes you spend time searching for useful articles and putting them together into a coherent picture.

This series of articles aims to explain the theoretical foundations of the Kerberos protocol and describe the attacks that can be implemented in the Active Directory-based infrastructure. In addition, effective methods for countering such attacks will be considered.

The first part examines in detail the general structure of the Kerberos protocol, as well as its implementation in Active Directory. It is important to remember that this material does not claim to be the absolute truth, because in the world of information security there is always room for doubts and discussions.

Excursion. Short and historical

The Kerberos protocol was created at MIT as part of Project Athena, which aimed to develop a distributed educational environment. By 1988, the project had achieved its goals, and the Kerberos v4 protocol specification was published, which became the basis for a single sign-on system for this environment. Early versions 1-3 were prototypes and did not find application outside of MIT.

In 1989, Kerberos v4 was officially released, but the protocol still needed improvement. Its main shortcomings were weak cryptographic algorithms, architectural vulnerabilities that allowed offline attacks on passwords, and the lack of support for delegation of credentials and the use of additional authentication factors.

To address these problems, an updated version of the protocol, Kerberos v5, was released in 1993. Subsequently, in 1999, Microsoft announced the integration of Kerberos v5 into its new operating system Windows 2000, which was an important milestone in the development of Active Directory. Previously, Windows workgroup authentication used the NT LAN Manager (NTLM) protocol, one of the improved versions of which, NTLM v2, is still used for local authentication on modern systems. However, this protocol also had certain shortcomings that were addressed with the introduction of Kerberos v5 in Windows 2000.

Today, despite its age, Kerberos v5 is actively used in many systems, not just Active Directory. Here are some of them:

  • Amazon Web Services

  • Apple macOS

  • Google Cloud

  • Microsoft Azure

  • Oracle Solaris

  • Red Hat Linux

This article will focus on Kerberos v5, which for convenience will be simply called Kerberos.

Kerberos protocol requirements

Understanding the principles of Kerberos protocol operation can be difficult, especially at the beginning. There is a constant need to return to the material already studied, repeat the details and try to understand why everything is so complicated. The protocol contains many elements, and in order to properly understand its logic, you need to have some knowledge of cryptography and related technologies. However, going too deep into technical details may not make practical sense – it is enough to understand the key principles of operation.

The main task that Kerberos was supposed to solve was to create an authentication system for working in an open, potentially dangerous environment. Despite the fact that the devices exchanging data are trusted, network traffic can always be intercepted or modified by an attacker. Therefore, secret user data should not be transmitted over the network in an unprotected form under any circumstances.

An interesting point is that Kerberos appeared even before the introduction of SSL – a protocol that is widely used today for secure information exchange. All user secrets are stored in a dedicated location, which reduces the number of critical objects that need to be protected. In addition, this solution simplifies credential management – adding a new user or changing their secrets does not require updating information in all other system participants.

For clarity, this principle is often compared to a central key store: all critical data is stored in a secure location, access to which is strictly controlled. This approach greatly simplifies administration and increases the overall level of system security.

Network options without and with a dedicated trust center
  • Single Sign-On technology must be supported. This limitation is due to the fact that it is inconvenient for the user to re-enter the password each time they access the resource.

  • Successful completion of the protocol should mean successful mutual authentication of the parties.

  • As a result of the protocol, a secret session key should be formed between the client and the service. Knowing the session key allows an attacker to decrypt some old messages, but it will not be possible to organize a new session using an already known session key.

List of terms

Before we get into the technical part, let’s define the terminology to avoid confusion in the future.

  • Kerberos – primarily an authentication protocol, but also provides the ability to transport information necessary for authorization.

It is important not to confuse:

  1. Authentication is the process of verifying that a user attempting to access a system is who they claim to be.

  2. Authorization is the process of verifying access rights. Authorization can only be applied to an authenticated user, because before verifying access rights, it is necessary to determine the identity of the object to which the specified rights are to be granted.

  • Server – a network object that functions one or more services. Examples of a server: file server, mail server.

  • Client – ​​an object that accesses a service to gain access to resources. Examples of clients: a user account or workstation.

  • Realm – a collection of clients, servers, and services in the Kerberos protocol.

  • Principal – a string that fully identifies a Kerberos participant.

The principal can be either a service principal name (Service Principal Name) or a client principal name (User Principal Name). The principal formats for clients and services have some differences.

Client Principal Format

The client principal looks like this:

principal-name[/instance-name]@REALM
  • If the username is Ivan and the scope is DOMAIN.LOCAL, the full principal would be: [email protected]

  • The instance-name extension is optional. It allows a single user to have multiple different principals. For example, if Ivan is an administrator at DOMAIN.LOCAL, his principal would be: Ivan/[email protected] Such a principal would have separate access rights.

Service principal format

The service principal has the form:

service-name/host[:port]@REALM
  • service-name – a unique string that identifies the service on the host.

  • host – the domain name of the host where the service is running.

  • port – the port on which the service is running (may be omitted).

Example: For an ftp service running on the host fileserver.example.com in the domain @EXAMPLE.COM, the principal would be:

ftp/[email protected]

Using principals for identification

Kerberos uses the principal (name) to identify the server, while NTLM can work with an IP address.

Example: There is a workstation with the following parameters:

  • DNS name: station.domain.local

  • IP address: 192.168.10.12

  • Public network folder: scan

When opening Explorer and navigating to a UNC path:

  • \\station.domain.local\scan – Kerberos will be used.

  • \\192.168.10.12\scan – NTLM will be used, as no principal is created for the IP address.

Administrators often leave NTLM support enabled because some legacy network equipment, such as printers and routers, may only work with static IP addresses or may not support Kerberos at all.

Key Distribution Center (KDC)

A Key Distribution Center (KDC) is a trusted authentication center for all Kerberos protocol participants within a specific realm (REALM).

Main components of KDC

  1. Kerberos database. Contains information about all principals and their secrets.

  2. Authentication Server (AS). Handles client authentication requests within a scope.

  3. Ticket Granting Server (TGS). Handles client authentication requests to a specific service within a specified scope.

Let us illustrate the above with the following sketch:

Kerberos protocol participants

Authentication using Kerberos

Let’s start with the general and move on to the private.

Let’s consider a somewhat fictional situation, but useful for the following analogies. Imagine an amusement park. Let’s assume that the list of allowed visitors to the park is contained in a special database. Those who are not in the database are denied entry. How is the park organized:

The visitor comes to the entrance and shows his passport to the security guard.

  1. The security guard checks the visitor’s presence in the database.

  2. The security guard issues the visitor a daily ticket to visit the park.

  3. The visitor chooses an attraction that he likes and goes to the cash register to get a ticket.

  4. At the cash register, the visitor’s daily ticket is checked and a ticket for the attraction is issued.

  5. The visitor goes to the selected attraction and shows the attraction supervisor the ticket received at the cash register.

  6. The supervisor checks the ticket and lets the visitor through.

  7. If desired, the visitor can look at the supervisor’s badge to make sure that he is really an employee of the park.

If the visitor wants to go to another attraction, he goes to the ticket office again and shows the daily ticket. Then the process of steps 5, 6, 7 is repeated only with a different attendant and a different attraction.

At the top in general

Now, by analogy, let’s consider a simplified authentication scheme using Kerberos:

General scheme of Kerberos request exchange
  1. The client sends an authentication request to the action.

  2. The authentication server verifies the client’s authenticity using the Kerberos Database.

  3. The server issues the client a grant (for now, let’s just call it a TGT) to obtain individual permissions (hereinafter – ST) required to access the services included in the scope of the action.

  4. Using the grant (TGT) obtained in step #3, the client requests permission to access Service A (ST for A).

  5. The grant server verifies the TGT and issues the client an ST for access to service A.

  6. Using the “ST for A”, the client requests access to its resources from Service A.

  7. Service A verifies the ST for A and grants the client access to its resources. If necessary, the service also authenticates with the client. In the future, if it is necessary to access another service:

  8. Using the grant (TGT) obtained in step #3, the client requests access to Service B (ST for B).

  9. The authorization server validates the TGT and grants Client ST access to Service B.

  10. The Client, using “ST for B”, requests access to its resources from Service B.

  11. Service B validates the ST for B and grants Client access to its resources.

It can be seen that the parties exchange messages containing requests and responses with permissions. The formats of these messages are officially documented in RFC 4120.

Now let’s rename the messages being transmitted in accordance with the RFC:

  • Request for authentication before action (step 1) – message KRB_AS_REQ .

  • Server response to client authentication request (step 3) – message KRB_AS_REP .

  • Permission to obtain permissions – TGT ( Ticket Granting Ticket ).

Other names found in the literature: mandate / ticket for obtaining permissions, primary user certificate.

Note: in various sources the phrase TGT ticket is often found, but the abbreviation TGT already contains the word ticket – Ticket Granting Ticket, so it is more correct to say simply TGT.

  • Request for access to the service (step 4) – message KRB_TGS_REQ.

  • Response from the authorization server (step 5) – message KRB_TGS_REP.

  • Service access permission – ST (Service Ticket) Other names that occur: TGS ticket, service ticket, service mandate.

  • Client request for authentication to the service (step 6) – message KRB_AP_REQ.

  • Optional response with authentication of the service to the client (step 7) – message KRB_AP_REP.

To make it easier to remember:

  • KRB ~ K e RB eros

  • AS ~ A uthentication S erver

  • REP ~ RE s P onse

  • REQ ~ REQ uest

  • AP ~ AP plication server

Each request will be analyzed in more detail below.

Kerberos Authentication Analysis According to the RFC

Initially, there are three participants in the Kerberos protocol:

  • Customer

  • Service

  • Key Distribution Center

Each participant has their own long-term secret (key). In addition, the key distribution center has the secrets of all participants.

Fig. 3 – Initial distribution of secrets

Key generation algorithm

The Kerberos key is created using the string2key hash function, which converts the password into a cryptographic key. The method of calculating the hash depends on the configuration and supported algorithms. The main ones are:
  • RC4_HMAC_MD5 — uses the NT hash of the user’s password.

  • AES128_CTS_HMAC_SHA1_96 — the key is generated using PBKDF2 (password, salt*, kvno**, 128).

  • AES256_CTS_HMAC_SHA1_96 — a similar method with a key length of 256 bits.

Modern versions of Windows use AES encryption by default. However, for compatibility with older systems (Windows Vista and Windows Server 2008 and below), the RC4 algorithm is supported.

The salt for key generation is formed as follows:

  • For domain users: domain FQDN (fully qualified domain name) in uppercase letters + case-sensitive username. Example: DOMAIN.LOCALuser.

  • For computers: domain FQDN + hostname + computer name without the $ symbol at the end. Example: DOMAIN.LOCALhostcomputer.domain.local.

kvno (Key Version Number) — the key version number.

So, even if the password is the same across domains, the generated keys will be different due to the different salt. This makes building rainbow tables for these hashes inefficient.

Sources:

The client sends a request to the authentication server containing:

  • Customer Principles

  • Ticket Lifespan

KRB_AS_REP

The authentication server finds the client secret in the Kerberos database using the received principal. In addition, for further communication with the KDC, the authentication server randomly generates a session key. As a result, two messages are sent to the client in response.

The first message is encrypted using the client secret and contains:

  • Session key for the KDC

  • Timestamp

  • TGT lifetime

The second message (TGT) is encrypted using (!) the KDC secret and includes the same data as the first message, but together with the client principal.

Note: the TGT lifetime is defined as the shortest time between the one requested by the client and the key distribution center, which is stored in the settings.

The client, having accepted the response, can decrypt only the first message. Thus, it receives a session key for further communication with the KDC. The TGT is also stored in encrypted form by the client.

KRB_TGS_REQ

After successful authentication, the client sends a request to the TGS for access to a specific service. This request contains several important elements:

  • The service principal that the client wants to access.

  • An authenticator that includes the client principal and a timestamp encrypted with the session key obtained during authentication.

  • A TGT (Ticket Granting Ticket) issued in the previous step.

Upon receiving the request, the authorization server performs the following actions:

  • Decrypts the TGT using the KDC’s secret key.

  • Checks the expiration timestamp on the TGT to ensure it is still valid.

  • Retrieves the session key from the TGT. Since only the KDC can create and modify the TGT, the data obtained from it can be fully trusted, so there is no need to store the session key in a database.

Protection against attacks

A logical question arises: how can you be sure that a TGT intercepted by an attacker is not reused? To do this, an authenticator is used, which is attached to the request. It is encrypted with a session key, which is accessible only to a client that has successfully authenticated and received a KRB_AS_REP response from the KDC.

The time stamp in the authenticator protects against replay attacks, making it impossible to use an old authenticator. The authorization server checks that the authenticator was created no later than two minutes ago, and also checks the client principals in the TGT and the authenticator. Only after all checks have been successfully passed does the client receive a ticket to access the desired service.

KRB_TGS_REP

If the checks are successful, the authorization server sends a response to the client containing two messages. The first message is encrypted using the session key for the KDC and contains:

  • Session key for communicating with the service

  • Timestamp

  • TGS ticket lifetime

  • Service principal

The second message (TGS ticket) is encrypted using the service secret and includes the same data as the first message, as well as the client principal.

The client, having accepted the response, can decrypt only the first message. Thus, it receives a session key for further communication with the service. The TGS ticket is stored in encrypted form by the client.

KRB_AP_REQ

The client sends the service an access request containing:

  • Authenticator consisting of the client principal and a timestamp encrypted using the previously used session key to communicate with the service.

  • A stored TGS ticket

  • A mutual authentication flag

After receiving the request, the service first verifies the received data. First, using its secret, the service decrypts the TGS (1) and uses the timestamp with the expiration date to verify that the TGS has not expired (2).

The TGS ticket cannot be changed by anyone except the person who knows the service secret, which is the KDC, and the service itself trusts the KDC, so the service can also trust the data extracted from the TGS ticket.

Similarly, the KRB_TGS_REQ decrypts the authenticator and performs other checks. Note that the service authenticates the client without contacting the KDC.

KRB_AP_REP

Optionally, if the mutual authentication flag is active, the service also confirms its authenticity to the client by sending a response with a timestamp encrypted using the session key.

Kerberos in Active Directory

To get the point across, you have to say it three times, but in different words” — and that’s what we’ll do.

In Active Directory, the implementation of the Kerberos protocol has certain differences and features compared to the standard scheme. First, it’s worth clarifying the terminology:

  1. The scope in the context of Active Directory corresponds to the concept of a domain.

  2. The Key Distribution Center (KDC) is implemented at the domain controller level.

  3. The Authentication Server (AS) and the Granting Server (TGS) are combined into a single component that also runs on the domain controller.

  4. The Kerberos database is the ntds.dit file on the domain controller, which stores information about user secrets.

  5. krbtgt is a special account that is automatically created with the domain and contains the domain controller’s secret key.

With these clarifications, the structure of Kerberos in Active Directory becomes clearer: the domain controller acts as a central point for authentication and authorization, storing all the necessary data about user accounts and their secrets.

Although the general operation of Kerberos in Active Directory complies with the RFC specification, there are some specific differences. Further consideration of these differences is best done using a specific example, which will allow us to more clearly explain the features of this implementation.

Domain Authentication of a User to an Active Directory Workstation

Initially, the following dialog box is active on the workstation:

When a user enters their credentials (domain, username, and password) and clicks “OK,” the system sends an authentication request to the Local Security Authority (LSA). This authority manages various dynamic libraries that perform authentication, password changes, and token issuance. All of these libraries run in the context of the Local Security Authority Subsystem Service (lsass.exe) process.

A specific library is used for each type of request. Here are some examples:

  • msv1_0.dll for NTLM

  • kerberos.dll for the Kerberos protocol

  • SChannel.dll for TLS/SSL

  • WDigest.dll for digest authentication

By default, when a user logs into a domain, the system uses the kerberos.dll library, which implements the Kerberos protocol.

It is important to understand that the user does not interact directly with the system. Instead, the system acts as an intermediary, accessing the necessary resources on behalf of the user using their rights. Thus, during authentication, the system can be considered as a service that represents the user on the network.

As a result, we have the following picture:

The system secret (key) is provided to the workstation when it is added to the domain. It is important that the password entered by the user is not stored in the workstation’s memory. The user key is generated using the previously discussed string2key hash function.

Next, the process that provides user authentication contacts the domain controller using the generated key. Here one of the features of the Kerberos implementation in Active Directory is manifested – the previous standard authentication is enabled.

KRB_AS_REQ with pre-authentication

In this case, the client sends a request to the authentication server containing:

  • Client Principal

  • Timestamp encrypted using client secret

Upon receiving the request, the domain controller uses the client secret to decrypt the timestamp and compare it to the current value. If the transmitted time differs from the current time by less than five minutes, then the client’s pre-authentication has been successfully completed. Otherwise, the controller sends an error message.

KRB_AS_REP (AD)

If the pre-authentication has been successfully completed, the domain controller sends a response to the workstation similar to that discussed in the RFC section.

Another important feature of the Kerberos implementation in Active Directory is the PAC (Privilege Attribute Certificate) field, which is added to the contents of the TGT. The PAC is a set of data used to authorize a user after authentication.

As mentioned earlier, Kerberos can be used not only for authentication, but also for authorization. The PAC field was specified in the RFC specification, but its content and processing depend on the specific protocol implementation.

In the context of Active Directory, the PAC contains the following information:

  • The user’s security identifier (SID).

  • The group identifiers of which the user is a member.

This information is used to determine the level of access to resources. To ensure its integrity, the PAC is signed twice:

  1. The first signature is added by the krbtgt account, which is responsible for issuing tickets and authentication.

  2. The second signature is applied by the service that the client is accessing. In the case of a KRB_AS_REP response, this signature is also owned by krbtgt.

  3. Thus, PAC ensures that information about user access rights is reliable and protected from forgery.

KRB_TGS_REQ (AD)

The request is made similarly to the RFC discussed earlier.

KRB_TGS_REP (AD)

The PAC with the TGT received in the previous message is placed in the TGS ticket. This time, the PAC is signed using not only the krbtgt secret, but also the system secret.

LOGON

Using the session key, LSA obtains the signed PAC from the TGS ticket. LSA verifies the PAC signature using the system secret and then, taking into account the domain security groups obtained from the PAC, forms a Winlogon process with the appropriate client access flow.

Optionally, the system can request a domain controller to perform additional signature verification with the PAC using the krbtgt secret.

Summary

This material is quite enough for a general introduction to the Kerberos protocol. Although some aspects were left out of consideration, the information provided is enough for a basic understanding of the principles of the protocol. This knowledge will serve as a good basis for a detailed analysis of attacks on Kerberos, which will be discussed in the next part.

Other related articles
Found an error?
If you find an error, take a screenshot and send it to the bot.