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.
Kerberos Ticket and Authentication Explained
It works on the basis of tickets and relies on symmetric-key cryptography to ensure secure communication. Here’s a detailed explanation of how Kerberos authentication works.
Principals and Key Distribution Center (KDC)
In Kerberos, each entity (user or service) is known as a principal. The Key Distribution Center (KDC) acts as a trusted third party responsible for authenticating principals and issuing tickets.
The KDC consists of two main components:
- Authentication Server (AS)
- Ticket Granting Server (TGS)
The AS handles initial authentication requests and issues Ticket Granting Tickets (TGTs), while the TGS provides service tickets for accessing specific services.
Ticket Granting Ticket (TGT)
When a client wants to access a service, it first obtains a TGT from the AS. The TGT is a credential that allows the client to request service tickets without repeatedly authenticating with the AS.
Authentication Process
The authentication process begins when a client sends a request to the AS for authentication. This request typically includes the client’s identity and a request for a TGT. The AS verifies the client’s identity, usually by checking the client’s credentials (e.g., password), and if successful, issues a TGT encrypted with the client’s secret key. The client receives the TGT and stores it securely.
Service Ticket Request
When the client needs to access a specific service, it sends a request to the TGS, presenting the TGT obtained in the previous step. The request includes the desired service’s identifier (typically a service principal name) and a timestamp to prevent replay attacks.
Service Ticket Issuance
The TGS verifies the TGT presented by the client. If valid, the TGS issues a Service Ticket (ST) for the requested service. The TGS generates the ST by encrypting it with the service’s secret key, ensuring only the intended service can decrypt and validate the ticket.
Service Authentication
The client presents the ST to the desired service. The service decrypts the ST using its own secret key and verifies the client’s identity and authorization to access the service. If authentication is successful, the service grants access to the client, establishing a secure session for communication.
Session Establishment
Once authentication is successful, the client and service establish a secure session, allowing encrypted communication, often using keys derived from the exchanged tickets.
Ticket Expiration and Renewal
Tickets issued by the KDC have a limited validity period. Clients need to renew their tickets periodically to continue accessing services without authentication.
Overall, Kerberos authentication provides a robust and secure method for authenticating clients and servers in a networked environment, ensuring that only authorized entities can access protected resources. It employs cryptographic techniques and ticket-based authorization to prevent unauthorized access and protect sensitive information.
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.
Kerberos Tickets
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:
% /usr/bin/kinit
Kerberos Attacks
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.
