How does Kerberos work - an introduction for beginner.

How does Kerberos work - an introduction for beginner.


6 min read


Kerberos is an authentication protocol that superseded NTLM with the release of Windows 2000 (technically…)


Well… It's complicated 😅

Long story short - NTLM is still alive and kicking and… it might still be the fall-back solution in case Kerberos does not work. 😵

With that in mind let's talk about the moving parts in Kerberos and look at some wireshark pcaps.

This is Kerberos Authentication in a nutshell 🥜




That's not really explaining it though, is it?!

Ok ok, you are right. Let's try to figure out what those words??? letters! mean..

Kerberos Tickets 101

Kerberos comes from the Greek Cerberus - the three-headed guard dog of the underworld.

We don’t judge and love all puppies 🐶

This particular one has an affinity for tickets.

F*CK balls and toys, it only likes tickets.

When thinking about tickets, the first thing that comes to our heads is:

theme park!!! 🎉

In order to go into a theme park you need a ticket - the ACCESS ticket

But sometimes, you also need separate tickets to take rides inside the theme park - the ride tickets.

Usually, there is a booth at the entrance of the park where you pay 💰 and show your ID to prove you are of legal age to enter alone 🐣.

This booth is called the KDC.

KDC - Key Distribution Center

This is the magical 🪄 place that hands out tickets.

The ticket booth consists of two small tents - one checks IDs + gives access tickets (left - AS)

+ The other checks take access tickets + hand out ride tickets (right - TGS).

In the middle is the entrance to the theme park.

AND in front of it all, sits our little puppy wagging its tail.

Wait but why do we need a ticket from the booth if Kerberos had one under its paw?!

Can’t we just steal it?!
And why does it have a different color (golden)?!

Well… I don't know if you are a dog whisperer but for me, this is a big NO NO

I would much rather trade something to get the ticket from mr puppy without hurting myself.

But what does Kerberos like?!


It’s like the cookie monster but instead of cookies 🍪 Kerberos has an unhealthy obsession with tickets 🎫

No steaks, no squeakers, just tickets. get the ticket we need another ticket…


Ticket Granting Tickets

Concerning the colors - We have seen a few different tickets already:

Ticket Granting Ticket (TGT) - access ticket (red)
Ticket Granting Service Ticket - single ride ticket (silver)
Golden Ticket - VIP pass for all rides (golden)

Now how do we combine all of this into the beautiful mess that we saw earlier?
Remember our Wireshark flow?


ok slowly:

AS - Authentication Service - This was the left tent in the KDC picture
REQ - Request
REP - Response

OHHHHH, that makes sense 🤯
But WAIT what about the KRB Error?!

YES, good catch 🫴🏉

Look at the Length of the AS-REQ(uest) - it is 300 Bytes and we receive a KRB5KD_ERR_PREAUTH_REQUIRED

This means that the account that we try to authenticate with does not have the “Does not require preauthentication” flag set.

ok sure… WHAT?!!?

There is a (non-default) setting called “Does not require preauthentication” and if that one is set, this account does NOT require preauthentication.

In essence, this means you can request an access ticket (TGT),

WITHOUT the credentials of the user you are requesting it for.


AS-REP Roasting 101

Yeah… there is a technique called AS-REP (GET IT?!?!?!) roasting, which requests an access ticket for users without Kerberos preauth.

Keep in mind - while a TGT gets issued by the DC during AS-REP Roasting, this is not a working TGT that can be used to request ride tickets (TGS) - Thx @exploitph & @filip_dragovic

Back to the Ticket - Why do we want to request a ticket that we know will not be correctly working?

Part of the response is encrypted with the password of the user…


Yes… They can then be used for offline cracking/brute force guessing of the user password. 😈😅

Hacker use a tool called to get a crackable hash like the one below

Long story short - there is a reason why this “option” is not default!

Be careful BEFORE turning this on.

Back to the Error - We send the ID (credentials) of a user to get a personalized access ticket

→ There is a difference of 80 bytes (300 → 380) between the 1st & the 2nd AS-REQ

If all goes well, the KDC responds w/ an AS-REP (Authentication Service Response) with our access ticket 🎟️

Can we see that?!


Ticket Granting Service Tickets

Looking at the AS-REP in Wireshark shows us that there is a section called “Kerberos”

This one holds the AS-REP section → a part called ticket

Another one called cname - the account (CNameString) that requested the ticket (maikroservice), and crealm aka domain (snackempire.home)

The ticket is encrypted and we can see it at the bottom highlighted in blue 💙🙆‍♂️

Wonderful, now we have a Ticket Granting Ticket or as I like to call it “access ticket” 🎟️

For all the defenders and curious people out there:

The request for an access ticket generates an event with ID 4768 on the domain controller.

Our access ticket gives us access 🤓 to the 2nd tent - the Ticket Granting Service (TGS) 🏕️🔑🎪 → ⛺️🎫

We now present said access ticket to the clerk in the 2nd ticket tent and they will ask one question:

Which ride do you want a ticket for?!


Which rides are there?!

Great question!
I have prepared an overview.

These are often called silver- or service tickets but we can think of them as “rollercoaster tickets” or whichever ride you prefer.

Concerning some of the possible services we can ask them for - 👀 ⬇️

Ticket Granting Service Tickets Types (Silver Tickets)

HOST - winrm/PowerShell remoting → remote access

CIFS - file server/psexec → remote access if the share is writeable

HTTP - winrm/PowerShell remoting → remote access

LDAP - remote server administration → remote control


Ooofff... That's a lot.

Ok, slowly!

Ok but what's the process like?!

In Wireshark - in the AS-REP our access ticket is 2da8de0621…

When we now request a ride ticket we send our access ticket in the TGS-REQuest (see below), this is important because it VERIFIES that we are a real user in the domain.

You can see that in our TGS-REQ we send our ticket (cipher) 2da8de0621… which allows the Key Distribution Center to verify that we are who we say we are.

Conceptually, we send our access ticket (TGT) with the name of the requested ride (service) and receive a personalized service/silver/ride ticket back.

This triggers a Windows Security Event #4769 which might be helpful when hunting for hackers 😉

With the ride ticket in hand, we can now access the theme park and specific rides 🎢 or request a new ride ticket with our access ticket 🎟️

In one of the next posts we walk through RDP and what happens on a packet level.

Stay tuned.

Did you find this article valuable?

Support Maik Ro by becoming a sponsor. Any amount is appreciated!