> For the complete documentation index, see [llms.txt](https://dev-angelist.gitbook.io/crtp-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev-angelist.gitbook.io/crtp-notes/readme/network-security-5/2.1.md).
# 7.1 - Kerberos Intro
## What is Kerberos?
Kerberos is an authentication protocol designed to allow two entities to establish a shared secret key securely over an insecure communication channel. Unlike web authentication methods that rely on X.509 digital certificates and public-key cryptography, Kerberos uses a centralized Key Distribution Center (KDC) to authenticate entities and establish session keys. It is based on the Needham-Schroeder Symmetric Key Protocol and is widely used in environments like Active Directory for secure authentication.
Kerberos mitigates several authentication risks, such as replay attacks and credential exposure, by using time-sensitive tickets and strong cryptographic mechanisms. It also enables Single Sign-On (SSO), allowing users to authenticate once and access multiple services without re-entering credentials.
### Key Components of Kerberos
Kerberos authentication involves multiple components, each playing a crucial role in the process.
#### Key Distribution Center (KDC)
The KDC is the central authority that manages authentication and ticket issuance. It consists of two main services:
* **Authentication Server (AS):** Handles initial authentication and issues a Ticket Granting Ticket (TGT) to users upon successful verification.
* **Ticket Granting Server (TGS):** Issues Service Tickets (ST) to users who present a valid TGT, allowing access to specific resources.
The KDC relies on a database containing user credentials and service principal information, ensuring that only legitimate entities receive authentication tokens.
#### Realm
A Kerberos Realm is a logical security boundary where authentication is managed by a specific KDC. In Active Directory, the realm is automatically created when the domain is initialized and is represented in uppercase (e.g., `EXAMPLE.COM` for the `example.com` domain, but it's not mandatory).
To identify the realm of a user, you can use:
```
whoami /upn # Display realm (second part)
klist # Current Kerberos list tickets active in the session
```
We've a Devan's realm name (DEV-ANGELIST.LAB) and 2 tickets: Ticket Granting Ticket (TGT) and Service Ticket (ST) used to connect via LDAP server.
Kerberos realms can establish **trust relationships**, enabling authentication across different domains. Trusts can be **one-way** (only one realm trusts the other) or **two-way** (mutual trust between realms).
#### Principal
A **Kerberos Principal** is a unique identity for which Kerberos can issue tickets. There are different types of principals:
* **User Principal:** Represents an individual user (User Principal Name - UPN).
* **Service Principal:** Identifies a service requiring authentication (e.g., SMB, SQL Server, LDAP).
* **Host Principal:** Represents a computer within a Kerberos realm.
```powershell
whoami /upn # Display User Principal Name (UPN)
```
while the service principal can be obtained using `klist` if there're a Service Ticket (ST): LDAP/CORP-DC.dev-angelist.lab/dev-angelist.lab + @ and kerberos realm name: DEV-ANGELIST.LAB
Each principal has a **secret key** for authentication. Service principals require proper Service Principal Names (SPNs) registered within Active Directory:
```powershell
setspn -L CORP-DC # List SPNs for a machine
setspn -A HTTP/webserver.dev-angelist.lab devan # Assign an SPN to a user Devan
setspn -L devan # List SPNs for Devan user
```
Ticket Granting Ticket (TGT)
The **TGT** is issued by the AS after successful authentication and allows users to request Service Tickets. The TGT is encrypted with the KDC’s secret key and contains:
* User ID
* TGS ID
* Expiration Time
* Ticket Flags (eg. pre\_authent that specify that's the first ticket)
To view a TGT:
```powershell
klist
```
#### Service Ticket (ST)
The **Service Ticket (TGS Ticket)** is granted by the TGS in exchange for a valid TGT. It allows users to access a specific service without entering credentials again. The ST is encrypted with the service’s secret key, ensuring secure access.
### Kerberos Authentication Messages
Kerberos authentication consists of several message exchanges:
#### AS-REQ + AS-REP (Authentication Request & Response)
* **AS-REQ:** Sent by the client to the AS to request a TGT. It may include pre-authentication data, such as:
* `PA-PAC-REQUEST`: Requests a PAC (Privileged Attribute Certificate) for authorization data.
* `PA-ENC-TIMESTAMP`: Contains a timestamp encrypted with the user's password-derived key to prevent replay attacks.
If pre-authentication fails, errors like `KRB5KDC_ERR_PREAUTH_REQUIRED` or `KRB5KRB_AP_ERR_SKEW` (time skew error) may occur.
* **AS-REP:** The AS responds with a TGT and an encrypted session key, which the client decrypts using its long-term key.
#### TGS-REQ + TGS-REP (Service Ticket Request & Response)
* **TGS-REQ:** The client sends the TGT to the TGS, requesting a Service Ticket.
* **TGS-REP:** The TGS verifies the TGT and issues a Service Ticket encrypted with the target service’s secret key.
#### AP-REQ + AP-REP (Application Request & Response)
* **AP-REQ:** The client presents the Service Ticket to the target service for authentication.
* **AP-REP:** If valid, the service grants access, possibly returning an authentication response.
### Mutual Authentication
Kerberos supports mutual authentication, ensuring that both the client and the service verify each other’s identity. This protects against attacks like man-in-the-middle (MITM) by confirming that the service the client is communicating with is legitimate.
### Kerberos attacks
In an Active Directory (AD) environment, "roasting attacks" exploit weaknesses in the Kerberos authentication protocol, allowing attackers to capture tickets encrypted with passwords of users or service accounts.
Kerberos authentication relies on various encrypted tickets, which are generated using long-term secrets derived from user or service passwords. By capturing these tickets, an attacker can attempt to crack them offline to retrieve the plaintext password.
The main roasting techniques include:
* **AS-REP Roasting** – Targeting user accounts that do not require Kerberos preauthentication. ([deep dive here](/crtp-notes/readme/network-security-5/2.1-1.md))
* **Kerberoasting** – Exploiting service accounts with registered Service Principal Names (SPNs). ([deep dive here](/crtp-notes/readme/network-security-5/2.1-2.md))
## Other Resources
* [Kerberos Authentication Hexdump YT](https://www.youtube.com/watch?v=dQz3CMlVYNY\&list=PLJnLaWkc9xRi71Pso26JlvyBkLUOETLjn)
* Kerberos v5 RFC 1510
* Needham–Schroeder protocol
* Kerberos V5 UNIX User's Guide
* Kerberos Authentication Explained | A deep dive
* Kerberos Explained in a Little Too Much Detail
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://dev-angelist.gitbook.io/crtp-notes/readme/network-security-5/2.1.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.