Kerberos Certification
It's a clichéd topic, and we always see parsing of the Kerberos authentication process on a variety of platforms. So instead of going into excessive depth on the concept here, in this post I will just list the key authentication steps to help understand the concepts that follow.
The Kerberos authentication process can be simplified into the following key steps:
1. Client request TGT (Ticket Granting Ticket)
- move: The client sends a request to the Kerberos Authentication Server (AS) containing user identity information
- goal: Obtain TGT for subsequent requests for service tickets
2. Obtain TGT and Session Key
- move: The AS returns the encrypted TGT and Session Key to the client.
- goal: Client obtains TGT and session key for communication with TGS
3. Client request for a service ticket (Service Ticket)
- move: The client sends a request to the TGS containing information about the TGT and the service to be accessed
- goal: Get tickets to access specific services
4. Obtaining service tickets
- move: The TGS returns the encrypted service ticket and the new session key to the client
- goal: The client obtains a service ticket and session key for communicating with the target service
5. Client access to target services
- move: The client sends the service ticket previously obtained from the TGS to the target service
- goal: Prove your identity and authority to the target service
6. Targeted service validation tickets
- move: Targeted services to validate tickets
- goal: Confirm that the client is entitled to access the service and establish secure communications
The steps as above can be visualised in a simple diagram:
Kerberos Rely
The concept of Kerberos Relay (Kerberos Relay) is not complicated. The core idea is to forward AP_REQ messages initiated by a client to one service to another service.
This attack has one crucial prerequisite: the target service as well as the client cannot enable a forced encryption or signing mechanism, such as LDAPS or LDAP Signing.
The reason for this is that we do not have access to the session keys needed to perform these operations. This is similar to the NTLM Relay is very similar because in NTLM relay, the attacker is also unable to directly process encrypted or signed data.
One more point to note:AP_REQ Messages cannot be relayed to a different service running under a different identity than the one originally requested by the client. Therefore, in order for the attack to be successful, we need to force the client to generate an AP_REQ and send it to us.
" Kerberos relay was once thought to be impossible, but multiple researchers have since proven otherwise."