Tickets, TGTs, the KDC, AS-REQ to TGS-REP, delegation, and every attack you've heard of (Kerberoasting, AS-REP roasting, Golden & Silver, S4U) — built up step by step with motion and diagrams.
Kerberos is a network authentication protocol that lets a user prove who they are to a service without ever sending their password over the wire — using tickets handed out by a trusted third party. In Active Directory, every Domain Controller is that trusted party.
Your password (or rather, a key derived from it) stays on your machine. Only encrypted blobs travel across the network.
Once you've authenticated once, you carry a Ticket Granting Ticket (TGT) and use it to request short-lived service tickets — like an event wristband.
Both client and server can prove their identity to each other in the same exchange. No more "did I really connect to the real server?"
Kerberos is named after the three-headed dog from Greek mythology — and the protocol has three roles to match. In Active Directory, the KDC role lives on every Domain Controller.
alice@CONTOSO.COM. Holds a long-term key derived from the user's password.
cifs/fs01.contoso.com. Has its own long-term key.
The AS handles initial authentication: takes your password proof and hands you a TGT.
The TGS handles ongoing requests: takes your TGT and hands you tickets for individual services. Both run in the same process on a Windows DC, but conceptually they're separate.
Anything Kerberos can authenticate — a user, a computer, or a service. Each principal has a long-term secret (a hash, technically) that the KDC also knows. That shared secret is the foundation of every ticket exchange.
Unlike TLS or AD certificates, classic Kerberos is built almost entirely on symmetric crypto: each principal shares a secret key with the KDC, and the KDC uses that as glue to introduce parties to each other. Modern Kerberos adds optional asymmetric extensions (PKINIT for smart cards), but the core flow is symmetric.
One key, used to both encrypt and decrypt. The KDC and the principal each hold the same key. Fast, but it means the KDC literally knows everyone's keys — protect that database.
Used for: every ticket, every authenticator, every session key in vanilla Kerberos.
Public/private key pairs — used for smart-card and certificate-based logon. The user proves possession of a private key (on a smart card, TPM, or virtual smart card) and the KDC validates the matching cert.
Used for: smart card logon, Windows Hello for Business, Azure AD-joined hybrid scenarios.
Kerberos doesn't store or transmit passwords. It stores a key derived from the password through a one-way function. For modern AES enctypes, that derivation uses PBKDF2 with the realm and username as salt.
This long-term key (and never the password itself) is what the workstation holds in memory and what the KDC has stored. Kerberos exchanges then use this key to encrypt the very first piece of evidence the user is who they claim to be.
There are six messages in a complete Kerberos exchange. Step through them with the buttons below.
AS-REQ to the KDC saying "I am alice@CONTOSO.COM and I want to talk to krbtgt/CONTOSO.COM." It includes a pre-authentication blob: the current timestamp encrypted with Alice's long-term key. If she typed the wrong password, this blob won't decrypt and the KDC rejects her.
A Kerberos ticket has two parts: a section the service can read, and a section only the client can read. Same blob, two different decryption keys. This split is the core trick that lets a third party introduce two strangers.
The Privilege Attribute Certificate is a Microsoft extension stuffed into every AD ticket. It carries the user's SID, all of their group SIDs, and other authorization data — signed by the KDC. The service trusts it without re-querying AD on every request. PAC vulnerabilities (sAMAccountName spoofing, CVE-2021-42278/42287) live here.
A small structure containing the client's name and the current time, encrypted with the session key. The service decrypts it using the session key (which was inside the ticket) and checks that the timestamp is within ~5 minutes. If it is, the client has proven they actually possess the session key — not just a stolen ticket from yesterday.
This is what klist, Rubeus describe, or Wireshark with a session key would show you. Edit the fields and see the decoded ticket update.
These are the fields a TGS would populate.
Kerberos supports a menu of cipher suites. Choosing the wrong one (or letting the KDC fall back to it) is one of the most common AD weaknesses pentesters find.
| EncType (etype) | Algorithm | Status | Notes |
|---|---|---|---|
1, 3 — DES-CBC |
DES + CRC / MD5 | Disabled | Removed in modern Windows. If you find it enabled, that itself is a finding. |
23 — RC4-HMAC |
RC4 + HMAC-MD5 | Deprecated | Key is the user's NTLM hash. Tickets crackable offline (Kerberoasting). Disable wherever possible. |
17 — AES128-CTS-HMAC-SHA1 |
AES-128 CTS + SHA-1 | Acceptable | Modern default. Key derived via PBKDF2. |
18 — AES256-CTS-HMAC-SHA1 |
AES-256 CTS + SHA-1 | Preferred | Strongest widely-supported option. Should be the only one used in modern AD. |
19, 20 — AES-SHA2 |
AES + SHA-256/384 | Emerging | Added in newer Windows / MIT Kerberos. Not yet ubiquitous in AD. |
When a service ticket is encrypted with RC4-HMAC, the encryption key is the service account's NTLM hash. Anyone with a valid TGT can request that ticket, take the encrypted blob offline, and brute-force the password by guessing & encrypting candidate hashes until one matches. That's Kerberoasting in one paragraph.
On user / computer / gMSA accounts, set msDS-SupportedEncryptionTypes to allow only 0x18 (AES128 + AES256) and not 0x17 (RC4). Domain-wide, set the GPO "Network security: Configure encryption types allowed for Kerberos". Watch for breakage with old Linux/Java clients first.
Sometimes a frontend service (a web app, say) needs to access a backend service (SQL Server) as the user, not as itself. Kerberos handles this through three flavors of delegation — each with very different attack surface.
alice@contoso
trusted for delegation
sees alice, not webapp
The frontend gets a copy of the user's TGT and can request tickets for anything, anywhere, on the user's behalf. If a Domain Admin ever connects to a server with this flag, their TGT sits in that server's memory — ripe for theft. Should not exist in 2026 networks.
The frontend is told which services it can delegate to (a list on its AD object). Better, but still trust-based: an attacker who controls the frontend account can hop to anything in the allowed list as any user.
The backend says "I'll accept delegation from these accounts" — flipping who's in control. Configured via msDS-AllowedToActOnBehalfOfOtherIdentity. Still abusable: if you can write to that attribute on a target, you can pivot.
msDS-AllowedToDelegateTo list, sees sql/backend, issues the ticket.If you've spent time on Hack The Box, Proving Grounds, or pentest engagements against AD, you've met these. Every one of them exploits a specific design choice in the protocol or a misconfiguration on top of it.
Some accounts have "Do not require Kerberos pre-authentication" set. Without pre-auth, anyone can ask the KDC for an AS-REP for that account — and the AS-REP contains a blob encrypted with the user's password-derived key.
DONT_REQUIRE_PREAUTH. Audit accounts where it's set. Use a long passphrase if it's truly required (rare).Any authenticated user can request service tickets for any SPN in the domain. If the service runs as a user account (not a managed service account), the ticket is encrypted with that account's password-derived key — crackable offline, especially if RC4 is allowed.
If you have the krbtgt account's hash (typically from a DC compromise), you can forge a TGT for any user, with any group memberships, valid for any duration. Total domain compromise. Persistence mechanism par excellence.
Same idea as Golden, but forged with a service account's hash — producing a TGS for that one service. Stealthier (no KDC interaction) but limited in scope. Often the first step after Kerberoasting cracks an account.
Compromise a server with unconstrained delegation, then coerce a privileged account to authenticate to it (PrinterBug, PetitPotam). The privileged user's TGT lands in your memory — pass-the-ticket onward.
If you have write access to a target computer's msDS-AllowedToActOnBehalfOfOtherIdentity attribute, you can configure your own controlled account as a "trusted delegate" and then S4U2Self / S4U2Proxy your way to arbitrary user impersonation on that target.
msDS-AllowedToActOnBehalfOfOtherIdentity. Remove "Authenticated Users" from the default machine quota (ms-DS-MachineAccountQuota = 0).Tickets are just files (or LSA cache entries). Dump them from a compromised host with mimikatz / Rubeus, copy them to your attacker box, inject them into your session, and you're authenticated as the original user — no password needed.
If AD CS is misconfigured, you can pivot from low-priv to TGT-as-anyone via PKINIT. Certify and Certipy enumerate the well-known ESC paths — ESC1 (vulnerable template), ESC8 (NTLM relay to web enrollment), and others.
ENROLLEE_SUPPLIES_SUBJECT, require manager approval, restrict enrollment ACLs). Apply CVE-2022-26923 patches (strong cert mapping). Audit with Certify / Locksmith.Kerberos in AD is a 30-year-old protocol carrying every authentication in the enterprise. You can't replace it overnight, but you can shrink the attack surface dramatically.
Set the "Configure encryption types allowed for Kerberos" GPO to allow only AES128 + AES256 + Future. Set msDS-SupportedEncryptionTypes = 0x18 on accounts. Hunt for 4769 events with TicketEncryptionType=0x17.
gMSAs have 240-byte randomly-generated passwords that the KDC rotates automatically every 30 days. They're the cure for Kerberoasting. Convert standard service accounts wherever the application supports it.
The krbtgt account signs every TGT — if its hash leaks, every TGT in your domain forever is forgeable. Rotate the password (twice, 24h apart) on a schedule and immediately after any tier-0 incident.
Members get: no NTLM, no RC4, no DES, no unconstrained delegation as a target, 4-hour TGT lifetime (no renew), no cached creds. The right place for tier-0 admins.
Run Get-ADComputer -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=524288)" — anything that comes back is a coercion target. Replace with constrained or RBCD.
Tier-0 (DCs, AD CS, ADFS) admins log on only to tier-0. They never RDP into a workstation, never read email on their admin account. This single control would have prevented most Golden Ticket attacks.
| Event ID | What it means | Why you care |
|---|---|---|
4768 |
TGT requested (AS-REQ) | RC4 etype = AS-REP roasting target. No pre-auth = misconfigured account. |
4769 |
Service ticket requested (TGS-REQ) | RC4 etype on a non-machine SPN = Kerberoasting attempt. Anomalous SPN = recon. |
4770 |
TGT renewed | Tickets renewed beyond max lifetime = forgery. |
4771 |
Pre-auth failure | Spray attacks, bad-passwords-from-script. |
4624 / 4634 |
Logon / logoff | LogonType=3 from unexpected hosts, especially with Authentication Package=Kerberos. |
4742 |
Computer account changed | Sudden delegation flag changes = RBCD abuse. |
If you've ever logged into a Windows machine joined to a domain, you've already used Kerberos. Here's where else it shows up.
The first thing winlogon does after you press Ctrl+Alt+Del — an AS-REQ to the nearest DC.
Connecting to \\fileserver\share triggers a TGS-REQ for cifs/fileserver.
Trusted/Integrated SQL connections use Kerberos for MSSQLSvc/host:port SPNs.
Domain joins, Group Policy fetch, AD admin tools — all over Kerberos-bound LDAP.
Outlook authenticates to Exchange via Kerberos when on the corporate network (Modern Auth elsewhere).
NLA-protected RDP uses Kerberos to pre-authenticate before the desktop session is ever created.
IIS & reverse proxies use SPNEGO/Kerberos for transparent SSO to intranet apps.
PKINIT extension — the user's smart card cert validates instead of a password during AS-REQ.
Tickets get re-signed by referral KDCs as you cross trust boundaries — the basis of multi-domain SSO.
Terms you'll see in MS-KILE, klist output, Wireshark dissectors, and incident reports.
http/web01.contoso.com.alice@contoso.com.