Kerberos is the default authentication protocol in Active Directory, and it is the one that matters most offensively — Kerberoasting, AS-REP roasting, delegation abuse, and every ticket-forging attack are all abuses of some step in its exchange. Understanding the protocol flow is not optional background; it is the thing that tells you why each of those attacks is possible and what the tools are actually doing.
The core idea
Kerberos exists to solve one problem: let a user prove who they are to many services without sending their password to any of them, and without each service having to check with a central authority every time. It does this with tickets — time-limited, encrypted proofs of identity issued by a trusted third party.
That trusted third party is the Key Distribution Center (KDC), which runs on every domain controller. It has two logical halves: the Authentication Service (AS), which proves you are you, and the Ticket Granting Service (TGS), which grants you access to specific services. The whole model rests on one assumption: the KDC knows the secret key (derived from the password) of every principal in the domain.
The three exchanges
A Kerberos login is three request/response pairs. Keep the actors straight: the client (the user), the KDC (the DC), and the service (whatever the user wants to reach).
| Exchange | Purpose |
|---|---|
| AS-REQ / AS-REP | The user authenticates to the KDC and receives a Ticket Granting Ticket (TGT) |
| TGS-REQ / TGS-REP | The user presents the TGT to ask for a ticket to a specific service |
| AP-REQ / AP-REP | The user presents the service ticket to the service itself and is granted access |
Step 1 — AS-REQ / AS-REP (getting the TGT)
The client sends an AS-REQ to the KDC. Crucially, it includes a pre-authentication component: a timestamp encrypted with the user's own key (derived from their password). The KDC decrypts it with its copy of that key; if the timestamp comes out sensible, the user has proven they know the password without the password ever being sent.
The KDC responds with two things: a TGT, encrypted with the
secret key of the special krbtgt account (which only the KDC knows),
and a session key for the user, encrypted with the user's own
key. The user can read their session key but cannot read the TGT — it is opaque
to them, which is the point.
Two attacks live in this one step. If pre-authentication is disabled for
an account, anyone can request an AS-REP for it and receive material encrypted
with that account's key — crackable offline. That is
AS-REP roasting. And because the
TGT is encrypted with the krbtgt key, anyone who steals that key can
forge TGTs for anyone, forever — the Golden
Ticket.
Step 2 — TGS-REQ / TGS-REP (getting a service ticket)
Now the user wants to reach a service — say the file share on
SRV01. They send a TGS-REQ to the KDC, presenting their TGT as proof
of identity and naming the service they want via its
Service Principal Name (SPN), e.g. cifs/srv01.corp.local.
The KDC validates the TGT (it can, because it holds the krbtgt key),
then issues a service ticket encrypted with the secret key of
the service account that owns that SPN. The user cannot read this ticket
either — it is meant for the service.
This step is the mechanism behind Kerberoasting. Any authenticated user can request a service ticket for any SPN. That ticket is encrypted with the service account's password-derived key — so an attacker requests tickets for service accounts and cracks them offline to recover the passwords. No special privilege required; it is a normal, expected TGS-REQ.
Step 3 — AP-REQ / AP-REP (using the ticket)
Finally the user presents the service ticket directly to the service. The service decrypts it with its own key — which it knows, because the ticket was encrypted for it — reads the user's identity and authorisation data from inside, and grants access. The KDC is not involved at all in this step, which is exactly the efficiency Kerberos was designed for.
The PAC — where authorisation lives
Inside every ticket is a Privilege Attribute Certificate (PAC). This is the structure that carries authorisation data: the user's SID, the SIDs of every group they belong to, and related claims. Authentication proves who you are; the PAC states what you are allowed to do.
The PAC is signed by the KDC so a service can trust it without asking the DC. This is powerful and dangerous in equal measure — a forged ticket with a forged PAC that claims Domain Admin membership will be honoured by any service that trusts the signature, which is the heart of Golden and Silver ticket attacks.
Encryption types matter
Kerberos tickets can be encrypted with different algorithms, and the choice directly affects how crackable a roasted ticket is:
| Etype | Relevance |
|---|---|
| RC4 (etype 23) | Legacy, derived directly from the NT hash. Fast to crack — attackers explicitly request it for roasting |
| AES128 / AES256 (etype 17/18) | Modern default. Much slower to crack; roasting yield drops sharply when only AES is available |
| DES (etype 1/3) | Obsolete and broken; should never appear, but occasionally does on ancient configs |
Tools like Rubeus and Impacket will request RC4 tickets when possible precisely because they crack orders of magnitude faster than AES. A domain that enforces AES-only removes a large amount of roasting value.
Where each attack attaches
| Attack | Step it abuses |
|---|---|
| AS-REP roasting | AS-REP, when pre-auth is disabled |
| Kerberoasting | TGS-REP, cracking the service account key |
| Golden Ticket | Forging a TGT with the stolen krbtgt key |
| Silver Ticket | Forging a service ticket with a stolen service account key |
| Pass-the-Ticket | Reusing a stolen TGT or service ticket directly |
| Overpass-the-Hash | Using an NT hash to request a legitimate TGT |
| Delegation abuse | The rules governing how services request tickets on a user's behalf |
The takeaway
Kerberos is elegant, and its elegance is the attack surface. Tickets are reusable
proof, so stealing them beats attacking passwords. Service tickets are encrypted
with service-account keys, so requesting them hands you crackable material. The
krbtgt key underwrites the entire domain, so stealing it is total and
durable compromise. And the PAC lets a signed ticket assert privilege that
services accept without question.
When you run Rubeus, Impacket, or NetExec against Kerberos, you are not exploiting a flaw — you are participating in the protocol exactly as designed, from a position it did not anticipate. The specific attacks each have their own page: Kerberoasting, AS-REP Roasting, Delegation, and Ticket Attacks.