Many ask, what is Kerberos? Kerberos is an authentication protocol. It is designed for client-server applications and requires mutual verification. It is the default protocol used for logging into a Windows machine that is part of a domain, relies on a secure communication channel between the client and the Domain Controller (DC). Windows updates address security concerns such as vulnerabilities in this channel, ensuring that the user database stored on the DC is protected.
Active Directory (AD) is a component running on the DC that implements the Kerberos account database (containing users and passwords). Kerberos messages are resilient against eavesdropping and replay attacks.
It is important to make sure you manage Kerberos protocol when possible. Since some operations still need to use NTLM, Microsoft hasn’t yet disabled it. The main challenge is finding where you can shift to Kerberos. This hardening task ensures your attack surface is as small as possible. The best approach for this task is using automation. By automating the hardening process and securing your servers you won’t be risking production outages.
This blog post will discuss the basics of Kerberos protocol:
- How Kerberos authentication works
- Kerberos tickets
- Kerberos vulnerabilities
- Kerberos hardening configuration
How Kerberos Authentication Works:
In Kerberos authentication, a client user undergoes client authentication to access network resources through single sign-on (SSO). This process involves the generation of a session key, facilitated by secret key cryptography, ensuring secure communication between the client user and operating systems, thereby enabling efficient access to various network resources without the need for repeated authentication.
Here’s a simplified explanation of Kerberos’s authentication process:
- Client requests access: The client user requests access to a network resource.
- Authentication server (AS): The client sends an authentication request to the Kerberos authentication server (AS).
- Ticket-granting ticket (TGT): The AS verifies the client’s identity and issues a TGT, a ticket that grants access to the ticket-granting service (TGS).
- Ticket-granting service (TGS): The client presents the TGT to the TGS, requesting a service ticket for the specific network resource.
- Service ticket: The TGS issues a service ticket, which includes a session key for communicating with the network resource.
- Resource access: The client presents the service ticket to the network resource, and they establish secure communication using the session key.
Kerberos requires both the server and the client to verify themselves. Suppose a client wants to connect a server. He first must verify himself to a trusted third party- Key Distribution Center (KDC).
What happens inside the KDC?
The KDC includes two servers: 1. An authentication server (AS). 2. Ticket Granting Server (TGS).
When a client wants to verify himself to the KDC, he first connects with the AS. He presents to the AS his User ID, and requests a ticket to the targeted server. This request is partially encrypted with his password’s secret key (so that a plain password won’t be sent over an insecure network). The AS uses the client’s password to decrypt his request. This is how the AS verifies the user.
After verifying the client, the AS sends the client a Ticket Granting Ticket (TGT). The TGT is encrypted with a different secret key.
After the client gets the TGT, he sends it to the TGS along with his request to access the target server. When the TGS receives the TGT, it decrypts it with a secret key that he shares with the AS. The TGS issues a token for the client, that it encrypts with another key. This third key is shared between the TGS and the targeted server.
Finally, the client sends the token to the client-server. The targeted server will decrypt the token with the TGS shared key. Now the client can use the targeted server for a limited time (which is set by the token).
The Kerberos authentication process uses three different secret keys.
1. The first key between the client and the AS is based on the client’s password.
2. The AS and the TGS share another secret key.
3. The TGS and the targeted server.
As mentioned in the previous section, the client requested and granted a ticket. This method is common and used in other programs such as Secure Shell (SSH).
How to check and delete Kerberos tickets:
To view or delete Kerberos tickets you can use the Kerberos List (Klist.exe). The Klist.exe is a command-line tool you can find in the Kerberos resource kit. You can only use it to check and delete tickets from the current logon session.
If you wish to use it your computer must be a member of a Kerberos realm. The Klist.exe uses the following syntax:
klist \[tickets | tgt | purge\] \[-?\]
We recommend destroying your Kerberos tickets after your use. To do that, you can add the kdestroy command to your .logout file.
How to create a Kerberos ticket:
Some scenarios may require you to create. For example, when your ticket expires. To create a ticket using the ‘kinit’ command:
Kerberos was aiming to present a more secure alternative to other authentication protocols. But due to its popularity, hackers have developed ways to crack it. Here are three iconic Kerberos vulnerabilities:
1.) Kerberos Golden Ticket attack:
Kerberos Golden Ticket is the authentication token for the KRBTGT account. The KRBTGT is a hidden account responsible for encrypting all the authentication tokens for the DC. The Golden Ticket forges the TGT. An attacker can use this Golden Ticket with a Pass-the-Hash attack to move around the network.
2.) Kerberos Silver Ticket Attack:
Silver Tickets are services that forge the Kerberos Ticket Granting Services. That means that they have no communication with the DC. The Silver Ticket’s scope is limited to the specific service it is targeting on a specific server. Although its scope is smaller than the Golden Ticket, the Silver Ticket attack is still powerful. It enables persistence and stealthy access to resources.
3.) DCShadow attack:
This attack uses a feature in Mimikatz to simulate DC behavior. This allows the attacker to inject its own data. The attacker first has to hack into an account with DC credentials to push the data. It is very hard to detect this kind of attack.
Kerberos Hardening Configuration:
To minimize Kerberos attack surface there are several baseline hardening actions that you should take:
1. Make sure you use efficient encryption
2. Audit Authentication Service
3. Audit Service Ticket Operations
4. Ensure ‘Support device authentication using certificate’ is set to ‘Enabled: Automatic’
To make sure you don’t miss anything, we recommend using hardening automation when securing Kerberos configurations. Using server hardening automation can help you lower the risk for attacks. CalCom Hardening Suite is the perfect tool for this job.