Kerberos Authentication: Basics to Kerberos attacks

Developed by MIT, Kerberos Authentication Protocol is the default authentication service for Microsoft Active Directory. It is named after the three-headed dog (Cerberus) found in Greek mythology, because the security protocol involves three major steps in the entire authentication process. Although Kerberos is a technology used by Microsoft Windows, by default, its implementations in other operating systems, such as Linux, FreeBSD and macOS, are also present.

Whether it is security teams, IT administrators or active directory teams, understanding the basics and security of Kerberos is a critical element. We often find Kerberos security issues during security reviews of Active Directory environments. This blog is divided into two parts. In the first part, we will be discussing the basics of Kerberos and in the second part, we will discuss attacks on Kerberos.

Part 1: Kerberos authentication protocol

Kerberos is a network authentication protocol that works on the basis of “tickets” to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.

What is Kerberos?

Kerberos is a network protocol that works on a client-server model and uses secret-key cryptography. It works on the principle of granting and requesting tickets to and from different nodes connected on the network to identify themselves. By default, Kerberos runs on UDP port 88.

What are the components of the Kerberos authentication protocol?

Kerberos is a third-party authentication scheme consisting of the following three entities:

1. The Server
2. The Client
3. The Key Distribution Center (KDC) – which is further divided into two parts, i.e. (i) The Authentication Server and (ii) The Ticket Granting Service (TGS).

1. The server machine

The server or computer hosting the service that supports or requires Kerberos authentication

2. The client machine

The computer that requires access to the service that supports or requires Kerberos authentication.

3. The key distribution centre (or the KDC)

The most important component of Kerberos is the key distribution centre, which is responsible for the distribution of Kerberos tickets and granting access to the clients to authenticate into the server machines to access the desired service(s). In an Active Directory environment, the secret key distribution centre is deployed on the Domain Controller. The Kerberos key distribution center is further subdivided into the following two components:

• The Authentication Server (AS):

It is responsible for the initial authentication of users to access the desired service. It grants the users the tickets that they can use to further authenticate themselves with Active Directory to use the desired service.

• The Ticket Granting Server (TGS):

It is responsible for the secondary authentication phase and grants access to the user after verification of the ticket that was issued by the AS.

What are Kerberos tickets?

Kerberos authentication works on the principle of granting access to clients based on the verification of tickets. In the realm of Kerberos, two types of tickets are found:

1. The Ticket Granting Ticket (TGT)

This ticket is first assigned to the client (or user) asking to access a particular service. This ticket is required by the KDC to grant access to the client to authenticate and use the desired service. The TGT is issued by the Authentication Server.

2. The Service Granting Ticket or Service Ticket (ST)

The ST is required during the second phase of the Kerberos authentication method. This ticket is used to verify that the client requesting access to a particular service has permission to access and use that service.

What is a service and what are service principal names (SPNs)?

In an Active Directory environment, service is anything that is shared and can be accessed and used by the nodes of the AD. It can be a network file share, a printing service, a web server, a file server etc. The same service can run on multiple hosts within the AD, but each service must have a specific and unique identifier for its host. This unique identifier is called a Service Principal Name or an SPN. When a user wants to connect to and use a service, they must first provide the SPN at the time of authentication.

According to Microsoft:

“A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.”

How does Kerberos authentication work?

The entire Kerberos authentication process follows two authentication phases:

Initial authentication

The user logs onto his workstation and enters his user ID and password into the client application for the service he desires to access. The application encrypts a timestamp with the secret keys (user’s password) and sends it to the AS, along with the UID. The AS looks for the password in its principal database that matches the UID and decrypts the received encrypted timestamp using the password. It then generates a Ticket Granting Ticket (TGT) and encrypts it using the secret key, and sends it back to the user’s workstation. The encrypted TGT consists of the actual TGT and the session key. The client application upon receiving decrypts it using the secret key, i.e. user password. The user now has the TGT, and he can further authenticate himself with the TGS and get access to the desired service.

Secondary authentication

After receiving the TGT, the client application server sends the TGT over to the TGS along with the Service Principal Name (SPN) for the service that the user wants to access, to get the Service Granting Ticket (ST). The TGS verifies the TGT with the AS for active sessions, and after verification sends the ST to the client application server. The AS then generates a TGT containing the client ID, client network address, timestamp, lifetime, and SK1. The application of the client sends the ST to the service application running on the windows server, the server verifies the ST with the TGS and after verification grants access to the user to access the desired service.

Part 2: Hacking Kerberos – Attacks on the Kerberos protocol

Just like every other system, service, or anything connected to the internet, the Kerberos protocol is also prone to some attacks. This does not mean that the Kerberos protocol is vulnerable itself, but some misconfigurations in its implementation and abuse of the legit functionality within the protocol make it a target for attackers.

In this part of the blog, we will discuss some basic attacks and their mitigations on the Kerberos.

User enumeration

Since Kerberos is one of the authentication protocols, it is possible to brute-force it for valid users in an Active Directory environment. Kerberos does not produce a generic message for a failed user login attempt, instead tells you whether you are using a correct username but an incorrect password, hence making username enumeration possible.

AS-REP Roasting (Steal or forge Kerberos tickets)

MITRE ATT&CK reference:

• Tactic: Credential Access
• ID: T1558.004
• Platform: Windows
• Required privileges: A regular user in the network

A common misconfiguration in a windows domain-joined network is that some accounts are specifically set to not require pre-authentication, i.e. Accounts Do not Require Pre-Authentication or DONT_REQ_PREAUTH.

Kerberos pre-authentication is the first step to protect against password brute-forcing attacks.

If Kerberos pre-authentication is not set, then an attacker can simply query the KDC for a TGT for a user that has an SPN set. Since the TGT is encrypted with the user’s password hash, the attacker will take this ticket off the network and can crack the TGT for a cleartext password.

This type of cyber attack is very simple, as it does not require access to a domain-joined machine or a domain user. Any attacker in the network can request the TGT from the domain. Successful exploitation of the attack involves the following steps:

• An attacker gets a list of users that have pre_auth disabled.
• The attacker requests the domain controller for a TGT for a user that doesn’t require pre_auth.
• Then they dump the TGT from the memory using credential dumping techniques.
• The attacker takes the received TGT off the network, and cracks for a cleartext password.

Detection of AS-REP Roasting

Enabling Audit Kerberos Service Ticket Operations logs TGS requests for service tickets. Specifically, Log IDs 4768 and 4769 shows the service access being requested.

Mitigation against AS-REP Roasting

• Enabling pre-authentication.
• Have strong and complex password policies.
• Enforcing a password rotation policy.
• Enabling Kerberos AES encryption, instead of RC4 where possible.
• Implement the principle of least privileges if having pre_auth disabled is a necessity.

Kerberoasting (or TGS-REP Roasting)

MITRE ATT&CK reference:

• Tactic: Credential Access
• ID: T1558.003
• Platform: Windows
• Required privileges: Valid domain user credentials, or access in the network as a domain user.

Similar to an AS-REP Roasting attack, kerberoasting requires access to the domain-joined network as a domain user or credentials of a domain user.

This attack involves the following steps:

• An attacker identifies Active Directory accounts with Service Principal Names (SPNs) set.
• Attacker requests service tickets for the service accounts using SPN values.
• An attacker uses credential dumping techniques to dump the STs from the memory.
• An attacker takes the received service tickets off the network and cracks them for clear text credentials.

Detection of kerberoasting

Enabling Audit Kerberos Service Ticket Operations logs TGS client requests for service tickets. Specifically, Log IDs 4768 and 4769 shows the service access being requested.

Mitigation against kerberoasting

• Have strong and complex password policies.
• Enforcing a password rotation policy.
• Enabling Kerberos AES encryption, instead of RC4 where possible.
• Implement the principle of least privileges when setting SPNs to a domain account.

Pass the ticket

MITRE ATT&CK reference:

• Tactic: Lateral movement
• ID: T1550.003
• Platform: Windows
• Required privileges: Kerberos authentication enabled

Similar to a Pass-the-Hash attack, a pass-the-ticket uses Kerberos tickets (or session key) as an alternate authentication material, to get access to more resources in the network and to increase their foothold and visibility.

Attackers once having access to TGTs or STs may try to pass them to KDC and may get direct access to a service or resource in the domain, from where they can execute more attacks and move laterally or vertically in the network.

Pass the ticket attacks are usually associated with Golden and Silver ticket attacks, explained below:

Silver Ticket

Silver tickets are forged service tickets that are passed in a pass-the-ticket attack. Attackers once getting local admin access to a computer may dump credentials and then use the dumped NTLM hashes to forge a session key (silver ticket), then pass them to Kerberos and get access to more resources or impersonate other users hence increasing their foothold and privileges in the network.

Golden Ticket

A golden ticket is similar to a silver ticket, but here instead of forging a user, service or computer account’s ticket, we forge a ticket for the Kerberos service user itself, i.e. the krbtgt account.

Since the krbtgt account is responsible for all Kerberos related activities, getting access to the krbtgt account would mean taking over Kerberos, and eventually all the services and users in the domain that are managed by Kerberos authentication.

Detection

• Monitor for unusual user authentication.
• Monitor for unusual login session creation.
• Have strong and complex user passwords policies.
• Enforcing a password rotation policy.
• Enabling Kerberos AES encryption, instead of RC4 where possible.

Kerberos is a critical part of the security infrastructure for many organizations. Without it, authentication and authorization would be far more difficult to manage. Security assessments are an important way to identify vulnerabilities in Kerberos deployments and fix them before they can be exploited. This ensures active directory environments are providing safe and secure access to resources.

Schedule a free consultation call to discuss your concerns.