What is Kerberos?

Kerberos is the default authentication protocol in modern Windows Active Directory environments.

It’s like a digital passport system:

• Instead of entering your username and password every time you want to access a file or system, Kerberos issues tickets that prove you’re allowed to be there.
• It’s faster, more secure, and more efficient than retyping credentials every time.

The Core Players in Kerberos

Let’s introduce the main characters:

Role	Description
Client	The user’s computer
User	You, logging in
Service	What you want to access (e.g., file share, SQL server)
KDC (Key Distribution Center)	The brain — a component of the Domain Controller
TGT (Ticket Granting Ticket)	Your passport to ask for access
TGS (Ticket Granting Service)	The visa to enter each service
SPN (Service Principal Name)	The identity of the service you’re trying to reach

How Kerberos Works (Step-by-Step)

Let’s break it into three phases:

Phase 1: Authentication (Getting the Passport – TGT)

1. You log in to your domain-joined computer as osiris@corp.local.
2. The computer sends an AS-REQ (Authentication Service Request) to the KDC on the Domain Controller.
   • It says: “Hey, I’m osiris, can I get a TGT?”
3. The KDC looks you up in AD, sees you’re real, and replies with an AS-REP:
   • It contains the TGT (Ticket Granting Ticket), encrypted with your password hash (specifically, your NTLM hash or Kerberos key).
4. Your system uses your password (which you just typed) to decrypt the response.
   • If it works, you now have a valid TGT, and you’re officially “logged in” to the domain.

TGT is like your passport — you’ll use it to ask for access to services without re-entering your credentials.

Phase 2: Service Ticket Request (Getting a Visa – TGS)

5. You now want to access a service, e.g., \\fileserver\confidential.
6. Your computer sends a TGS-REQ (Ticket Granting Service Request) to the KDC:
   • It includes your TGT and a request for a ticket to cifs/fileserver.corp.local.
7. The KDC checks:
   • Is your TGT still valid?
   • Does the service exist (via its SPN)?
   • Are you allowed to access it?
8. If all checks out, the KDC sends back a TGS-REP, which contains:
   • A service ticket, encrypted with the service account’s secret key (password hash)

📝 This service ticket is like a visa for that specific destination (e.g., CIFS service on the file server).

Phase 3: Accessing the Service

9. You now send that service ticket to the file server.
   • The server decrypts the ticket using its own password hash (since it knows it’s the rightful owner).
10. The file server says: “Cool, this is valid — welcome in!”

You now have access to the shared folder — without typing your password again.

Does the DC Check Permissions Before Granting a Service Ticket?

Yes. When you request a service ticket, the KDC will check your group memberships and access permissions.

• If you’re authorized, it gives you the ticket.
• If you’re not, it denies the request — no ticket is issued.
• This is how access control is enforced centrally by the domain controller.

Can Any Domain User Request a Service Ticket?

Yes — any authenticated domain user can request a service ticket for any SPN that exists in Active Directory.

That’s how Kerberoasting works:

• A low-privileged user can request tickets for service accounts with SPNs.
• Those tickets are encrypted with the service account’s NTLM hash.
• The attacker captures that ticket and cracks it offline to recover the service account’s password.

This is why just having an SPN makes a service account a target — it’s enough to request a ticket and start cracking.

Where SPNs Fit In

A Service Principal Name (SPN) is what identifies a service on the network. It’s what the client uses when asking the KDC:

“Hey, I need access to this service — can I get a ticket for it?”

SPNs look like:

MSSQLSvc/db01.domain.local:1433
HTTP/webserver.domain.local
CIFS/fileserver.domain.local

Each SPN is registered to a user or computer account in Active Directory.

Summary: End-to-End Flow

1. User logs in → Gets TGT from KDC
2. Wants access to a service → Sends TGT + SPN request to KDC
3. KDC checks if user is allowed
   - ✅ If allowed → Sends Service Ticket (TGS)
   - ❌ If denied → No ticket issued
4. Client sends Service Ticket to service
5. Service decrypts it → Grants access

Real-World Pentesting Relevance

Now let’s flip the table to your side:

Attack/Technique	Description
AS-REP Roasting	If an account doesn’t require pre-auth, you can request an AS-REP and crack the response offline.
Kerberoasting	If a service has an SPN, you can request a TGS and crack the service account’s hash offline.
Pass-the-Ticket	If you steal a TGT or service ticket, you can reuse it to impersonate a user without knowing their password.
Golden Ticket	Forge your own TGTs by compromising the KRBTGT account. You now control the whole domain.
Silver Ticket	Forge a TGS ticket directly to a service — you don’t even need the DC for that one.

Kerberos Cheat Sheet (Pentester’s Edition)

Action	Tool	Command
Request SPNs	GetUserSPNs.py	GetUserSPNs.py corp.local/osiris:Password123
Kerberoast	Rubeus	Rubeus kerberoast
AS-REP Roast	GetNPUsers.py	GetNPUsers.py corp.local/ -usersfile users.txt -format hashcat
Pass-the-Ticket	Mimikatz	kerberos::ptt ticket.kirbi

TL;DR

• Kerberos is a ticket-based authentication protocol.
• It keeps passwords off the wire by using encrypted tickets.
• It’s efficient, secure, and attackable if misconfigured.
• Learn the ticket flow: AS-REQ → TGT → TGS-REQ → Service Ticket → Access