Kerberos

Kerberos is a ticket-based network authentication protocol — the default for Windows Active Directory domains, designed to succeed NTLM. Version 5 is specified in RFC 4120 (July 2005, obsoleting RFC 1510); Microsoft’s implementation extends it with public-key authentication (PKINIT), authorization-data transport (the PAC), and delegation. Rather than sending credentials to every server, a client authenticates once to a Key Distribution Center (KDC) and receives tickets it can present to services. On Windows, the KDC runs on every domain controller and uses the AD DS database as its account store.

Terminology

Term	Meaning
KDC (Key Distribution Center)	Service that issues tickets; comprises the Authentication Service (AS) and Ticket-Granting Service (TGS). AD bundles both into the domain-controller role.
AS (Authentication Service)	Issues Ticket-Granting Tickets after pre-authentication.
TGS (Ticket-Granting Service)	Issues service tickets when presented a valid TGT.
TGT (Ticket-Granting Ticket)	Authentication ticket used to request service tickets. Encrypted with the KDC long-term key — the NT hash of the krbtgt account.
SPN (Service Principal Name)	Identifier binding a service instance to the domain account whose key encrypts its service tickets. Every Kerberoastable service has one.
PAC (Privilege Attribute Certificate)	Microsoft extension carrying the user’s SID, groups, and authorization data inside the ticket.
Session key	Per-session symmetric key issued alongside a ticket; a service expects both ticket and session key before acting.
KDC / Service long-term key	Secret key encrypting a ticket: for TGTs, the krbtgt NT hash; for service tickets, the service account’s key (NT hash under RC4).

Authentication process (Windows domain)

1. Client → AS (“pre-authentication”)

1. AS-REQ — client sends the user ID in cleartext plus a timestamp encrypted with the NT hash of the user’s password (the timestamp defeats replay).
2. AS-REP — if the KDC can decrypt the timestamp with the stored NT hash, it returns:
   • Message A: Client/TGS session key, encrypted with the user’s NT hash
   • Message B: the TGT (PAC + client address + validity + Client/TGS session key), encrypted with the KDC long-term key. The client cannot read Message B.

If pre-authentication is disabled on the account, the KDC returns the AS-REP without verifying the timestamp — this is the entire basis of as-rep-roasting.

2. Client → TGS (service authorization)

1. TGS-REQ — client sends the TGT + target SPN, plus an authenticator (client ID + timestamp) encrypted with the Client/TGS session key.
2. TGS-REP — KDC decrypts the TGT with its long-term key, validates the authenticator, and returns:
   • Message E: the service ticket, encrypted with the service account’s long-term key — the plaintext-crackable artifact behind kerberoasting
   • Message F: Client/Server session key, encrypted with the Client/TGS session key.

The KDC performs no authorization check at this step — any authenticated user may request a ticket for any SPN. That design decision is what makes Kerberoasting possible.

3. Client → service (access)

1. AP-REQ — client presents the service ticket plus a fresh authenticator encrypted with the Client/Server session key.
2. AP-REP — service decrypts the ticket with its own long-term key, validates the authenticator, and (optionally, for mutual authentication) returns the timestamp encrypted with the session key.

Because the service ticket decrypts with the service account’s key, the protocol trusts that only the KDC and that account know the key — the assumption silver tickets violate. And because the KDC trusts a TGT that decrypts with the krbtgt key without re-authenticating the user, a stolen krbtgt hash enables golden tickets.

Kerberos across domain trusts

When a client requests a service in a trusted domain, its own KDC can’t issue the ticket — instead it returns an inter-realm TGT (referral ticket): a TGT for the foreign KDC, encrypted with the trust key, a shared secret held as the key of the trust account (OTHERDOMAIN$) in each domain’s directory. The client presents the referral to the foreign KDC, which decrypts it, trusts the embedded PAC (subject to SID filtering), and issues the service ticket. Trust keys rotate ~every 30 days but not when krbtgt is rotated — which is why forged trust tickets survive golden- ticket remediation. Both krbtgt-based forging and trust-key forging, combined with SID-history injection, are covered in active-directory-trust-pivoting.

Pre-authentication and its weaknesses

The pre-auth step (the encrypted timestamp in the AS-REQ) can be disabled per-account (DONT_REQUIRE_PREAUTH, userAccountControl bit 4194304) — rare today but still found on legacy service accounts. The KDC then returns the AS-REP without verifying anything, the basis of as-rep-roasting. Even with pre-auth enforced, the KDC’s distinct error codes leak whether a username exists — the basis of Kerbrute user enumeration.

Delegation

Microsoft extends Kerberos with delegation so services can impersonate users onward: unconstrained (holds visitors’ TGTs), constrained (S4U2self/S4U2proxy to an allowed-SPN list), and resource-based. Each is abusable — see kerberos-delegation-abuse.

.kirbi files — a note on “ticket” terminology

Tools like Mimikatz and Rubeus dump Kerberos structures as .kirbi files containing both a ticket and its session key. Colloquially called “tickets,” they are really ticket+key bundles — a ticket alone is useless without the matching session key.

Attack surface

Attack	What it abuses	MITRE
kerberoasting	TGS-REP encrypted with service-account key → offline crack	T1558.003
as-rep-roasting	Pre-auth disabled → AS-REP returned without verification → offline crack	T1558.004
golden-and-silver-ticket-attacks	Stolen krbtgt / service-account keys → forged tickets	T1558.001 / .002
Pass-the-ticket	Reuse of a stolen valid ticket/session-key bundle	T1550.003
[[kerbrute	Kerbrute userenum]]	KDC error-code oracle leaks valid usernames via AS-REQ
active-directory-trust-pivoting	Forged referral/golden tickets + SID-history across intra-forest trusts	T1550.003
kerberos-delegation-abuse	S4U extensions let delegation accounts impersonate any user to allowed SPNs	T1558
[[active-directory-certificate-services	AD CS abuse]]	PKINIT: forged/mis-issued certificates authenticate as any principal

Pass-the-ticket’s practical defense is architectural: domain admins should only log into domain controllers and tier-0 assets, never lower-privilege machines where their tickets can be harvested from memory.

Primary tooling: impacket (remote, Linux-friendly, Python) and rubeus (Windows, C#, in-memory). Contrast with ntlm-relay-attacks, which forwards live NTLM authentication rather than cracking or forging Kerberos material. The built-in Windows klist command shows tickets currently in the local cache.

Related

• key-transparency — the same trusted-directory problem, answered with public auditability instead of ticket cryptography

Sources

• RFC 4120 — The Kerberos Network Authentication Service (V5)
• Microsoft Learn — Kerberos authentication overview in Windows Server
• MITRE ATT&CK T1558 — Steal or Forge Kerberos Tickets
• MITRE ATT&CK T1558.001 — Golden Ticket
• MITRE ATT&CK T1558.002 — Silver Ticket
• MITRE ATT&CK T1558.003 — Kerberoasting
• MITRE ATT&CK T1558.004 — AS-REP Roasting
• MITRE ATT&CK T1087.002 — Account Discovery: Domain Account
• MITRE ATT&CK T1649 — Steal or Forge Authentication Certificates
• MITRE ATT&CK T1550.003 — Pass the Ticket
• Wikipedia — Kerberos (protocol)